Patent Description:
The present disclosure relates generally to communications, and more particularly to communication methods and related devices and nodes.

<FIG> illustrates an example of a 5th Generation ("<NUM>") network (also referred to as a new radio ("NR") network) including a pair of network nodes 110a-b (e.g., <NUM> base stations ("gNB")) and multiple communication devices <NUM> (also referred to as user equipment ("UE")).

Document <CIT> may be construed to disclose a base station that may identify an association between a set of physical cell identifiers (PCIs) identifying different transmission reception points (TRPs) and a set of transmission configuration indicator (TCI) states for a user equipment (UE). The base station may transmit a TCI state and PCI association indication to the UE. The UE may receive a downlink transmission using a receive beam associated with a TCI state, and may identify a PCI of the set of PCIs to use to decode the received downlink transmission. In cases where the TCI state used to receive the downlink transmission is associated with multiple PCIs, the UE may select a default PCI from the multiple PCIs, and may decode the received transmission accordingly. The UE may receive reference signals from one or more of the serving TRPs and may identify a PCI to use to decode the received reference signals.

Document <CIT> may be construed to disclose techniques for preconfiguring transmission configuration indication (TCI)-states at a user-equipment (UE) to reduce handover latency. There is a method for wireless communication. The method generally includes receiving, at a UE, a message indicating a first TCI-state for a current serving base station (BS) and a second TCI-state for a target BS, performing handover to the target BS, and activating the second TCI-state for the target BS after the handover.

Document "<NPL>, may be construed to disclose an evaluation of enhancement of multi-beam operation. The following proposals were made. Proposal <NUM>: Support SRS for beam management configured in unified TCI to serve as a source RS for determining DL Rx beam at UE. Proposal <NUM>: To maintain the flexibility of DL and UL beam indication, support separate unified TCI state pools (Alt. <NUM>-<NUM>) for DL and UL beam indication. Proposal <NUM>: For inter-band CCs, a common beam management procedure, including TCI states across bands, should be considered for data/control, DL/UL, multiple BWPs, multiple TRPs and multiple UE panels. Proposal <NUM>: The UE capabilities reporting related to simultaneously steering in the same direction beams belonging to CCs in different bands should be considered. Proposal5: For the optimization of TCI states across bands, the polarization property of beams should be considered. Proposal <NUM>: Investigate and specify (if the overall performance including overhead, latency and flexibility, reliability can be justified) the DCI based TCI state updating for DL and UL channels/signals. Proposal <NUM>: Study and specify (if necessary) the L1/L2-centric approach for inter-cell mobility: incorporate/associate PCI with unified TCI state for DL beam management; and incorporate/associate PCI with unified TCI state or Spatial Relation for UL beam management. Proposal <NUM>: RAN1 studies and specifies if necessary the L1-event based TCI state automatic activation from non-serving cell. Proposal <NUM>: A panel ID either explicitly or implicitly combined with unified TCI or Spatial Relation can be used for UL panel selection. Proposal <NUM>: Confirm the working assumption on panel selection for PUSCH/PUCCH/SRS and include PRACH with its conditions FFS. Proposal <NUM>: For UE supporting beam correspondence without UL beam sweeping, RAN1 should study and, if necessary, specify MPE-aware beam reporting. Proposal <NUM>: For UE supporting beam correspondence with the aid of UL beam sweeping, RAN1 should specify UE behavior on MPE-aware UL beam sweeping. Proposal <NUM>: RAN1 supports (CAT1. ) the UE reporting associated with an MPE and/or a potential/anticipated MPE event. Proposal <NUM>: Associate the P-MPR values with the spatial relation for UL transmission to mitigate the coverage loss due to the MPE. Proposal <NUM>: Introduce a panel-specific P-MPR reporting associated to a panel ID. Proposal <NUM>: To avoid UL MPE issue, it would be beneficial for RAN1 to study and, if necessary, specify the mechanism of UE triggered UL beam/panel switch. Proposal <NUM>: We suggest that definition of a UE panel and the related properties are addressed prior to further advancing discussions related to UE panel enhancements. Proposal <NUM>: A beam can be defined as a spatial filtering associated with one or two antenna ports carrying one or two layers separated in the polarization domain. Proposal <NUM>: RAN1 needs to study and specify (if necessary) whether additional signaling is necessary when a beam can support up to two independent layers separated by polarization.

Document 3GPP TS <NUM> V16. <NUM> may be construed to disclose details on the NR MAC protocol.

Document "<NUM> types of HO in NR", <NPL> may be construed to disclose an evaluation on the HO types: <NUM>) legacy LTE like handover; <NUM>) HO with no PDCP anchor change/reset and <NUM>) HO with only PDCP anchor change/reset while no RLC (and MAC) layer re-establishment is involved. Proposal <NUM>: Allow RRC connection reconfiguration without including PDCP configuration in the case of type <NUM> handover. Proposal <NUM>: Retransmission of PDCP PDUs after type <NUM> handover follows the LTE baseline behavior. Consider if fast retransmission schemes offer a worthwhile benefit over this baseline. Proposal 3a: Design NR solely security key change process as Type <NUM> handover. Proposal 3b: Design NR PCell <NUM> interruption switch by employing Type <NUM> handover in a DC architecture.

According to a first aspect of the present disclosure, there is provided a method of operating a communication device configured with a plurality of physical cell identifiers, PCIs, for a mobility procedure, a plurality of transmission configurations, and one or more cells, each cell operating in a same serving frequency and each cell associated with one or more PCIs. The method comprises receiving an indication of a transmission configuration to be activated, from the plurality of transmission configurations, that is associated with a non-serving cell or a non-serving PCI, from a network node; and determining to perform a media access control, MAC, reset operation based on the transmission configuration to be activated.

According to a second aspect of the present disclosure, there is provided a method of operating a network node in a communications network with a communication device that is configured with a plurality of physical cell identifiers, PCIs, for a mobility procedure, a plurality of transmission configurations, and one or more cells, each cell operating in a same serving frequency and each cell associated with one or more PCIs. The method comprises transmitting an indication of a transmission configuration to be activated from the plurality of transmission configurations that is associated with a non-serving cell or a non-serving physical cell identifier, PCI, to the communication device; and transmitting an indication to the communication device to perform the MAC reset based on the transmission configuration to be activated.

According to a third aspect of the present disclosure, there is provided a communication device adapted to perform all steps of a method according to the first aspect.

According to a fourth aspect of the present disclosure, there is provided a network node (<NUM>) adapted to perform all steps of a method according to the second aspect.

According to a fifth aspect of the present disclosure, there are provided computer program products each comprising a non-transitory storage medium (<NUM>, <NUM>) including either: program code to be executed by processing circuitry of a communication device, whereby execution of the program code causes the communication device to perform all steps of a method according to the first aspect; or program code to be executed by processing circuitry of a network node, whereby execution of the program code causes the network node to perform all steps of a method according to the second aspect.

Whenever in the following disclosure any of the above-stated aspects (corresponding to the independent claims) is disclosed as "optional" (e.g., due to usage of conjunctive terms, such as "can", "may", "should", etc.), it is nevertheless to be read as "mandatory".

Hereinabove and in the following, "examples" pertain to principles underlying the claimed subject-matter and/or being useful for understanding the claimed subject-matter, while "embodiments" pertain to the claimed subject-matter within the claim scope. In the drawings:.

Whenever in this description an "embodiment" is described, reference is to be made to the above figure list to determine whether this is to be read as "embodiment" or "example".

These embodiments are presented as teaching examples and are not to be construed as limiting the scope of the disclosed subject matter, which is defined by the appended claims.

In Rel-<NUM>, the third generation partnership project ("3GPP") is going to standardize what is called so far layer <NUM>/layer <NUM> ("L1/L2") centric inter-cell mobility (or L1-mobility, inter-physical cell identifier ("PCI") transmission configuration indicator ("TCI") state change/update/modification. This is justified in the Work Item Description ("WID") RP-<NUM> (further enhancements on multiple input multiple output ("MIMO") for NR) by the fact that while Rel-<NUM> manages to offer some reduction in overhead and/or latency, high-speed vehicular scenarios (e.g., a communication device traveling at high speed on highways) at FR2 require more aggressive reduction in latency and overhead (not only for intra-cell, but also for L1/L2 based inter-cell mobility).

Even though 3GPP has not decided how a L1/L2 based inter-cell mobility should be standardized, the understanding for the purpose of this specification is that the UE receives a L1/L2 signaling (instead of radio resource control ("RRC") signaling) indicating a transmission configuration indicator ("TCI") state (e.g. for physical downlink control channel ("PDCCH")) possibly associated to an synchronization signal block ("SSB") whose PCI is not necessarily the same as the PCI of the cell the UE has connected to e.g. via connection resume or connection establishment. Moreover, it may be the case that the frequency band and/or SSB absolute radio-frequency channel number ("ARFCN") of the current serving cell is also changed during the L1/L2 based inter-cell mobility procedure.

<FIG> is a schematic diagram illustrating an example of a wireless communications network in which a UE travels between different cells.

In some embodiments, a L1/L2 based inter-cell mobility procedure can be interpreted as a beam management operation expanding the coverage of multiple SSBs associated to multiple PCIs (e.g., possibly associated to the same cell or different cells), possibly being an inter-frequency beam management.

With the L1/L2 based inter-cell mobility procedurethere is two types of mobility for the UE. The layer <NUM> ("L3") mobility which is to/from these L1/L2 mobility clusters and the L1/L2 mobility within the cluster.

The L3 mobility is based on Cell defining SSB ("CD-SSB"). CD-SSB means that for a special cell ("spCell") there is one SBB on sync raster which is configured for the UE as the anchor for the cell. To change the CD-SSB, L3 mobility procedure (reconfig with sync) is needed. The PCI for the target cell SSB (referred to as phyCellld), or the serving cell after handover ("HO") (or initial access) is given in an information element ("IE") referred to as ServingCellConfigCommon. Then, depending whether the HO is intra or inter-frequency HO, the sync raster location may be given in an IE referred to as frequencylnfoDL.

For L3 mobility procedures there is always a media access control ("MAC") reset.

The L1/L2 based inter-cell mobility is as default based on L1 channel state information ("CSI")-measurements as it follows the existing beam management procedures.

Beam management in Release <NUM> NR was designed for a situation where multiple beams cover one cell. Due to the smaller coverage area of these narrow beams, it could be anticipated that a communication device would change beam more frequently than it changes cells. To reduce the signaling load for the beam switches, it was decided that RRC signaling would not be required to facilitate such changes. Instead, signaling solution based on Multiple MAC Control Element ("CE") or downlink control information ("DCI") have been introduced for beam management / intra-cell mobility. This is illustrated in <FIG>.

Three examples of sub-functionality to support beam management are the following: layer <NUM> reference signal received power ("L1-RSRP") reporting on SSB and channel state information reference signal ("CSI-RS"); MAC CE based activation/deactivation updates of beam indications, so-called Quasi-Co-Location ("QCL") source, explained in the following in more details); and Beam failure recovery/radio link monitoring/beam failure detection.

As these functionalities were designed to handle mobility without RRC involvement, they were limited to intra-cell operation. Various embodiments herein may focus on the functionality related to the MAC CE based updates of QCL source, i.e., beam indications.

Beam indications, QCL source, and TCI states are discussed now.

Several signals can be transmitted from the same base station antenna from different antenna ports. These signals can have the same large-scale properties, for instance in terms of Doppler shift/spread, average delay spread, or average delay, when measured at the receiver. These antenna ports are then said to be QCL.

The network can then signal to the communication device that two antenna ports are QCL so that the communication device interprets that signals from these will have some similar properties. If the communication device knows that two antenna ports are QCL with respect to a certain parameter (e.g., Doppler spread), the communication device can estimate that parameter based on a reference signal transmitted one of the antenna ports and use that estimate when receiving another reference signal or physical channel the other antenna port. Typically, the first antenna port is represented by a measurement reference signal such as a CSI-RS (sometimes referred to as a source RS) and the second antenna port is a demodulation reference signal ("DMRS") (sometimes referred to as a target RS) for physical downlink shared channel ("PDSCH") or PDCCH reception.

For instance, if antenna ports A and B are QCL with respect to average delay, the communication device can estimate the average delay from the signal received from antenna port A (sometimes referred to as the source RS) and assume that the signal received from antenna port B (sometimes referred to as a target RS) has the same average delay. This is useful for demodulation since the communication device can know beforehand the properties of the channel when trying to measure the channel using the DMRS, which may help the communication device in, for example, selecting an appropriate channel estimation filter.

Information about what assumptions can be made regarding QCL is signaled to the communication device from the network. In new radio ("NR"), four types of QCL relations between a transmitted source RS and transmitted target RS were defined:.

QCL type D was introduced to facilitate beam management with analog beamforming and is known as spatial QCL. There is currently no strict definition of spatial QCL, but the understanding is that if two transmitted antenna ports are spatially QCL, the communication device can use the same receive ("Rx") beam to receive them. This is helpful for a communication device that uses analog beamforming to receive signals, since the communication device needs to adjust its Rx beam in some direction prior to receiving a certain signal. If the communication device knows that the signal is spatially QCL with some other signal it has received earlier, then it can safely use the same Rx beam to also receive this signal. In some examples, for beam management, the discussion mostly revolves around QCL Type D, but it can also be necessary to convey a Type A QCL relation for the RSs to the communication device, so that it can estimate all the relevant large-scale parameters.

This can be achieved by configuring the communication device with a CSI-RS for tracking ("TRS") for time/frequency offset estimation. To be able to use any QCL reference, the communication device would have to receive it with a sufficiently good signal-to-interference-plus-noise ratio ("SINR"). In many cases, this means that the TRS has to be transmitted in a suitable beam to a certain communication device.

The concept of a TCI state is associated with the concept of a QLC source. Each of the M states in the list of TCI states can be interpreted as a list of M possible beams transmitted in the downlink from the network and/or a list of M possible TRPs used by the network to communicate with the communication device. The M TCI states can also be interpreted as a combination of one or multiple beams transmitted from one or multiple TRPs.

Each TCI state includes the previously described QCL information (e.g., one or two source downlink RS), where each source RS is associated with a QCL type. For example, a TCI state can include a pair of reference signals, each associated with a QCL type (e.g., two different CSI-RSs {CSI-RS1, CSI-RS2} are configured in the TCI state as {qcl-Type1,qcl-Type2} = {Type A, Type D}). The UE can derive the Doppler shift, Doppler spread, average delay, delay spread from CSI-RS1, and Spatial Rx parameter (e.g., the Rx beam to use) from CSI-RS2. In terms of RRC signaling, a TCI state is represented by an IE sometimes referred to as a TCI-State.

In a TCI-State IE definition, there is a field called cell. According to the definition in TS <NUM>, the field called cell in the QCL-Info configuration (i.e. cell field of IE ServCelllndex) is the communication device's serving cell in which the RS that is the QCL source is being configured. If the field is absent, it applies to the serving cell in which the TCI-State is configured (i.e. the special cell ("spCell") of the cell group, not an indexed SCell). The RS can be located on a serving cell other than the serving cell in which the TCI-State is configured only if the qcl-Type is configured as type D (see TS <NUM> section <NUM>.

In this case, it has been argued in R1-<NUM> "Lower-layer mobility enhancements" that the only thing that is needed for the communication device to be able to start receiving data on the physical layer in the target cell is that the QCL source is updated: this would enable the communication device to align to the target cell in an indicated direction to demodulate the bits and decode the data.

As mentioned above, the QCL source is included in the TCI-state. The TCI state includes pointers to reference signal(s). The reference signals are implicitly associated with a serving cell via a serving cell integer index: hence, in Rel-<NUM>, it is only possible to change QCL source to reference signals transmitted within a serving cell (SpCell or associated SCell within that SpCell group); it is not possible to change the QCL source to a reference signal in a non-serving cell.

To be able to use this functionality, it has been proposed in R1-<NUM> "Lower-layer mobility enhancements" to introduce an identifier of the non-serving cell in the QCL-info. The identifier of the non-serving cell can be the PCI.

If a PCI would be introduced in the QCL-info, the network ("NW") could update the QCL source to an RS in a non-serving cell. Once the indication command takes effect, the NW can directly start transmitting data over PDSCH from the new cell. Since the procedure is synchronized, the NW and the communication device have the same understanding of when the updated configuration takes effect. Thus, the interruption in data communication can be eliminated.

A MAC reset is performed at the MAC entity at the communication device and can be triggered by the upper layers in different situations, such as when a handover is performed (e.g., upon reception of an RRCReconfiguration including a Reconfiguration with Sync). The reset of MAC includes a set of actions such as stopping timers, flushing of buffers, etc., as specified in TS <NUM>. Agreements have been made in Release <NUM> and <NUM> concerning the feature.

During Release <NUM> agreements were made for multiTRP operation which is closely linked to L1 mobility as each of the PCIs in <FIG> can be seen as a TRP. The agreements included: <NUM>) RAN2 assumes that also in "non-ideal backhaul" scenarios, transmission from two TRPs is always slot/frame/SFN-aligned; and <NUM>) mPDCCH mTRP operation is supported via a single shared MAC entity.

For L3 mobility procedure, i.e. for a handover (SpCell change) /reconfiguration with sync (e.g., a primary cell ("PCell") or a primary secondary cell ("PSCell") change) the communication device always performs a MAC reset (e.g., higher layers trigger the MAC reset and the MAC entity at the communication device perform actions upon the trigger) as part of the procedure.

In Rel-<NUM>, with the introduction of L1/L2 based inter-cell mobility, the network should be able to indicate to the communication device, via L1/L2 signaling, a TCI state (e.g., by indicating a TCI identifier ("ID") configured via RRC) whose QCL source is associated to a non-serving cell, i.e. a cell different from a serving cell the communication device is connected to, like the PCell. One of the goals of introducing L1/L2 based inter-cell mobility is to improve service continuity and reduce interruption time as much as possible, i.e., in as many protocol layers as possible. Hence, performing the MAC reset for every L1/L2 based inter-cell mobility would increase the overhead in terms of latency as experienced by the UE. The MAC reset aspect has not been discussed earlier in context of L1 mobility.

It should be noted that the terms serving and non-serving cell have possibly alternative meaning to legacy interpretation. This is because of the formulation of the work item description for Rel-<NUM> MIMO uses the term non-serving cell in an undefined way. Some embodiments may refer to actual non-serving cell, to a plurality of serving cells configured for the communication device that are interpreted differently from carrier aggregation configuration, or to an additional SSB configured in a serving cell configuration which has a different PCI than the cell defining SSB of that serving cell.

Various embodiments herein define when a MAC reset is performed for L1 mobility. With the diverse definitions, there are options for how the L1 mobility is designed. In some procedures, the communication device does not need to perform the MAC reset upon every L1 mobility and does so only conditionally, thus increasing the gains in terms of latency at L1 mobility without MAC reset.

One of the advantages to add this flexibility is that the communication device can be configured with non-serving cells associated to a TRP in non-ideal backhaul with the TRP associated to a serving cell and/or non-serving cell associated to a different distributed unit ("DU") than the DU of the serving cell.

<FIG> is a block diagram illustrating elements of a communication device <NUM> (also referred to as a wireless device, mobile terminal, a mobile communication terminal, a wireless communication device, a wireless terminal, mobile device, a wireless communication terminal, a UE", a user equipment node/terminal/device, etc.) configured to provide wireless communication according to embodiments of inventive concepts. As shown, communication device <NUM> may include an antenna <NUM> and transceiver circuitry <NUM> (also referred to as a transceiver) including a transmitter and a receiver configured to provide uplink and downlink radio communications with a base station(s) of a radio access network. Communication device <NUM> may also include processing circuitry <NUM> (also referred to as a processor) coupled to the transceiver circuitry, and memory circuitry <NUM> (also referred to as memory) coupled to the processing circuitry. The memory circuitry <NUM> may include computer readable program code that when executed by the processing circuitry <NUM> causes the processing circuitry to perform operations according to embodiments disclosed herein, for example, the operations of <FIG>. According to other embodiments, processing circuitry <NUM> may be defined to include memory so that separate memory circuitry is not required. Communication device <NUM> may also include an interface (such as a user interface) coupled with processing circuitry <NUM>, and/or communication device <NUM> may be incorporated in a vehicle.

As discussed herein, operations of communication device <NUM> may be performed by processing circuitry <NUM> and/or transceiver circuitry <NUM>. For example, processing circuitry <NUM> may control transceiver circuitry <NUM> to transmit communications through transceiver circuitry <NUM> over a radio interface to a radio access network node (also referred to as a base station) and/or to receive communications through transceiver circuitry <NUM> from a RAN node over a radio interface. Moreover, modules may be stored in memory circuitry <NUM>, and these modules may provide instructions so that when instructions of a module are executed by processing circuitry <NUM>, processing circuitry <NUM> performs respective operations.

<FIG> is a block diagram illustrating elements of a radio access network RAN node <NUM> (also referred to as a network node, base station, eNodeB/eNB, gNodeB/gNB, etc.) of a Radio Access Network ("RAN") configured to provide cellular communication according to embodiments of inventive concepts. As shown, the RAN node may include transceiver circuitry <NUM> (also referred to as a transceiver) including a transmitter and a receiver configured to provide uplink and downlink radio communications with mobile terminals. The RAN node may include network interface circuitry <NUM> (also referred to as a network interface) configured to provide communications with other nodes (e.g., with other base stations) of the RAN and/or core network CN. The network node may also include processing circuitry <NUM> (also referred to as a processor) coupled to the transceiver circuitry, and memory circuitry <NUM> (also referred to as memory) coupled to the processing circuitry. The memory circuitry <NUM> may include computer readable program code that when executed by the processing circuitry <NUM> causes the processing circuitry to perform operations according to embodiments disclosed herein. According to other embodiments, processing circuitry <NUM> may be defined to include memory so that a separate memory circuitry is not required.

As discussed herein, operations of the RAN node may be performed by processing circuitry <NUM>, network interface <NUM>, and/or transceiver <NUM>. For example, processing circuitry <NUM> may control transceiver <NUM> to transmit downlink communications through transceiver <NUM> over a radio interface to one or more communication devices and/or to receive uplink communications through transceiver <NUM> from one or more communication devices over a radio interface. Similarly, processing circuitry <NUM> may control network interface <NUM> to transmit communications through network interface <NUM> to one or more other network nodes and/or to receive communications through network interface from one or more other network nodes. Moreover, modules may be stored in memory <NUM>, and these modules may provide instructions so that when instructions of a module are executed by processing circuitry <NUM>, processing circuitry <NUM> performs respective operations, such as the operations of <FIG>.

This disclosure uses the terminology in the NR specification as examples and refer to the Rel-<NUM>. However, this disclosure may also be applicable in the context of <NUM>th generation ("<NUM>") research, which is often label as Distributed-MIMO ("D-MIMO") and cell-less mobility. This may also be relevant for other multi-beam transmission schemes, such as in Tera Hertz communications system, which may be the case in some frequencies possibly allocated to <NUM> and/or <NUM>th generation ("<NUM>") enhancements.

The term "beam" can correspond to a reference signal that is transmitted in a given direction. For example, if may refer to an SS/PBCH Block or L3 configured CSI-RS in the following sub-section. During a half-frame, different SSBs may be transmitted in different spatial directions (i.e. using different beams, spanning the coverage area of a cell). That corresponds to different SSBs meaning different beams.

The term "TCI state" may also be considered as a synonym for beam in the sense that an indication of a TCI state can correspond to an indication of a beam, and/or an SSB index and/or a CSI-RS index.

The term "QCL" may also be considered as a synonym for beam in the sense that an indication of a QCL source associated to a TCI state can correspond to an indication of a beam, and/or an SSB index and/or a CSI-RS index.

The term PCI and/or PCI of an SSB cancorrespond to the PCI encoded by a Primary Synchronization Sequence/Signal ("PSS") and an a Secondary Synchronization Sequence/Signal ("SSS") that are comprised in an SSBas defined in TS <NUM>.

The "cells" or a "set of cells" with which the communication device can be configured to perform L1/L2 based inter-cell mobility may be called a set of intra-frequency neighbour cells (the communication device can perform measurements on and can perform a handover/reconfiguration with sync to), or a set of intra-frequency non-serving cells or simply a set of non-serving cells. These may be a set of inter-frequency neighbors that are non-serving cells wherein their SSB's frequency location (e.g. SSB ARFCN) are not in the same frequency location as a serving cell SSB frequency location (i.e. different ARFCN).

The terms CORESET and PDCCH configuration are used interchangeably to indicate a control channel configuration, including an indication of frequency and time locations the communication device monitors for scheduling from the network, e.g. when it is in Connected state. A CORESET can be defined as a time/frequency control resource set in which to search for downlink control information (see TS <NUM>, clause <NUM>).

The L1/L2 based inter-cell mobility refers to a procedure where the communication device change cells (e.g. changes SpCell, like PCell change or PSCell change) upon reception of a L1 and /or L2 signaling, such as upon the reception of a MAC CE.

Some embodiments herein focus on how to handle MAC reset for L1 mobility including two approaches which give the underlying assumptions for the embodiments that follow.

Even though the term "L1/L2 based inter-cell mobility" has the term "inter-cell", a fundamental aspect is that the configuration of the communication device (e.g., the serving cell configuration of the communication device) can have more than one PCI associated to it, and for that there are at least <NUM> approaches (or solutions) to create that association:
Approach <NUM> - Intra-cell multi-PCI L1/L2 based inter-cell mobility refers to the case where the same serving cell configuration is associated to more than one PCI (e.g. a TCI state configuration within ServingCellConfig can be associated to a PCI, wherein that can be different from the PCI in ServingCellConfigCommon). For a secondary node ("SN") Addition (or PSCell Addition) and/or SN Change (or PSCell Change) and/or, as proposed by the some embodiments of Approach <NUM>, the implication is that the SCG configuration the communication device receives (e.g. as an nr-scg within an MN RRCReconfiguration) contains the L1/L2 based inter-cell mobility configuration (e.g. ServingCellConfig with TCI states associated to PCI(s) that can be different from the PCI in ServingCellConfigCommon, and can be associated to non-serving cells). Currently, a communication device can receive a MAC CE from the network to indicate the TCI state to be associated to a given PDCCH configuration, while the PDCCH TCI state association can be provided via DCI. Upon reception, the communication device knows which TCI state (e.g. in which downlink beam PDCCH is being transmitted and should be monitored/received) is associated to a given PDCCH configured to be monitored. In other words, in a system where SS/PBSH Blocks are transmitted in different beams for a given cell with a given PCI, a TCI indication for a given PDCCH configurations triggers the communication device to monitor PDCCH in a given beam of that cell associated to its PCI, in this case, a beam / SSB of the serving cell where that TCI state is configured.

However, for this approach, in the context of L1/L2 based inter-cell mobility, for a given serving cell configuration, there can be a different PCI in a TCI state configuration compared to the PCI in ServingCellConfigCommon, e.g. PCI-<NUM>, which is an additional PCI e.g. PCI-<NUM>. In that case, the communication device receiving the MAC CE needs to determine the PCI associated to the indicated TCI, to determine the SSB (or CSI-RS) associated, hence, determine the downlink beam. If it receives a TCI with PCI indicating PCI-<NUM>, for example, the communication device needs to monitor PDCCH in a beam / SSB associated to PCI-<NUM>. The different PCIs (not the one in ServingCellConfigCommon) can be associated to non-serving cell(s).

Another way to configure the communication device is that in serving cell config (e.g. ServingCellConfig) communication device is configured with SSB sets that has other PCI associated to it. These SSB sets would have an index and in TCI state configuration an index of SSB set is referred to together with exact SSB beam index from that SSB set. It is possible these sets will be named differently to reflect "inter PCI candidates", thus SSB set index is an example of an RRC configuration specific ID given to the PCI(SSB set) to be used in the L1/L2 based inter-cell mobility in communication device's current RRC configuration.

Approach <NUM> - Inter-cell multi-PCI L1/L2 based inter-cell mobility refers to the case where the communication device has several serving cell configurations with respective PCIs associated but the TCI state may refer to other cell PCIs (e.g. other serving cell or, even a non-serving cell the communication device can move to with L1/L2 based inter-cell mobility). For an SN Addition (or PSCell Addition) and/or SN Change (or PSCell Change) and/or, as proposed by the method, the implication is that the SCG configuration the communication device receives contains a configuration prepared by a target node (e.g. a target gNodeB) that is associated to more than one cell (e.g. TCI state configurations can be associated to multiple cells' PCIs e.g. TCI state Id=<NUM> associated to PCI-x of cell A, TCI state Id=<NUM> associated to PCI-y of cell B, etc.). These multiple cells can be a serving cell and/or non-serving cell(s).

Currently, a communication devicecan assume that the QCL source of a configured TCI state is a RS associated to the serving cell's single configured PCI (i.e. the PCI in ServingCellConfigCommon). However, in Approach <NUM>, the communication device can be configured with a different PCI in the TCI state configuration wherein these PCIs are considered to be associated with different cells e.g. to non-serving cells. In that case, the communication device can have different serving cell configurations for these PCIs e.g. a set of ServingCellConfigCommon(s) that may be switched upon the change of serving cell via MAC CE.

In other words, the communication device is configured with a list of TCI states meaning that it is configured with a list of additional cells (e.g. non-serving cells configured for L1/L2 based inter-cell mobility), as the different PCIs are PCIs of different cells (each TCI state has its own PCI, but the same PCI may be used by multiple TCI states). These could be, for example, considered as some kind of serving cells e.g. if these are all in the same frequency (like same ARFCN for their SSB) these could be considered as intra-frequency serving cells, where one is considered to be active at the time (except if some form of multi-TRP transmission is enabled). Or, alternatively, these could be considered as non-serving cells, wherein the communication device can perform L1/L2 based inter-cell mobility.

Notice that what is called "changing cell" or "inter-cell" herein does not have the same meaning as changing serving cell as in legacy.

Operations of a communication device (implemented using the structure of the block diagram of <FIG> will now be discussed with reference to the flow chart of <FIG> according to some embodiments of inventive concepts. For example, modules may be stored in memory <NUM> of <FIG>, and these modules may provide instructions so that when the instructions of a module are executed by respective communication device processing circuitry <NUM>, processing circuitry <NUM> performs respective operations of the flow chart.

<FIG> illustrates an example of operations performed by a communication device that is configured with a plurality of PCIs for a mobility procedure, a plurality of transmission configurations, and one or more cells. Each of the cells can operate in a same serving frequency and each cell can be associated with one or more PCIs. In some examples, the mobility procedure is a Layer <NUM>/Layer <NUM>, L1/L2, based inter-cell mobility. In additional or alternative examples, the L1/L2 based inter-cell mobility includes a MAC control element, CE.

At block <NUM>, processing circuitry <NUM> receives, via transceiver <NUM>, a plurality of transmission configurations, which include a plurality of TCI state configurations, for a respective plurality of TCI states.

At block <NUM>, processing circuitry <NUM> receives, via transceiver <NUM>, an indication of a transmission configuration to be activated that is associated with a non-serving cell or a non-serving PCI. In some embodiments, receiving the indication of the transmission configuration to be activated that is associated with the non-serving cell or the non-serving PCI includes receiving an indication of a TCI state associated with a TCI state configuration of the plurality of TCI state configurations.

In additional or alternative embodiments, receiving the indication of the transmission configuration to be activated comprises receiving an indication of the second group ID. In some examples, radio resource control, RRC, configurations indicate a grouping of serving cell configurations and/or non-serving cell configurations among which layer <NUM>, L1, mobility may be performed.

In additional or alternative embodiments, the transmission configuration to be activated that is associated with the non-serving cell or the non-serving PCI includes an indication of a quasi-co-location, QCL, configuration. In some examples, the QCL configuration includes a reference signal configuration including at least one of a synchronization signal block, SSB, index and a channel state information reference signal, CSI-RS, index.

At block <NUM>, processing circuitry <NUM> determines to perform a MAC reset operation based on the transmission configuration to be activated. In some embodiments, determining to perform the MAC reset operation based on the transmission configuration to be activated includes determining to perform the MAC reset based on determining that layer <NUM>, L1, mobility occurred.

In additional or alternative embodiments, determining to perform the MAC reset operation includes determining that the communication device has moved from a first beam associated with a first group identifier, ID, to a second beam associated with a second group ID that is different than the first group ID.

In additional or alternative embodiments, the transmission configuration to be activated includes a field indicating that the communication device perform the MAC reset and determining to perform the MAC reset operation includes determining to perform the MAC reset operation based on the field.

In additional or alternative embodiments, determining to perform the MAC reset operation includes checking that an index in the transmission configuration to be activated is associated with the non-serving cell or non-serving PCI and determining to perform the MAC reset operation based on the index.

At block <NUM>, processing circuitry <NUM> performs a MAC reset operation. In some embodiments, a communication device always performs a MAC reset when L1 mobility takes place.

Various operations from the flow chart of <FIG> may be optional with respect to some embodiments of communication devices and related methods. For example, block <NUM> of <FIG> may be optional.

In some embodiments, when a communication device is configured with the plurality of PCIs, the communication device is configured with additional SSB/PCls within the serving cell configuration which may be linked to the TCI states which are thereafter used for the L1 mobility by MAC CE signaling, the SSB/PCls are grouped such that MAC reset is performed when the L1 MAC CE based mobility moves the communication device from the beam of one group to the beam of another group. The grouping may be based on SSB belonging to the same PCI. The grouping may be based on existing index in RRC called CORESETid. The grouping may be with a new group ID.

In some embodiments, there is an added field in the MAC CE that is used to perform the L1 mobility that indicates to the communication device that the communication device needs to do a MAC reset for the MAC entity that the PCI associated to the TCI state belongs to. That field may be set or not set, depending whether the network wants the communication device to perform the MAC reset or not. In one alternative that is the same MAC entity, still considered to be associated to the same cell group but reset upon the L1 mobility.

In some embodiments, the use of the above embodiments depends on whether the SSB/PCIs linked to a TCI state that is indicated in the MAC CE used for L1 mobility belong to the same DU or different DUs. The network (e.g. the serving DU) may determine to set the indication to the communication device for the MAC reset in the MAC upon L1/L2 based inter-cell mobility if the network has included in the MAC CE an indication of a TCI state associated to a non-serving cell/ PCI that is associated to a different DU. Notice that the serving DU knows this based on information on its neighbor relation (which may be placed in the DU). The network (serving DU) may also determine to set the indication to the communication device for MAC reset in the MAC upon L1/L2 based inter-cell mobility if the network is aware that the target cell/ PCI (indicated implicitly by the included TCI state ID) is not time aligned with the current serving cell (so that upon MAC Reset the time alignment timers are stopped as a consequence of the MAC Reset).

In some embodiments, the network configures the communication device with the conditions upon which the communication device needs to perform the MAC reset. Such a configuration could be part of the TCI state configurations or explicitly configured outside of TCI state configurations (e.g., a direct RRC configuration).

In one example, for each possible TCI state change pair (i.e., original TCI state - new TCI state at TCI state change), the configuration indicates whether the MAC reset is required or not (as illustrated below).

In this example, the communication device is considered to be initially served by PCI-<NUM>. The communication device then receives a MAC CE whose TCI state indicates TCI state id = <NUM>, then the communication device realizes that the serving PCI has been switched to PCI-<NUM> but the communication device also realizes that there is no need to perform the MAC reset as the transition from TCI state ID-<NUM> to TCI state ID-<NUM> does not require any MAC resetting operation. The communication device then receives a MAC CE whose TCI state indicates TCI state id = <NUM>, then the communication device realizes that the serving PCI has been switched to PCI-<NUM> and the communication device realizes that there is a need to perform the MAC reset as the transition from TCI state ID-<NUM> to TCI state ID-<NUM> needs the MAC resetting operation.

In another example, for each possible PCI change pair (i.e., original PCI - new PCI at TCI state change involving PCI changes), the configuration indicates whether the MAC reset is required or not (as illustrated below).

In this example the communication device is considered to be initially served by PCI-<NUM>. The communication device then receives a MAC CE whose TCI state indicates TCI state id = <NUM>, then the communication device realizes that the serving PCI has been switched to PCI-<NUM> but the communication device also realizes that there is no need to perform the MAC reset as the transition from PCI-<NUM> to PCI-<NUM> does not require any MAC resetting operation. The communication device then receives a MAC CE whose TCI state indicates TCI state id = <NUM>, then the communication device realizes that the serving PCI has been switched to PCI-<NUM> and the communication device also realizes that there is a need to perform the MAC reset as the transition from PCI-<NUM> to PCI-<NUM> needs the MAC resetting operation.

In some embodiments, a communication device always performs a MAC reset when L1 mobility takes place.

In some embodiments, as illustrated in <FIG>, the RRC configuration groups the serving cell/non-serving cell configurations among which L1 mobility may be performed such that MAC reset is performed when the L1 MAC CE based mobility moves the communication device from the beam of one group to the beam of another group. The grouping may be based on SSB belonging to the same PCI. The grouping may be based on existing index in RRC called CORESETid. The grouping may be with a new group ID.

At operation <NUM>, a RRC reconfiguration message is transmitted from a serving cell (Cell-A) <NUM> to the communication device <NUM>. At operation <NUM>, a RRC reconfiguration complete message is transmitted from the communication device <NUM> to the serving cell <NUM>.

At operation <NUM>, the communication device determines a mapping between a TCI state ID and a non-serving cell (Cell-B) <NUM>. At operation <NUM>, the serving cell <NUM> transmits a MAC CE with an indication of a TCI state to the communication device <NUM>.

At operation <NUM>, the communication device <NUM> determines the PCI and/or non-serving cell <NUM> for the indicated TCI state. At operation <NUM>, the communication device <NUM> determines that when moving from cell-A <NUM> to cell-B <NUM>, a MAC reset is required. At operation <NUM>, the communication device <NUM> performs the MAC reset.

At operation <NUM>, cell-B <NUM> transmits PDCCH / CORESET transmissions to the communication device <NUM>.

The ServingCellConfigCommon IE could be used to configure a non-serving cell for the purpose of L1/L2 based inter-cell mobility. According to some embodiments of Approach <NUM>, the non-serving cell configuration can also be associated to a reference, which can be the non-serving cell index (e.g. field nsCelllndex of IE NSCelllndex (see Table <NUM> below), which can be an integer to be later referred to in another configuration, such as in the TCI state configuration and/or within a list of TCI state configurations). The integer can be from <NUM> to a Max value (e.g. <NUM>), depending on the maximum number of non-serving cells that can be configured for L1/L2 based inter-cell mobility. Then, in each of these it may be indicated if a L1 mobility should trigger a MAC reset or not.

In another embodiment, as illustrated in <FIG>, there is an added field in the MAC CE that is used to perform the L1 mobility that indicates to the communication device that the communication device needs to do a MAC reset for the MAC entity that serving cell is pointed/indicated in the MAC CE used for L1 mobility.

Similarly to <FIG>, at operation <NUM>, a RRC reconfiguration message is transmitted from a serving cell (Cell-A) <NUM> to the communication device <NUM>. At operation <NUM>, a RRC reconfiguration complete message is transmitted from the communication device <NUM> to the serving cell <NUM>. At operation <NUM>, the communication device determines a mapping between a TCI state ID and a non-serving cell (Cell-B) <NUM>.

In contrast to <FIG>, at operation <NUM>, the serving cell <NUM> transmits a MAC CE with an indication of a TCI state (that includes the indication for a MAC reset) to the communication device <NUM>.

As a result of receiving the indication to perform the MAC reset, the communication device <NUM> can avoid operations <NUM> and <NUM> of <FIG> and proceed to operation <NUM>, which (similar to as in <FIG>) includes the communication device <NUM> performing a MAC reset. At operation <NUM>, cell-B <NUM> transmits PDCCH / CORESET transmissions to the communication device <NUM>.

In some embodiments, the use of the above embodiments depends on whether the serving cell configuration that is pointed in the MAC CE used for L1 mobility belong to the same distributed unit or different distributed units.

In some embodiments, a pre-configuration-based indication is provided indicating whether the MAC reset is required at the time of L1 mobility. In one embodiment, the network pre-configures the communication device with the conditions upon which the communication device needs to perform the MAC reset. Such a configuration could be part of the TCI state configurations or explicitly configured outside of TCI state configurations (e.g., a direct RRC configuration).

Similarly to as Approach <NUM>, in some examples, for each possible TCI state change pair (i.e., original TCI state - new TCI state at TCI state change), the configuration indicates whether the MAC reset is required or not.

Similarly to Approach <NUM>, in some examples, for each possible PCI change pair (i.e., original PCI - new PCI at TCI state change involving PCI changes), the configuration indicates whether the MAC reset is required or not.

Network embodiments are described below.

Operations of a network node (implemented using the structure of the block diagram of <FIG> will now be discussed with reference to the flow chart of <FIG> according to some embodiments of inventive concepts. For example, modules may be stored in memory <NUM> of <FIG>, and these modules may provide instructions so that when the instructions of a module are executed by respective RAN processing circuitry <NUM>, processing circuitry <NUM> performs respective operations of the flow chart.

<FIG> illustrates an example of a network node in a communications network with a communication device that is configured with a plurality of PCIs for a mobility procedure, a plurality of transmission configurations, and one or more cells. Each cell can operate in a same serving frequency and be associated with one or more PCIs. In some embodiments, the mobility procedure is a layer <NUM>/layer <NUM>, L1/L2, based inter-cell mobility. In some examples, the L1/L2 based inter-cell mobility includes a MAC control element, CE.

At block <NUM>, processing circuitry <NUM> transmits, via transceiver <NUM>, an indication of a plurality of transmission configurations to a communication device. In some embodiments, the plurality of transmission configurations include a plurality of transmission configuration indicator, TCI, state configurations for a respective plurality of TCI states.

At block <NUM>, processing circuitry <NUM> determines that the communication device should perform the MAC reset operation based on the transmission configuration to be activated. In some embodiments, determining that the communication device should perform the MAC reset operation includes determining to perform the MAC reset based on whether layer <NUM>, L1, mobility occurred.

In additional or alternative embodiments, determining that the communication device should perform the MAC reset operation includes determining whether multiple synchronization signal block or PCI within a transmission configuration belong to a same distributed unit or different distributed units.

In additional or alternative embodiments, determining that the communication device should perform the MAC reset operation comprises determining that the communication device has moved from a first beam associated with a first group identifier, ID, to a second beam associated with a second group ID that is different than the first group ID. In some examples, processing circuitry <NUM> assigns group IDs to groups of serving cell and/or non-serving cell configuration based on synchronization signal blocks belonging to a same PCI and/or based on an existing index in radio resource control, RRC.

At block <NUM>, processing circuitry <NUM> transmits, via transceiver <NUM>, a configuration to the communication device indicating under which L1 mobility possibilities the communication device should perform a MAC reset operation.

At block <NUM>, processing circuitry <NUM> transmits, via transceiver <NUM>, an indication of a transmission configuration to be activated that is associated with a non-serving cell or a non-serving PCI. In some embodiments, transmitting the indication of the transmission configuration to be activated includes transmitting an indication of a TCI state associated with a TCI state configuration of the plurality of TCI state configurations.

In additional or alternative embodiments, transmitting the indication of the transmission configuration to be activated that is associated with the non-serving cell or the non-serving PCI includes transmitting an indication of a quasi-co-location, QCL configuration. In some examples, the QCL configuration comprises a reference signal configuration including at least one of a synchronization signal block, SSB, index and a channel state information reference signal, CSI-RS, index.

In additional or alternative embodiments, the transmission configuration to be activated includes a field indicating that the communication device perform the MAC reset.

At block <NUM>, processing circuitry <NUM> transmits, via transceiver <NUM>, an indication to the communication device to perform a MAC reset operation based on the transmission configuration to be activated.

Various operations from the flow chart of <FIG> may be optional with respect to some embodiments of network nodes and related methods. For example, blocks <NUM>, <NUM>, and <NUM> of <FIG> may be optional.

In some embodiments, network embodiments relate to the on the fly configuration of whether the MAC resetting is required at the time of L1 mobility.

In additional or alternative embodiments, a network node can transmit a plurality of TCI state configurations (at least one) wherein at least one of the TCI state configurations has a QCL configuration (e.g. a reference signal configuration e.g. an SSB index and/or a CSI-RS index) associated to at least one non-serving cell/non-serving frequency. The network node can further transmit a MAC CE indicating one of the configured TCI states and determining that the QCL source reference signal is associated to a non-serving cell/non-serving PCI. The network node can further transmit a MAC CE indicating whether the communication device needs to performs the MAC resetting or not.

In some embodiments, network embodiments relate to the pre-configuration of whether the MAC resetting is required at the time of L1 mobility.

In additional or alternative embodiments, a network node can transmit a plurality of TCI state configurations (at least one) wherein at least one of the TCI state configurations has a QCL configuration (e.g. a reference signal configuration e.g. an SSB index and/or a CSI-RS index) associated to at least one non-serving cell/non-serving frequency. The network node can further transmit a configuration (either via RRC based or a MAC configuration) indicating whether the communication device needs to perform the MAC resetting or not at different L1 mobility possibilities. The network node can further transmit a MAC CE indicating one of the configured TCI states and determining that the QCL source reference signal is associated to a non-serving cell/non-serving PCI.

The term "and/or" (abbreviated "/") includes any and all combinations of one or more of the associated listed items.

As used herein, the terms "comprise", "comprising", "comprises", "include", "including", "includes", "have", "has", "having", or variants thereof are openended, and include one or more stated features, integers, elements, steps, components or functions but does not preclude the presence or addition of one or more other features, integers, elements, steps, components, functions or groups thereof.

Claim 1:
A method of operating a communication device configured with a plurality of physical cell identifiers, PCIs, for a mobility procedure, a plurality of transmission configurations, and one or more cells, each cell operating in a same serving frequency and each cell associated with one or more PCIs, the method comprising:
receiving (<NUM>) an indication of a transmission configuration to be activated, from the plurality of transmission configurations, that is associated with a non-serving cell or a non-serving PCI, from a network node; and
determining (<NUM>) to perform a media access control, MAC, reset operation based on the transmission configuration to be activated.