Method and apparatus for handling inter-cell multi-TRP configuration during reconstruction
The method allows UEs to manage inter-cell mTRP configurations during re-establishment, addressing ambiguity and inefficiency by releasing or retaining configurations based on network indications, ensuring smooth re-establishment and reducing signaling overhead.
Patent Information
- Application Number
- CN202411409513.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2021-10-14
- Filing Date
- 2022-10-14
- Publication Date
- 2024-12-13
- Estimated Expiration
- Not applicable · inactive patent
AI Technical Summary
During the re-establishment process in wireless communication, UEs configured with inter-cell multi-TRP configurations face ambiguity and inefficiency due to the deletion of dedicated configurations, leading to unnecessary measurements and potential conflicts when re-establishing connections, especially in scenarios where the target cell may not support inter-cell mTRP operation.
A method for UEs to release or retain inter-cell mTRP configurations during re-establishment, with network nodes providing corresponding indications to avoid ambiguity and optimize signaling by ensuring consistent configuration management.
Prevents reconfiguration failures and reduces overhead by eliminating ambiguity regarding UE behavior, allowing seamless re-establishment and efficient inter-cell mTRP configuration management.
Smart Images

Figure CN119136339A_ABST
Abstract
Description
[0001] This application is a divisional application of the Chinese national phase application (application number 202280069169.5) of the PCT international application with application number PCT / IB2022 / 059876 and titled “Methods and apparatuses for handling of inter-cell multi-TRP configurations during re-establishment” filed on October 14, 2022. Related Applications
[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 255,674, entitled “Handling of inter-cell multi-TRP configurations during re-establishment,” filed in the U.S. Patent and Trademark Office on October 14, 2021, the contents of which are incorporated herein by reference. Technical Field
[0003] The present application relates to the field of wireless communications, and in particular to a method and apparatus for processing multiple TRP configurations between cells during reconstruction. Background Art
[0004] Radio Resource Control (RRC) Reestablishment Procedure
[0005] The re-establishment procedure is an RRC procedure defined in Section 5.3.7 of the 3rd Generation Partnership Project (3GPP) Technical Specification (TS) 38.331 for New Radio (NR) (and summarized in Section 9.2.3.3 of 3GPP TS 38.300). A user equipment (UE) in RRC_CONNECTED may initiate a re-establishment procedure to continue the RRC connection when a failure condition occurs (e.g., radio link failure (RLF), reconfiguration failure, integrity check failure). Figure 1 The steps involved in the rebuild process are shown in the figure below:
[0006] Step 1: The UE reestablishes the connection, providing the UE identity (Physical Cell Identity (PCI) + Cell Radio Network Temporary Identity (C-RNTI)) to the gNodeB (gNB) where the reestablishment is triggered. In the case where the reestablishment is triggered due to RLF, the PCI is the identity of the cell selected by the UE after RLF has been declared and while the timer T311 is running.
[0007] Step 2: If the UE context is not available locally, the gNB requests the last serving gNB to provide the UE context data. This context acquisition procedure has been introduced later in Long Term Evolution (LTE) and from the first release of NR.
[0008] Step 3: The last serving gNB provides the UE context data (if upon request, i.e. if not already available at the gNB).
[0009] Step 4 / 4a: The gNB continues with the reestablishment of the RRC connection. This message is sent on the signalling radio bearer (SRB1). Once this reestablishment is complete / ended, the UE sends a response (e.g., RRCReestablishmentComplete message) to the gNB.
[0010] Step 5 / 5a: While the reestablishment process is ongoing, the gNB may perform the reconfiguration to reestablish SRB2 and data radio bearers (DRBs). The UE may acknowledge the reconfiguration by sending a response (e.g., RRCReconfigurationComplete message) to the gNB.
[0011] Step 6 / 7: If the loss of user data buffered in the previous serving gNB should be prevented, the gNB provides the forwarding address and the previous serving gNB provides the sequence number (SN) status to the gNB.
[0012] Step 8 / 9: gNB performs path switching.
[0013] Step 10: The gNB triggers the release of UE resources at the previous serving gNB.
[0014] Further details of UE actions during the re-establishment procedure can be found in the RRC. Some aspects of interest to the present disclosure are i:) handling of stored configurations according to the Master Cell Group (MCG) (e.g. lower layers), ii) cell selection when timer T311 is running when a failure is detected and re-establishment is initiated, and iii) steps after cell selection, such as random access of the target cell with which the UE performs re-establishment.
[0015] Inter-cell multiple transmit receive point (mTRP) in Release (Rel) 17
[0016] RAN2 is currently discussing possible RRC models for configuring inter-cell mTRP (which may also be referred to as inter-cell beam management operation) for Release 17. The options for the RRC model can be summarized as follows:
[0017] 3GPP Option 1: Cell
[0018] In this option / method, TRPs with different PCIs are defined as independent cells. The following aspects are summarized based on [R2-2107948], [R2-2108478], [R2-2108632]:
[0019] - The new cell is always "associated" with the legacy serving cell via inter-cell mTRP operation. In Release 17, the two cells share the same frequency.
[0020] - A secondary TRP cell (Secondary cell) may have the same or different C-RNTI as the associated primary cell (Primary cell).
[0021] -Configuration for adding, modifying and releasing the secondary TRP cell (secondary cell) is done by RRC signaling.
[0022] -Each legacy serving cell (SpCell or SCell) can have an associated secondary TRP cell.
[0023] - When the secondary cell is used for uplink (UL), the Radio Link Management (RLM) shall follow the secondary cell signal (it is for future study whether this is part of the primary cell (legacy serving cell) or as a separate secondary cell RLM).
[0024] There can be different sub-options derived from option 1, such as the following sub-options:
[0025] - Each inter-cell mTRP configuration has its own ServingCellConfig (so the UE is configured with multiple ServingCellConfigs, one for each TRP) and its own ServingCellConfigCommon (so the UE is configured with multiple ServingCellConfigs, one for each TRP);
[0026] - Each inter-cell TRP configuration has its own ServingCellConfig (so the UE is configured with multiple ServingCellConfigs, one for each TRP), but there is a single ServingCellConfigCommon that may be associated with the initial PCell (the PCell to which the UE initially connects and / or performs reconfiguration with synchronization).
[0027] 3GPP Option 2: Bandwidth Part (BWP)
[0028] In this option / approach, TRPs with different PCIs are modeled as additional bandwidth parts (BWPs). The following aspects are summarized based on [R2-2107585] and [R2-2108632]:
[0029] - Different TRPs are configured as different BWPs, and TRP activation / deactivation can be achieved via the BWP switching mechanism.
[0030] - The source cell will retain the common configuration, i.e. the UE will continue to monitor the common channels of the source cell.
[0031] -For TRP with different PCI, it has a complete set of PUCCH / PDCCH / PDSCH / PUSCH (PxxCH) configurations, as well as a complete set of common and dedicated configurations. Switching to TRP with different PCI is based on Layer 1 (L1) signaling.
[0032] 3GPP Option 3: Beam resources (e.g., TCI status, QCL information)
[0033] In this option / method, TRPs with different PCIs are modeled as dedicated resources to enable separate beams, i.e. separate transmission configuration indicator (TCI) status / co-location (QCL) information. Based on [R2-2107906], [R2-2108632], [R2-2108656], [R2-2108807], the following aspects are summarized:
[0034] - Additional Synchronization Signal Block (SSB) sets from non-serving cells (TRPs with different PCIs) are configured within the serving cell configuration and associated with an index. This index can then be used to associate TCI states, channel state information (CSI) measurement configurations, potential UL configurations, etc. with the additional SSB set (PCI).
[0035] -TCI state is also configured in the serving cell configuration, but is assigned an SSB index associated with a different PCI.
[0036] - In inter-cell mTRP operation, a CORESETPoolIndex with a value of 0 is associated with a serving cell, while a CORESETPoolIndex with a value of 1 is associated with a non-serving cell.
[0037] -Except for the physical (PHY) dedicated channels (PxxCH), all other configurations in the BWP can be shared by neighboring cells.
[0038] - The cell specific parameters of the neighboring TRP / cell are shared with the source cell or the neighboring TRP / cell does not require cell specific parameters, e.g. the neighboring cell does not require a Random Access Channel (RACH) and if required, the RACH is triggered by a PDCCH command. It is assumed that the Timing Advance (TA) is always aligned between the source cell and the neighboring cell.
[0039] -SSB related information of non-serving PCI is included in CSI configuration to configure CSI to TRP with different PCI.
[0040] A sub-option derived from option 3 is as follows:
[0041] - Inter-cell mTRP configurations are within a single ServingCellConfig, and even though there may be PCI-specific configurations, there is a single ServingCellConfigCommon.
[0042] 3GPP Option 4: New Structure
[0043] In [R2-2107415], a new option is proposed, where a new information element (IE) (eg, NonServingCellConfig) is defined to include all non-serving cell information (ie, TRPs with different PCIs).
[0044] - Non-serving cell SSB information (at least SSB time domain position, SSB transmission period, SSB transmission power) is required in inter-cell MTRP operation.
[0045] - The PCI of the non-serving cell is included in a new IE (eg, NonServingCellConfig) for the non-serving cell.
[0046] -Introducing an index of non-serving cells with corresponding configuration to be associated with the TCI state.
[0047] These options describe how to organize "the configuration required for using radio resources for data transmission / reception (including resources for different PCIs)" within the UE-specific RRC configuration.
[0048] In options 1 and 2, all physical layer configuration parameters can be set differently between TRPs, while in option 3, most parameters are shared. Option 4 is an Abstract Syntax Notation One (ASN1) encoding specific hybrid that can be consistent with either option 1 or option 3.
[0049] Inter-cell multi-TRP (mTRP) in Release 18 and possible 6G
[0050] In the last Radio Access Network (RAN) plenary meeting, the scope of Release 18 (currently referred to as Advanced 5G) was being discussed. Inter-cell beam management is one of the main topics in the area of mobility enhancement. Although it is not clear which specific solution will be adopted in Release 18 compared to Release 17 inter-cell mTRP, one possible difference is that in Release 17, the UE relies on control channels from a single serving cell, while it may receive data from / send data to other cells (dedicated channels with Transmission Configuration Indicator (TCI) status, whose quasi-co-located (QCL) source is associated with a reference signal (RS) with the PCI of the other cell), in Release 18, it may also use common channels from these other cells. For example, Release 17 may end up modeling inter-cell mTRP as in Option 3, while Release 18 will model inter-cell mTRP as in Option 1. However, these differences may not be fundamental to the present disclosure, i.e., for inter-cell mTRP, the present disclosure can be applicable to Release 17 scenarios, and also to possible Release 18 scenarios.
[0051] In the 5G era, some topics from 4G evolution are proposed in the first 5G release (Release 15). It is also possible that 5G evolution topics (e.g., from advanced 5G) become part of the 6G standard. Inter-cell beam management / inter-cell mTRP is a topic that may attract attention in the 6G era. If one solution is adopted in 5G evolution, another solution may be adopted in 6G.
[0052] Another topic discussed in Release 18 is L1 / Layer 2 (L2)-centric inter-cell mobility. One similarity between inter-cell mTRP and L1 / L2-centric inter-cell mobility is that the UE is configured with multiple cells / PCIs at the same serving frequency. In inter-cell mTRP, the UE can monitor channels on more than one cell (i.e., more than one activated TCI state), where at least one QCL source has an RS of a first cell at the serving frequency of the primary cell (PCell) and at least one QCL source has an RS of a second cell at the serving frequency of the PCell. Summary of the invention
[0053] There are some challenges at present. During the re-establishment process, the UE deletes the dedicated configuration (UE specific) within the spCellConfig (if configured). spCellConfig is the SpCell configuration for the MCG, containing UE specific configuration for operation in the PCell. spCellConfig is part of the MCG configuration (in the CellGroupConfig for the MCG) and includes most of the physical layer configurations in, for example, IE ServingCellConfig (part of spCellConfigDedicated). As defined in RRC (TS 38.331), the IE ServingCellConfig is used to configure (add or modify) a serving cell for the UE. The parameters in this article are mainly UE specific, but are also partially cell specific (for example, in the additionally configured bandwidth section). For example, see below:
[0054]
[0055] In addition, the UE also releases the MCG SCell and Multi-Radio Dual Connectivity (MR-DC), such as the Secondary Cell Group (SCG) configuration (if configured). These configurations will be deleted for the SCell.
[0056] The problem is that with the introduction of inter-cell mTRP in Release 17 and possible extensions in Release 18 (e.g., L1 / L2-centric inter-cell mobility), a UE may be configured with multiple cells / PCIs that have their own per-PCI / per-cell configuration (not in spCellConfig). In fact, for inter-cell mTRP operation, various 3GPP options that are proposed to configure the UE with per-PCI / cell configuration include configurations that are not in spCellConfig, such as Option 1 and Option 4.
[0057] These cells / PCIs will also not be part of the MR-DC configuration and these multiple cells used for inter-cell mTRP will not be SCells. Therefore, upon reestablishment, the UE may remain configured with these L1 neighboring cells (for inter-cell mTRP and / or L1 / L2-centric inter-cell mobility) despite the possibility that the target cell to which the UE is reestablishing may not support inter-cell mTRP operation and / or it does not wish to configure the UE accordingly. Therefore, the UE will likely continue to operate according to the stored inter-cell mTRP configuration and perform unnecessary measurements. Since the reestablishment is triggered by some failure in the UE's operation with the source cell (where the UE is operating according to the inter-cell mTRP configuration), an explicit release from the network to the UE (for explicitly releasing the inter-cell mTRP configuration by receiving an RRC reconfiguration before the reestablishment occurs) is also not possible.
[0058] At the same time, it is not optimal to release the inter-cell mTRP in all cases / scenarios. For example, it is possible that during handover (HO) in the source cell of a UE configured with an inter-cell mTRP, upon HO failure, the UE initiates a re-establishment to a cell for which a UE AS context is prepared and which is able to operate according to the inter-cell mTRP. For example, if the cell is within the same distributed unit (DU), it is likely that at least some of the same cells that were configured for the UE for the inter-cell mTRP in the source cell will be configured, so removing these configurations will waste signaling as some of the same cells will be added again upon re-establishment.
[0059] On the network side, if this solution is adopted, there is also a risk of ambiguity, that is, the network is not clear about which UEs will release the inter-cell mTRP configuration and which UEs will retain the stored inter-cell mTRP configuration.
[0060] Certain aspects of the present disclosure and embodiments thereof may provide solutions to these or other challenges.
[0061] In general, when the UE AS context is obtained and the network needs to reestablish the UE's connection, the embodiments allow the UE to release or retain the stored inter-cell mTRP configuration (the network should also delete or retain the stored configuration) when the UE initiates the reestablishment process to avoid ambiguity with the network.
[0062] In one aspect, a method in a UE for reestablishing a connection with a first network node in the context of an inter-cell mTRP is provided. The method includes: receiving one or more inter-cell mTRP configurations; initiating a reestablishment process with a network node; and in response to initiating the reestablishment process, releasing at least one of the one or more inter-cell mTRP configurations. Another method in a UE is provided. The method includes: receiving one or more inter-cell mTRP configurations; obtaining an indication for the reestablishment process for performing at least one of the following operations: releasing at least one of the one or more inter-cell mTRP configurations, and storing at least one of the one or more inter-cell mTRP configurations; initiating a reestablishment process with a network node; and performing one of the following operations according to the indication obtained: releasing at least one of the one or more inter-cell mTRP configurations, and storing at least one of the one or more inter-cell mTRP configurations. A UE for implementing these methods is also provided.
[0063] On the other hand, a method for reestablishing a connection of a UE in a network node is provided. The method includes: receiving a reestablishment request from a UE configured with one or more inter-cell mTRP configurations; obtaining an indication for performing one of the following operations: releasing at least one of the one or more inter-cell mTRP configurations, and storing at least one of the one or more inter-cell mTRP configurations; and performing one of the following operations according to the indication: releasing at least one of the one or more inter-cell mTRP configurations, and storing at least one of the one or more inter-cell mTRP configurations. A network node for implementing the method is also provided.
[0064] Certain embodiments may provide the following technical advantages.
[0065] Through the embodiments of the present disclosure, when the UE initiates a re-establishment process and attempts to re-establish in a target cell (of the gNB), ambiguity regarding the UE behavior regarding inter-cell mTRP operations can be eliminated.
[0066] For example, when the UE deletes the inter-cell mTRP configuration and the network does the same, the network can add the new inter-cell mTRP configuration in the first RRC reconfiguration after the reestablishment without causing a reconfiguration failure. These failures (which are prevented by the present disclosure) may occur if the network attempts to add a new inter-cell mTRP configuration using a configuration identifier (ID) of a configuration that the UE has not yet deleted. Alternatively, even if the network does not add any inter-cell mTRP configuration and the UE retains its previous inter-cell mTRP configuration, but the network is unaware of the previous inter-cell mTRP configuration (because it was deleted), the UE may search for RSs to perform measurements and not find them (because the network is not sending them) and / or report measurements in resources that the network no longer assumes to be configured for the UE, thereby creating a conflict in the system. Therefore, conflict prevention is another advantage of the present disclosure.
[0067] Embodiments also prevent other issues, such as the network sending a medium access control (MAC) control element (CE) for L1 / L2-centric inter-cell mobility and / or for inter-cell mTRP transmission / reception to a UE that is not configured with inter-cell mTRP and / or inter-cell mobility, which may result in a failure declaration at the UE.
[0068] Since the present disclosure implements a solution associated with the UE storing the inter-cell mTRP configuration between state transitions, the overhead of the inter-cell mTRP configuration over-the-air transmission of the cell in which the UE is reestablishing is reduced. BRIEF DESCRIPTION OF THE DRAWINGS
[0069] Exemplary embodiments will be described in more detail with reference to the following drawings, in which:
[0070] Figure 1 A signal diagram for the reconstruction process is shown.
[0071] Figure 2 An exemplary signal flow diagram is shown for a situation when a UE releases at least one inter-cell mTRP configuration and reestablishes in the last serving gNB according to an embodiment.
[0072] Figure 3 An exemplary signal flow diagram is shown for a case when a UE retains / stores at least one inter-cell mTRP configuration and reestablishes in the last serving gNB according to an embodiment.
[0073] Figure 4 An exemplary signal flow diagram is shown for the case when a UE releases at least one inter-cell mTRP configuration and re-establishes in a cell from a gNB that received the UE context during HO preparation according to an embodiment.
[0074] Figure 5An exemplary signal flow diagram is shown for a situation when a UE releases at least one inter-cell mTRP configuration and reestablishes in a cell from a gNB that is not prepared and is the gNB that releases the inter-cell mTRP configuration from the UE context according to an embodiment.
[0075] Figure 6 An exemplary signal flow diagram according to an embodiment is shown for the following situation: the UE releases at least one inter-cell mTRP configuration and reestablishes in a cell from a gNB that is not prepared, and the last serving gNB releases the inter-cell mTRP configuration from the UE context before providing the UE context to the new gNB.
[0076] Figure 7 An exemplary signal flow diagram is shown for the case when the UE retains / stores at least one inter-cell mTRP configuration and reestablishes in a cell from a gNB that is not prepared according to an embodiment.
[0077] Figure 8 and Fig. 9 A flow chart of a method in a UE according to an embodiment is shown.
[0078] Fig.10 and Fig.11 A flow chart of a method in a network node according to an embodiment is shown.
[0079] Fig.12 An example of a communication system according to an embodiment is shown.
[0080] Fig.13 A schematic diagram of a UE according to an embodiment is shown.
[0081] Fig.14 A schematic diagram of a network node according to an embodiment is shown.
[0082] Fig.15 A block diagram of a host computer is shown.
[0083] Fig.16 A block diagram illustrating a virtualized environment is shown.
[0084] Fig.17 A communication diagram of the host is shown. DETAILED DESCRIPTION
[0085] Some embodiments contemplated herein will now be described more fully with reference to the accompanying drawings.The embodiments are provided merely as examples to convey the scope of the subject matter to those skilled in the art.
[0086] Disclaimer / Definitions
[0087] The term "PCI" corresponds to a cell identifier, such as a cell identifier encoded by one or more synchronization sequences, such as a primary synchronization sequence (PSS) and a secondary synchronization sequence (SSS). An example of a PCI is defined in the NR specification, such as in TS 38.311.
[0088] The terms "TCI state" and "TCI state identification (ID)" are used to refer to the TCI state configuration and TCI state identification / identifier defined in the NR specifications (e.g., TS 38.331 and / or TS38.213). However, the present disclosure also applies to any indication of a downlink (DL) beam (beam indication) that indicates to the UE that it needs to monitor a given RS transmitted in a spatial direction, which may be referred to as a "beam". In the case of a TCI state, it has an associated QCL configuration, which may include an RS configuration.
[0089] The term "beam" as used herein may correspond to an RS transmitted in a given spatial direction. Or vice versa: when describing an RS, it may be an RS that is beamformed, i.e., it may correspond to a beam. For example, a beam or RS may refer to an SS / Physical Broadcast Channel (PBCH) Block (SSB) or a Channel State Information (CSI)-RS of a Layer 3 configuration. Different SSBs may be transmitted in different spatial directions during a half-frame (i.e., using different beams, across the coverage area of the cell). This corresponds to different SSBs meaning different beams.
[0090] The term "UE context" (or UE AS context) includes inter-cell mTRP configuration. It corresponds to any one or a combination of the following items: i) the RRC configuration of the UE for different layers of the protocol stack, such as any parameters or parameter sets that can be included in the RRCReconfiguration, RRCResume, RRCSetup messages defined in TS38.311; and / or ii) parameters with which the UE is configured for operation with the RAN, used to configure layers in the protocol stack, such as the physical (PHY) layer, MAC layer, radio link control (RLC) layer, packet data convergence protocol (PDCP) layer, service data adaptation protocol (SDAP) layer; iii) state variables (e.g., timer values, counter values) for the operation of the UE in the RAN, used to configure layers in the protocol stack, such as the PHY, MAC, RLC1, PDCP and SDAP layers; iv) the security context of the UE, including at least security keys (e.g., KgNB, S-KgNB, integrity protocol keys, encryption keys), security counters (e.g., next hop link counter (NCC), SK counter), security capabilities; v) the capabilities of the UE, e.g., from the perspective of the RAN, referred to as radio capabilities.
[0091] One similarity between inter-cell mTRP and L1 / L2-centric inter-cell mobility is that the UE is configured with multiple cells / PCIs at the same serving frequency. In inter-cell mTRP, the UE can monitor channels on more than one cell (i.e., more than one activated TCI state), where at least one QCL source has an RS of a first cell at the serving frequency of the PCell, and at least one QCL source has an RS of a second cell at the serving frequency of the PCell.
[0092] The disclosed method is implemented in a UE configured with inter-cell mTRP, wherein the inter-cell mTRP configuration may be provided as any option discussed for inter-cell mTRP / inter-cell beam management in Release 17 and may also be applicable to Release 18.
[0093] In general, when the UE initiates a reestablishment process, the method disclosed herein allows the UE to release or retain the stored inter-cell mTRP configuration to avoid ambiguity with the network node. To this end, the network node should take action accordingly, such as deleting / releasing or retaining the stored inter-cell mTRP configuration when the UE AS context is obtained and the network node needs to reestablish the UE's connection. In one example, the UE and the network node may be configured (or determined) to always release or always retain the inter-cell mTRP configuration. In another example, the network node may determine to retain one or more inter-cell mTRP configurations. The network node indicates this to the UE so that both the UE and the network node retain the one or more inter-cell mTRP configurations. The UE may receive a message including such an indication from the network node. In another example, the network node may determine to release one or more inter-cell mTRP configurations. The network node indicates this to the UE so that both the UE and the network node release the one or more inter-cell mTRP configurations. The UE may receive a message including such an indication from the network node. When the UE receives a message including such an indication from the network node, an indication for releasing or retaining one or more inter-cell mTRP configurations may be stored in a UE context associated with the UE.
[0094] Some more detailed examples are provided below with reference to the accompanying drawings.
[0095] For example, Figure 2 A signaling flow diagram 100 of a UE is shown which releases at least one inter-cell mTRP configuration and re-establishes in the last serving gNB.
[0096] In this example, the UE is configured to release one or more inter-cell mTRP configurations when initiating the reestablishment procedure. For example, the UE may release the inter-cell mTRP configurations for all cell candidates for inter-cell mTRP. The network node (e.g., the last serving gNB) may have determined to release one or more inter-cell mTRP configurations and indicated such action to the UE. Alternatively, both the network node and the UE may have decided to release one or more inter-cell mTRP configurations.
[0097] like Figure 2 As shown, first, the UE and the network node (e.g., the previous serving gNB) are connected to each other. The network node stores the UE context in its memory. For example, the UE context includes the inter-cell mTRP configuration.
[0098] When / after the UE declares / detects RLF, the UE initiates the reestablishment procedure (step 105). In step 110, the UE also performs cell selection (e.g., selects a cell in the last serving gNB). In step 115, the UE releases one or more of the inter-cell mTRP configurations. The release can have different timings, such as the UE releasing the inter-cell mTRP configuration when declaring RLF, or releasing the inter-cell mTRP configuration as part of the reestablishment initialization procedure.
[0099] The UE sends an RRC re-establishment request message to the network node (step 120).
[0100] The network node is aware that the UE has deleted (released, discarded) one or more inter-cell mTRP configurations in its inter-cell mTRP configurations. Therefore, after receiving the RRC Reestablishment Request message (e.g., RRCReestablishmentRequest) and after obtaining the UE context from the last serving node in step 125 (e.g., retrieving the UE context from the memory in the case where the UE attempts to reestablish to the cell of the last serving gNB), the target node (e.g., the last serving gNB) with which the UE attempts to reestablish deletes (releases, discards) the one or more inter-cell mTRP configurations from the UE context before possibly deciding to add new inter-cell mTRP configurations. In addition, it should be noted that the source node (e.g., the last serving gNB) that served the UE before the RLF may remove the one or more inter-cell mTRP configurations from the UE context when receiving the UE context acquisition request from the reestablishing node (e.g., the target node). In this case, the UE context received by the reestablishing node no longer has the one or more inter-cell mTRP configurations.
[0101] In step 130, the network node responds to the re-establishment request by sending an RRC re-establishment message to the UE.
[0102] The UE sends a reestablishment complete message to the network node (step 135 ).
[0103] In step 140, the network node may determine to add or not add one or more inter-cell mTRP configurations to the UE.
[0104] In step 145, the network node sends an RRC reconfiguration message to the UE, the RRC reconfiguration message including the added one or more inter-cell mTRP configurations (if so determined in step 140).
[0105] The UE sends a reconfiguration complete message to the network node (step 150).
[0106] Figure 3 An example signaling flow diagram 200 of a UE is shown, which retains (or stores) at least one inter-cell mTRP configuration and reestablishes it in the last serving gNB.
[0107] In this case, the UE is configured to retain (store) at least one of the inter-cell mTRP configurations when initiating the reestablishment procedure. The network node (e.g., the last serving gNB) may have determined to retain one or more inter-cell mTRP configurations and indicated such action to the UE. Alternatively, both the network node and the UE have decided to retain one or more inter-cell mTRP configurations.
[0108] like Figure 3 As shown, first, the UE and the network node (e.g., the last serving gNB) are connected to each other. The network node stores the UE context in its memory. The UE context includes the inter-cell mTRP configuration. In step 205, the UE performs a reestablishment procedure to a cell that is being served by the same network node (e.g., the last serving gNB) as the cell to which the UE was connected before initiating the reestablishment procedure. The UE also performs cell selection (e.g., selecting a cell in the last serving gNB).
[0109] In step 210, the UE retains one or more inter-cell mTRP configurations.
[0110] In step 215, the UE sends a reestablishment request message to the network node.
[0111] When the reestablishing node and the previous serving node are the same, there is no explicit X2 / Xn signaling associated with acquiring the UE context.There may be UE context movement managed via memory in the node, eg, obtaining the UE context from memory (step 220).
[0112] In step 225, the network node responds to the re-establishment request by sending an RRC re-establishment message to the UE.
[0113] In step 230, the UE sends a reestablishment completion message to the network node.
[0114] In step 235, the network node may determine to add one or more inter-cell mTRP configurations and / or release one or more inter-cell mTRP configurations, and / or modify the inter-cell mTRP configuration of the UE. When the reconstructing node (e.g., the network node / target node) knows that the UE has retained (stored) one or more inter-cell mTRP configurations, it may send incremental signaling associated with the new inter-cell mTRP configuration, i.e., it may utilize the RRC reconfiguration message to add / delete / modify the inter-cell mTRP configuration stored at the UE (step 240). In one option, the parameters for inter-cell mTRP may be defined as needed with code M (defined in TS 38.331), which means that upon receiving a message lacking the parameter and having stored the parameter, the UE assumes that the stored parameter is valid and operates accordingly.
[0115] In step 245, the UE sends a reconfiguration complete message to the network node.
[0116] Figure 4 The example signaling flow diagram 300 shows an example signal flow diagram of the case when the UE releases at least one inter-cell mTRP configuration and re-establishes in a cell from a gNB that received the UE context during HO preparation.
[0117] For example, the UE is configured to release at least one of the inter-cell mTRP configurations when initiating the reestablishment procedure. The network node (e.g., source gNB and / or target gNB) may have determined to release one or more inter-cell mTRP configurations and indicated such action to the UE. Alternatively, both the network node and the UE have decided to release one or more inter-cell mTRP configurations.
[0118] The re-established cell (i.e. the cell selected while timer T311 is running which the UE is attempting to re-establish) is served by (belongs to) a network node (e.g. the target gNB) which is the same network node as that associated with the target cell of the HO.
[0119] like Figure 4As shown, first, the UE connects to the source gNB in which the UE context is stored. The UE context includes the inter-cell mTRP configuration. In step 305, the source gNB sends a HO request to the target gNB, and the HO request includes the UE context. Therefore, the target gNB has the UE context including the inter-cell mTRP configuration. In step 310, the target gNB sends a HO request response to the source gNB. In step 315, the source gNB sends an RRC reconfiguration with a HO command to the UE. Then, in step 320, the UE may declare a HO failure (HOF) and then initiate a reestablishment process. In step 325, the UE also performs cell selection (e.g., selects a cell in the target gNB). In step 330, the UE releases one or more inter-cell mTRP configurations. In another example, the UE may release the one or more inter-cell mTRP configurations when declaring the HOF.
[0120] In step 335, the UE sends an RRC re-establishment request to the target gNB. When the network node (target gNB) knows that the UE has deleted one or more inter-cell mTRP configurations, upon receiving the re-establishment request, the re-establishment node (e.g., target gNB) deletes the one or more inter-cell mTRP configurations from the UE context before possibly deciding to add new inter-cell mTRP configurations.
[0121] In step 340, the target gNB sends a reestablishment to the UE in response to the request of step 335.
[0122] In step 345, the UE sends a re-establishment completion message to the target gNB.
[0123] In step 350, the target gNB may determine to add (or not add) one or more inter-cell mTRP configurations for the UE.
[0124] In step 355, the target gNB sends an RRC reconfiguration to the UE (with the added inter-cell mTRP configuration, if so determined in step 350).
[0125] In step 360, the UE sends an RRC reconfiguration complete to the target gNB.
[0126] Figure 5 The signaling flow chart 400 shows that the UE releases at least one inter-cell mTRP configuration and re-establishes in a cell from a gNB that is not prepared but is the gNB that releases the one or more inter-cell mTRP configurations from the UE context.
[0127] For example, the UE is configured to release at least one of the inter-cell mTRP configurations when initiating the reestablishment procedure. The network node (e.g., a different gNB / target gNB or source gNB) may have determined to release one or more inter-cell mTRP configurations and indicated such action to the UE. Alternatively, both the network node and the UE have decided to release one or more inter-cell mTRP configurations.
[0128] The reestablished cell is established by a network node other than the node associated with the target cell of the HO (e.g. Figure 5 different gNBs).
[0129] exist Figure 5 In step 405, the UE first declares HOF, then initiates the reestablishment process and performs cell selection.
[0130] In step 410, the UE releases one or more inter-cell mTRP configurations. However, it is not excluded that the UE releases the one or more inter-cell mTRP configurations immediately when declaring HOF.
[0131] In step 415, the UE sends an RRC re-establishment request to a target gNB that is different from the source gNB (referred to as a different gNB).
[0132] In step 420, the target gNB sends a retrieve UE context request to the source gNB. In response to the request, the source gNB sends a retrieve context response to the target gNB in step 425. The retrieve UE context response includes the UE context including the inter-cell mTRP configuration.
[0133] When a network node (e.g., source gNB or a different gNB) knows that the UE has deleted one or more inter-cell mTRP configurations, upon receiving a re-establishment request and upon receiving a UE context from the source gNB associated with the HO source cell, the re-establishment node deletes the one or more inter-cell mTRP configurations from the UE context before possibly deciding to add new inter-cell mTRP configurations.
[0134] In step 430, the target gNB sends an RRC reestablishment message to the UE.
[0135] In step 435, once the UE is connected to the target gNB, the UE sends a message of RRC re-establishment completion to the target gNB.
[0136] In step 440, the target gNB may determine to add or not add one or more inter-cell mTRP configurations to the inter-cell mTRP configuration of the UE.
[0137] In step 445, the target gNB sends an RRC reconfiguration message to the UE. If it is determined in step 440 to add the inter-cell mTRP configuration, the message includes the added inter-cell mTRP configuration.
[0138] In step 450, the UE sends an RRC reconfiguration complete message to the target gNB in response to the message in step 445.
[0139] Figure 6 The example signaling flow diagram 500 shows that a UE releases at least one inter-cell mTRP configuration and re-establishes in a cell from a gNB that is not prepared and that is the last serving gNB that released at least one inter-cell mTRP configuration from the UE context before providing the UE context to a new gNB.
[0140] In this case, for example, the UE is configured to release at least one of the inter-cell mTRP configurations when initiating the reestablishment procedure. The network node (e.g., a different gNB / target gNB or source gNB) may have determined to release one or more inter-cell mTRP configurations and indicated such action to the UE. Alternatively, both the network node and the UE have decided to release one or more inter-cell mTRP configurations.
[0141] Reestablishing a cell may be performed by a network node (e.g. Figure 6 The HO target cell is served by a network node (referred to as a different gNB) that is different from the network node associated with the HO target cell.
[0142] It should be noted that the signaling 500 flow chart indicates the following UE process: the UE initially declares HOF, then initiates the reestablishment process, and then releases the at least one inter-cell mTRP configuration. However, this should be regarded as an example, i.e., it is not excluded that the UE releases the inter-cell mTRP configuration immediately when declaring HOF. Therefore, the first few steps (505 to 520) are similar to Figure 5 Steps 405 to 420.
[0143] When the network node (e.g., source gNB, different gNB, target gNB) knows that the UE has deleted one or more inter-cell mTRP configurations, upon receiving the reestablishment request, the reestablishment node (e.g., different gNB) sends a UE context retrieval request to the source node of the HO (e.g., source gNB). When the source node serving the UE knows that the UE has deleted one or more inter-cell mTRP configurations, it removes the inter-cell mTRP configurations from the UE context upon receiving the UE context acquisition request from the reestablishment node. In this case, the UE context received by the reestablishment node in step 530 no longer has the one or more inter-cell mTRP configurations. The reestablishment node stores the received UE context.
[0144] Steps 535 to 550 are similar to steps 430 , 435 , 445 , and 450 .
[0145] Figure 7 The example signaling flow diagram 600 shows that the UE retains (stores) at least one inter-cell mTRP configuration and reestablishes in a cell from an unprepared gNB.
[0146] For example, in this case, the UE is configured to retain at least one of the inter-cell mTRP configurations when initiating the reestablishment procedure. The network node (e.g., a different gNB / target gNB or source gNB) may have determined to retain one or more inter-cell mTRP configurations and indicated such action to the UE. Alternatively, both the network node and the UE have decided to retain one or more inter-cell mTRP configurations.
[0147] like Figure 7 As shown, first, the UE connects to the source gNB in which the UE context is stored. The UE context includes the inter-cell mTRP configuration. Due to some reasons, the connection is suspended, and in step 605, the UE initiates a reestablishment procedure to a cell being served by a target network node (e.g., a different gNB) that is different from the source gNB that served the previous serving cell of the UE. For example, the UE selects a cell served by the target network node.
[0148] In step 610, the UE retains / stores one or more inter-cell mTRP configurations.
[0149] In step 615, the UE sends an RRC Reestablishment Request to the target gNB. In step 620, the target gNB sends a Retrieve UE Context Request to the source gNB. In step 625, the source gNB replies to the target node with a Retrieve UE Context Response including the UE context. The target node now has the UE context including the inter-cell mTRP configuration and can store the UE context in the target node's memory.
[0150] In step 630, the target node sends an RRC reestablishment message to the UE. In step 635, the UE replies with an RRC reestablishment complete message.
[0151] At step 640, when the reestablishing node (e.g., a different gNB) knows that the UE has retained one or more inter-cell mTRP configurations, it may send incremental signaling associated with the stored inter-cell mTRP configurations received in the UE context shared with the source node, i.e., it may add / delete / modify the inter-cell mTRP configurations.
[0152] In step 645, the target node / reestablishing node sends an RRC reconfiguration message to the UE, the message including the added / deleted / modified inter-cell mTRP configuration. In step 650, the UE sends a reconfiguration complete message to the target node.
[0153] Now turn to Figure 8 , a method 700 in a UE / wireless device for reestablishing a connection in the context of an inter-cell mTRP will be described. The method 700 includes:
[0154] Step 710: Receive one or more inter-cell mTRP configurations;
[0155] Step 720: Initiate a reestablishment process with a network node; and
[0156] Step 730: In response to initiating the reestablishment process, releasing at least one inter-cell mTRP configuration among the one or more inter-cell mTRP configurations.
[0157] This method can correspond to Figures 2 to 7 A procedure performed by the UE in any case.
[0158] In some examples, the one or more inter-cell mTRP configurations configure multiple physical cell identities (PCIs) for the UE for mobility procedures, wherein the UE is configured with one or more cells operating at the same service frequency, each cell being associated with one or more PCIs. In some examples, upon releasing the at least one or more inter-cell mTRP configurations, the UE may stop operating according to the one or more inter-cell mTRP configurations that have been released. In some examples, the received one or more inter-cell mTRP configurations include one of the following items: a parameter associated with the one or more inter-cell mTRP configurations in which TRP is defined as an independent cell; a parameter associated with the one or more inter-cell mTRP configurations in which TRP is modeled as a BWP; a parameter associated with the one or more inter-cell mTRP configurations in which TRP is modeled as a dedicated resource; a parameter associated with the one or more inter-cell mTRP configurations in which TRP is defined as a non-serving cell. In some examples, the UE may be configured to release one or more inter-cell mTRP configurations. In some examples, the UE may receive an indication for releasing the at least one inter-cell mTRP configuration. In some examples, the UE may receive configuration for one or more additional inter-cell mTRP configurations.
[0159] Fig. 9 A method 800 for reestablishing a connection in the context of an inter-cell mTRP in a UE is shown. The method 800 includes:
[0160] Step 810: Receive one or more inter-cell mTRP configurations;
[0161] Step 820: Obtain an indication for the reestablishment process for performing at least one of the following operations: releasing at least one inter-cell mTRP configuration of the one or more inter-cell mTRP configurations, and storing at least one inter-cell mTRP configuration of the one or more inter-cell mTRP configurations;
[0162] Step 830: Initiate a reestablishment process with the network node; and
[0163] Step 840: Perform one of the following operations according to the obtained indication: release at least one inter-cell mTRP configuration among the one or more inter-cell mTRP configurations, and store at least one inter-cell mTRP configuration among the one or more inter-cell mTRP configurations.
[0164] In some examples, through the one or more inter-cell mTRP configurations, the wireless device may be configured with multiple PCIs for mobility procedures, wherein the wireless device is configured with one or more cells operating at the same service frequency, each cell being associated with one or more PCIs. In some examples, the UE may receive a configuration for one or more additional inter-cell mTRP configurations. For example, the configuration may be an incremental configuration. In some examples, the network node is one of a source node, a target node, or another network node. In some examples, the one or more inter-cell mTRP configurations may include at least one of the following items (or any combination of these items):
[0165] - parameters (and / or fields and / or IEs, such as parameters and / or fields and / or IEs included in IE ServingCellconfig or ServingCellconfigCommon (defined in TS 38.331)) for the configuration of the cell and / or the PCI to be used for inter-cell mTRP operation; these parameters may be included in new IEs (not necessarily in IE ServingCellConfig, ServingCellconfigCommon), although similar or identical parameters may exist;
[0166] - Parameters enabling the UE to perform measurements on a cell configured for inter-cell mTRP, such as: i) at least one SS / PBCH block (SSB) measurement timing configuration (SMTC), channel state information (CSI) measurement configuration, channel state information (CSI) reporting configuration;
[0167] - Parameters that enable the UE to perform Layer 1 measurements on cells configured for inter-cell mTRP (such as SS-reference signal received power (RSRP), SS-reference signal received quality (RSRQ));
[0168] -Parameters that enable the UE to perform inter-cell mTRP operations, such as adding or activating cells / PCIs for transmission, and / or removing or deactivating cells / PCIs for transmission and / or reception on channels (e.g., PDCCH, PDSCH, PUSCH, PUCCH, PBCH).
[0169] -TCI state configuration with RS of a cell as QCL configuration, which cell is not the source cell to which the UE was connected before initiating the re-establishment procedure, e.g. a cell where a Radio Link Failure (RLF) is detected.
[0170] -Beam indication for the beam used for a cell that is not the source cell to which the UE was connected before initiating the re-establishment procedure, e.g. a cell in which RLF was detected.
[0171] - Configuration of DL channel (such as PDSCH) control resource set (CORESET) for a cell configured for inter-cell mTRP operation, wherein the DL channel is a UE-specific configuration and / or a cell-specific / common configuration;
[0172] - Configuration of UL channels (such as PUCCH, PUSCH) of the cell configured for inter-cell mTRP operation, where the UL channels are UE-specific configurations and / or cell-specific / common configurations;
[0173] - a C-RNTI or a set of C-RNTIs, such as the one included in SpCellConfig, used by the UE in the corresponding PCI configured in inter-cell mTRP operation;
[0174] - Parameters associated with 3GPP Option 1, in which TRPs with different PCIs are defined as independent cells;
[0175] a. See the first 4 features of Option 1 above.
[0176] b. When the secondary cell is used for UL, the RLM shall follow the secondary cell signal (it can be determined whether this is part of the primary cell (legacy serving cell) or as a separate secondary cell RLM).
[0177] c. In the sub-option, each inter-cell mTRP configuration has its own ServingCellConfig (so the UE is configured with multiple ServingCellConfigs, one for each TRP) and its own ServingCellConfigCommon (so the UE is configured with multiple ServingCellConfigs, one for each TRP);
[0178] d. In the sub-option, each inter-cell mTRP configuration has its own ServingCellConfig (so the UE is configured with multiple ServingCellConfigs, one for each TRP), but there is a single ServingCellConfigCommon that may be associated with the initial PCell (the PCell to which the UE initially connects and / or performs reconfiguration with synchronization).
[0179] - Parameters associated with 3GPP Option 2, where a TRP with a different PCI is modeled as an additional BWP:
[0180] a. See the features for Option 2 above.
[0181] - Parameters associated with 3GPP Option 3, in which TRPs with different PCIs are modeled as beam resources (e.g., TCI status, QCL information), such as one or a combination of the following:
[0182] a. TRPs with different PCIs are modeled as dedicated resources to enable separate beams, i.e. separate TCI status / QCL information.
[0183] b. See the characteristics of Option 3 above.
[0184] - Parameters associated with 3GPP Option 4, in which a new structure is defined. For example, a new IE (e.g., NonServingCellConfig) is defined to include all non-serving cell information (i.e., TRPs with different PCIs):
[0185] See the features of Option 4 as described above.
[0186] When releasing the one or more inter-cell mTRP configurations, the UE may stop operating according to the inter-cell mTRP configuration, such as: stopping performing measurements according to the L1 measurement configuration and based on the one or more inter-cell mTRP configurations, stopping sending / receiving on the cell configured for inter-cell mTRP, stopping monitoring the physical channels (e.g., PDCCH, PDSCH, PBCH) of the cell configured for inter-cell mTRP, stopping transmission on the UL physical channels (e.g., PUCCH, PUSCH, PRACH) of the cell configured for inter-cell mTRP, resetting the MAC entity, resetting the counters and / or timers associated with the inter-cell mTRP configuration, suspending the inter-cell mTRP configuration, etc.
[0187] In some examples, releasing at least one of the one or more inter-cell mTRP configurations or storing at least one of the one or more inter-cell mTRP configurations can be based on an indication received from a network node. In some examples, the inter-cell mTRP configurations can be configured / reconfigured in the add list / modify list and the release list to benefit from incremental signaling (the stored information is retained and can be modified or released, while new configurations, such as new inter-cell mTRP configurations, can be added) in the following cases: i) when the UE releases at least one inter-cell mTRP configuration, but can be reconfigured (added and / or modified) in the first RRC reconfiguration message after the reestablishment process; or ii) when the UE stores at least one inter-cell mTRP configuration, but can be reconfigured (added and / or modified) in the first RRC reconfiguration message after the reestablishment.
[0188] In some examples, the event that triggers the initiation of the reconstruction process may be at least one of the following events:
[0189] -RLF of MCG is detected;
[0190] -Timer t316 is not configured;
[0191] -SCG transmission is suspended;
[0192] -RLF of MCG is detected when PSCell change or PSCell addition is in progress;
[0193] - Reconfiguration of the MCG with synchronization fails (e.g. timer T304 expires);
[0194] - Mobility caused by NR failure;
[0195] - Integrity check failure indication from lower layers on SRB1 or SRB2;
[0196] -When RRC connection reconfiguration fails;
[0197] -When RLF of SCG is detected and MCG transmission is suspended;
[0198] -When the reconfiguration of the SCG with synchronization fails and the MCG transmission is suspended;
[0199] -When SCG change fails and MCG transmission is suspended;
[0200] -When SCG configuration fails and MCG transmission is suspended;
[0201] - When an integrity check failure indication on SRB3 is received from the SCG lower layer and the MCG is suspended;
[0202] -When T316 expires;
[0203] - upon detection of a failure associated with inter-cell mTRP operations;
[0204] In some examples, initiation of the reconstruction process may include at least one of the following operations:
[0205] - Start timer T311;
[0206] -Perform cell selection;
[0207] -Send an RRC re-establishment request message to the selected cell.
[0208] In some examples, receiving one or more inter-cell mTRP configurations may include receiving one or more inter-cell mTRP configurations when the UE is in connected mode (e.g., RRC_CONNECTED), or when the UE transitions from an idle state (RRC_IDLE) or an inactive state (RRC_INACTIVE) to a connected state, or during HO (as a target cell configuration).
[0209] In some examples, the one or more inter-cell mTRP configurations may be received in an RRC reconfiguration message or in an RRC resume message (eg, RRC Resume).
[0210] In some examples, obtaining the indication may include receiving a message from a network node. Another indication may be obtained via configuration of the UE, such as the UE being configured with one of the following operations: releasing at least one of the one or more inter-cell mTRP configurations, and storing at least one of the one or more inter-cell mTRP configurations.
[0211] Fig.10 A method 900 in a network node (e.g., a target gNB) communicating with a UE performing a reestablishment procedure is shown. The method 900 includes:
[0212] Step 910: receiving a reestablishment request from a UE configured with one or more inter-cell mTRP configurations;
[0213] Step 920: Obtain an indication for performing one of the following operations: releasing at least one inter-cell mTRP configuration of the one or more inter-cell mTRP configurations, and storing at least one inter-cell mTRP configuration of the one or more inter-cell mTRP configurations; and
[0214] Step 930: Perform one of the following operations according to the indication: release at least one inter-cell mTRP configuration among the one or more inter-cell mTRP configurations, and store at least one inter-cell mTRP configuration among the one or more inter-cell mTRP configurations.
[0215] This method can correspond to Figure 2 and Figure 3 In the last serving gNB, Figure 4 In the target node, Figures 5 to 7 Methods implemented in different gNBs.
[0216] In some examples, the one or more inter-cell mTRP configurations configure multiple physical cell identities (PCIs) for the UE for mobility procedures, wherein the UE is configured with one or more cells operating at the same service frequency, each cell being associated with one or more PCIs. In some examples, upon releasing the at least one or more inter-cell mTRP configurations, the network node may stop operating according to the one or more inter-cell mTRP configurations that have been released. In some examples, the one or more inter-cell mTRP configurations may include the same parameters as those described above (with respect to method 700). In some examples, the network node may send a configuration for one or more additional inter-cell mTRP configurations to the UE. In some examples, it also includes obtaining a UE context from a previous network node to which the UE is connected. In some examples, the UE context may include an indication that the UE (attempting to reestablish the connection) has released the at least one inter-cell mTRP configuration or stored at least one inter-cell mTRP configuration in the one or more inter-cell mTRP configurations.
[0217] In some examples, the obtained UE context may include the one or more inter-cell mTRP configurations of the UE. In some examples, the network node may determine whether the obtained UE context includes at least one of the one or more inter-cell mTRP configurations.
[0218] In some examples, the network node may also determine one or more of: adding one or more inter-cell mTRP configurations; releasing one or more inter-cell mTRP configurations; and modifying one or more inter-cell mTRP configurations.
[0219] In some examples, the request to reestablish the connection may be a reestablishment request message. The reestablishment request message may be an RRCReestablishmentRequest message defined in TS 38.331, or it may be any message that the UE sends (e.g., after a failure has been detected) to indicate to the network that it is attempting to reestablish the connection.
[0220] In some examples, obtaining the UE context may include any action for accessing the UE context, such as retrieving it from memory or from another network node and / or from a database (internal or external to the first network node).
[0221] In some examples, the UE context may be obtained via a UE context acquisition procedure defined in TS 38.324. In some examples, the network node may send an RRC reestablishment message to the UE. In some examples, the network node may receive an RRC reestablishment complete message. In some examples, the network node may send an RRC reconfiguration message to the UE after the reestablishment procedure based on the UE context.
[0222] In some examples, the release of the one or more inter-cell mTRP configurations based on the indication may be associated with UE capabilities. In one option, the UE is unable to store the inter-cell mTRP configuration, so that the indication may be a lack of UE capabilities (e.g., the UE capabilities do not exist). For example, if the UE capability for storing the inter-cell mTRP configuration upon reestablishment is lacking, the network node understands that the UE has released the inter-cell mTRP configuration, so it also releases the inter-cell mTRP configuration. The UE capability for storing the inter-cell mTRP configuration may be sent by the network node as part of a UE radio capability signaling message, such as in an RRC message and an IE.
[0223] In some examples, storage of the inter-cell mTRP configuration based on the indication may be associated with the UE capability. In one option, the UE is capable of storing the inter-cell mTRP configuration, so that the indication may be that the UE capability exists. For example, if there is a UE capability for storing the inter-cell mTRP configuration upon reestablishment, the first network node understands that the UE has stored the inter-cell mTRP configuration, so it also stores the inter-cell mTRP configuration. The UE capability for storing the inter-cell mTRP configuration may be sent by a network node of the network as part of a UE radio capability signaling message, such as in an RRC message and an IE.
[0224] In some examples, since the one or more inter-cell mTRP configurations have been released by the previous serving gNB, determining whether the obtained UE context (of the UE that has sent the reestablishment request message) can include at least one of the one or more inter-cell mTRP configurations may include: determining that the UE context does not include one or more inter-cell mTRP configurations.
[0225] In some examples, the RRC reconfiguration message sent to the UE may include at least one of the following:
[0226] - one or more inter-cell mTRP configurations being added;
[0227] - one or more inter-cell mTRP configurations being released;
[0228] - one or more inter-cell mTRP configurations being modified;
[0229] - one or more inter-cell mTRP configurations being activated;
[0230] - one or more inter-cell mTRP configurations being deactivated;
[0231] In some examples, the first network node in which the UE attempts to re-establish (i.e., which receives the re-establishment request message) is one of the following network nodes:
[0232] - The last serving network node to which the UE was connected when the re-establishment procedure was triggered. This is the case when the UE was re-established in the last serving gNB (e.g. Figure 2 and Figure 3 the situation shown);
[0233] - A different network node than the last serving gNB, which is the case when the UE is reestablishing in a different node. In one example, for example, the different network node / first network node is a prepared network node, i.e. the first network node in which the UE attempts to reestablish has received the UE context in a HO request message from the second network node (operating as the source network node in the mobility / HO procedure). The HO request message may include the UE identity associated with the UE context (this is the Figure 4 the situation shown; or
[0234] - A network node different from the last serving gNB, which is the case when the UE is reestablished in a different node. In another example, the different network node / first network node is not a prepared network node, so the first network node needs to retrieve the UE context by requesting the UE context from the last serving network node where the UE context is located. In this case, retrieving the UE context may include: obtaining the UE context by requesting the UE context from the last serving network node where the UE context is located. This is Figures 5 to 7 The situation shown in .
[0235] As a note, the one or more inter-cell mTRP configurations are similar to the one or more inter-cell mTRP configurations discussed when describing methods 700 and 800.
[0236] Fig.11 A method 950 performed by a first network node serving a UE and having a UE context is shown. The method may include:
[0237] Step 960: Send one or more inter-cell mTRP configurations to the UE;
[0238] Step 970: Storing the one or more inter-cell mTRP configurations in a UE context associated with the UE; and
[0239] Step 980: Send the UE context to a second network node where the UE is attempting to re-establish after having left the connection with the first network node.
[0240] This method can correspond to Figure 2 and Figure 3 In the last serving gNB or in Figures 4 to 7 The method implemented in the source gNB.
[0241] In some examples, sending the UE context to the second network node may include sending a HO request message, wherein the HO request message includes the UE context. In some examples, sending the UE context to the second network node may include responding to a UE context retrieval request message from the second network node.
[0242] In some examples, before sending the UE context, the first network node may perform one of the following operations: releasing at least one of the one or more inter-cell mTRP configurations from the UE context associated with the UE (which has sent a re-establishment request message); and storing at least one of the one or more inter-cell mTRP configurations from the UE context associated with the UE (which has sent a re-establishment request message).
[0243] In some examples, the first network node may stop performing inter-cell mTRP operations, such as stopping performing measurements based on the inter-cell mTRP configuration, stopping sending / receiving on the cell configured for inter-cell mTRP, stopping monitoring the physical channels (e.g., PDCCH, PDSCH, PBCH) of the cell configured for inter-cell mTRP, and stopping transmission on the UL physical channels (e.g., PUCCH, PUSCH, PRACH) of the cell configured for inter-cell mTRP.
[0244] Fig.12 An example of a communication system 1200 is shown in accordance with some embodiments.
[0245] In this example, the communication system 1200 includes a telecommunications network 1202, which includes an access network 1204 (e.g., RAN) and a core network 1206, which includes one or more core network nodes 1208. The access network 1204 includes one or more access network nodes, such as network nodes 1210a and 1210b (one or more of which may be generally referred to as network nodes 1210), or any other similar 3GPP access nodes or non-3GPP access points. The network node 1210 facilitates direct or indirect connection of UEs, such as connecting UEs 1212a, 1212b, 1212c, and 1212d (one or more of which may be generally referred to as UE 1212) to the core network 1206 via one or more wireless connections.
[0246] Example wireless communications via wireless connections include sending and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information without using wiring, cables, or other material conductors. In addition, in different embodiments, the communication system 1200 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that can facilitate or participate in the communication of data and / or signals (whether via a wired connection or via a wireless connection). The communication system 1200 may include any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system, and / or be connected to any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system interface.
[0247] UE 1212 may be any of a variety of communication devices, including wireless devices that are arranged, configured and / or operable to wirelessly communicate with network node 1210 and other communication devices. Similarly, network node 1210 is arranged, capable, configured and / or operable to communicate directly or indirectly with UE 1212 and / or with other network nodes or devices in telecommunication network 1202 to enable and / or provide network access (e.g., wireless network access) and / or to perform other functions (e.g., management) in telecommunication network 1202.
[0248] In the depicted example, the core network 1206 connects the network node 1210 to one or more hosts (e.g., host 1216). These connections may be direct connections or indirect connections via one or more intermediate networks or devices. In other examples, the network node may be directly coupled to the host. The core network 1206 includes one or more core network nodes (e.g., core network node 1208) composed of hardware and software components. The features of these components may be substantially similar to those described with respect to the UE, network node, and / or host, so that their descriptions are generally applicable to the corresponding components of the core network node 1208. The example core network node includes the functions of one or more of the following items: a mobile switching center (MSC), a mobility management entity (MME), a home subscriber server (HSS), an access and mobility management function (AMF), a session management function (SMF), an authentication server function (AUSF), a subscription identifier de-hiding function (SIDF), a unified data management (UDM), a security edge protection agent (SEPP), a network open function (NEF), and / or a user plane function (UPF).
[0249] The host 1216 may be owned or under the control of a service provider other than the operator or provider of the access network 1204 and / or the telecommunications network 1202, and may be operated by or on behalf of the service provider. The host 1216 may host a variety of applications to provide one or more services. Examples of such applications include real-time and pre-recorded audio / video content, data collection services (e.g., retrieving and compiling data about various environmental conditions detected by multiple UEs), analysis functions, social media, functions for controlling or otherwise interacting with remote devices, functions for alarm and monitoring centers, or any other such functions performed by a server.
[0250] As a whole, Fig.12The communication system 1200 enables connections between UEs, network nodes, and hosts. In this sense, the communication system can be configured to operate according to predefined rules or procedures such as a specific standard, including but not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); LTE and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standards (e.g., 6G); Wireless Local Area Network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard (WiFi); and / or any other appropriate wireless communication standards, such as Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any Low Power Wide Area Network (LPWAN) standards (e.g., LoRa and Sigfox).
[0251] In some examples, the telecommunication network 1202 is a cellular network implementing 3GPP standardized features. In addition, the telecommunication network 1202 can support network slicing to provide different logical networks to different devices connected to the telecommunication network 1202. For example, the telecommunication network 1202 can provide ultra-reliable low-latency communication (URLLC) services to some UEs, while providing enhanced mobile broadband (eMBB) services to other UEs, and / or providing massive machine type communication (mMTC) / massive IoT services to yet other UEs.
[0252] In some examples, UE 1212 is configured to send and / or receive information without direct human interaction. For example, the UE may be designed to send information to the access network 1204 according to a predetermined schedule when triggered by an internal or external event or in response to a request from the access network 1204. In addition, the UE may be configured to operate in a single RAT mode or a multi-RAT mode or a multi-standard mode. For example, the UE may operate using any one or a combination of Wi-Fi, NR, and LTE, i.e., be configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved UMTS Terrestrial Radio Access Network) New Radio-Dual Connectivity (EN-DC).
[0253] In this example, the hub 1214 communicates with the access network 1204 to facilitate indirect communication between one or more UEs (e.g., UE 1212c and / or 1212d) and a network node (e.g., network node 1210b). In some examples, the hub 1214 may be a controller, a router, a content source and an analyzer, or any other communication device described herein with respect to the UE. For example, the hub 1214 may be a broadband router that enables the UE to access the core network 1206. As another example, the hub 1214 may be a controller that sends commands or instructions to one or more actuators in the UE. The commands or instructions may be received from the UE, the network node 1210, or received through executable code, scripts, processes, or other instructions in the hub 1214. As another example, the hub 1214 may be a data collector that acts as a temporary storage device for UE data, and in some embodiments, analysis or other processing of the data may be performed. As another example, the center 1214 may be a content source. For example, for a UE that is a VR headset, display, speaker, or other media delivery device, the hub 1214 can retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, and then the hub 1214 provides it directly to the UE after performing local processing and / or after adding additional local content. In yet another example, the hub 1214 acts as a proxy server or coordinator for the UE, especially if one or more of the UEs are low-energy IoT devices.
[0254] The hub 1214 may have a continuous / persistent or intermittent connection to the network node 1210b. The hub 1214 may also allow different communication schemes and / or scheduling between the hub 1214 and the UE (e.g., UE 1212c and / or 1212d) and between the hub 1214 and the core network 1206. In other examples, the hub 1214 is connected to the core network 1206 and / or one or more UEs via a wired connection. In addition, the hub 1214 may be configured to be connected to an M2M service provider through the access network 1204, and / or to another UE through a direct connection. In some scenarios, the UE may establish a wireless connection with the network node 1210 while still being connected through the hub 1214 via a wired or wireless connection. In some embodiments, the hub 1214 may be a dedicated hub, that is, a hub whose main function is to route communications from the network node 1210b to the UE / route communications from the UE to the network node 1210b. In other embodiments, the hub 1214 may be a non-dedicated hub - ie, a device operable to route communications between UEs and the network node 1210b but additionally capable of operating as a communications origin and / or endpoint for certain data channels.
[0255] Fig.13 A UE 1300 according to some embodiments is shown. As used herein, a UE refers to a device capable of, configured, arranged and / or operable to wirelessly communicate with a network node and / or other UEs. Examples of UEs include, but are not limited to, smart phones, mobile phones, cellular phones, voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, game consoles or devices, music storage devices, playback devices, wearable terminal devices, wireless endpoints, mobile stations, tablet computers, laptop computers, laptop embedded devices (LEEs), laptop-mounted devices (LMEs), smart devices, wireless client equipment (CPEs), vehicle-mounted or vehicle-embedded / integrated wireless devices, etc. Other examples include any UE identified by 3GPP, including narrowband Internet of Things (NB-IoT) UEs, machine type communication (MTC) UEs, and / or enhanced MTC (eMTC) UEs.
[0256] The UE may support device-to-device (D2D) communications, for example, by implementing 3GPP standards for sidelink communications, dedicated short-range communications (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, the UE may not necessarily have a user in the sense of a human user who owns and / or operates the associated device. Alternatively, the UE may represent a device that is intended to be sold to or operated by a human user but may not or may not initially be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, the UE may represent a device that is not intended to be sold to or operated by an end user but may be associated with or operated for the benefit of a user (e.g., a smart power meter).
[0257] UE 1300 includes a processing circuit 1302 that is operably coupled to an input / output interface 1306, a power supply 1308, a memory 1310, a communication interface 1312, and / or any other components or any combination thereof via a bus 1304. Some UEs may utilize Fig.13 All or a subset of the components shown. The level of integration between components may vary from one UE to another. In addition, some UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.
[0258] The processing circuit 1302 is configured to process instructions and data, and may be configured to implement any sequential state machine operable to execute instructions stored in the memory 1310 as a machine-readable computer program. The processing circuit 1302 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc.); programmable logic and suitable firmware; one or more stored computer programs, general-purpose processors (e.g., microprocessors or digital signal processors (DSPs)) and appropriate software; or any combination of the above. For example, the processing circuit 1302 may include multiple central processing units (CPUs).
[0259] In this example, the input / output interface 1306 can be configured to provide one or more interfaces to an input device, an output device, or one or more input and / or output devices. Examples of output devices include speakers, sound cards, video cards, displays, monitors, printers, actuators, transmitters, smart cards, another output device, or any combination thereof. An input device can allow a user to capture information into the UE 1300. Examples of input devices include touch-sensitive or presence-sensitive displays, cameras (e.g., digital cameras, digital video cameras, web cameras, etc.), microphones, sensors, mice, trackballs, directional keyboards, trackpads, scroll wheels, smart cards, etc. The presence-sensitive display can include a capacitive or resistive touch sensor to sense input from a user. The sensor can be, for example, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device can use an interface port of the same type as an input device. For example, a universal serial bus (USB) port can be used to provide input devices and output devices.
[0260] In some embodiments, the power supply 1308 is configured as a battery or a battery pack. Other types of power supplies may be used, such as an external power supply (e.g., a power outlet), a photovoltaic device, or a battery. The power supply 1308 may also include a power supply circuit for delivering power from the power supply 1308 itself and / or an external power supply to various parts of the UE 1300 via an input circuit or an interface such as a power cable. The delivered power may be used, for example, for charging the power supply 1308. The power supply circuit may perform any formatting, conversion, or other modification on the power from the power supply 1308 so that the power is suitable for the corresponding components of the UE 1300 to which the power is supplied.
[0261] The memory 1310 may be or be configured to include a memory such as a random access memory (RAM), a read-only memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM), an electrically EPROM (EEPROM), a magnetic disk, an optical disk, a hard disk, a removable tape, a flash drive, etc. In one example, the memory 1310 includes one or more application programs 1314, such as an operating system, a web browser application, a widget, a gadget engine, or other applications, and corresponding data 1316. The memory 1310 may store any one of a variety of operating systems or a combination of operating systems used by the UE 1300.
[0262] The memory 1310 may be configured to include a plurality of physical drive units, such as a redundant array of independent disks (RAID), a flash memory, a USB flash drive, an external hard drive, a thumb drive, a pen drive, a key drive, a high-density digital versatile disc (HD-DVD) optical drive, a built-in hard drive, a Blu-ray optical drive, a holographic digital data storage (HDDS) optical drive, an external mini dual in-line memory module (DIMM), a synchronous dynamic random access memory (SDRAM), an external micro DIMM SDRAM, a smart card memory (e.g., a tamper-proof module in the form of a universal integrated circuit card (UICC), including one or more subscriber identity modules (SIMs), such as USIM and / or ISIM), other memories, or any combination thereof. The UICC may be, for example, an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC commonly referred to as a "SIM card". The memory 1310 may allow the UE 1300 to access instructions, applications, etc. stored on a temporary or non-temporary storage medium to offload data or upload data. An article of manufacture, such as an article of manufacture utilizing a communication system, may be tangibly embodied as or in memory 1310, which may be or include a device-readable storage medium.
[0263] The processing circuit 1302 may be configured to communicate with an access network or other network using a communication interface 1312. The communication interface 1312 may include one or more communication subsystems and may include an antenna 1322 or be communicatively coupled to the antenna 1322. The communication interface 1312 may include one or more transceivers for communicating (e.g., by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network)). Each transceiver may include a transmitter 1318 and / or a receiver 1320 suitable for providing network communications (e.g., optical, electrical, frequency allocation, etc.). In addition, the transmitter 1318 and the receiver 1320 may be coupled to one or more antennas (e.g., antenna 1322) and may share circuit components, software, or firmware, or alternatively be implemented separately. In addition, the processing circuit 1302 is configured to perform Figure 8 Method 700 and Fig. 9 Any step of method 800.
[0264] In the illustrated embodiment, the communication functionality of the communication interface 1312 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communication such as Bluetooth, near field communication, location-based communication (e.g., using a global positioning system (GPS) to determine location), another type of communication functionality, or any combination thereof. Communication may be implemented according to one or more communication protocols and / or standards such as IEEE 802.11, code division multiple access (CDMA), wideband code division multiple access (WCDMA), GSM, LTE, NR, UMTS, WiMax, Ethernet, transmission control protocol / Internet protocol (TCP / IP), synchronous optical network (SONET), asynchronous transfer mode (ATM), QUIC, hypertext transfer protocol (HTTP), etc.
[0265] Regardless of the type of sensor, the UE may provide an output of data captured by its sensor through its communication interface 1312 via a wireless connection to a network node. The data captured by the UE's sensor may be transmitted via another UE via a wireless connection to a network node. The output may be periodic (e.g., every 15 minutes if it reports the sensed temperature), random (e.g., to balance the load of reports from several sensors), in response to a trigger event (e.g., sending an alarm when humidity is detected), in response to a request (e.g., a user-initiated request), or a continuous stream (e.g., a live video feed of a patient).
[0266] As another example, the UE includes an actuator, motor or switch associated with a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input, the state of the actuator, motor or switch may change.
[0267] When the UE is in the form of an Internet of Things (IoT) device, the UE may be a device used in one or more application areas including, but not limited to, urban wearable technology, extended industrial applications, and healthcare. Non-limiting examples of such IoT devices are the following devices or devices embedded in the following devices: connected refrigerators or freezers, televisions, connected lighting devices, electricity meters, robotic vacuum cleaners, voice-controlled smart speakers, head-mounted displays for augmented reality (AR) or virtual reality (VR), wearable devices for tactile or sensory enhancement, sprinklers, animal tracking or item tracking devices, sensors for monitoring plants or animals, industrial robots, unmanned aerial vehicles (UAVs), and any kind of medical equipment (such as heart rate monitors or teleoperated surgical robots). In addition to the above, Fig.13 In addition to the other components depicted in the illustrated UE 1300 , a UE in the form of an IoT device may include circuitry and / or software depending on the intended application of the IoT device.
[0268] As yet another specific example, in an IoT scenario, a UE may represent a machine or other device that performs monitoring and / or measurement and sends the results of such monitoring and / or measurement to another UE and / or a network node. In this case, the UE may be an M2M device, which may be referred to as an MTC device in the 3GPP context. As a specific example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle (e.g., a car, bus, truck, ship, and airplane) or other device that is capable of monitoring and / or reporting its operating status or other functions associated with its operation.
[0269] In fact, for a single use case, any number of UEs may be used together. For example, a first UE may be a drone or integrated in a drone and provide the drone's speed information (obtained via a speed sensor) to a second UE, which is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g., by controlling an actuator) to increase or decrease the drone's speed. The first UE and / or the second UE may also include more than one of the above functions. For example, a UE may include a sensor and an actuator and handle data communications for both the speed sensor and the actuator.
[0270] Fig.14A network node 1400 according to some embodiments is shown. As used herein, a network node refers to a device capable of, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or devices in a telecommunications network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, NodeBs, evolved NodeBs (eNBs), and NR NodeBs (gNBs)).
[0271] Base stations may be classified based on the amount of coverage they provide (or in other words, their transmit power level), and thus may be referred to as femto, pico, micro or macro base stations, depending on the amount of coverage provided. A base station may be a relay node or a relay donor node that controls a relay. A network node may also include one or more (or all) parts of a distributed radio base station, such as a centralized digital unit and / or a remote radio unit (RRU), sometimes referred to as a remote radio head (RRH). These remote radio units may or may not be integrated with an antenna as an antenna-integrated radio. Portions of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).
[0272] Other examples of network nodes include a multi-transmission point (multi-TRP) 5G access node, a multi-standard radio (MSR) device (e.g., an MSR BS), a network controller (e.g., a radio network controller (RNC) or a base station controller (BSC)), a base transceiver station (BTS), a transmission point, a transmission node, a multi-cell / multicast coordination entity (MCE), an operation and maintenance (O&M) node, an operation support system (OSS) node, a self-organizing network (SON) node, a positioning node (e.g., an evolved serving mobile location center (E-SMLC)), and / or a minimization of drive tests (MDT).
[0273] The network node 1400 includes a processing circuit 1402, a memory 1404, a communication interface 1406, and a power supply 1408. The network node 1400 may be composed of multiple physically separated components (e.g., a Node B component and an RNC component, a BTS component and a BSC component, etc.), which may have their own corresponding components. In certain scenarios where the network node 1400 includes multiple separate components (e.g., BTS and BSC components), one or more separate components may be shared between several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair may be considered to be a single separate network node in some cases. In some embodiments, the network node 1400 may be configured to support multiple radio access technologies (RATs). In such an embodiment, some components may be duplicated (e.g., separate memories 1404 exist for different RATs), and some components may be reused (e.g., the same antenna 1410 may be shared by different RATs). The network node 1400 may also include multiple sets of the various components shown for different wireless technologies (e.g., GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, radio frequency identification (RFID), or Bluetooth wireless technologies) integrated into the network node 1400. These wireless technologies may be integrated into the same or different chips or chipsets and other components within the network node 1400.
[0274] The processing circuit 1402 may include a combination of one or more of the following: a microprocessor, a controller, a microcontroller, a central processing unit, a digital signal processor, an application specific integrated circuit, a field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic that is operable to provide network node 1400 functionality alone or in combination with other network node 1400 components (e.g., memory 1404).
[0275] In some embodiments, processing circuitry 1402 includes a system on a chip (SOC). In some embodiments, processing circuitry 1402 includes one or more of radio frequency (RF) transceiver circuitry 1412 and baseband processing circuitry 1414. In some embodiments, radio frequency (RF) transceiver circuitry 1412 and baseband processing circuitry 1414 may be on separate chips (or chipsets), boards, or units (e.g., a radio unit and a digital unit). In alternative embodiments, part or all of RF transceiver circuitry 1412 and baseband processing circuitry 1414 may be on the same chip or chipset, board, or unit. In addition, processing circuitry 1402 is configured to perform Fig.10 Method 900 and Fig.11 Any step of method 950.
[0276] The memory 1404 may include any form of volatile or non-volatile computer-readable memory, including but not limited to permanent storage devices, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (e.g., hard disk), removable storage media (e.g., flash drive, compact disk (CD) or digital video disk (DVD)), and / or any other volatile memory or non-volatile, non-transitory device-readable and / or computer-executable memory device that stores information, data and / or instructions that can be used by the processing circuit 1402. The memory 1404 may store any suitable instructions, data or information, including computer programs, software, applications including one or more of logic, rules, codes, tables, and / or other instructions that can be executed by the processing circuit 1402 and used by the network node 1400. The memory 1404 may be used to store any calculations performed by the processing circuit 1402 and / or any data received via the communication interface 1406. In some embodiments, the processing circuit 1402 and the memory 1404 are integrated together.
[0277] The communication interface 1406 is used for wired or wireless communication of signaling and / or data between network nodes, access networks and / or UEs. As shown, the communication interface 1406 includes a port / terminal 1416 for, for example, sending data to the network and receiving data from the network via a wired connection. The communication interface 1406 also includes a radio front-end circuit 1418, which can be coupled to the antenna 1410, or in some embodiments, a part of the antenna 1410. The radio front-end circuit 1418 includes a filter 1420 and an amplifier 1422. The radio front-end circuit 1418 can be connected to the antenna 1410 and the processing circuit 1402. The radio front-end circuit can be configured to adjust the signal transmitted between the antenna 1410 and the processing circuit 1402. The radio front-end circuit 1418 can receive digital data to be sent to other network nodes or UEs via a wireless connection. The radio front-end circuit 1418 can use a combination of a filter 1420 and / or an amplifier 1422 to convert the digital data into a radio signal with appropriate channel and bandwidth parameters. The radio signal can then be sent via the antenna 1410. Similarly, when data is received, antenna 1410 may collect the radio signal, which radio front end circuit 1418 may then convert into digital data. The digital data may be passed to processing circuit 1402. In other embodiments, the communication interface may include different components and / or different combinations of components.
[0278] In certain alternative embodiments, the network node 1400 does not include a separate radio front end circuit 1418, instead the processing circuit 1402 includes the radio front end circuit and is connected to the antenna 1410. Similarly, in some embodiments, all or some of the RF transceiver circuit 1412 is part of the communication interface 1406. In yet another embodiment, the communication interface 1406 includes one or more ports or terminals 1416, the radio front end circuit 1418, and the RF transceiver circuit 1412 as part of a radio unit (not shown), and the communication interface 1406 communicates with the baseband processing circuit 1414, which is part of the digital unit (not shown).
[0279] Antenna 1410 may include one or more antennas or antenna arrays configured to send and / or receive wireless signals. Antenna 1410 may be coupled to radio front end circuit 1418 and may be any type of antenna capable of wirelessly sending and receiving data and / or signals. In some embodiments, antenna 1410 is separate from network node 1400 and may be connected to network node 1400 via an interface or port.
[0280] Antenna 1410, communication interface 1406 and / or processing circuit 1402 may be configured to perform any receiving operation and / or certain obtaining operations performed by a network node as described herein. Any information, data and / or signal may be received from a UE, another network node and / or any other network device. Similarly, antenna 1410, communication interface 1406 and / or processing circuit 1402 may be configured to perform any sending operation performed by a network node as described herein. Any information, data and / or signal may be sent to a UE, another network node and / or any other network device.
[0281] The power supply 1408 provides power to the various components of the network node 1400 in a form suitable for the various components (e.g., at the voltage and current levels required by each corresponding component). The power supply 1408 may also include power management circuitry or be coupled to a power management circuitry to supply power to the components of the network node 1400 for performing the functions described herein. For example, the network node 1400 may be connected to an external power source (e.g., a power grid, a power outlet) via an input circuit or interface (e.g., a cable), whereby the external power source supplies power to the power circuit of the power supply 1408. As another example, the power supply 1408 may include a power source in the form of a battery or a battery pack, which is connected to the power circuit or integrated in the power circuit. If the external power source fails, the battery may provide backup power.
[0282] Embodiments of network node 1400 may include beyond Fig.14Additional components to the components shown are used to provide certain aspects of the functionality of the network node (including any functionality described herein and / or any functionality required to support the subject matter described herein). For example, the network node 1400 may include a user interface device to allow information to be input into the network node 1400 and to allow information to be output from the network node 1400. This may allow a user to perform diagnostic, maintenance, repair, and other management functions for the network node 1400.
[0283] Fig.15 is a block diagram of a host 1500 according to various aspects described herein, which host 1500 may be Fig.12 As used herein, host 1500 may be or include various combinations of hardware and / or software (including processing resources in a standalone server, blade server, cloud-implemented server, distributed server, virtual machine, container, or server cluster). Host 1500 may provide one or more services to one or more UEs.
[0284] Host 1500 includes processing circuitry 1502 operatively coupled to input / output interface 1506, network interface 1508, power supply 1510, and memory 1512 via bus 1504. Other components may be included in other embodiments. The features of these components may be substantially similar to those described with respect to previous figures (e.g., Fig.13 and Fig.14 ) so that its description is generally applicable to corresponding components of host 1500.
[0285] The memory 1512 may include one or more computer programs, including data 1516 and one or more host applications 1514, which may include user data, such as data generated by a UE for the host 1500, or data generated by the host 1500 for the UE. An embodiment of the host 1500 may utilize only a subset or all of the components shown. The host application 1514 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for a variety of different categories, types, or implementations of UE (e.g., mobile phones, desktop computers, wearable display systems, head-up display systems). The host application 1514 may also provide user authentication and permission checks, and may periodically report health status, routing, and content availability to a central node (e.g., a device in the core network or a device on the edge of the core network). Thus, the host 1500 can select and / or indicate to the UE a different host for an over-the-top service. The host application 1514 can support various protocols, such as HTTP Live Streaming (HLS) protocol, Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.
[0286] Fig.16 1600 is a block diagram showing a virtualized environment 1600 in which functions implemented by some embodiments can be virtualized. In this context, virtualization means creating a virtual version of an apparatus or device that can include virtualized hardware platforms, storage devices, and network resources. As used herein, virtualization can be applied to any device or component thereof described herein, and involves an implementation in which at least a portion of the functions are implemented as one or more virtual components. Some or all of the functions described herein can be implemented as virtual components performed by one or more virtual machines (VMs), which are implemented in one or more virtual environments 1600 hosted by one or more of the hardware nodes (e.g., hardware computing devices operating as network nodes, UEs, core network nodes, or hosts). In addition, in embodiments where the virtual node does not require a radio connection (e.g., a core network node or a host), the node can be fully virtualized.
[0287] Application 1602 (which may alternatively be referred to as a software instance, a virtual application, a network function, a virtual node, a virtual network function, etc.) runs in a virtualized environment Q400 to implement some features, functions and / or benefits of some embodiments disclosed herein.
[0288] Hardware 1604 includes processing circuitry, memory storing software and / or instructions executable by the hardware processing circuitry, and / or other hardware devices described herein (e.g., network interfaces, input / output interfaces, etc.). The software may be executed by the processing circuitry to instantiate one or more virtualization layers 1606 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1608a and 1608b (one or more of which may be generally referred to as VMs 1608), and / or perform any of the functions, features, and / or benefits described in connection with some embodiments described herein. Virtualization layer 1606 may present a virtual operating platform to VM 1608 that appears to be network hardware.
[0289] VM 1608 includes virtual processing, virtual memory, virtual network or interface, and virtual storage, and can be run by corresponding virtualization layer 1606. Different embodiments of instances of virtual device 1602 can be implemented on one or more VMs 1608, and these implementations can be made in different ways. In some contexts, virtualization of hardware is referred to as network function virtualization (NFV). NFV can be used to unify numerous network device types onto industry standard high-capacity server hardware, physical switches, and physical storage that can be located in data centers and customer premises equipment (CPE).
[0290] In the context of NFV, VM 1608 can be a software implementation of a physical machine that runs programs as if they were executed on a physical, non-virtualized machine. Each VM 1608 and the hardware portion of 1604 that executes the VM (whether it is hardware dedicated to the VM and / or hardware shared by the VM with other VMs) form a separate virtual network element. Still in the context of NFV, a virtual network function is responsible for handling a specific network function running in one or more VMs 1608 on the hardware 1604 and corresponding to an application 1602.
[0291] Hardware 1604 may be implemented in a standalone network node with general or specific components. Hardware 1604 may implement some functions via virtualization. Alternatively, hardware 1604 may be part of a larger hardware cluster (e.g., in a data center or CPE) where many hardware nodes work together and are managed by management and coordination 1610, which oversees, among other things, the lifecycle management of application 1602. In some embodiments, hardware 1604 is coupled to one or more radio units, each of which includes one or more transmitters and one or more receivers that may be coupled to one or more antennas. The radio unit may communicate directly with other hardware nodes via one or more appropriate network interfaces, and may be used in conjunction with virtual components to provide radio capabilities to virtual nodes (e.g., radio access nodes or base stations). In some embodiments, some signaling may be provided by using a control system 1612, which may alternatively be used for communication between hardware nodes and radio units.
[0292] Fig.17 A communication diagram is shown in which a host 1702 communicates with a UE 1706 via a network node 1704 over a partially wireless connection according to some embodiments. Fig.17 Describe the UE discussed in the previous paragraphs (e.g., Fig.12 UE 1212a and / or Fig.13 UE 1300), network node (e.g., Fig.12 The network node 1210a and / or Fig.14 network node 1400) and a host (e.g., Fig.12 Host 1216 and / or Fig.15 An example implementation of a host 1500 according to various embodiments.
[0293] Similar to the host 1500, an embodiment of the host 1702 includes hardware, such as a communication interface, a processing circuit, and a memory. The host 1702 also includes software that is stored in the host 1702 or accessible by the host 1702 and can be executed by the processing circuit. The software includes a host application that is operable to provide services to a remote user, such as a UE 1706 connected via an over-the-top (OTT) connection 1750 extending between the UE 1706 and the host 1702. When providing services to the remote user, the host application can provide user data sent using the OTT connection 1750.
[0294] The network node 1704 includes hardware that enables it to communicate with the host 1702 and the UE 1706. The connection 1760 can be a direct connection or through a core network (such as Fig.12The core network 1206 of the present invention) and / or one or more other intermediate networks (eg, one or more public, private, or managed networks). For example, the intermediate network may be a backbone network or the Internet.
[0295] UE 1706 includes hardware and software, which is stored in UE 1706 or accessible by UE 1706 and can be executed by the processing circuit of UE. The software includes a client application (e.g., a web browser or operator-specific "application"), which is operable to provide services to human or non-human users via UE 1706 with the support of host 1702. In host 1702, the executing host application can communicate with the executing client application via OTT connection 1750, which is terminated at UE 1706 and host 1702. When providing services to users, the client application of UE can receive request data from the host application of the host and provide user data in response to the request data. OTT connection 1750 can send both request data and user data. The client application of UE can interact with the user to generate user data provided to the host application via OTT connection 1750.
[0296] The OTT connection 1750 may extend via a connection 1760 between the host 1702 and the network node 1704 and via a wireless connection 1770 between the network node 1704 and the UE 1706 to provide connectivity between the host 1702 and the UE 1706. The connection 1760 and the wireless connection 1770 through which the OTT connection 1750 may be provided have been drawn abstractly to illustrate communications between the host 1702 and the UE 1706 via the network node 1704 without explicitly involving any intermediate devices and the precise routing of messages via those devices.
[0297] As an example of sending data via OTT connection 1750, in step 1708, host 1702 provides user data, which can be performed by executing a host application. In some embodiments, the user data is associated with a specific human user who interacts with UE 1706. In other embodiments, the user data is associated with UE 1706, and UE 1706 shares data with host 1702 without explicit human interaction. In step 1710, host 1702 initiates a transmission to UE 1706, which carries the user data. Host 1702 may initiate the transmission in response to a request sent by UE 1706. The request may be caused by human interaction with UE 1706 or by the operation of a client application executed on UE 1706. According to the teachings of the embodiments described throughout the present disclosure, the transmission may be delivered via network node 1704. Therefore, in step 1712, according to the teachings of the embodiments described throughout the present disclosure, network node 1704 sends the user data carried in the transmission initiated by host 1702 to UE 1706. In step 1714 , UE 1706 receives the user data carried in the transmission, which may be performed by a client application executing on UE 1706 that is associated with a host application executed by host 1702 .
[0298] In some examples, UE 1706 executes a client application that provides user data to host 1702. User data may be provided as a reaction or response to data received from host 1702. Therefore, in step 1716, UE 1706 may provide user data, which may be performed by executing the client application. When providing user data, the client application may also take into account user input received from a user via an input / output interface of UE 1706. Regardless of the specific manner in which user data is provided, in step 1718, UE 1706 initiates a transmission of user data to host 1702 via network node 1704. In step 1720, in accordance with the teachings of the embodiments described throughout the present disclosure, network node 1704 receives user data from UE 1706 and initiates sending the received user data to host 1702. In step 1722, host 1702 receives the user data carried in the transmission initiated by UE 1706.
[0299] One or more of the various embodiments improve the performance of OTT services provided to UE 1706 using OTT connection 1750, in which wireless connection 1770 forms the final part. More specifically, the teachings of these embodiments can improve data rate, latency, power consumption, and thereby improve benefits such as reduced user waiting time, better responsiveness, and extended battery life.
[0300] In an example scenario, host 1702 may collect and analyze plant status information. As another example, host 1702 may process audio and video data that may have been retrieved from a UE for use in creating a map. As another example, host 1702 may collect and analyze real-time data to help control vehicle congestion (e.g., control traffic lights). As another example, host 1702 may store monitoring videos uploaded by a UE. As another example, host 1702 may store or control access to media content such as video, audio, VR, or AR, which may be broadcast, multicast, or unicast to a UE. As other examples, host 1702 may be used for energy pricing, remote control of non-time-critical power loads to balance power generation demand, positioning services, presentation services (e.g., compiling charts based on data collected from remote devices, etc.), or any other function for collecting, retrieving, storing, analyzing, and / or sending data.
[0301] In some examples, a measurement process may be provided for monitoring data rate, latency, and other factors that are the object of improvement of one or more embodiments. There may also be an optional network function for reconfiguring the OTT connection 1750 between the host 1702 and the UE 1706 in response to changes in the measurement results. The measurement process and / or the network function for reconfiguring the OTT connection may be implemented in the software and hardware of the host 1702 and / or the UE 1706. In some embodiments, sensors (not shown) may be deployed in other devices through which the OTT connection 1750 passes, or associated with the other devices; the sensors may participate in the measurement process by providing the values of the monitored quantities shown above, or providing the values of other physical quantities from which the software can calculate or estimate the monitored quantities. The reconfiguration of the OTT connection 1750 may include message formats, retransmission settings, preferred routes, etc.; the reconfiguration does not require direct changes to the operation of the network node 1704. Such processes and functions may be known and practiced in the art. In some embodiments, the measurement may involve proprietary UE signaling that facilitates the host 1702 to measure throughput, propagation time, latency, etc. Measurements can be made by software using the OTT connection 1750 to send messages (particularly empty or "dummy" messages) while monitoring propagation times, errors, etc.
[0302] Although the computing devices (e.g., UE, network node, host) described herein may include a combination of the hardware components shown, other embodiments may include computing devices with different combinations of components. It should be understood that these computing devices may include any suitable combination of hardware and / or software required to perform the tasks, features, functions, and methods disclosed herein. The determination, calculation, acquisition, or similar operations described herein may be performed by a processing circuit, which may process information by, for example, converting the obtained information to other information, comparing the obtained information or the converted information with the information stored in the network node, and / or performing one or more operations based on the obtained information or the converted information, and making a determination based on the result of the processing. In addition, although the components are depicted as a single box located within a larger box or nested within multiple boxes, in fact, the computing device may include multiple different physical components constituting a single illustrated component, and the functions may be divided between separate components. For example, a communication interface may be configured to include any component described herein, and / or the functions of the components may be divided between the processing circuit and the communication interface. In another example, the non-computationally intensive functions of any such component may be implemented in software or firmware, and the computationally intensive functions may be implemented in hardware.
[0303] In some embodiments, some or all of the functions described herein may be provided by a processing circuit that executes instructions stored in a memory, which in some embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functions may be provided, for example, by a processing circuit in a hardwired manner, without executing instructions stored on a separate or discrete device-readable storage medium. In any of these specific embodiments, the processing circuit may be configured to perform the described functions, regardless of whether instructions stored on a non-transitory computer-readable storage medium are executed. The benefits provided by such functionality are not limited to separate processing circuits or to other components of a computing device, but are enjoyed by the computing device as a whole and / or are generally enjoyed by end users and wireless networks.
Claims
1. A method performed by a user equipment UE, the method comprising: -Receive one or more inter-cell multiple transmit / receive point mTRP configurations; -Initiate the reestablishment process with the network nodes; as well as - In response to initiating the reestablishment process, releasing at least one of the one or more inter-cell mTRP configurations.
2. The method according to claim 1, wherein: The one or more inter-cell mTRP configurations configure multiple physical cell identifiers PCIs for the UE for use in a mobility process, wherein the UE is configured with one or more cells operating at the same serving frequency, each cell being associated with one or more PCIs.
3. The method according to claim 1 or 2, further comprising: When the at least one or more inter-cell mTRP configurations are released, operation according to the one or more inter-cell mTRP configurations that have been released is stopped.
4. The method according to any one of claims 1 to 3, wherein: The one or more received inter-cell mTRP configurations include one of the following items: parameters associated with the one or more inter-cell mTRP configurations in which TRP is defined as an independent cell; parameters associated with the one or more inter-cell mTRP configurations in which TRP is modeled as a bandwidth part BWP; parameters associated with the one or more inter-cell mTRP configurations in which TRP is modeled as a dedicated resource; parameters associated with the one or more inter-cell mTRP configurations in which TRP is defined as a non-service cell.
5. The method according to any one of claims 1 to 4, further comprising: An indication for releasing the at least one inter-cell mTRP configuration is received.
6. The method according to any one of claims 1 to 4, wherein: The UE is configured to release one or more inter-cell mTRP configurations.
7. The method according to any one of claims 1 to 6, further comprising: A configuration for one or more additional inter-cell mTRP configurations is received.
8. A method performed by a user equipment UE, the method comprising: -Receive one or more inter-cell multiple transmit / receive point mTRP configurations; - obtaining an indication for a reestablishment procedure for performing at least one of the following operations: releasing at least one of the one or more inter-cell mTRP configurations, and storing at least one of the one or more inter-cell mTRP configurations; -Initiate the reestablishment process with the network nodes; as well as - Perform one of the following operations according to the obtained indication: release at least one of the one or more inter-cell mTRP configurations, and store at least one of the one or more inter-cell mTRP configurations.
9. A method in a network node, the method comprising: receiving a re-establishment request from a user equipment UE configured with one or more inter-cell mTRP configurations; Obtaining an indication for performing one of the following operations: releasing at least one inter-cell mTRP configuration of the one or more inter-cell mTRP configurations, and storing at least one inter-cell mTRP configuration of the one or more inter-cell mTRP configurations; as well as Perform one of the following operations according to the indication: release at least one of the one or more inter-cell mTRP configurations, and store at least one of the one or more inter-cell mTRP configurations.
10. The method according to claim 9, wherein: The one or more inter-cell mTRP configurations configure multiple physical cell identifiers PCIs for the UE for use in a mobility process, wherein the UE is configured with one or more cells operating at the same serving frequency, each cell being associated with one or more PCIs.
11. The method according to claim 9 or 10, further comprising: When the at least one or more inter-cell mTRP configurations are released, operation according to the one or more inter-cell mTRP configurations that have been released is stopped.
12. The method according to any one of claims 9 to 11, wherein: The one or more inter-cell mTRP configurations include one of the following items: parameters associated with the one or more inter-cell mTRP configurations in which TRP is defined as an independent cell; parameters associated with the one or more inter-cell mTRP configurations in which TRP is modeled as a BWP; parameters associated with the one or more inter-cell mTRP configurations in which TRP is modeled as a dedicated resource; parameters associated with the one or more inter-cell mTRP configurations in which TRP is defined as a non-service cell.
13. The method according to any one of claims 9 to 12, further comprising: A configuration for one or more additional inter-cell mTRP configurations is sent to the UE.
14. The method according to any one of claims 9 to 13, further comprising: A UE context is obtained from a previous network node to which the UE was connected.
15. The method according to claim 14, wherein: The UE context includes an indication that the UE has released the at least one inter-cell mTRP configuration or stored at least one inter-cell mTRP configuration among the one or more inter-cell mTRP configurations.
16. The method according to claim 14 or 15, wherein: The obtained UE context includes the one or more inter-cell mTRP configurations of the UE.
17. The method according to any one of claims 9 to 16, wherein: Releasing the one or more inter-cell mTRP configurations is associated with UE capabilities.
18. The method according to any one of claims 9 to 17, further comprising sending a message to the UE, the message comprising at least one of the following items: - the one or more inter-cell mTRP configurations determined to be added; - the one or more inter-cell mTRP configurations determined to be released; - the one or more inter-cell mTRP configurations determined to be modified; - one or more inter-cell mTRP configurations being activated; -One or more inter-cell mTRP configurations being deactivated.
19. A user equipment UE, comprising a network interface and a processing circuit, wherein the processing circuit is connected to the network interface and configured to perform any one of the methods according to any one of claims 1 to 8.
20. A network node comprising a network interface and a processing circuit connected to the network interface and configured to perform any of the methods according to any of claims 9 to 18.
