Communication method

Abstract

A communication system is disclosed in which one or more procedures / techniques are implemented to support event-triggered layer 1 (L1) / layer 2 (L2) triggered mobility (LTM) measurement reporting.

Description

COMMUNICATION METHOD

[0001] The present disclosure relates to a communication system and to parts thereof. The disclosure has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards or equivalents or derivatives thereof (including Long-Term Evolution (LTE)-Advanced, Next Generation or 5G networks, future generations, and beyond). The disclosure has particular, although not necessarily exclusive, relevance to enhanced mechanisms and procedures for supporting event-triggered layer 1 (L1) / layer 2 (L2) triggered mobility (LTM) measurement reporting (which may also be referred to as L1 measurement reporting).

[0002] Earlier developments of the 3GPP standards were referred to as the Long-Term Evolution (LTE) of Evolved Packet Core (EPC) network and Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN), also commonly referred as '4G'. More recently, the term '5G' and 'new radio' (NR) is used to refer to an evolving communication technology that supports a variety of applications and services. Various details of 5G networks are described in, for example, the 'NGMN 5G White Paper' V1.0 (NPL1). 3GPP intends to support 5G by way of the so-called 3GPP Next Generation (NextGen) radio access network (RAN) and the 3GPP NextGen core network.

[0003] Under the 3GPP standards, a NodeB (or an eNB in LTE, and gNB in 5G) is the radio access network (RAN) node (or simply 'access node', 'access network node' or 'base station') via which communication devices (user equipments or 'UEs') connect to a core network and communicate with other communication devices or remote servers. For simplicity, the present application may use the term access network node, RAN node (or simply RAN) or base station to refer to any such access nodes.

[0004] For simplicity, the present application will use the term mobile device, user device, or UE, to refer to any communication device that is able to connect to the core network via one or more RAN nodes. Although the present application may refer to mobile devices in the description, it will be appreciated that the technology described can be implemented on any communication devices (mobile and / or generally stationary) that can connect to a communication system for sending / receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory. For example, such a communication device may be operable by a human or may be a partially or fully automated (e.g., machine-type-communication (MTC) / Internet of Things (IoT)) device.

[0005] In the current 5G architecture, the RAN architecture may be distributed with the RAN node structure split into two or more parts. In some RAN implementations there are two parts, known as the Central Unit (CU or gNB-CU) - sometimes referred to as a 'control unit' - and the Distributed Unit (DU or gNB-DU), connected by an F1 interface. This enables the use of a 'split' architecture in which the typically 'higher' CU layers (for example, but not necessarily or exclusively, Packet Data Convergence Protocol (PDCP) and Radio Resource Control (RRC) layers) and the, 'lower' DU layers (for example, but not necessarily or exclusively, Radio Link Control (RLC), Media (sometimes referred to as 'Medium') Access Control (MAC), and Physical (PHY) layers) are separated between a particular CU, and one or more DUs that are connected to and controlled by that CU via the F1 interface. Thus, for example, the higher layer CU functionality for a number of RAN nodes may be implemented centrally (for example, by a single processing unit, or in a cloud-based or virtualised system), whilst retaining the lower layer DU functionality locally separately for each RAN node.

[0006] In more recently proposed RAN distributed architectures, in addition to the CU and DU, the concept of a Radio Unit (RU) - sometimes referred to as a 'remote unit' - has been introduced. In this architecture the RU is responsible for handling the digital front end (DFE), digital beamforming functionality and, typically, the functionality of the lower parts of the PHY layer, whilst the DU typically handles the higher parts of the PHY layer and the RLC and MAC layers. The CU in this architecture continues to be responsible for controlling one or more DUs (each DU corresponding to a different respective gNB) and to handle higher layer signalling (typically RRC and PDCP layers).

[0007] The actual functional split between the CU and DUs (and potentially RUs where applicable) of these distributed architectures is flexible allowing the functionality to be optimised for different use cases. Effectively, the split architecture enables a 5G network to use a different distribution of protocol stacks between CU and DUs (and potentially RUs) depending on, for example, midhaul availability and network design.

[0008] The choice of how to split functions in the architecture depends on, among other things, factors related to radio network deployment scenarios, constraints and intended supported use cases. Key considerations include: the need to support a specific quality of service for each service offered and for real / non-real time applications; support of specific user density and load demand in a given geographical area; and available transport networks with different performance levels.

[0009] In 5G, core network entities comprise logical nodes (or 'functions') including control plane functions (CPFs) and one or more user plane functions (UPFs). The CPFs include, amongst other things, one or more Access and Mobility Management Functions (AMFs), a session management function (SMF), an Authentication Server Function (AUSF), a Unified Data Management (UDM) entity for managing user specific data, a Policy Control Function (PCF), an Application Function (AF), a Security Anchor Function (SEAF), an Authentication credential Repository and Processing Function (ARPF), and / or the like. The AMF generally corresponds to the mobility management entity (MME) in 4G and performs many of the functions performed by the MME. Each UPF combines functionality of both the S-GW and P-GW - specifically user plane functionality of the S-GW (SGW-U) and user plane functionality of the P-GW (PGW-U). The SMF provides session management functionality (that formed part of MME functionality in 4G). The SMF also combines the some of the functionality provided by the S-GW and P-GW - specifically control plane functionality of the S-GW (SGW-C) and control plane functionality of the P-GW (PGW-C). The SMF also allocates IP addresses to each UE.

[0010] With the increasing usage of mobile communication for a wide range of different use cases, additional frequencies and bands are needed to accommodate this increasing demand. Accordingly, a variety of different frequency bands are available for 5G NR. These frequency bands include many of the existing frequency bands used by previous generations of telecommunication technology and many new frequency bands including bands in the millimetre wave region. The bandwidth available for frequency bands in the millimetre wave region is very much higher than for frequency bands used by earlier generations and thus allow for greater data speeds to be achieved albeit at the expense of the range of the signals.

[0011] The available frequency bands are grouped into two different frequency ranges referred to as frequency range 1 (FR1) containing the lower frequency bands and frequency range 2 (FR2) containing the higher frequency bands. FR1 bands are likely to carry much of the traditional cellular mobile communication traffic whereas the FR2 bands are aimed at providing short range very high data rate capability for 5G radio. Originally the FR1 band was intended to define bands below 6 GHz, but with anticipated additional spectrum allocations, the FR1 range has now been extended to 7.125 GHz.

[0012] Historically, communication systems have employed two core duplex schemes - frequency division duplex (FDD) and time division duplex (TDD). In FDD the frequency domain resource is split between downlink (DL) and uplink (UL) whereas in TDD the time domain resource is split between DL and UL. The appropriate duplex scheme to be used in a given scenario is broadly spectrum dependent, albeit with some overlap. Where lower frequency bands are used for communication, paired spectrum UL and DL resource allocations are generally employed and hence FDD is used. In contrast, for higher frequency bands the use of unpaired spectrum, and hence TDD, is becoming increasingly prevalent. Thus, TDD is widely used in commercial NR deployments.

[0013] The coverage in 5G is primarily beam-based rather than cell based. There is no cell-level reference channel from where the coverage of the cell could be measured. Instead, each cell has one or more so-called synchronisation signal (SS) / physical broadcast channel (PBCH) block (SSB) beams. SSB beams form a matrix of beams covering an entire cell area. Each SSB beam carries an SSB comprising a primary synchronisation signal (PSS), secondary synchronisation signal (SSS), and physical broadcast channel (PBCH).

[0014] The UE searches for and performs measurements on the SSB beams. The measurements may, for example, be performed on the synchronisation signals carried by the SSB (e.g. of the synchronisation signal reference signal received power, 'SS-RSRP', synchronisation signal reference signal received quality, 'SS-RSRQ', and / or the synchronisation signal to noise or interference ratio, 'SS-SINR').

[0015] The UE maintains a set of candidate beams which may contain beams from multiple cells, and so a physical cell identifier (PCI) and beam ID (or SSB index) may be used to distinguish the SSB beams from one another. Effectively, therefore, the SSB beams are like mini cells which may be within a larger cell. Once a UE has detected and selected an SSB beam (e.g., based on the SSB measurements) it may attempt to access that cell and / or SSB beam using an initial RRC connection setup procedure comprising a random-access procedure.

[0016] Following selection of an initial SSB beam, measurements may also be performed on reference signals (RS) transmitted via a selected SSB beam for beam refinement purposes (for example on channel state information (CSI) RSs (CSI-RSs)). Specifically, reference signals (e.g., CSI-RSs) may be transmitted in different directions using finer (narrower) beams (which may be called CSI-RS beams) within the angular range of the SSB beam selected during an initial acquisition process.

[0017] The UE may attempt to access a cell via a selected beam using a contention-based random-access (CBRA) procedure that typically involves four distinct steps. Prior to attempting initial access the UE may perform transmission of a selected preamble (or 'signature') to a RAN node over a physical random-access channel (which may be referred to either as a 'PRACH' or a 'RACH' - the term (P)RACH will be used herein) for initiating a random-access procedure (also referred to as a (P)RACH procedure, or simply (P)RACH) for obtaining synchronisation in the uplink (UL). A so-called two-step random-access procedure has also been developed (in addition to the above described four-step random-access procedure). The two-step random-access is mainly intended for supporting (Ultra) Low Latency Communication, 10ms control plane latency, fast handover, efficient channel access in unlicensed spectrum, and transmission of small data packets, amongst other things. However, it may also apply to large cells such as non-terrestrial cells. The main difference is that whilst the four-step random-access procedure requires two round-trip cycles between the UE and the base station, the two-step random-access procedure aims to reduce latency and control-signalling overhead by using a single round trip cycle between the UE and the base station.

[0018] As those skilled in the art will appreciate, while a CBRA procedure is mentioned above, a non-contention based / 'contention free' random-access (CFRA) procedure may also be used in which a dedicated preamble is assigned by the RAN node to the UE.

[0019] NPL 1:'NGMN 5G White Paper' V1.0, the Next Generation Mobile Networks (NGMN) Alliance, February 2015, https: / / ngmn.org / wp-content / uploads / NGMN_5G_White_Paper_V1_0.pdf

[0020] Historically, mobility between different cells was based on communication at higher layers, such as layer 3 (e.g., the L3 or radio resource control (RRC) layer) signalling. More recently support for layer 1 (e.g., the L1 or physical (PHY) layer) and / or layer 2 (e.g., the L2 or media access control (MAC) layer) centric mobility (also referred to as L1 / L2 centric mobility) has been developed, with a view to providing enhanced mobility. Such L1 / L2 centric mobility (also referred to as L1 / L2 triggered mobility or 'LTM') has prospects for improving mobility for devices operating both below 7 GHz and in mmWave bands, for example by supporting lower handover latency and improved robustness.

[0021] However, whilst current mobility procedures are generally effective and have been deployed successfully, they are not without potential technical issues. Such issues are particularly prevalent when the UE is moving rapidly and / or is moving in areas where coverage can change dramatically in a relatively short distance (e.g., because of human made structures, or natural physical features of the land, acting as a barrier to radio waves). For example, for L3 triggered mobility, after a decision to trigger handover based on L3 measurements is made, radio signal conditions may change before (or during) handover execution. This could potentially lead to there being a significant communication quality gap between when the measurements were performed and when handover execution occurs (e.g., based on UE and / or cell movement, and / or other factors) thereby increasing the chance of a handover failure or incorrect handover (e.g., to a non-optimum target cell). Similarly, disparities between the radio signal conditions at measurement and the radio signal conditions at handover may lead to handover occurring at a non-optimum time (e.g., too early or too late), or unnecessary handover occurring.

[0022] In respect of LTM based mobility, whilst a cell switch / handover decision is based on more 'real-time' measurement reporting (and hence alleviates some potential issues that may occur in an L3 triggered mobility-based handover), the use of L1 measurement reporting causes a relatively large amount of signalling overhead. For example, handover decisions based on an instant L1 measurement report (i.e., a measurement report that has not been subject to L3 filtering by the UE), may be rapidly followed by a similar decision in the new cell to handover back to the previous cell. Hence, unnecessary handovers and so called 'ping-pong' handovers may occur, thereby increasing measurement report and other signalling overhead significantly.

[0023] In earlier developments of LTM, the L1 measurement reporting for LTM supported RAN node-scheduled periodic, semipersistent, and aperiodic reporting. As SSBs are transmitted periodically, it is envisaged that the main mechanism for L1 measurement reporting in which the UE conducts L1 measurements of beams in candidate cells and transmits the measurement results using periodic uplink resources. However, periodic L1 measurement reporting may lead to unnecessary power consumption and increased signalling overhead. For example, if a potential candidate cell is not suitable (e.g., because of low signal strength), the network will not switch the UE to that cell, making the L1 measurement report for such a candidate cell redundant and wasteful.

[0024] More recently, to address this issue, event-triggered reporting is being developed. In this approach, the UE evaluates specific conditions, such as whether the beam from a candidate cell exceeds a predefined threshold and only reports that beam if the condition is fulfilled thereby reduces power consumption and reporting overhead compared to periodic reporting.

[0025] In LTM procedures, it is currently envisaged that LTM event-triggered measurement reports may be used to assist the network to select a candidate beam of a candidate cell to trigger early synchronisation, to select the target beam / cell, and to trigger an LTM cell switch procedure.

[0026] The LTM event-triggered measurement reporting may support measurements on SSB and / or CSI-RS resources corresponding to beams of one or more candidate beam sets (e.g., a plurality of candidate beam sets for the same and / or different cells). The SSB and / or CSI-RS resources may, for example, be configured by one or more associated LTM resource configurations (e.g., defined by an LTM-CSI-ResourceConfig IE or the like). The LTM resource configuration / configurations may be provided as part of a corresponding LTM reporting configuration (e.g., defined by an LTM-CSI-ReportConfig IE or the like). The occurrence of an LTM event is based on an L1 beam level measurement result.

[0027] A number of different LTM events may be configured at the UE by a RAN node (e.g., with multiple LTM reporting configurations), and evaluated based on a beam specific quality of the serving cell and / or of one or more candidate cells. The events may include, for example: 　　- Event LTM2: which occurs when a beam specific quality of a (serving) beam of the UE's serving cell (which may sometimes be referred to as the UE's "current beam") becomes worse than an absolute threshold; 　　- Event LTM3: which occurs when a beam specific quality of a beam of a candidate cell becomes an 'offset' amount better than a (serving) beam of the UE's serving cell; 　　- Event LTM4: which occurs when a beam specific quality of a beam of a candidate cell becomes better than an absolute threshold; and 　　- Event LTM5: which occurs when a beam specific quality of a (serving) beam becomes worse than a first absolute threshold (threshold1) AND a beam of a candidate cell becomes better than a second absolute threshold (threshold2).

[0028] For these LTM events, any beam associated with a candidate reference signal (RS) (e.g., SSB or CSI-RS) resource configuration in the LTM reporting configuration may be used for LTM event evaluation for a candidate cell. For event LTM3 and LTM5, the event evaluation is based on the measurement result of the same type of RS for both the serving cell and the candidate cell, and the current (serving) beam (e.g., a beam corresponding to an indicated transmission configuration indication (TCI) state) is used for LTM event evaluation for the serving cell.

[0029] A given UE may be configured with a plurality of different LTM reporting configurations (e.g., each defined by a respective LTM-CSI-ReportConfig IE or the like) - for example: to link the same set of one or more beams and / or set of one or more cells to different configured events; or to link different sets of one or more beams and / or sets of one or more cells to the same or different configured events.

[0030] When an LTM event condition is continuously met during a given time-to-trigger (TTT) duration / window (i.e., for the serving / current beam and / or for the same beam of the same candidate cell), the UE triggers corresponding LTM measurement reporting by initiating a transmission of a MAC control element (CE) including the event-triggered L1 measurement report. The MAC CE carrying the measurement report may be referred to as an LTM measurement reporting (MR) MAC CE ('LTM MR MAC CE') or by any other suitable name.

[0031] In addition to being able to configure triggering of an LTM measurement report by meeting an entering condition for a given event, the RAN node may also configure LTM measurement reporting triggered by meeting a leaving condition for a given event. Moreover, in addition to being able to configure triggering of an individual LTM measurement report by fulfilling one or more conditions for a given event, the RAN node may also configure LTM event-triggered periodic (or 'event-periodic') LTM measurement reporting. For example, when one or more (e.g., entering) conditions for an event have been fulfilled, L1 measurement reporting for that event may occur on a periodic basis (e.g., based on expiry of, or fulfilment of one or more conditions based on, a periodic reporting timer) - e.g., until one or more further (e.g., leaving or number of transmission) conditions are fulfilled (or when one or more original conditions are no longer fulfilled).

[0032] The MAC CE including the event-triggered L1 measurement report (e.g., LTM MR MAC CE) may, for example, include all (or a subset) of the following information: 　　- Triggered event information (e.g., an LTM channel state information (CSI) report configuration identifier (e.g., a 'ReportConfigID') or the like); 　　- Beam information (e.g., an SSB resource set index ('SSBRI') and / or a CSI-RS resource indicator (CRI) identifying a corresponding CSI-RS and hence CSI-RS beam); 　　- Beam quantity (e.g., L1 reference signal received power (L1-RSRP), or signal to interference plus noise ratio (SINR) of a given number (N) of beams); 　　- The information and quantity of a current beam (e.g., based on a network configuration)

[0033] The MAC CE including the event-triggered L1 measurement report (e.g., LTM MR MAC CE) may include up to a maximum number (N) beams for event-triggered L1 measurement reporting (where 'N' may be configured by the RAN node).

[0034] For the transmission of the MAC CE including the event-triggered L1 measurement report (e.g., LTM MR MAC CE), if there is no available uplink resource (e.g., physical uplink shared channel (PUSCH) resource for the transmission), an appropriate scheduling request (SR) procedure may be applied to request uplink resource allocation. In this context, the RAN node can configure a dedicated SR configuration for the transmission of the MAC CE including the event-triggered L1 measurement report (e.g., LTM MR MAC CE).

[0035] A MAC layer entity at the UE handles the entire LTM event evaluation, and the reporting procedure for transmission of the MAC CE including the event-triggered L1 measurement report (e.g., LTM MR MAC CE). The LTM event evaluation is based on the latest L1 measured results reported by the L1 (PHY) layer.

[0036] For event-triggered L1 measurement reporting, the RAN node may control if one or more beams for which a measured beam quantity (e.g., RSRP and / or SINR) does not satisfy the conditions for a given reporting event (if any) could, nevertheless, be reported (e.g., together with the beam / beams that do satisfy the conditions) in the L1 measurement report (e.g., in the LTM MR MAC CE) - for example, up to the maximum number (N) of beams.

[0037] However, it is generally accepted, that more than one of the same type of MAC CE cannot be included in the same transport block (TB) transmission. This represents a challenge for reporting the results for, potentially, multiple beams / sets of beams for the same or different cells and / or for the same or different LTM events.

[0038] This issue is complicated by the possibility that, as an uplink grant for reporting following occurrence of a given LTM event may not be available immediately, other events may be triggered and / or conditions fulfilled while the UE is awaiting the uplink grant.

[0039] For example, while the UE is waiting for an uplink grant in respect of a given LTM event-triggered for one beam, the same LTM event may be triggered for another beam. For example, a first LTM report configuration having a first LTM report configuration identity (e.g., an ltm-CSI-ReportConfigId IE equal to a first value 'x') may be triggered by a first beam ('i') and then by a second beam ('j') later.

[0040] Alternatively (or additionally) while the UE is waiting for an uplink grant in respect of a given LTM event-triggered for one beam, a different LTM event might be triggered by a different beam / the same beam. For example, a first LTM report configuration having a first LTM report configuration identity (e.g., an ltm-CSI-ReportConfigId IE equal to a first value 'x') may be triggered by a first beam ('i'), and later a second LTM report configuration having a second LTM report configuration identity (e.g., an ltm-CSI-ReportConfigId IE equal to a first value 'y') may be triggered by the first beam ('i') or by a second beam ('y').

[0041] Alternatively (or additionally) while the UE is waiting for an uplink grant in respect of a given LTM event-triggered for a beam, a leaving condition may be fulfilled for that LTM event. For example, the leaving condition for a first LTM report configuration having a first LTM report configuration identity (e.g., an ltm-CSI-ReportConfigId IE equal to a first value 'x') may be is fulfilled for a first beam ('i').

[0042] Alternatively (or additionally) one candidate beam may trigger a plurality of configured events while the UE is waiting for an uplink grant. For example, a first LTM report configuration having a first LTM report configuration identity (e.g., an ltm-CSI-ReportConfigId IE equal to a first value 'x') and a second LTM report configuration having a second LTM report configuration identity (e.g., an ltm-CSI-ReportConfigId IE equal to a first value 'y') may both be triggered by the same beam ('i').

[0043] By way of example, a number of possible hypothetical scenarios that might arise in the context of event-triggered measurement reporting will now be described in more detail. In a first example scenario, a first L1 measurement report (e.g., an LTM CSI report) is triggered at a first timepoint (T1) by occurrence of a first event - e.g. due to fulfilment of one or more conditions for the first event and / or due to expiry of, or fulfilment of one or more conditions based on, a periodic reporting timer.

[0044] A second L1 measurement report (e.g., an LTM CSI report) may then be triggered at a second, subsequent, timepoint (T2) by occurrence of a second event - e.g. due to fulfilment of one or more conditions for the second event and / or due to expiry of, or fulfilment of one or more conditions based on, a periodic reporting timer.

[0045] At a third timepoint (T3), after timepoints T1 and T2, an uplink grant is received at the UE indicating uplink resources to be used for L1 measurement reporting.

[0046] It can be seen that, in this first scenario, a question arises as to whether the uplink grant will provide sufficient uplink resources for reporting the L1 measurement results for both triggered events. If insufficient uplink resources are provided by the UL grant a question arises as to which L1 measurement results should be reported, and how those L1 measurement results should be reported. Moreover, even where there are sufficient uplink resources to do so, a question arises as to how the L1 measurement results for both triggered events should be reported either in the same MAC CE, or in separate MAC CEs.

[0047] In a second example scenario, at a first timepoint (T0), a first L1 measurement report, associated with a first LTM reporting configuration (e.g., LTM-CSI-ReportConfig#1), is triggered. Then, at a second, subsequent, timepoint (T1) the UE sends an associated MAC CE including the L1 measurement report associated with the first LTM reporting configuration. At a third timepoint (T2), after timepoints T0 and T1, a second L1 measurement report, associated with a second LTM reporting configuration (e.g., LTM-CSI-ReportConfig#2), is triggered.

[0048] In this second scenario, a question arises as to whether, when the second L1 measurement report, associated with a second LTM reporting configuration (e.g., LTM-CSI-ReportConfig#2), is triggered, whether the UE should still send the L1 measurement report (MAC CE) associated with a first LTM reporting configuration also (e.g., in accordance with event-periodic reporting or the like). Moreover, if both L1 measurement reports should be sent, but the associated uplink grant does not provide sufficient resource for both, the question arises as to which L1 measurement report should be prioritised, and what should the UE do after only reporting one of those L1 measurement reports.

[0049] In a third example scenario, the UE may be configured with multiple LTM reporting configurations (e.g., LTM-CSI-ReportConfigId #1 and LTM-CSI-ReportConfigId #2) for the same candidate cell (e.g., for different events for the same cell). In this case it is possible that more than one event for the same candidate cell will be satisfied at, or nearly at, the same time. In this case the question arises as to what the UE should report and how reporting should be handled in the event that the uplink grant does not provide sufficient resources for providing L1 measurement reporting for both events.

[0050] In a fourth example scenario, at a first timepoint (T0), a first L1 measurement report, associated with a first LTM reporting configuration (e.g., LTM-CSI-ReportConfig#1) is triggered in respect of a beam for a first candidate cell. The UE requests an associated uplink grant. While waiting for that uplink grant, at a second timepoint (T2), a second L1 measurement report, associated with a second LTM reporting configuration (e.g., LTM-CSI-ReportConfig#2) is triggered in respect of a beam for a second candidate cell. At a third timepoint (T3), after timepoints T1 and T2, an uplink grant is received at the UE indicating uplink resources to be used for L1 measurement reporting. In this scenario, the question arises as to how the UE should handle L1 measurement reporting in the case where the UE attempts to include the L1 measurement results for both LTM reporting configurations (e.g., LTM-CSI-ReportConfig#1 and LTM-CSI-ReportConfig#2).

[0051] Given the potential complexity associated with the above (and other similar) scenarios, and the constraints on the transmission of measurement reporting MAC CEs, therefore, there are a number of issues that still need to be addressed.

[0052] For example, there is a need to define the format of the MAC CE that carries the event-triggered L1 measurement report (e.g., LTM MR MAC CE) taking into account the possibility of a plurality of configured LTM events (leaving or entering) may have been triggered when the TTT duration has completed and the uplink grant becomes available for transmission of the MAC CE.

[0053] There is also a need to define an efficient mechanism for determining when to trigger transmission of the MAC CE that carries the event-triggered L1 measurement report (e.g., LTM MR MAC CE) and / or when to cancel transmission of the MAC CE, to avoid transmission of unnecessary reports whilst still ensuring transmission of necessary reports.

[0054] Moreover, there is also a need to define appropriate mechanisms and procedures for supporting LTM event-triggered periodic (or 'event-periodic') L1 measurement reporting.

[0055] Moreover, given the constraints on the transmission of the MAC CE that carries the event-triggered L1 measurement report (e.g., LTM MR MAC CE), there is a need to define an efficient mechanism for determining what information should (and should not) be included in the MAC CE. Specifically, there is a need to define how to sort and / or select for which beams, cells, LTM reporting configurations, events, entering and / or leaving conditions, associated L1 measurement results should be included in the MAC CE. For example, in the event that there is a need to truncate the information included in the MAC CE (e.g., due to limited uplink resource / TB size for transmission of the MAC CE), then there is a need to prioritise which L1 measurement results to include in the MAC CE. Similarly, in the event that multiple MAC CEs may be constructed that each include respective L1 measurement results for different beams, cells, LTM reporting configurations, events, entering and / or leaving conditions, there is a need or to prioritise which of those MAC CEs to include first.

[0056] The disclosure aims to describe one or more apparatus and / or one or more associated mechanisms / procedures that at least partially addresses or contributes to meeting one or more of the above needs and / or to addressing one or more of the above issues.

[0057] In one aspect, the present disclosure provides a method performed by a User Equipment, UE, the method comprising: receiving, from a network node, a Radio Resource Control, RRC, message comprising a first ID identifying a first configuration to configure the UE to perform an L1 measurement; performing the L1 measurement; during a procedure for reporting the L1 measurement, maintaining one or more lists comprising: a first list indicating a first set of one or more beams for which an entry condition corresponding to the first ID is fulfilled; and a second list indicating a second set of one or more beams for which a leaving condition corresponding to the first ID is fulfilled; and triggering, based on the L1 measurement, an L1 measurement report to the network node.

[0058] In one aspect, the present disclosure provides a method performed by network node, the method comprising: transmitting, to a User Equipment, UE, a Radio Resource Control, RRC, message comprising a first ID identifying a first configuration to configure the UE to perform an L1 measurement, wherein, during a procedure for reporting the L1 measurement, one or more lists are maintained by the UE, and the one or more lists comprise: a first list indicating a first set of one or more beams for which an entry condition corresponding to the first ID is fulfilled; and a second list indicating a second set of one or more beams for which a leaving condition corresponding to the first ID is fulfilled; and receiving, from the UE, an L1 measurement report based on the L1 measurement.

[0059] Various examples described below may be implemented by means of a computer program product comprising computer implementable instructions for causing a programmable computer to carry out any of the methods described below. The computer implementable instructions may be provided as a signal or on a tangible computer readable medium.

[0060] Example embodiments of the disclosure will now be described, by way of example, with reference to the accompanying drawings in which:Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') communication system;Fig. 2 illustrates a typical frame structure that may be used in the communication system of Fig. 1;Fig. 3 is a simplified sequence diagram illustrating an L3 triggered mobility procedure that may be implemented in the communication system of Fig. 1;Fig. 4 is a simplified sequence diagram illustrating an L1 / L2 triggered mobility (LTM) procedure that may be implemented in the communication system of Fig. 1;Fig. 5 illustrates schematically a measurement model that may be used for LTM event-triggered measurement reporting in the communication system of Fig. 1;Fig. 6 illustrates schematically a hypothetical scenario involving event-triggered L1 measurement reporting based on event LTM3 that might occur in the communication system of Fig. 1;Fig. 7 illustrates a first MAC CE format for L1 measurement reporting that may be used in the communication system of Fig. 1;Fig. 8 illustrates a second MAC CE format for L1 measurement reporting that may be used in the communication system of Fig. 1;Fig. 9 illustrates a third MAC CE format for L1 measurement reporting that may be used in the communication system of Fig. 1;Fig. 10 illustrates a fourth MAC CE format for L1 measurement reporting that may be used in the communication system of Fig. 1;Fig. 11 illustrates a mechanism for maintaining a list of beams, that have fulfilled one or more conditions, in respect of one or more LTM reporting configurations / events that may be implemented in the communication system of Fig. 1;Fig.12 is a schematic block diagram illustrating the main components of a UE the communication system of Fig. 1;Fig. 13 is a schematic block diagram illustrating the main components of a RAN node for the communication system of Fig. 1; andFig. 14 is a schematic block diagram illustrating the main components of a core network function may be used in the communication system of Fig. 1.

[0061] Overview 　　An exemplary telecommunication system will now be described in general terms, by way of example only, with reference to Figs. 1 to 6.

[0062] Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') communication system (e.g. communication system 1) to which examples of the present disclosure are applicable.

[0063] In the communication system 1, user equipments (UEs) 3 (3-1, 3-2, 3-3) (e.g. mobile telephones and / or other mobile devices) can communicate with each other via a corresponding radio access network (RAN) node 5-1, 5-2 that operates according to one or more compatible radio access technologies (RATs). In the illustrated example, each RAN node 5 (5-1, 5-2) comprises a base station or 'gNB' that respectively operates one or more associated cells. In the illustrated communication system 1, the coverage provided by each RAN node 5 may be by means of a plurality of beams. It will be appreciated that while, for clarity of illustration, only a selection of possible beams is shown, the set of beams may include any suitable number of beams and each RAN node 5 may operate a respective set of beams or may provide coverage in a non-beamformed manner.

[0064] Communication via each RAN node 5 is typically routed through a core network 7 (e.g. a 5G or later generations core network or evolved packet core network (EPC)).

[0065] As those skilled in the art will appreciate, whilst three UEs 3 and two RAN nodes 5 are shown in Fig. 1 for illustration purposes, the system, when implemented, will typically include other RAN nodes 5 and UEs 3.

[0066] Each RAN node 5 controls one or more associated cells either directly, or indirectly via one or more other nodes (such as home base stations, relays, remote radio heads, distributed units, and / or the like). It will be appreciated that the RAN nodes 5 may be configured to support more than one radio access technology and its associated communication protocols (e.g., 4G, 5G, 6G, and / or later generation, and / or any other 3GPP or non-3GPP communication protocols).

[0067] The UEs 3 and their serving RAN node 5 are connected via an appropriate air interface (for example the so-called 'Uu' interface and / or the like). Neighbouring RAN nodes 5 may be connected to each other via an appropriate RAN node-to-RAN node interface (such as the so-called 'X2' interface, 'Xn' interface and / or the like).

[0068] The core network 7 includes a number of logical nodes (or 'functions') for supporting communication in the communication system 1. In this example, the core network 7 comprises control plane functions (CPFs) 10 and network node entities for the communication of user data (e.g. user plane functions (UPFs) 11). The CPFs 10 include one or more network node entities for the communication of control signalling (e.g. Access and Mobility Management Functions (AMFs) 10-1), one or more network node entities for session management (e.g. Session Management Functions (SMFs) 10-2) and a number of other functions 10-n. Additional functions may include, for example: an Authentication Server Function (AUSF) which facilitates security processes; a Unified Data Management (UDM) entity for managing user specific data (e.g., for access authorization, user registration, and data network profiles); a Policy Control Function (PCF); an Application Function (AF); a Security Anchor Function (SEAF) which is in a serving network and acts as a "middleman" during an authentication process between a UE 3 and its home network; an Authentication credential Repository and Processing Function (ARPF) which maintains the authentication credentials; and / or the like. It will be appreciated that the nodes or functions may have different names in different systems.

[0069] Each RAN node 5 is respectively connected to the core network nodes via appropriate interfaces (or 'reference points') such as an N2 reference point between the RAN node 5 and the AMF 10-1 for the communication of control signalling, and an N3 reference point between the RAN node 5 and each UPF 11 for the communication of user data. The UEs 3 are each connected to the AMF 10-1 via a non-access stratum (NAS) connection over an appropriate reference point (e.g., N1 reference point (analogous to the S1 reference point in LTE)). It will be appreciated, that N1 communication is routed transparently via the RAN node 5.

[0070] Each UPF 11 is respectively connected to an external data network 20 (e.g. an IP network such as the internet) via an appropriate reference point (e.g., N6 reference point) for communication of the user data.

[0071] The AMF 10-1 performs mobility management related functions, maintains the NAS connection with each UE 3 and manages UE registration. The AMF 10-1 is also responsible for managing paging.

[0072] The SMF 10-2 is connected to the AMF 10-1 via an appropriate reference point (e.g., N11 reference point). The SMF 10-2 provides session management functionality (that formed part of MME functionality in LTE) and additionally combines some control plane functions (provided by the serving gateway and packet data network gateway in LTE). The SMF 10-2 also allocates IP addresses to each UE 3. The SMF 10-2 uses user information provided via the AMF 10-1 to determine what session manager would be best assigned to the user. The SMF 10-2 may be considered effectively to be a gateway from the user plane to the control plane of the network. The SMF 10-2 also allocates IP addresses to each UE 3.

[0073] Each RAN node 5 is also configured for transmission of, and the UEs 3 are configured for the reception of, control information and user data via a number of downlink (DL) physical channels and for transmission of a number of physical signals. The DL physical channels correspond to resource elements (REs) carrying information originated from a higher layer, and the DL physical signals are used in the physical layer and correspond to REs which do not carry information originated from a higher layer.

[0074] The physical channels may include, for example, a physical downlink shared channel (PDSCH), a physical broadcast channel (PBCH), and a physical downlink control channel (PDCCH). The PDSCH carries data sharing the PDSCH's capacity on a time and frequency basis. The PDSCH can carry a variety of items of data including, for example, user data, UE-specific higher layer control messages mapped down from higher channels, system information blocks (SIBs), and paging. The PDCCH carries downlink control information (DCI) for supporting a number of functions including, for example, scheduling the downlink transmissions on the PDSCH and also the uplink data transmissions on a physical uplink shared channel (PUSCH). The PBCH provides at least the UEs 3 with the Master Information Block (MIB). It also, in conjunction with the PDCCH, supports the synchronisation of time and frequency, which aids cell acquisition, selection and re-selection. Specifically, a UE 3 may receive synchronization signal (SS) / physical broadcast channel (PBCH) block (SSB) and the UE 3 may assume that reception occasions of a PBCH, primary synchronization signal (PSS) and secondary synchronization signal (SSS) are in consecutive symbols and form the SS / PBCH block (SSB). The RAN node 5 may transmit a number of SSBs corresponding to different DL beams. The total number of SSBs may be confined, for example, within a 5ms duration as an SS burst.

[0075] The DL physical signals may include, for example, reference signals (RSs) and synchronization signals (SSs). A reference signal (sometimes known as a pilot signal) is a signal with a predefined special waveform known to both the UE 3 and the RAN node 5. The reference signals may include, for example, cell specific RSs, UE-specific RSs (UE-RSs), downlink demodulation RSs (DMRSs), and channel state information (CSI) RSs (CSI-RSs).

[0076] Similarly, the UEs 3 are configured for transmission of, and the RAN node 5 is configured for the reception of, control information and user data via a number of uplink (UL) physical channels corresponding to REs carrying information originated from a higher layer, and UL physical signals which are used in the physical layer and correspond to REs which do not carry information originated from a higher layer. The physical channels may include, for example, the PUSCH, a physical uplink control channel (PUCCH), and / or a physical random-access channel (which may be abbreviated as either 'PRACH' or 'RACH' - the term (P)RACH will be used herein). The UL physical signals may include, for example, demodulation reference signals (DMRS) for a UL control / data signal, and / or sounding reference signals (SRS) used for UL channel measurement.

[0077] Frame Structure 　　Referring to Fig. 2, which illustrates the typical frame structure that may be used in the communication system 1, the RAN nodes 5 and UEs 3 of the communication system 1 communicate with one another using resources that are organised, in the time domain, into frames in this case of length 10ms. Each frame comprises ten equally sized subframes of 1ms length. Each subframe is divided into one or more slots comprising 14 (or in some cases 12) orthogonal frequency-division multiplexing (OFDM) symbols of equal length.

[0078] As seen in Fig. 2, the communication system 1 supports multiple different numerologies (subcarrier spacing (SCS), slot lengths and hence OFDM symbol lengths). Specifically, each numerology is identified by a parameter, μ, where μ=0 represents 15 kHz (corresponding to the LTE SCS). Currently, the SCS for other values of μ can, in effect, be derived from μ=0 by scaling up in powers of 2 (i.e., SCS = 15 x 2μkHz). The relationship between the parameter, μ, and SCS (Δf) is as shown in Table 1:

[0079] Mobility Procedures 　　Each UE 3 and each RAN node 5 are configured for taking its respective part in performing a number of different types of mobility (or 'handover') procedure (depending on requirements), e.g., as a UE 3 moves from cell-to-cell (or beam-to-beam), or as the cells / beams move relative to the UE 3 (in the case of moving cells / beams e.g., in non-terrestrial networks). 　　These mobility procedures include, for example, L3 triggered mobility / handover procedures where handover is triggered based on L3 measurement reporting and associated signalling (e.g., radio resource control (RRC) layer signalling). 　　These mobility procedures include, for example, L1 / L2 triggered mobility / handover (or 'LTM') procedures where handover is typically triggered by L1 measurement reporting and associated signalling.

[0080] Mobility Procedures - L3 triggered 　　In more detail, the UEs 3 and RAN nodes 5 of the communication system 1 may be mutually configured for performing a RAN centric, L3 triggered, handover, based on direct communication over a RAN node-to-RAN node interface (e.g., X2, Xn or the like), in which the source RAN node 5-1 triggers handover based on an L3 measurement report.

[0081] An exemplary L3 handover procedure that may be used in the communication system 1, will now be described, by way of example only, with reference to Fig. 3.

[0082] Fig. 3 is a simplified sequence diagram illustrating the L3 triggered mobility procedure that may be implemented in the communication system 1.

[0083] Referring to Fig. 3, the L3 triggered mobility procedure in this case concerns a handover of a UE 3 between a source cell of a source (serving) RAN node 5-1 and a target cell of a target RAN node 5-2, where a handover decision is made by the source RAN node 5-1 based on a measurement report previously received from the UE 3.

[0084] Before the handover procedure starts, the serving RAN node 5-1 serving and communicating with the UE 3 (i.e., the source RAN node 5-1 of the handover) is in a measurement phase (S300). The serving RAN node 5-1 will typically have a UE context for the UE 3 stored. This may include, for example, information regarding roaming and access restrictions which were provided either at establishment of the connection between the UE 3 and the serving RAN node 5-1 or at the last tracking area update.

[0085] At the start of this measurement phase, at S302, the serving RAN node 5-1 performs measurement control by sending an appropriate measurement configuration, to the UE 3 (e.g., in an RRC reconfiguration message or the like), to configure the measurement procedures to be performed by the UE 3.

[0086] The measurement configuration typically includes, for example, a list of one or more so called 'measurement objects', which indicate what the UE 3 should measure (i.e., the 'object' or 'target' of the UE measurements). For example, for intra-frequency and inter-frequency measurements, the measurement object may indicate the frequency / time location and subcarrier spacing of the reference signals to be measured. For inter-RAT measurements, a measurement object may be a specific carrier frequency (e.g., a E-UTRA frequency or the like).

[0087] The measurement configuration also typically includes, for example, a list of one or more 'reporting configurations', that configures how the UE 3 performs the measurements and when measurement reports should be sent. There can be one or multiple reporting configurations per measurement object. For example, each measurement reporting configuration typically defines at least one 'reporting criterion' (e.g., a criterion that, when met, triggers the UE 3 to send a measurement report). A reporting criterion may, for example, be time based (e.g., representing a period at which measurement reports may be sent) or may be event based (e.g., defining a single event which, on occurrence, triggers measurement reporting). Each measurement reporting configuration also typically defines at least one reference signal type (i.e., defining the RS that the UE 3 uses for beam and cell measurement results). The reference signal type may, for example, be defined as an SS / PBCH block (SSB) or as CSI-RS. Each measurement reporting configuration also typically defines at least one reporting format that defines the quantity or quantities per cell and / or per beam that the UE 3 is to include in the measurement report (e.g., reference signal received power (RSRP), reference signal received quality (RSRQ), signal to interference plus noise ratio (SINR) and / or the like). Each measurement reporting configuration may also include other associated information such as the maximum number of cells and the maximum number beams per cell to report.

[0088] The serving RAN node 5-1 may, for example, configure the UE 3 to report any of the following list of measurement information based on one or more SS / PBCH blocks (SSBs): 　　- Measurement results per SSB; 　　- Measurement results per cell based on one or more SSBs; 　　- One or more SSB indexes.

[0089] The serving RAN node 5-1 may, for example, configure the UE 3 to report any of the following measurement information based on CSI-RS resources: 　　- Measurement results per CSI-RS resource; 　　- Measurement results per cell based on one or more CSI-RS resources; 　　- CSI-RS resource measurement identifiers.

[0090] The UE 3 performs, at S304, the configured measurements and reports them in a measurement report at S306 (e.g., a measurement report that is triggered when a particular configured trigger event occurs, or periodically) according to the measurement configuration.

[0091] A handover preparation phase (S310) then commences when the serving RAN node 5-1 decides to initiate handover at S312. Specifically, the serving RAN node 5-1 makes a decision to handover the UE 3 to the target cell of the target RAN node 5-2, for example based on measurement results received in the measurement report and / or radio resource management (RRM) information. The serving RAN node 5-1 thus begins to operate as a source RAN node 5-1 of the handover.

[0092] The source RAN node 5-1 issues, at S314, a handover request, to the target RAN node 5-2. This message will typically pass the necessary information, to the target RAN node 5-2 in a transparent RRC container, for preparing the handover at the target side. The information may include, for example, the target cell ID, security information, a cell radio network temporary identifier (C-RNTI) of the UE 3 at the source RAN node 5-1, RRM configuration information (e.g., including UE inactive time), basic access stratum (AS) configuration information including antenna information and downlink carrier frequency, current quality of service (QoS) flow to data radio bearer (DRB) mapping rules applied to the UE 3, the SIB1 from the source RAN node 5-1, the UE capabilities for different RATs, protocol data unit (PDU) session related information, and / or UE reported measurement information including beam-related information if available.

[0093] Admission control may then be performed by the target RAN node 5-2 at S315. Slice-aware admission control may, for example, be performed if corresponding slice information is sent to the target RAN node 5-2 and if protocol data unit (PDU) sessions are associated with non-supported slices the target RAN node 5-2 may reject such a PDU session.

[0094] The target RAN node 5-2 prepares handover with its lower layers (L1 and L2) and sends, to the source RAN node 5-1, an appropriate response (e.g., a handover request acknowledge message or the like) at S316. The response includes a transparent container comprising a message (e.g., an RRC message) to be sent to the UE 3 and that is to be used to configure handover (e.g., as a handover command to instruct performance of the handover). The message to be sent to the UE 3 may, for example, be an RRC reconfiguration message or the like.

[0095] The source RAN node 5-1 triggers the handover by sending the handover configuration message (e.g., the RRC reconfiguration message / handover command or the like) to the UE 3 at S318. This message contains the information required to access the target cell (e.g., the target cell ID, the new C-RNTI, security algorithm identifiers of the target RAN node 5-2 for the selected security algorithms and / or the like).

[0096] As soon as the source RAN node 5-1 receives the response (e.g., the handover request acknowledge message or the like), or as soon as the transmission of the handover command (e.g., the RRC reconfiguration message or the like) is initiated in the downlink, data forwarding may be initiated.

[0097] A handover execution phase (S320) is then initiated, and the UE 3 detaches from the source cell of the source RAN node 5-1 and synchronises to the target cell of the target RAN node 5-2 (at S326).

[0098] The UE 3 synchronises to the target cell and completes the handover procedure by sending an appropriate message (e.g., an RRC message) to indicate that handover configuration is complete (e.g., an RRC Reconfiguration Complete / handover complete message) to the target RAN node 5-2 (S328).

[0099] The last phase is the handover completion phase (S330) during which the target RAN node 5-2 coordinates with the core network to switch communication to the target RAN node 5-2 (at S332). Once communication has been switched the target RAN node 5-2 initiates a UE context release at the source RAN node 5-1 to release the associated resources of the source RAN node 5-1 (e.g., by sending a UE context release message at S334).

[0100] Mobility Procedures - L1 / L2 Triggered Mobility (LTM) 　　The UEs 3 and RAN nodes 5 of the communication system 1 may be mutually configured for performing an L1 / L2 triggered mobility (LTM) mobility procedure, in which the source RAN node 5-1 triggers a change of cell based on an L1 measurement report (that has not been subject to L3 filtering).

[0101] Specifically, LTM is a procedure in which the RAN node 5 receives one or more L1 measurement reports from the UE 3, and on their basis the RAN node 5 changes the serving cell of the UE 3 using a cell switch command (e.g., signalled via a MAC control element (CE)). The cell switch command indicates an LTM candidate configuration that the RAN node 5 previously prepared and provided to the UE 3 through appropriate L3 (e.g., RRC) signalling. Then the UE 3 switches to the target configuration according to the cell switch command.

[0102] An exemplary LTM procedure that may be used in the communication system 1, will now be described, by way of example only, with reference to Fig. 4.

[0103] Fig. 4 is a simplified sequence diagram illustrating the LTM procedure that may be implemented in the communication system 1.

[0104] Referring to Fig. 4, the LTM procedure in this case concerns a handover of a UE 3 between a source cell of a source RAN node 5-1 and a target cell of a target RAN node 5-2, where a decision is initially made by the source RAN node 5-1, based on a measurement report previously received from the UE 3, to (pre)configure the UE 3 for handover / cell switch to each of one or more LTM candidate cells / RAN nodes 5 forming an LTM candidate set. The LTM candidate set includes, for example, at least the cell / RAN node 5-2 that will ultimately become the target cell / target RAN node 5-2.

[0105] Before the LTM procedure starts, the serving RAN node 5-1 (i.e., the source RAN node 5-1 of the handover / cell switch) and the UE 3 are in a measurement phase (S400). The serving RAN node 5-1 will typically have a UE context for the UE 3 stored. This may include, for example, information regarding roaming and access restrictions which were provided either at establishment of the connection between the UE 3 and the serving RAN node 5-1 or at the last tracking area update.

[0106] At the start of this measurement phase, at S402, the serving RAN node 5-1 performs measurement control by sending an appropriate measurement configuration, to the UE 3 (e.g., in an RRC reconfiguration message or the like), to configure the (L3) measurement procedures to be performed by the UE 3.

[0107] The measurement configuration typically includes, for example, a list of one or more so called 'measurement objects', which indicate what the UE 3 should measure (i.e., the 'object' or 'target' of the UE measurements). For example, for intra-frequency and inter-frequency measurements, the measurement object may indicate the frequency / time location and subcarrier spacing of the reference signals to be measured. For inter-RAT measurements, a measurement object may be a specific carrier frequency (e.g., a E-UTRA frequency or the like).

[0108] The measurement configuration also typically includes, for example, a list of one or more 'reporting configurations', that configures how the UE 3 performs the measurements and when measurement reports should be sent. There can be one or multiple reporting configurations per measurement object. For example, each measurement reporting configuration typically defines at least one 'reporting criterion' (e.g., a criterion that, when met, triggers the UE 3 to send a measurement report).

[0109] A reporting criterion may, for example, be time based (e.g., representing a period at which measurement reports may be sent) or may be event based (e.g., defining a single event which, on occurrence, triggers measurement reporting). Each measurement reporting configuration also typically defines at least one reference signal type (i.e., defining the RS that the UE 3 uses for beam and cell measurement results). The reference signal type may, for example, be defined as an SS / PBCH block (SSB) or as CSI-RS. Each measurement reporting configuration also typically defines at least one reporting format that defines the quantity or quantities per cell and / or per beam that the UE 3 is to include in the measurement report (e.g., reference signal received power (RSRP), reference signal received quality (RSRQ), signal to interference plus noise ratio (SINR), and / or the like). Each measurement reporting configuration may also include other associated information such as the maximum number of cells and the maximum number beams per cell to report.

[0110] The serving RAN node 5-1 may, for example, configure the UE 3 to report any of the following list of measurement information based on one or more SS / PBCH blocks (SSBs): 　　- Measurement results per SSB; 　　- Measurement results per cell based on one or more SSBs; 　　- One or more SSB indexes.

[0111] The serving RAN node 5-1 may, for example, configure the UE 3 to report any of the following measurement information based on CSI-RS resources: 　　- Measurement results per CSI-RS resource; 　　- Measurement results per cell based on one or more CSI-RS resources; 　　- CSI-RS resource measurement identifiers.

[0112] The UE 3 performs, at S404, the configured measurements and reports them in a measurement report at S406 (e.g., a measurement report that is triggered when a particular configured trigger event occurs, or periodically) according to the measurement configuration.

[0113] An LTM (pre)configuration phase (S410) then commences when the serving RAN node 5-1 decides, based on measurement results, to configure LTM and initiate LTM preparation at S412 (this decision may be referred to as an LTM handover decision). Specifically, the serving RAN node 5-1 makes a decision to (pre)configure the UE 3 for handover / cell switch to each of one or more LTM candidate cells / RAN nodes 5 forming an LTM candidate set. The LTM candidate set includes, for example, at least the cell / RAN node 5-2 that will ultimately become the target cell / target RAN node 5-2. The serving RAN node 5-1 thus begins to operate as a source RAN node 5-1 of the LTM procedure.

[0114] The source RAN node 5-1 issues, at S414, a respective handover request, to each candidate RAN node 5 (i.e., each RAN node 5 that may become a target of the handover / cell switch in the future). In Fig. 6, whilst a single candidate RAN node 5 (the RAN node 5-2 that ultimately becomes the target) is shown there may (but do not have to) be a plurality of candidate RAN nodes 5. The information may include, for example, the target cell ID, security information, a C-RNTI of the UE 3 at the source RAN node 5-1, RRM configuration information (e.g., including UE inactive time), basic AS configuration information including antenna information and downlink carrier frequency, current QoS flow to DRB mapping rules applied to the UE 3, the SIB1 from the source RAN node 5-1, the UE capabilities for different RATs, PDU session related information, and / or UE reported measurement information including beam-related information if available.

[0115] The following procedure will be described from the perspective of the candidate RAN node 5 that ultimately becomes the target RAN node 5-2. It will, nevertheless, be appreciated that a similar procedure will be performed at each candidate RAN node 5 as part of the procedure to configure the UE 3 for LTM.

[0116] Admission control may be performed by the target RAN node 5-2 at S415. Slice-aware admission control may, for example, be performed if corresponding slice information is sent to the target RAN node 5-2 and if protocol data unit (PDU) sessions are associated with non-supported slices the target RAN node 5-2 may reject such a PDU session.

[0117] The target RAN node 5-2 prepares handover with its lower layers (L1 and L2) (e.g., including reserving corresponding resources for the UE 3) and sends, to the source RAN node 5-1, an appropriate response (e.g., a handover request acknowledge message or the like) at S416. The response includes a transparent container comprising a message (e.g., an RRC message) to be sent to the UE 3 and that is to be used as an 'LTM candidate configuration' message to configure LTM handover / cell switch for that specific candidate RAN node 5 (e.g., as a handover command to instruct performance of the handover). The message to be sent to the UE 3 may, for example, be an RRC reconfiguration message or the like.

[0118] The source RAN node 5-1 transmits, at S418, the respective LTM candidate configuration to the UE 3 received from each candidate RAN node 5 in an appropriate (e.g. RRC) message (e.g., an RRC reconfiguration message) comprising an appropriate LTM configuration information element (IE) including the respective LTM candidate configuration for each candidate RAN node 5 (of which there may be one or more). Each LTM candidate configuration in the LTM configuration IE may, for example, be a complete candidate configuration or may be a delta configuration relative to a reference configuration.

[0119] The source RAN node 5-1 may also include as part of the LTM configuration, LTM measurement configuration information for configuring L1 measurements to be reported. The measurement configuration information may, for example, be configured for configuring the UE 3 to provide an SSB based L1-RSRP measurement report for beam selection. The source RAN node 5-1 may also include as part of the LTM configuration, LTM reporting configuration (e.g., defined by an LTM-CSI-ReportConfig IE or the like) for configuring L1 measurement reporting. The LTM reporting configuration may, for example, configure measurement reporting to be periodic (on the PUCCH), aperiodic, semipersistent (on the PUCCH or the PUSCH), or and / or the like.

[0120] Nevertheless, the LTM reporting configuration may also (or alternatively) configure LTM event-triggered measurement reporting. Moreover, in addition to being able to configure triggering of an individual L1 measurement report by fulfilling one or more conditions for a given event, the source RAN node 5-1 may also be able to configure LTM event-triggered periodic (or 'event-periodic') L1 measurement reporting. In this case, when one or more (e.g., entering) conditions for an event have been fulfilled, L1 measurement reporting for that event may occur on a periodic basis (e.g., based on expiry of, or fulfilment of one or more conditions based on, a periodic reporting timer) - e.g., until one or more further (e.g., leaving) conditions are fulfilled (or when one or more original conditions are no longer fulfilled).

[0121] The LTM event-triggered measurement reporting may support measurements on SSB and / or CSI-RS resources corresponding to beams of one or more candidate beam sets (e.g., a plurality of candidate beam sets for the same and / or different candidate cells). The SSB and / or CSI-RS resources may, for example, be configured by one or more associated LTM resource configurations (e.g., defined by an LTM-CSI-ResourceConfig IE or the like). The LTM resource configuration / configurations may be provided as part of the corresponding LTM reporting configuration (e.g., defined by an LTM-CSI-ReportConfig IE or the like).

[0122] A number of different LTM events are configurable at the UE 3 by the source RAN node 5-1 (e.g., in an LTM reporting configuration), and evaluated by the UE 3 based on a beam specific quality of the serving cell and / or of one or more candidate cells. The events may include, for example: 　　- Event LTM2: which occurs when a beam specific quality of a (serving) beam of the serving cell of the UE 3 (which may be referred to as the "current beam") becomes worse than an absolute threshold; 　　- Event LTM3: which occurs when a beam specific quality of a beam of a candidate cell becomes an 'offset' amount better than a (serving) beam of the serving cell of the UE 3; 　　- Event LTM4: which occurs when a beam specific quality of a beam of a candidate cell becomes better than an absolute threshold; and 　　- Event LTM5: which occurs when a beam specific quality of a (serving) beam becomes worse than a first absolute threshold (threshold1) AND a beam of a candidate cell becomes better than a second absolute threshold (threshold2).

[0123] For these LTM events, any beam associated with a candidate reference signal (RS) (e.g., SSB or CSI-RS) resource configuration in the LTM reporting configuration may be used for LTM event evaluation for a candidate cell. For event LTM3 and LTM5, the event evaluation is based on the measurement result of the same type of RS for both the serving cell and the candidate cell, and the current (serving) beam (e.g., a beam corresponding to an indicated transmission configuration indication (TCI) state) is used for LTM event evaluation for the serving cell.

[0124] The UE 3 may be configured with a plurality of different LTM reporting configurations (e.g., each defined by a respective LTM-CSI-ReportConfig IE or the like). For example, different LTM reporting configurations may link the same set of one or more beams and / or set of one or more cells to different configured events, or may link different sets of one or more beams and / or sets of one or more cells to the same or different configured events.

[0125] The UE 3 stores the LTM candidate configurations and responds to the message carrying the LTM configuration, at S419, with an appropriate response message (e.g., an RRC reconfiguration complete message or the like) to effectively indicate that the LTM configuration has been completed at the UE 3.

[0126] The UE 3 may, at this stage, perform early synchronization, in the downlink, with each candidate cell (i.e., before receiving any corresponding cell switch (or 'handover') command).

[0127] The UE 3 may also, at this stage, perform early synchronization, in the uplink, with each candidate cell. Specifically, when UE-based timing advance (TA) measurement is configured, the UE 3 may acquire a respective TA value of each candidate cell by measurement. The UE 3 may perform early TA acquisition with a candidate cell in accordance with a request by the network (i.e., before receiving any corresponding cell switch (or 'handover') command). This may, for example, be done via a contention free random access (CFRA) triggered by a PDCCH order from the source RAN node 5-1, following which the UE 3 sends preamble towards the indicated candidate cell. In order to minimise the data interruption of the source cell due to CFRA towards a candidate cell, the UE 3 need not receive random access response from the network for the purpose of TA value acquisition and the TA value of the candidate cell may be indicated in any cell switch command.

[0128] An LTM execution / completion phase (S420) is then initiated during which the UE 3 performs, at S421, the configured L1 measurements for the configured candidate cells (where possible) and sends, at S422, a corresponding L1 measurement report to the source RAN node 5-1 in accordance with the report configuration information. L1 measurement may be performed as long as the LTM configuration (i.e., the RRC reconfiguration) provided at S418 is applicable. The L1 measurement report may, for example, be via a MAC control element (CE) including the L1 measurement report. The MAC CE carrying the measurement report may be referred to as an LTM measurement reporting (MR) MAC CE ('LTM MR MAC CE') or by any other suitable name.

[0129] For example, in the context of LTM event-triggered reporting, when an LTM event condition is continuously met during a given time-to-trigger (TTT) duration / window (i.e., for the serving / current beam and / or for the same beam of the same candidate cell), the UE 3 triggers corresponding L1 measurement reporting by initiating a transmission of the MAC CE including the event-triggered L1 measurement report (e.g., the LTM MR MAC CE).

[0130] In addition to being able to configure triggering of an L1 measurement report by meeting an entering condition for a given event, the RAN node 5 may also configure L1 measurement reporting triggered by meeting a leaving condition for a given event. The MAC CE including the event-triggered L1 measurement report (e.g., LTM MR MAC CE) may, for example, include all (or a subset) of the following information: 　　- Triggered event information (e.g., an LTM channel state information (CSI) report configuration identifier (e.g., a 'ReportConfigID') or the like); 　　- Beam information (e.g., an SSB resource set index ('SSBRI') and / or a CSI-RS resource indicator (CRI) identifying a corresponding CSI-RS and hence CSI-RS beam); 　　- Beam quantity (e.g., L1 reference signal received power (L1-RSRP), or signal to interference plus noise ratio (SINR) of a given number (N) of beams); 　　- The information and quantity of a current beam (e.g., based on a network configuration)

[0131] The MAC CE including the event-triggered L1 measurement report (e.g., LTM MR MAC CE) may include up to a maximum number (N) beams for event-triggered L1 measurement reporting (where 'N' may be configured by the RAN node).

[0132] For the transmission of the MAC CE including the event-triggered L1 measurement report (e.g., LTM MR MAC CE), if there is no available uplink resource (e.g., physical uplink shared channel (PUSCH) resource for the transmission), an appropriate scheduling request (SR) procedure may be applied to request uplink resource allocation. In this context, the RAN node 5 can configure a dedicated SR configuration for the transmission of the MAC CE including the event-triggered L1 measurement report (e.g., LTM MR MAC CE).

[0133] A MAC layer entity at the UE 3 handles the entire LTM event evaluation, and the reporting procedure for transmission of the MAC CE including the event-triggered L1 measurement report (e.g., LTM MR MAC CE). The LTM event evaluation is based on the latest L1 measured results reported by the L1 (PHY) layer.

[0134] For event-triggered L1 measurement reporting, the source RAN node 5-1 may also control if one or more beams for which a measured beam quantity (e.g., RSRP and / or SINR) does not satisfy the conditions for a given reporting event (if any) could, nevertheless, be reported (e.g., together with the beam / beams that do satisfy the conditions) in the L1 measurement report (e.g., in the LTM MR MAC CE) - for example, up to the maximum number (N) of beams.

[0135] At S423, the source RAN node 5-1 decides to execute cell switch to a target cell (i.e., a cell of the target RAN node 5-2 in this example). The source RAN node 5-1 may then initiate transmission, at S424, of an LTM cell switch command (e.g., as a MAC CE for triggering a cell switch (or handover)) including a candidate configuration index corresponding to the target cell / target RAN node 5-2.

[0136] The UE 3 then, at S426, detaches from the source cell of the source RAN node 5-1 and switches to the target cell by applying the corresponding LTM candidate configuration indicated by candidate configuration index.

[0137] As indicated at S428, the UE 3 can then access the cell using a RACH based or RACH-less procedure. The UE 3 may, for example, perform a random-access procedure towards the target cell if the UE 3 does not have valid TA of the target cell. Nevertheless, the UE 3 may access the cell without performing a random-access procedure where the UE 3 has a valid TA. The UE 3 can complete the LTM cell switch procedure by sending an appropriate message (e.g., an RRC reconfiguration complete message) to the target RAN node 5-2. If the UE 3 has performed a random-access procedure the UE 3 may consider that LTM cell switch execution has been successfully completed when the random-access procedure has successfully completed. For RACH-less LTM, on the other hand, the UE 3 may consider that the LTM cell switch execution has successfully completed when the UE 3 determines that the target RAN node 5-2 has successfully received its first uplink data.

[0138] It will be appreciated that the steps following the sending of the message (e.g., RRC reconfiguration complete message) indicating that LTM configuration is complete at S419 (including any early synchronisation) can be performed multiple times for subsequent LTM, for example by using any stored LTM candidate configuration provided at S418 and stored at the UE 3.

[0139] Event-triggered LTM Measurement Model 　　Fig. 5 illustrates schematically a measurement model that may be used for LTM event-triggered measurement reporting in the communication system 1.

[0140] As seen in in Fig. 5 measurements (e.g., beam specific samples) may be performed for a plurality of beams (e.g., beams A1, A2, A3, and A4) for a serving cell (e.g., Cell A) and for a plurality of beams (e.g., beams C1, C2, C3, and C4) for a candidate cell (e.g., Cell B). These measurements are performed internal to the PHY layer.

[0141] Internal L1 filtering of the measurements may then be performed and the L1 filtered (beam specific) measurements reported to the MAC layer. A MAC layer entity of the UE 3 may identify the best (or 'current', or 'serving') beam of the serving cell (e.g., Cell A). It will be appreciated that the best (or 'current', or 'serving') beam of the serving cell may change during a TTT.

[0142] The L1 filtered (beam specific) measurements for the identified best (or 'current', or 'serving') beam (e.g., for events LTM2, LTM3, and LTM5), and / or the L1 filtered (beam specific) measurements for the beams (e.g., beams C1, C2, C3, and C4) of the candidate cell (e.g., Cell B) (e.g., for events LTM3, LTM4, and LTM5), may then be used for subsequent evaluation of the event-triggered reporting criteria (depending on the LTM event being evaluated).

[0143] When the condition (or conditions) for triggering a given LTM event is fulfilled for an associated TTT, a corresponding L1 measurement report (e.g., the LTM MR MAC CE) is triggered and sent to the source RAN node 5-1 (e.g., as described with reference to step S422, Fig. 4).

[0144] Example with Event LTM3 Evaluation 　　Fig. 6 illustrates schematically a hypothetical scenario involving event-triggered L1 measurement reporting based on event LTM3 that might occur in the communication system 1.

[0145] As seen in Fig. 6, in this hypothetical scenario, three beams (beam A1, A2, and A3) of a serving cell and two beams (beam C1 and C2) of a candidate cell are being evaluated for fulfilment of event LTM3 (assuming, for simplicity, that hysteresis is zero).

[0146] Initially, at T0, in Fig. 6, a beam quantity (e.g., L1-RSRP or SINR) for serving cell beam A1 is the highest and hence beam A1 is treated as the 'current' beam. At T1, this changes when the beam quantity (e.g., L1-RSRP or SINR) for serving cell beam A2 becomes the highest and is therefore treated as the 'current' beam. This changes again, at T2, when the beam quantity (e.g., L1-RSRP or SINR) for serving cell beam A3 becomes the highest and is therefore treated as the 'current' beam.

[0147] Then, at T3, the beam quantity (e.g., L1-RSRP or SINR) for candidate cell beam C2 exceeds that of the current beam (A3) of the serving cell by the threshold configured for triggering event LTM3 and hence a first TTT duration (TTT1) commences for triggering event LTM3 based on candidate cell beam C2.

[0148] At T4, before the first TTT duration (TTT1) has ended, the beam quantity (e.g., L1-RSRP or SINR) for candidate cell beam C1 exceeds that of the current beam (A3) of the serving cell by the threshold required for triggering event LTM3 and hence a second TTT duration (TTT2) commences for triggering event LTM3 based on candidate cell beam C1.

[0149] At T5, the first TTT duration (TTT1) ends and hence event LTM3 is triggered by candidate cell beam C2.

[0150] At T6, the second TTT duration (TTT2) ends and hence event LTM3 is triggered again - this time by candidate cell beam C1.

[0151] Accordingly, it can be seen that in the scenario illustrated in Fig. 6 it is possible that an uplink grant for transmission of the first L1 measurement report that is triggered at T5 may not be available until after the second L1 measurement report is triggered at T6.

[0152] Event-triggered L1 Measurement Reporting 　　Beneficially, as described in more detail later, each RAN node 5, and UE 3, of the communication system 1 is mutually configured for implementing one or more enhanced procedures / mechanisms for supporting event-triggered L1 measurement reporting.

[0153] Beneficially, for example, each RAN node 5, and UE 3, of the communication system 1 may be mutually configured to implement one or more enhanced procedures / mechanisms for L1 measurement reporting, in a case where a plurality of different events are triggered, using a MAC CE having an appropriate format.

[0154] Beneficially, for example, each RAN node 5, and UE 3, of the communication system 1 may be mutually configured to implement one or more enhanced procedures / mechanisms for triggering transmission of a MAC CE that carries event-triggered L1 measurement reporting, for one or more beams, in accordance with one or more LTM reporting configurations / events, and for cancelling transmission of the L1 measurement results in respect of one or more of those beams when appropriate.

[0155] Beneficially, for example, each RAN node 5, and UE 3, of the communication system 1 may be mutually configured to implement one or more enhanced procedures / mechanisms for supporting LTM event-triggered periodic (or 'event-periodic') L1 measurement reporting.

[0156] Beneficially, for example, each RAN node 5, and UE 3, of the communication system 1 may be mutually configured to implement one or more enhanced procedures / mechanisms for identifying what information should (and should not) be included in a given MAC CE for L1 measurement reporting and / or for prioritising which MAC CE for L1 measurement reporting should be transmitted at a given time (where a plurality of different MAC CEs for L1 measurement reporting may be sent.

[0157] Throughout the description depending on context, references may be made to: the triggering of an (LTM) event; the triggering of a (L1) measurement report by an (LTM) event; the triggering of a (L1) measurement report for (or by) a particular (LTM) reporting configuration; the triggering of a particular (LTM) reporting configuration; one or more event conditions being or fulfilled; and / or similar language. It will be appreciated that these all refer to essentially the same thing - namely the occurrence of a given LTM event that may result in associated L1 measurement results being reported to the serving (e.g., source) RAN node 5-1, by the UE 3 in an associated L1 measurement report (carried by an appropriate MAC CE).

[0158] L1 Measurement Reporting MAC CE Format 　　As mentioned above, each RAN node 5, and UE 3, of the communication system 1 may be mutually configured to implement one or more enhanced procedures / mechanisms for L1 measurement reporting, in a case where a plurality of different events are triggered, using a MAC CE having an appropriate format.

[0159] A number of different possible formats for a MAC CE that carries the L1 measurement results for L1 measurement reporting (e.g., an LTM MR MAC CE or the like) will now be described, by way of example only, with reference to Figs. 7 to 10.

[0160] It will be appreciated that whilst the communication system 1 may support each different format described on its own (without the other formats), the different formats are not mutually exclusive. For example, the communication system 1 may support all (or a subset of) the formats for use in different scenarios, e.g., based on a configuration provided to the UE 3 from the serving (e.g., source) RAN node 5-1.

[0161] Similarly, all (or a subset of one or more) of these formats of MAC CE may be used for L1 measurement reporting, where appropriate, in conjunction with any of the other procedures / mechanisms for supporting event-triggered L1 measurement reporting described in this disclosure. Nevertheless, it will be appreciated that, a different format of MAC CE may be used for L1 measurement reporting in respect of the other procedures / mechanisms for supporting event-triggered L1 measurement reporting described in this disclosure.

[0162] Independent MAC CE for Each LTM Reporting Configuration / LTM Event 　　In this example, the UE 3 is configured to handle each configured LTM reporting configuration and / or LTM event independently for the purposes of L1 measurement reporting. Specifically, if L1 measurement reporting is triggered for a plurality of different LTM reporting configurations (e.g., different LTM reporting configurations having different ltm-CSI-ReportConfigID values), and / or LTM events, then a plurality of different L1 measurement reporting MAC CEs are constructed (e.g., a respective MAC CE for each LTM reporting configuration / LTM event) at the UE 3 for transmission to the serving RAN node 5-1.

[0163] Fig. 7 illustrates a MAC CE format for L1 measurement reporting that may be used in the communication system 1 according to this example.

[0164] As seen in Fig. 7, in this example, the MAC CE carrying the L1 measurement results includes: 　　- A measured beam quantity (e.g., L1-RSRP or SINR depending on configuration) for the current beam (if the LTM event requires it), based on an associated configuration from the serving RAN node 5-1; 　　- An identifier of the associated LTM reporting configuration (e.g., an ltm-CSI-ReportConfigId or the like) for indicating that the configured event that corresponds to the identified LTM reporting configuration has been triggered; and 　　- A list of measurement results and associated information for one or more beams of candidate cells (if the LTM event requires it). As seen in Fig. 7 the measurement results and associated information may include, for each beam represented: information identifying the beam (e.g., SSBRI / CRI); the measured beam quantity (e.g., L1-RSRP or SINR depending on configuration); and (optionally) information (e.g., a single L / E bit or the like) indicating whether the beam satisfied an 'entering' or a 'leaving' condition. Assuming that the uplink grant provides sufficient uplink resources to do so, this may include, for example: 　　　　-- measurement results and associated information for one or more best beams up to the maximum number 'N' of best beams in the configured beam set corresponding to the indicated LTM reporting configuration; or 　　　　-- measurement results and associated information for each of one or more (e.g., 'X') beams which triggered the corresponding event.

[0165] It will be appreciated that the information included in the MAC CE will depend on the type of event that triggered the L1 measurement reporting being provided by that MAC CE relates. For example, if the event that triggered the L1 measurement reporting was event LTM2 (beam of serving cell becomes worse than absolute threshold), then the MAC CE may not include measurement results for the beams of the candidate cells for that L1 measurement report.

[0166] MAC CE Carrying Mixed Measurement Report for Plurality of LTM Reporting Configurations / LTM Events 　　In this example, the MAC CE carrying the L1 measurement results may include a combined L1 measurement report that includes L1 measurement results associated with a plurality of different LTM reporting configurations / LTM events for which L1 measurement reporting has been triggered. Specifically, in this example, a UE 3 may be configured to report: a list of events / LTM reporting configurations (e.g., as a list of ltm-CSI-ReportConfigIds or the like) for which L1 measurement reporting has been triggered; and a list of measurement results and associated information for one or more beams of candidate cells (if the LTM event requires it). The beam / beams for which the measurement results and associated information is included may, for example, correspond to: the best beam / beams among all configured beams for L1 measurement reporting (e.g., up to the maximum number 'N' of best beams); or each of one or more (e.g., 'X') beams which triggered the corresponding event.

[0167] Fig. 8 illustrates a MAC CE format for L1 measurement reporting that may be used in the communication system 1 that may be used according to this example. Fig. 9 illustrates another MAC CE format for L1 measurement reporting that may be used in the communication system 1 that may be used according to this example.

[0168] As seen in Figs. 8 and 9, in this example, the MAC CE carrying the L1 measurement results includes: 　　- A measured beam quantity (e.g., L1-RSRP or SINR depending on configuration) for the current beam (if the LTM event requires it), based on an associated configuration from the serving RAN node 5-1; 　　- A list of information identifying different LTM reporting configurations / LTM events for which L1 measurement reporting has been triggered. The list may include, for example, each LTM reporting configuration / LTM event for which either an 'entering' or a 'leaving' condition has been fulfilled by one or more configured / related beams. The list may be represented as: 　　　　-- an explicit list of LTM reporting configuration identifiers (e.g., as a list of ltm-CSI-ReportConfigIds or the like) for different LTM reporting configurations / LTM events for which L1 measurement reporting has been triggered (as illustrated in Fig. 8); 　　　　-- a field (e.g., an ID field) having a plurality of sub-fields (e.g., ID0, ID1…, IDM), where each subfield (e.g., IDi) indicates, for a respective LTM reporting configuration, whether L1 measurement reporting has been triggered for that LTM reporting configuration (e.g., an 'entering' and / or 'leaving' condition has been fulfilled) - e.g., as illustrated in Fig. 9. The LTM configuration corresponding to the ithsub-field (e.g., IDi) may, for example be the LTM reporting configuration having the (i+1)thLTM reporting configuration identifier (e.g., the ithltm-CSI-ReportConfigId) or may be the LTM reporting configuration for which the LTM reporting configuration identifier is equal to 'I' (or some function of 'i') (e.g., having an ltm-CSI-ReportConfigId = i (or some function of 'i')) 　　- A list of measurement results and associated information for each of one or more best beams of candidate cells, or for each of one or more beams which triggered the corresponding event (if the LTM event requires it). As seen in Figs. 8 and 9 the measurement results and associated information may include, for each beam represented: information identifying the beam (e.g., SSBRI / CRI); and the measured beam quantity (e.g., L1-RSRP or SINR depending on configuration). While not shown the list of measurement results and associated information may also include (optionally) information (e.g., a single L / E bit or the like) indicating whether the beam satisfied an 'entering' or a 'leaving' condition (e.g., in a similar manner to that shown in Fig. 7).

[0169] It will be appreciated that the information included in the MAC CE will depend on the type of event that triggered the L1 measurement reporting being provided by that MAC CE relates. For example, if the event that triggered the L1 measurement reporting was event LTM2 (beam of serving cell becomes worse than absolute threshold), then the MAC CE may not include measurement results for the beams of the candidate cells for that L1 measurement report.

[0170] It will also be appreciated that for the purposes of assisting decoding, one or more further fields may be included in the MAC CE for indicating: how many LTM reporting configurations (e.g., LTM reporting configurations represented by different ltm-CSI-ReportConfigIds) are reported; how many beams are being reported for each LTM reporting configuration (e.g., ltm-CSI-ReportConfigId); and / or what field or fields (if any) follows the current field / field set (e.g., one or more fields carrying field carrying identifier of an LTM reporting configuration, one or more fields carrying measurement results / associated information for a beam, or no further fields).

[0171] It will also be appreciated that the use of a MAC CE in accordance with either of the formats shown in Figs. 8 and 9 can help avoid duplicated reporting (e.g., reporting measurement results for the same beam more than once because the same beam triggered L1 measurement reporting for multiple events - i.e., in the third example scenario summarised in the introduction there will be no duplicated report for the same beam).

[0172] Independent Reporting for Each LTM Reporting Configuration / LTM Event in the Same MAC CE 　　As with the previous example, in this example, a single MAC CE may be used to report the L1 measurement results corresponding to associated with a plurality of different LTM reporting configurations / LTM events (e.g., different LTM reporting configurations represented by different ltm-CSI-ReportConfigIds or the like) for which L1 measurement reporting has been triggered. However, in this example, the respective L1 measurement results corresponding to each different LTM reporting configuration / LTM event are reported independently (within the same MAC CE). Specifically, in this example, the UE 3 may be configured to use a single MAC CE to report a respective a list of measurement results and associated information for one or more beams of candidate cells (if the LTM event requires it), independently for each of a plurality of LTM reporting configurations / LTM events (e.g., on a per ltm-CSI-ReportConfigId basis).

[0173] Fig. 10 illustrates a fourth MAC CE format for L1 measurement reporting that may be used in the communication system 1 according to this example.

[0174] As seen in Fig. 10, in this example, the MAC CE carrying the L1 measurement results includes: 　　- A measured beam quantity (e.g., L1-RSRP or SINR depending on configuration) for the current beam (if the LTM event requires it), based on an associated configuration from the serving RAN node 5-1; 　　- For each of the plurality of different LTM reporting configurations / LTM events for which L1 measurement reporting has been triggered (i.e., repeated in turn for each of the plurality of different LTM reporting configurations / LTM events): 　　　　-- Information identifying that LTM reporting configuration / LTM event (e.g., a corresponding ltm-CSI-ReportConfigId or the like); and 　　　　-- A list of measurement results and associated information for each beam of a candidate cell to be reported for that LTM reporting configurations / LTM event. The measurement results and associated information may include, for each beam represented: information identifying the beam (e.g., SSBRI / CRI); and the measured beam quantity (e.g., L1-RSRP or SINR depending on configuration). While not shown the list of measurement results and associated information may also include (optionally) information (e.g., a single L / E bit or the like) indicating whether the beam satisfied an 'entering' or a 'leaving' condition (e.g., in a similar manner to that shown in Fig. 7).

[0175] It will be appreciated that the information included in the MAC CE will depend on the type of event that triggered the L1 measurement reporting being provided by that MAC CE relates. For example, if the event that triggered the L1 measurement reporting was event LTM2 (beam of serving cell becomes worse than absolute threshold), then the MAC CE may not include measurement results for the beams of the candidate cells for that L1 measurement report.

[0176] It will also be appreciated that for the purposes of assisting decoding, one or more further fields may be included in the MAC CE for indicating: how many LTM reporting configurations (e.g., LTM reporting configurations represented by different ltm-CSI-ReportConfigIds) are reported; how many beams are being reported for each LTM reporting configuration (e.g., ltm-CSI-ReportConfigId); and / or what field or fields (if any) follows the current field / field set (e.g., one or more fields carrying field carrying identifier of an LTM reporting configuration, one or more fields carrying measurement results / associated information for a beam, or no further fields).

[0177] For example, if the number of reported beams per LTM reporting configuration / LTM event (e.g., per ltm-CSI-ReportConfigId or the like) is fixed, then a specific bit (e.g. an "R" bit or the like) may be provided, after / before the respective content for each LTM reporting configuration / LTM event (e.g., per ltm-CSI-ReportConfigId or the like). If the specific bit is set to a specific value (e.g., R=1) it indicates that content related to (at least) one more LTM reporting configuration / LTM event is followed and included the MAC CE. Otherwise, if the specific bit is set to a different specific value (e.g., R=0), it indicates that no further content related to another LTM reporting configuration / LTM event is included in the MAC CE following the current one.

[0178] Alternatively, if the number of reported beams per LTM reporting configuration / LTM event (e.g., per ltm-CSI-ReportConfigId or the like) is variable, then a specific bit (e.g. an "B / R" bit or the like) may be provided together with the content associated with each beam (beam quantity and associated beam identification information). The specific bit (e.g. an "B / R" bit or the like) may, for example, be added before the field carrying the beam identification information, after the field carrying the beam quantity, or between those two fields. The specific bit (e.g. an "B / R" bit or the like) may be set to a specific value that indicates whether the information in the field or fields following the content associated with the current beam is: content associated with another beam (beam quantity and associated beam identification information - e.g., another "SSBRI / CRI, RSRP / SINR" field pair); or is a field identifying another LTM reporting configuration / LTM event (e.g., including another ltm-CSI-ReportConfigId or the like). For example, a value of '0' for the specific bit (e.g. an "B / R" bit or the like) may indicate that the following field includes content associated with another beam, and a value of '1' for the specific bit (e.g. an "B / R" bit or the like) may indicate that the following field includes information identifying another LTM reporting configuration / LTM event (e.g., another ltm-CSI-ReportConfigId or the like).

[0179] Other L1 Measurement Reporting MAC CE Format Related Considerations 　　It will be appreciated that, in any of the MAC CE formats described above with reference to Figs. 7 to 10, the beam quantity (e.g., L1-RSRP or SINR) for the current beam of the serving cell may be used as a reference value based on which the beam quantity (e.g., L1-RSRP or SINR) for the beams of one or more candidate cells may be reported. For example, when reporting L1 measurements for one or more beams of one or more candidate cells, the UE 3 may only include, in the associated MAC CE, the difference (or 'delta') between the beam quantity for the reported beam, and the value of that beam quantity (the reference value) for the current beam. Alternatively, some other form of differential reporting may be implemented. For example, the largest measured beam quantity (e.g., L1-RSRP or SINR) may be quantised to an appropriate (e.g., 7-bit) value and other measured values of that measured beam quantity (e.g., L1-RSRP or SINR) may be represented as differential values, relative to the largest measured value (e.g., quantised a value having fewer bits, such as a 4-bit value).

[0180] It will be appreciated that, in any of the MAC CE formats described above with reference to Figs. 7 to 10, the length of the different fields may be any suitable length. Moreover, the order in which the different fields are included in the MAC CE is purely exemplary and any suitable order may be used.

[0181] It will be appreciated that, when a leaving condition is fulfilled, associated L1 measurement results may, or may not, be reported in an associated MAC CE.

[0182] Accordingly, in respect of any of the MAC CE formats described above with reference to Figs. 7 to 10, the UE 3 may be configured simply not to report L1 measurement results when a leaving condition is fulfilled. In this case no E / L bit (as described above) is necessary.

[0183] Alternatively, in respect of any of the MAC CE formats described above with reference to Figs. 7 to 10, the UE 3 may be configured to report L1 measurement results for one or more beams which fulfil a leaving condition without any E / L bit (as described above). In this case it may be left up to the serving RAN node 5-1 to which the MAC CE is sent to resolve whether a leaving condition has been fulfilled based on the reported L1 measurement results.

[0184] In another alternative, in respect of any of the MAC CE formats described above with reference to Figs. 7 to 10, the UE 3 may be configured to report L1 measurement results for one or more beams which fulfil a leaving condition and to include an associated E / L bit (as described above) for each reported beam to indicate if the reported beam fulfils an entering or leaving condition for the associated configured LTM reporting event. One possible implementation of such an E / L bit is shown in the MAC CE format illustrated in Fig. 7. Nevertheless, a similar E / L bit may be implemented in any of the MAC CE formats (e.g., the MAC CE formats illustrated in any of Figs. 8 to 10).

[0185] Moreover, the UE 3 may be configured to report L1 measurement results for one or more beams other than the triggered beam (that fulfilled a entering / leaving condition of an event) e.g., when the number of triggered beams is less than configured maximum reported beam, and the E / L indication may be extended from a single bit to a 2 bits indicator, for indicating whether a related beam fulfilled an entering condition, a leaving condition, or neither an entering nor a leaving condition. It will be appreciated that this may be helpful for indicating a beam that is not a beam that fulfilled an entering condition and is also not a beam that fulfilled a leaving condition.

[0186] In yet another alternative, in respect of any of the MAC CE formats described above with reference to Figs. 7 to 10, the UE 3 may be configured to report L1 measurement results for one or more beams that fulfilled a leaving condition in one MAC CE and to report L1 measurement results for one or more beams that fulfilled an entering condition in another - different - MAC CE. In this case, a single respective E / L bit may be included in each MAC CE is enough to indicate whether that MAC CE includes or results for one or more beams that fulfilled an entering condition.

[0187] Triggering / Cancelling MAC CE Transmission 　　As mentioned above, each RAN node 5, and UE 3, of the communication system 1 may be mutually configured to implement one or more enhanced procedures / mechanisms for triggering transmission of a MAC CE that carries event-triggered L1 measurement reporting, for one or more beams, in accordance with one or more LTM reporting configurations / events, and for cancelling transmission of the L1 measurement results in respect of one or more of those beams when appropriate.

[0188] A number of different possible procedures / mechanisms for such triggering (and / or cancellation) of transmission of L1 measurement results, for one or more beams, in accordance with one or more LTM reporting configurations / events, will now be described, by way of example only.

[0189] LTM Measurement Report List 　　Fig. 11 illustrates a mechanism for maintaining a list of beams, that have fulfilled one or more conditions, in respect of one or more LTM reporting configurations / events that may be implemented in the communication system 1.

[0190] Referring to Fig. 11, in one procedure / mechanism for triggering (and / or cancellation) of transmission of L1 measurement results, for one or more beams, the UE 3 is configured to maintain an 'LTM measurement report list' 1100. It will be appreciated that whilst the term 'LTM measurement report list' is used for clarity the list may have any suitable name and may be maintained in any suitable information element (e.g., a VarLTMMeasReportList IE or the like) by the UE 3.

[0191] The LTM measurement report list 1100 may include a respective LTM reporting configuration specific sub-list 1110x, 1110y, 1110z (1110) for each of one or more LTM reporting configurations / events. Each LTM reporting configuration specific sub-list 1110 may, for example, be represented, in the LTM measurement report list 1100, by information identifying the specific LTM reporting configuration / event to which that LTM reporting configuration specific sub-list 1110 relates (e.g., a corresponding ltm-CSI-ReportConfigId or the like).

[0192] Each LTM reporting configuration specific sub-list 1110 includes one or more beam lists 1120, 1130. Each beam list 1120, 1130 respectively lists information identifying beams that have fulfilled at least one condition in respect of the LTM reporting configuration / event to which the LTM reporting configuration specific sub-list 1110 including that beam list 1120, 1130 relates.

[0193] As seen in Fig. 11, the beam lists 1120, 1130, include a first beam list 1120 which lists information identifying beams that have fulfilled at least one entering condition in respect of the LTM reporting configuration / event to which the LTM reporting configuration specific sub-list 1110 including the first beam list 1120 relates. This first beam list 1120 may be referred to as a 'triggered beam list' 1120 and may be maintained in any suitable information element (e.g., a beamTriggeredList IE or the like) by the UE 3.

[0194] Moreover, as seen in Fig. 11, the beam lists 1120, 1130, may (optionally) also include a second beam list 1130 which lists information identifying beams that have fulfilled at least one leaving condition in respect of the LTM reporting configuration / event to which the LTM reporting configuration specific sub-list 1110 including the second beam list 1130 relates. This second beam list 1130 may be referred to as a 'beams met leaving condition list' 1130 and may be maintained in any suitable information element (e.g., a beamsMetLeavingCondlist IE or the like) by the UE 3.

[0195] Where event-periodic LTM reporting is supported, a ((pre)configured) number of LTM reports for a given LTM reporting configuration / LTM event may be sent on a periodic basis after reporting for that LTM event has first been triggered. In a case where such event-periodic reporting is supported, each LTM reporting configuration specific sub-list 1110 may (optionally) be associated with a periodic reporting timer, or the like, for controlling when respective transmission of each periodic LTM report occurs. Moreover, in a case where such event-periodic reporting of a (pre)configured number of periodic LTM reports is supported, the UE 3 may (optionally) maintain, for each LTM reporting configuration specific sub-list 1110, an associated indication of the number of periodic LTM reports that have already been sent (e.g., in a numberOfReportsSent IE or the like).

[0196] The triggering of transmission of one or more MAC CEs used to report the L1 measurement results, and the content of each MAC CE, may be based on the content of the LTM measurement report list 1100. For example, the information in the first and / or second beam lists 1120, 1130 (triggered beams list and / or beams met leaving condition list) may be used for the construction of one or more L1 measurement reporting MAC CEs (e.g., based on one or more of the MAC CE formats described with reference to Figs. 7 to 10) and when a given L1 measurement reporting MAC CE might be included in a TB - for example based an appropriate prioritisation (e.g., logical channel prioritisation (LCP)).

[0197] It will be appreciated that, if the LTM measurement report list 1100 is empty, then no MAC CE will be triggered, and when the LTM measurement report list 1100 is not empty, one or more MAC CEs may be triggered and subject to an appropriate prioritisation (e.g., logical channel prioritisation (LCP)) procedure for transmission when an uplink grant is available.

[0198] As illustrated in Fig. 11, maintenance of the LTM measurement report list 1100 may involve adding information identifying beams to; and removing information identifying beams from. Maintenance of the LTM measurement report list 1100 may also involve moving information identifying beams from the first ('triggered beam') beam list 1120 to the second ('beam met leaving condition') beam list 1130 (if present).

[0199] The LTM measurement report list 1100 may, for example, be maintained as follows.

[0200] If at least one entering condition is fulfilled, for a given LTM reporting configuration / event, by one or more related / configured beams then: 　　- If there is no information identifying that specific LTM reporting configuration / event already in the LTM measurement report list 1100, then add information identifying that specific LTM reporting configuration / event (e.g., a corresponding ltm-CSI-ReportConfigId or the like) to the LTM measurement report list 1100; and 　　- Respectively add information identifying each beam that has fulfilled one or more entering conditions to the first ('triggered beam') beam list 1120 (in association with the information identifying that specific LTM reporting configuration / event) (as indicated at 1122 in Fig. 11).

[0201] If at least one leaving condition is fulfilled, for a given LTM reporting configuration / event, for one or more beams listed in a first ('triggered beam') beam list 1120 associated with that LTM reporting configuration / event then: 　　- Move the information identifying each beam that has fulfilled one or more leaving conditions out of the first ('triggered beam') beam list 1120; and 　　- If the UE 3 is configured to maintain a second ('beam met leaving condition') beam list 1130, then move the information identifying each beam that has fulfilled one or more leaving conditions into the second ('beam met leaving condition') beam list 1130 (as indicated at 1140 in Fig. 11).

[0202] It will be appreciated that, optionally, the information identifying a given beam that has fulfilled one or more leaving conditions may be moved into the second ('beam met leaving condition') beam list 1130 subject to an additional extra condition requiring that LTM reporting has occurred in respect of that beam for fulfilment of the corresponding entering condition. In this case, if LTM reporting has not occurred in respect of that beam for fulfilment of the corresponding entering condition, then the information identifying the given beam that has fulfilled one or more leaving conditions may be removed from the first ('triggered beam') beam list 1120 (as indicated at 1124 in Fig. 11) without being moved to the second ('beam met leaving condition') beam list 1130.

[0203] Upon a MAC CE corresponding to a given LTM reporting configuration / event being included in a TB, and sent out then, for each beam for which L1 measurement results have been reported: 　　- if information identifying the reported beam is in the second ('beam met leaving condition') beam list 1130, then remove the information identifying the reported beam from the second ('beam met leaving condition') beam list 1130 (as indicated at 1134 in Fig. 11); 　　- if information identifying the reported beam is in the first ('triggered beam') beam list 1120, then: 　　　　-- if event-periodic LTM reporting is supported in which a (pre)configured number of LTM reports may be sent on a periodic basis after an entering condition is fulfilled, until a corresponding leaving condition is fulfilled, then remove the information identifying the reported beam from the first ('triggered beam') beam list 1120 only if LTM reporting for the reported beam has occurred the (pre)configured number of times. A timer (per LTM reporting configuration or per beam) may be defined for prohibiting re-reporting of the reported beam for a certain time period, and / or triggering of a periodic report for the reported beam. 　　　　-- Otherwise, remove the information identifying the reported beam from the first ('triggered beam') beam list 1120 (or, alternatively, leave the information identifying the reported beam in the first ('triggered beam') beam list 1120). 　　- If there is no more information identifying any beams in either the first ('triggered beam') beam list 1120 or the second ('beam met leaving condition') beam list 1130 for a given LTM reporting configuration then remove the information identifying that specific LTM reporting configuration / event (e.g., a corresponding ltm-CSI-ReportConfigId or the like) from the LTM measurement report list 1100.

[0204] MAC CE Triggering per LTM Reporting Configuration 　　The UE 3 may be configured to maintain MAC CE triggering on a per LTM reporting configuration (e.g., per ltm-CSI-ReportConfigId or the like) level. Specifically, the UE 3 may be configured to respectively identify, for each LTM reporting configuration, when transmission of a MAC CE containing L1 measurement results, in respect of one or more beams, configured by that LTM reporting configuration should be triggered.

[0205] For example, a MAC CE for reporting L1 measurement results in respect of a given LTM reporting configuration (e.g., identified by ltm-CSI-ReportConfigId = x) may be trigger when: 　　- An entering condition for a relevant event has been fulfilled for any beams configured for that LTM reporting configuration (e.g., identified by ltm-CSI-ReportConfigId = x); and / or 　　- An associated periodic reporting timer expires (or one or more conditions based on a periodic reporting timer are fulfilled) - e.g., a periodic reporting timer associated with the LTM reporting configuration in an LTM reporting configuration specific sub-list as described above with reference to Fig. 11.

[0206] Transmission of a MAC CE for reporting L1 measurement results in respect of a given LTM reporting configuration (e.g., identified by ltm-CSI-ReportConfigId = x) that has previously been triggered may be cancelled on occurrence of one or more of the following: 　　- A MAC CE corresponding to that LTM reporting configuration (e.g., identified by ltm-CSI-ReportConfigId = x) has been sent out; 　　- A 'full' MAC CE including a full set of L1 measurement results (rather than a 'truncated' MAC CE including a partial set of L1 measurement results) has been sent out (e.g., containing information identifying that LTM reporting configuration (e.g., having ltm-CSI-ReportConfigId = x)); 　　- Measurement results for all beams fulfilling an entering condition for the relevant event associated with that LTM reporting configuration (and (optionally) for all beams fulfilling a leaving condition for the relevant event associated with that LTM reporting configuration) have been included in the triggered MAC CE; 　　- A leaving condition of the relevant event associated with that LTM reporting configuration has been fulfilled for all beams configured for that LTM reporting configuration (e.g., having ltm-CSI-ReportConfigId = x); and / or 　　- Both the first ('triggered beam') beam list 1120 and any second ('beam met leaving condition') beam list 1130 (if present) are empty (if the UE 3 is configured to maintain an LTM measurement report list 1100 as described with reference to Fig. 11).

[0207] MAC CE Triggering per MAC Entity 　　The UE 3 may be configured to maintain MAC CE triggering on a per MAC entity level. Specifically, the UE 3 may be configured to respectively identify, for each MAC entity, when transmission of a MAC CE containing L1 measurement results, in respect of one or more beams, configured by one or more LTM reporting configurations should be triggered.

[0208] For example, a MAC CE for reporting L1 measurement results may be trigger when: 　　- An entering condition for a relevant event corresponding to any configured LTM reporting configuration (e.g., corresponding to any configured ltm-CSI-ReportConfigId = x) has been fulfilled for one or more beams configured for the corresponding LTM reporting configuration (e.g., the LTM reporting configuration corresponding to ltm-CSI-ReportConfigId = x); and / or 　　- An associated periodic reporting timer expires (or one or more conditions based on a periodic reporting timer are fulfilled) - e.g., a periodic reporting timer associated with the corresponding LTM reporting configuration (e.g., the LTM reporting configuration corresponding to ltm-CSI-ReportConfigId = x) in an LTM reporting configuration specific sub-list as described above with reference to Fig. 11.

[0209] Transmission of a MAC CE for reporting L1 measurement that has previously been triggered may be cancelled on occurrence of one or more of the following: 　　- A 'full' MAC CE including a full set of L1 measurement results (rather than a 'truncated' MAC CE including a partial set of L1 measurement results) has been sent (e.g., containing information identifying the LTM reporting configuration that caused triggering of the MAC CE (e.g., having ltm-CSI-ReportConfigId = x)); 　　- Measurement results for all beams fulfilling an entering condition for a relevant event associated with the LTM reporting configuration that caused triggering of the MAC CE (and (optionally) for all beams fulfilling a leaving condition for the relevant event associated with that LTM reporting configuration) have been included in the triggered MAC CE; 　　- A leaving condition of a relevant event has been fulfilled for all beams configured for the corresponding LTM reporting configuration that caused triggering of the MAC CE (e.g., having ltm-CSI-ReportConfigId = x); and / or 　　- Both the first ('triggered beam') beam list 1120 and any second ('beam met leaving condition') beam list 1130 (if present) are empty (if the UE 3 is configured to maintain an LTM measurement report list 1100 as described with reference to Fig. 11).

[0210] Event-Triggered Periodic LTM Measurement Reporting 　　As mentioned above, each RAN node 5, and UE 3, of the communication system 1 may be mutually configured to implement one or more enhanced procedures / mechanisms for supporting LTM event-triggered periodic (or 'event-periodic') LTM measurement reporting in which a periodic L1 measurement report may be transmitted after an event has triggered LTM measurement reporting.

[0211] A number of different possible procedures / mechanisms for supporting LTM event-triggered periodic LTM measurement reporting, will now be described, by way of example only.

[0212] Periodic Reporting Timer per LTM Reporting Configuration 　　To support event-periodic LTM reporting, the UE 3 may be configured to maintain a respective periodic reporting timer for each LTM reporting configuration (e.g., associated with the corresponding ltm-CSI-ReportConfigId).

[0213] For example, where the UE 3 is configured to maintain an LTM measurement report list 1100 as described with reference to Fig. 11 (e.g., in a VarLTMMeasReportList IE or the like), the UE 3 may maintain a different respective periodic reporting timer for each LTM reporting configuration represented in that LTM measurement report list 1100. Specifically, a different respective periodic reporting timer may be associated with information identifying the corresponding LTM reporting configuration (e.g., with each ltm-CSI-ReportConfigId in the VarLTMMeasReportList) in that LTM measurement report list 1100.

[0214] The UE 3 may be configured to start (or restart) the periodic reporting timer, for a corresponding LTM reporting configuration, each time a MAC CE has been sent out that includes L1 measurement reporting for the corresponding LTM reporting configuration (e.g., the transmitted MAC CE includes information identifying the corresponding LTM reporting configuration such as a corresponding ltm-CSI-ReportConfigId).

[0215] While the periodic reporting timer is running, L1 measurement results for the corresponding LTM reporting configuration (e.g., associated with the corresponding ltm-CSI-ReportConfigId) are not included in a triggered MAC CE.

[0216] When the periodic reporting timer expires (or one or more conditions based on a periodic reporting timer are fulfilled), transmission of a MAC CE that includes L1 measurement reporting for the corresponding LTM reporting configuration (e.g., associated with the corresponding ltm-CSI-ReportConfigId) may be triggered and the corresponding L1 measurement results thus reported.

[0217] Periodic Reporting Timer per Beam 　　To support event-periodic LTM reporting, the UE 3 may be configured to maintain a respective periodic reporting timer for each beam that has fulfilled an entering condition for a corresponding LTM event.

[0218] For example, where the UE 3 is configured to maintain an LTM measurement report list 1100 as described with reference to Fig. 11 (e.g., in a VarLTMMeasReportList IE or the like), the UE 3 may maintain a different respective periodic reporting timer for each beam for which corresponding identification information is included in the first ('triggered beam') beam list 1120 for an associated LTM reporting configuration.

[0219] The UE 3 may be configured to start (or restart) the periodic reporting timer, for a corresponding beam, each time a MAC CE has been sent out that includes L1 measurement reporting for the beam. This may be subject to a condition that a corresponding MAC CE has not previously be sent out a (pre)configured maximum number of times (e.g., based on an indication of the number of periodic LTM reports that have already been sent as described with reference to Fig. 11).

[0220] While the periodic reporting timer is running, the L1 measurement results for a corresponding beam will not be reported in a triggered MAC CE.

[0221] When the periodic reporting timer expires (or one or more conditions based on a periodic reporting timer are fulfilled), L1 measurement results for the corresponding beam may be reported in a corresponding MAC CE.

[0222] Periodic Reporting Timer per MAC Entity 　　To support event-periodic LTM reporting, the UE 3 may be configured to maintain a respective periodic reporting timer for each MAC entity.

[0223] In this example, the UE 3 may be configured to start (or restart) the periodic reporting timer each time a 'full' MAC CE including a full set of L1 measurement results (rather than a 'truncated' MAC CE including a partial set of L1 measurement results) has been sent out.

[0224] Optionally, while the periodic reporting timer is running, if another MAC CE for L1 measurement reporting is triggered, by one or more other beams and / or LTM reporting configurations, the triggered MAC CE is sent and the periodic reporting timer restarted (reset and started).

[0225] When the periodic reporting timer expires (or one or more conditions based on a periodic reporting timer are fulfilled), a corresponding MAC CE is sent out.

[0226] Prioritisation of Information Included in the LTM Measurement Report 　　As mentioned above, each RAN node 5, and UE 3, of the communication system 1 may be mutually configured to implement one or more enhanced procedures / mechanisms for prioritising what information should be included in a given MAC CE for L1 measurement reporting and / or for prioritising which MAC CE for L1 measurement reporting should be transmitted at a given time (where a plurality of different MAC CEs for L1 measurement reporting may be sent).

[0227] A number of different possible procedures / mechanisms for prioritising what information should be included in a given MAC CE for L1 measurement reporting, and / or for prioritising which MAC CE for L1 measurement reporting should be transmitted, will now be described, by way of example only.

[0228] Specifically, the UE 3 may be configured for constructing a truncated MAC CE including a partial set of L1 measurement results, or a full MAC CE including a full set of results for a maximum number of beams, for transmission based on logical channel prioritisation (LCP) and the available TB size. When constructing the full / truncated MAC CE for the purposes of L1 measurement reporting, the UE 3 may be configured to prioritise for which beams and / or LTM reporting configurations L1 measurement results should be included in the MAC CE.

[0229] Prioritisation Between Different Beams 　　It will be appreciated that, depending on the prevailing situation, when prioritising L1 measurement results to be included in the MAC CE between different beams, the UE 3 may need to prioritise between different beams: of the same (candidate) cell; of different (candidate) cells; and or associated with the same or different LTM reporting configurations (e.g., the same or different ltm-CSI-ReportConfigIDs).

[0230] First example: 　　In a first example, the UE 3 may be configured to include the L1 measurement results for 'triggered' beam or beams first (e.g., one or more beams that satisfy one or more conditions (entering or leaving) for an event) into the MAC CE carrying the L1 measurement results as a first priority.

[0231] In this first example, if the corresponding beams are to be reported in an event-periodic manner, then at least L1 measurement results for any beam for which L1 measurement reporting has previously been triggered ('previously triggered beams') are included in the MAC CE carrying the L1 measurement results (e.g., in preference to L1 measurement results for another beam). It will be appreciated that it is these previously triggered beams are beams that triggered the ongoing event-periodic reporting.

[0232] Moreover, in this first example, if more than one LTM reporting configuration (e.g., ltm-CSI-ReportConfigId) triggered the MAC CE for L1 measurement reporting, the L1 measurement results for the corresponding beams are included in a sequence corresponding to the order in which triggering occurred. For example, if a first LTM reporting configuration (e.g., ltm-CSI-ReportConfigId X) triggered L1 measurement reporting first, followed by a second LTM reporting configuration (e.g., ltm-CSI-ReportConfigId Y), then L1 measurement results for one or more triggered beams associated with first LTM reporting configuration (ltm-CSI-ReportConfigId X) are included first in the MAC CE, and then L1 measurement results for one or more triggered beams associated with second LTM reporting configuration (ltm-CSI-ReportConfigId Y) are included.

[0233] After including the L1 measurement results for 'triggered' beam or beams (in addition to the L1 measurement results for the serving / current beam where applicable), the L1 measurement results for other beams (e.g., represented in an associated candidate reference signal configuration) in an appropriate order.

[0234] For example, L1 measurement results for one or more other beams may be included in a sequence corresponding to the order in which triggering occurred. For example, in the above scenario, L1 measurement results for one or more other beams of the candidate cell associated with the first LTM reporting configuration (e.g., ltm-CSI-ReportConfigId X) that triggered L1 measurement reporting first may be included before L1 measurement results for one or more other beams of the candidate cell associated with the second LTM reporting configuration (e.g., ltm-CSI-ReportConfigId Y) that triggered L1 measurement reporting later.

[0235] Alternatively, the UE 3 may be configured to sort the other beams, among the measured beams from all (candidate) cells that are associated with the same LTM reporting configuration, based on the L1 measurement results (e.g. L1-RSRP / SINR) for those beams (e.g., from best / highest to worst / lowest). The L1 measurement results for the sorted other beams may then be included in the MAC CE for L1 measurement reporting in the order in which the beams have been sorted, starting with the best beam (exhibiting the best / highest L1-RSRP / SINR). Hence, the MAC CE for L1 measurement reporting will include L1 measurement results for the best quality other beams in preference to poorer quality other beams.

[0236] Alternatively, the UE 3 may be configured to respectively sort the other beams, among the measured beams within each (candidate) cell - for example, based on the L1 measurement results (e.g. L1-RSRP / SINR) for those other beams (e.g., from best / highest to worst / lowest). The UE 3 may then include, in the MAC CE for L1 measurement reporting, L1 measurement results for the other beams of as many different cells as possible (e.g., including the L1 measurement results for the best other beam of each (candidate) cell in turn and then including the second-best other beam of each (candidate) cell in turn, etc.).

[0237] Second example: 　　In a second example, the UE 3 may be configured to sort the beams, among the measured beams from all (candidate) cells that are associated with the same LTM reporting configuration, based on the L1 measurement results (e.g. L1-RSRP / SINR) for those beams (e.g., from best / highest to worst / lowest). The L1 measurement results for the sorted beams may then be included in the MAC CE for L1 measurement reporting in the order in which the beams have been sorted, starting with the best beam (exhibiting the best / highest L1-RSRP / SINR). Hence, the MAC CE for L1 measurement reporting will include L1 measurement results for the best quality beams in preference to poorer quality beams.

[0238] Third example: 　　In a third example, the UE 3 may be configured to respectively sort the beams, among the measured beams within each (candidate) cell - for example, based on the L1 measurement results (e.g. L1-RSRP / SINR) for those beams (e.g., from best / highest to worst / lowest). The UE 3 may then include, in the MAC CE for L1 measurement reporting, L1 measurement results for beams of as many different cells as possible (e.g., including the L1 measurement results for the best beam of each (candidate) cell in turn and then including the second-best beam of each (candidate) cell in turn, etc.).

[0239] For example, take a hypothetical scenario in which L1 measurement results for only two beams can be included in the MAC CE, and in which a first (candidate) cell has two beams that fulfilled an event condition for triggering L1 measurement reporting, and a second (candidate) cell has one beam that fulfilled an event condition for triggering L1 measurement reporting. In this hypothetical scenario, the UE 3 may include, in the MAC CE, the L1 measurement results for the best beam of the first (candidate) cell, and the L1 measurement results for the best beam of the second (candidate) cell, regardless of whether the second-best beam of the first (candidate) cell exhibited a better / higher measurement result than the best beam of the second (candidate) cell.

[0240] Fourth example: 　　In a fourth example, the UE 3 may be configured to firstly prioritise (i.e., sort into a priority order) the respective L1 measurement results associated with different LTM reporting configurations (e.g., having different ltm-CSI-ReportConfigIds), for which L1 measurement reporting has been triggered, either based on: a respective priority configured for each LTM reporting configuration (e.g., ltm-CSI-ReportConfigId); or a respective priority associated with each LTM event (e.g., the priority order may be Event LTM 3 -> Event LTM 5 -> Event LTM 5 -> Event LTM 4 or the like) to which the corresponding LTM reporting configuration relates. The respective group of L1 measurement results for each LTM reporting configuration may then be included in the MAC CE for L1 measurement reporting, in the corresponding priority order (highest to lowest).

[0241] The UE 3 may, additionally, be configured to sort beams corresponding to different LTM reporting configurations (e.g., having different ltm-CSI-ReportConfigIds) respectively - for example, based on the L1 measurement results (e.g. L1-RSRP / SINR) for those beams (e.g., from best / highest to worst / lowest). The L1 measurement results for each beam may then be included in the MAC CE for L1 measurement reporting (within the group of L1 measurement results for the corresponding LTM reporting configuration), in the order in which the beams have been sorted, starting with the best beam (exhibiting the best / highest L1-RSRP / SINR).

[0242] Prioritisation Between Different MAC CEs 　　It will be appreciated that, where the MAC CE format described with reference to Fig. 7 is used, the UE 3 is configured to handle each configured LTM reporting configuration and / or LTM event independently for the purposes of L1 measurement reporting. Specifically, if L1 measurement reporting is triggered for a plurality of different LTM reporting configurations (e.g., different LTM reporting configurations having different ltm-CSI-ReportConfigID values), and / or LTM events, then a plurality of different L1 measurement reporting MAC CEs are constructed (e.g., a respective MAC CE for each LTM reporting configuration / LTM event) at the UE 3.

[0243] In this scenario, therefore, the UE 3 may be configured to prioritise between the different MAC CEs for L1 measurement reporting, to determine which MAC CEs should be transmitted in a case where the uplink grant provides insufficient uplink resources for report all the constructed MR MAC CEs (e.g., corresponding to different LTM reporting configurations (e.g., ltm-CSI-ReportConfigIds)).

[0244] Depending on the prevailing situation, when prioritising L1 measurement results to be included in the MAC CE between different beams, the UE may need to prioritise between different beams: of the same (candidate) cell; of different (candidate) cells; and or associated with the same or different LTM reporting configurations (e.g., the same or different ltm-CSI-ReportConfigIDs).

[0245] First example: 　　In a first example, a respective priority is configured for each LTM reporting configuration (e.g., ltm-CSI-ReportConfigId) and the UE 3 is configured to determine which MAC CE / MAC CEs for L1 measurement reporting should / should not be included in a transmission (in a given TB) based on the configured priorities for the LTM reporting configurations (e.g., using an appropriate LCP procedure).

[0246] Alternatively, a respective priority is associated with each LTM event (e.g., the priority order may be Event LTM 3 -> Event LTM 5 -> Event LTM 5 -> Event LTM 4 or the like) to which a corresponding LTM reporting configuration relates. The UE 3 may then determine which MAC CE / MAC CEs for L1 measurement reporting should / should not be included in a transmission (in a given TB) based on the priorities associated with the LTM events (e.g., using an appropriate LCP procedure).

[0247] Devices of the Communication System User Equipment 　　Fig. 12 is a schematic block diagram illustrating the main components of a UE 3 as shown in Fig. 1.

[0248] As shown, the UE 3 has a transceiver circuit 31 that is operable to transmit signals to and to receive signals from a RAN node 5 via one or more antennas 33 (e.g., comprising one or more antenna elements). The UE 3 has a controller 37 to control the operation of the UE 3. The controller 37 is associated with a memory 39 and is coupled to the transceiver circuit 31. Although not necessarily required for its operation, the UE 3 might, of course, have all the usual functionality of a conventional UE (e.g., a user interface 35, such as a touch screen / keypad / microphone / speaker and / or the like for, allowing direct control by and interaction with a user) and this may be provided by any one or any combination of hardware, software, and firmware, as appropriate. Software may be pre-installed in the memory 39 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example.

[0249] The controller 37 is configured to control overall operation of the UE 3 by, in this example, program instructions or software instructions stored within memory 39. As shown, these software instructions include, among other things, an operating system 41, and a communication control module 43.

[0250] The communication control module 43 is operable to control the communication between the UE 3 and its serving RAN node or RAN nodes 5 (and other communication devices connected to the RAN node 5, such as further UEs 3 and / or core network nodes). The communication control module 43 is configured for the overall handling of uplink communication via associated uplink channels (e.g., via a physical uplink control channel (PUCCH), random access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). The communication control module 43 is also configured for the overall handling of receipt of downlink communication via associated downlink channels (e.g., of DCI via a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) including both dynamic and semi-persistent scheduling (e.g., SPS). The communication control module 43 is responsible, for example: for determining where to monitor for downlink control information; for determining the resources to be used by the UE 3 for transmission / reception of UL / DL communication (including interleaved resources and resources subject to frequency hopping); for managing frequency hopping at the UE side; for determining how slots / symbols are configured (e.g., for UL, DL or full duplex communication, or the like); for determining which bandwidth parts are configured for the UE 3; for determining how uplink transmissions should be encoded and the like.

[0251] It will be appreciated that the communication control module 43 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities. For example, the communication control module 43 may include a PHY sub-module, a MAC sub-module, an RLC sub-module, a PDCP sub-module, an RRC sub-module, etc.

[0252] The communication control module 43 is configured, in particular, to control the UE's communication, where applicable, in accordance with any of the methods described herein.

[0253] RAN node 　　Fig. 13 is a schematic block diagram illustrating the main components of the RAN node 5 for the communication system 1 shown in Fig. 1. As shown, the RAN node 5 has a transceiver circuit 51 for transmitting signals to and for receiving signals from the communication devices (such as UEs 3) via one or more antennas 53 (e.g. a single or multi-panel antenna array / massive antenna), and a core network interface 55 (e.g. comprising the N2, N3 and other reference points / interfaces) for transmitting signals to and for receiving signals from network nodes in the core network 7. Although not shown, the RAN node 5 may also be coupled to other RAN nodes 5 via an appropriate interface (e.g. the so-called 'Xn' interface in NR). The RAN node 5 has a controller 57 to control the operation of the RAN node 5. The controller 57 is associated with a memory 59. Software may be pre-installed in the memory 59 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example. The controller 57 is configured to control the overall operation of the RAN node 5 by, in this example, program instructions or software instructions stored within memory 59.

[0254] As shown, these software instructions include, among other things, an operating system 61, and a communication control module 63.

[0255] The communication control module 63 is operable to control the communication between the RAN node 5 and UEs 3 and other network entities that are connected to the RAN node 5. The communication control module 63 is configured for the overall control of the reception and decoding of uplink communication, via associated uplink channels (e.g. via a physical uplink control channel (PUCCH), a random-access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). The communication control module 63 is also configured for the overall handling the transmission of downlink communication via associated downlink channels (e.g. via a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) including both dynamic and semi-static signalling (e.g., CSI-RS, SSBs etc.). The communication control module 63 is also responsible, for example, for determining and scheduling the resources to be used by the UE 3 for receiving in DL / transmitting in UL, for configuring slots / symbols appropriately (e.g., for UL, DL, flexible, full duplex communication, or the like), for configuring one or more bandwidth parts for the UE 3, and for providing related configuration signalling to the UE 3.

[0256] It will be appreciated that the communication control module 63 may include a number of sub-modules (or 'layers') to support specific functionalities. For example, the communication control module 63 may include a PHY sub-module, a MAC sub-module, an RLC sub-module, a PDCP sub-module, an RRC sub-module, etc.

[0257] The communication control module 63 is configured, in particular, to control the RAN node's communication, where applicable, in accordance with any of the methods described herein.

[0258] Core Network Function 　　Fig. 14 is a schematic block diagram illustrating the main components of a core network function 10 / 11 that may be used in the communication system 1.

[0259] As shown, the core network function 10 / 11 has a transceiver circuit 711 for transmitting signals to and for receiving signals from nodes of the communication system 1 (such as other nodes / functions of the core network 7, and / or RAN nodes 5) via one or more network interfaces 712.

[0260] The core network function 10 / 11 has a controller 713 to control the operation of the core network function 10 / 11 in accordance with the specific functions that that core network function 10 / 11 is required to provide (e.g., when operating as an AMF 10-1, SMF 10-2, UDM, AUSF, PCF, AF, SEAF, ARPF, UPF 11 and / or the like). The controller 713 is configured to control the overall operation of the core network function 10 / 11 by, in this example, program instructions or software instructions stored within memory 714. Software may, for example, be pre-installed in the memory 714 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD). As shown, these software instructions include, among other things, an operating system 715, and a communication control module 716.

[0261] The communication control module 716 is operable to control the communication between the core network function 10 / 11 and other network entities. The communication control module 716 is configured, in particular, to control the communication of core network function 10 / 11, where applicable, in accordance with any of the methods described herein.

[0262] Modifications and Alternatives 　　As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above embodiments whilst still benefiting from the disclosure embodied therein.

[0263] Whilst the above examples have been described with reference to an AI / ML model, it will be appreciated that the above-described methods are advantageous even when the model is not an AI / ML model. Any other suitable type of model or function may be used to generate inferences (e.g. determinations or predictions).

[0264] It will be appreciated, for example, that whilst cellular communication generation (2G, 3G, 4G, 5G, 6G etc.) specific terminology may be used, in the interests of clarity, to refer to specific communication entities, the technical features described for a given entity are not limited to devices of that specific communication generation. The technical features may be implemented in any functionally equivalent communication entity regardless of any differences in the terminology used to refer to them.

[0265] In the above description, the UEs and the RAN node are described for ease of understanding as having a number of discrete functional components or modules. Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the innovative features described, in other applications, for example in systems designed with the innovative features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities.

[0266] In the above example embodiments, a number of software modules were described. As those skilled in the art will appreciate, the software modules may be provided in compiled or un-compiled form and may be supplied as a signal over a computer network, or on a recording medium. Further, the functionality performed by part, or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of the RAN node or the UE in order to update their functionalities.

[0267] The software module or the program includes instructions (or software codes) that, when loaded into a computer, cause the computer to perform one or more of the functions described in the above examples. The program may be stored in a non-transitory computer readable medium or a tangible storage medium. By way of example, and not a limitation, non-transitory computer readable media or tangible storage media can include a random-access memory (RAM), a read-only memory (ROM), a flash memory, a solid-state drive (SSD) or other types of memory technologies, a CD-ROM, a digital versatile disc (DVD), a Blu-ray disc or other types of optical disc storage, and magnetic cassettes, magnetic tape, magnetic disk storage or other types of magnetic storage devices. The program may be transmitted on a transitory computer readable medium or a communication medium. By way of example, and not a limitation, transitory computer readable media or communication media can include electrical, optical, acoustical, or other forms of propagated signals.

[0268] Each controller may comprise any suitable form of processing circuitry including (but not limited to), for example: one or more hardware implemented computer processors; microprocessors; central processing units (CPUs); arithmetic logic units (ALUs); input / output (IO) circuits; internal memories / caches (program and / or data); processing registers; communication buses (e.g. control, data and / or address buses); direct memory access (DMA) functions; hardware or software implemented counters, pointers and / or timers; and / or the like. Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

[0269] The RAN node may comprise a 'distributed' RAN node having a central unit 'CU' and one or more separate distributed units (DUs).

[0270] The User Equipment (or "UE", "mobile station", "mobile device" or "wireless device") in the present disclosure is an entity connected to a network via a wireless interface.

[0271] It should be noted that the present disclosure is not limited to a dedicated communication device and can be applied to any device having a communication function as explained in the following paragraphs.

[0272] The terms "User Equipment" or "UE" (as the term is used by 3GPP), "mobile station", "mobile device", and "wireless device" are generally intended to be synonymous with one another, and include standalone mobile stations, such as terminals, cell phones, smart phones, tablets, cellular IoT devices, IoT devices, and machinery. It will be appreciated that the terms "mobile station" and "mobile device" also encompass devices that remain stationary for a long period of time.

[0273] A UE may, for example, be an item of equipment for production or manufacture and / or an item of energy related machinery (for example equipment or machinery such as: boilers; engines; turbines; solar panels; wind turbines; hydroelectric generators; thermal power generators; nuclear electricity generators; batteries; nuclear systems and / or associated equipment; heavy electrical machinery; pumps including vacuum pumps; compressors; fans; blowers; oil hydraulic equipment; pneumatic equipment; metal working machinery; manipulators; robots and / or their application systems; tools; molds or dies; rolls; conveying equipment; elevating equipment; materials handling equipment; textile machinery; sewing machines; printing and / or related machinery; paper converting machinery; chemical machinery; mining and / or construction machinery and / or related equipment; machinery and / or implements for agriculture, forestry and / or fisheries; safety and / or environment preservation equipment; tractors; precision bearings; chains; gears; power transmission equipment; lubricating equipment; valves; pipe fittings; and / or application systems for any of the previously mentioned equipment or machinery etc.).

[0274] A UE may, for example, be an item of transport equipment (for example transport equipment such as: rolling stocks; motor vehicles; motorcycles; bicycles; trains; buses; carts; rickshaws; ships and other watercraft; aircraft; rockets; satellites; drones; balloons etc.). A UE may, for example, be an item of information and communication equipment (for example information and communication equipment such as: electronic computer and related equipment; communication and related equipment; electronic components etc.).

[0275] A UE may, for example, be a refrigerating machine, a refrigerating machine applied product, an item of trade and / or service industry equipment, a vending machine, an automatic service machine, an office machine or equipment, a consumer electronic and electronic appliance (for example a consumer electronic appliance such as: audio equipment; video equipment; a loud speaker; a radio; a television; a microwave oven; a rice cooker; a coffee machine; a dishwasher; a washing machine; a dryer; an electronic fan or related appliance; a cleaner etc.).

[0276] A UE may, for example, be an electrical application system or equipment (for example an electrical application system or equipment such as: an x-ray system; a particle accelerator; radio isotope equipment; sonic equipment; electromagnetic application equipment; electronic power application equipment etc.).

[0277] A UE may, for example, be an electronic lamp, a luminaire, a measuring instrument, an analyser, a tester, or a surveying or sensing instrument (for example a surveying or sensing instrument such as: a smoke alarm; a human alarm sensor; a motion sensor; a wireless tag etc.), a watch or clock, a laboratory instrument, optical apparatus, medical equipment and / or system, a weapon, an item of cutlery, a hand tool, or the like.

[0278] A UE may, for example, be a wireless-equipped personal digital assistant or related equipment (such as a wireless card or module designed for attachment to or for insertion into another electronic device (for example a personal computer, electrical measuring machine)).

[0279] A UE may be a device or a part of a system that provides applications, services, and solutions described below, as to "internet of things (IoT)", using a variety of wired and / or wireless communication technologies.

[0280] Internet of Things devices (or "things") may be equipped with appropriate electronics, software, sensors, network connectivity, and / or the like, which enable these devices to collect and exchange data with each other and with other communication devices. IoT devices may comprise automated equipment that follow software instructions stored in an internal memory. IoT devices may operate without requiring human supervision or interaction. IoT devices might also remain stationary and / or inactive for a long period of time. IoT devices may be implemented as a part of a (generally) stationary apparatus. IoT devices may also be embedded in non-stationary apparatus (e.g. vehicles) or attached to animals or persons to be monitored / tracked.

[0281] It will be appreciated that IoT technology can be implemented on any communication devices that can connect to a communication system for sending / receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.

[0282] It will be appreciated that IoT devices are sometimes also referred to as Machine-Type Communication (MTC) devices or Machine-to-Machine (M2M) communication devices. It will be appreciated that a UE may support one or more IoT or MTC applications. Some examples of MTC applications are listed in the following table. This list is not exhaustive and is intended to be indicative of some examples of machine-type communication applications.

[0283] Applications, services, and solutions may be an MVNO (Mobile Virtual Network Operator) service, an emergency radio communication system, a PBX (Private Branch eXchange) system, a PHS / Digital Cordless Telecommunications system, a POS (Point of sale) system, an advertise calling system, an MBMS (Multimedia Broadcast and Multicast Service), a V2X (Vehicle to Everything) system, a train radio system, a location related service, a Disaster / Emergency Wireless Communication Service, a community service, a video streaming service, a femto cell application service, a VoLTE (Voice over LTE) service, a charging service, a radio on demand service, a roaming service, an activity monitoring service, a telecom carrier / communication NW selection service, a functional restriction service, a PoC (Proof of Concept) service, a personal information management service, an ad-hoc network / DTN (Delay Tolerant Networking) service, etc.

[0284] Further, the above-described UE categories are merely examples of applications of the technical ideas and example embodiments described in the present document. Needless to say, these technical ideas and example embodiments are not limited to the above-described UE and various modifications can be made thereto.

[0285] Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

[0286] While the present disclosure has been particularly shown and described with reference to example embodiments thereof, the present disclosure is not limited to these example embodiments. It will be understood by those of ordinary skill in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present disclosure as defined by the claims. And each embodiment can be appropriately combined with at least one of embodiments.

[0287] Each of the drawings or figures is merely an example to illustrate one or more example embodiments. Each figure may not be associated with only one particular example embodiment, but may be associated with one or more other example embodiments. As those of ordinary skill in the art will understand, various features or steps described with reference to any one of the figures can be combined with features or steps illustrated in one or more other figures, for example, to produce example embodiments that are not explicitly illustrated or described. Not all of the features or steps illustrated in any one of the figures to describe an example embodiment are necessarily essential, and some features or steps may be omitted. The order of the steps described in any of the figures may be changed as appropriate.

[0288] This application is based upon and claims the benefit of priority from United Kingdom patent application No. 2501781.5, filed on February 6, 2025, the disclosure of which is incorporated herein in its entirety by reference.

[0289] The whole or part of the examples disclosed above can be described as, but not limited to, the following supplementary notes.

[0290] (Supplementary note 1) 　　A method performed by a User Equipment, UE, the method comprising: 　　receiving, from a network node, a Radio Resource Control, RRC, message comprising a first ID identifying a first configuration to configure the UE to perform an L1 measurement; 　　performing the L1 measurement; 　　during a procedure for reporting the L1 measurement, maintaining one or more lists comprising: 　　　　a first list indicating a first set of one or more beams for which an entry condition corresponding to the first ID is fulfilled; and 　　　　a second list indicating a second set of one or more beams for which a leaving condition corresponding to the first ID is fulfilled; and 　　triggering, based on the L1 measurement, an L1 measurement report to the network node.

[0291] (Supplementary note 2) 　　The method of Supplementary note 1, further comprising: 　　based on the entry condition for an event associated with the first ID being fulfilled for the first set of one or more beams, including indices of each beam of the first set of one or more beams, in the first list.

[0292] (Supplementary note 3) 　　The method of Supplementary note 2, further comprising: 　　based on a beam from the first set of one or more beams being in the second list, removing the beam from the first list.

[0293] (Supplementary note 4) 　　The method of any one of Supplementary notes 1-3, further comprising: 　　based on the entry condition for an event associated with the first ID being fulfilled for the first set of one or more beams, initiating a procedure for the L1 measurement report.

[0294] (Supplementary note 5) 　　The method of Supplementary note 1, further comprising: 　　based on the leaving condition for an event associated with the first ID being fulfilled for the second set of one or more beams, including indices of each beam of the second set of one or more beams, in the second list.

[0295] (Supplementary note 6) 　　The method of Supplementary note 5, further comprising: 　　based on a beam from the second set of one or more beams being in the first list, removing the beam from the second list.

[0296] (Supplementary note 7) 　　The method of any one of Supplementary notes 1, 5 or 6, further comprising: 　　based on the leaving condition for an event associated with the first ID being fulfilled for the second set of one or more beams, initiating a procedure for the L1 measurement report.

[0297] (Supplementary note 8) 　　The method of any one of Supplementary notes 1-7, further comprising: 　　restarting a periodic reporting timer for the first ID.

[0298] (Supplementary note 9) 　　The method of any one of Supplementary notes 1-8, wherein the first ID is ltm-CSI-ReportConfigId.

[0299] (Supplementary note 10) 　　The method of any one of Supplementary notes 1-9, wherein the one or more lists comprises a measurement report list.

[0300] (Supplementary note 11) 　　The method of any one of Supplementary notes 1-10, wherein the L1 measurement report is an event triggered L1 measurement report.

[0301] (Supplementary note 12) 　　The method of any one of Supplementary notes 1-11, wherein the L1 measurement report is transmitted in a Media Access Control, MAC, Control Element, CE.

[0302] (Supplementary note 13) 　　The method of Supplementary note 12, wherein the MAC CE comprises at least one of: 　　a second ID corresponding to the first ID associated with the L1 measurement report, 　　an indication of a type of a beam corresponding to a candidate cell in the L1 measurement report, wherein the type includes whether the entry condition is fulfilled, or whether the leaving condition is fulfilled, 　　at least either a Synchronization Signals, SS / Physical Broadcast Channel, PBCH, Block Resource indicator, SSBRI, or a Channel State Information Reference Signal, CSI-RS, resource indicator, CRI, of the beam, 　　a first L1- Reference Signal Received Power, RSRP, of a first beam, a differential measured quantity for the beam with reference to the first L1-RSRP, and a second L-RSRP of a current beam.

[0303] (Supplementary note 14) 　　The method of Supplementary note 13, wherein the first L1-RSRP is indicated by 7 bits, and the differential measured quantity is indicated by 4 bits.

[0304] (Supplementary note 15) 　　The method of any one of Supplementary notes 1-14, wherein in a case where the RRC message comprises more than one first IDs with different values, 　　transmitting more than one MAC CEs corresponding to the more than one first IDs.

[0305] (Supplementary note 16) 　　The method of any one of Supplementary notes 1-15, further comprising: 　　determining priority of the L1 measurement report based on at least one of the first list and the second list.

[0306] (Supplementary note 17) 　　A method performed by network node, the method comprising: 　　transmitting, to a User Equipment, UE, a Radio Resource Control, RRC, message comprising a first ID identifying a first configuration to configure the UE to perform an L1 measurement, wherein, 　　　　during a procedure for reporting the L1 measurement, one or more lists are maintained by the UE, and 　　　　the one or more lists comprise: 　　　　a first list indicating a first set of one or more beams for which an entry condition corresponding to the first ID is fulfilled; and 　　　　a second list indicating a second set of one or more beams for which a leaving condition corresponding to the first ID is fulfilled; and 　　receiving, from the UE, an L1 measurement report based on the L1 measurement.

[0307] Some or all of elements (e.g., structures and functions) specified in Supplementary Notes 2 to 16 dependent on Supplementary Note 1 may also be dependent on Supplementary Note 17 in dependency similar to that of Supplementary Notes 2 to 16 on Supplementary Note 1. Some or all of elements specified in any of Supplementary Notes may be applied to various types of hardware, software, and recording means for recording software, systems, and methods.

[0308] 1　　COMMUNICATION SYSTEM 3　　USER EQUIPMENT (UE) 5　　RADIO ACCESS NETWORK (RAN) NODE 5-1　　SOURCE RAN NODE 5-2　　TARGET RAN NODE 7　　CORE NETWORK 10　　CONTROL PLANE FUNCTION (CPF) 10-1　　ACCESS AND MOBILITY MANAGEMENT FUNCTION (AMF) 10-2　　SESSION MANAGEMENT FUNCTION (SMF) 10-n　　OTHER FUNCTION 11　　USER PLANE FUNCTION (UPF) 20　　EXTERNAL DATA NETWORK 31　　TRANSCEIVER CIRCUIT 33　　ANTENNA 35　　USER INTERFACE 37　　CONTROLLER 39　　MEMORY 41　　OPERATING SYSTEM 43　　COMMUNICATION CONTROL MODULE 51　　TRANSCEIVER CIRCUIT 53　　ANTENNA 55　　CORE NETWORK INTERFACE 57　　CONTROLLER 59　　MEMORY 61　　OPERATING SYSTEM 63　　COMMUNICATION CONTROL MODULE 711　　TRANSCEIVER CIRCUIT 712　　NETWORK INTERFACE 713　　CONTROLLER 714　　MEMORY 715　　OPERATING SYSTEM 716　　COMMUNICATION CONTROL MODULE

Claims

1. A method performed by a User Equipment, UE, the method comprising: 　　receiving, from a network node, a Radio Resource Control, RRC, message comprising a first ID identifying a first configuration to configure the UE to perform an L1 measurement; 　　performing the L1 measurement; 　　during a procedure for reporting the L1 measurement, maintaining one or more lists comprising: 　　　　a first list indicating a first set of one or more beams for which an entry condition corresponding to the first ID is fulfilled; and 　　　　a second list indicating a second set of one or more beams for which a leaving condition corresponding to the first ID is fulfilled; and 　　triggering, based on the L1 measurement, an L1 measurement report to the network node.

2. The method of claim 1, further comprising: 　　based on the entry condition for an event associated with the first ID being fulfilled for the first set of one or more beams, including indices of each beam of the first set of one or more beams, in the first list.

3. The method of claim 2, further comprising: 　　based on a beam from the first set of one or more beams being in the second list, removing the beam from the first list.

4. The method of any one of claims 1-3, further comprising: 　　based on the entry condition for an event associated with the first ID being fulfilled for the first set of one or more beams, initiating a procedure for the L1 measurement report.

5. The method of claim 1, further comprising: 　　based on the leaving condition for an event associated with the first ID being fulfilled for the second set of one or more beams, including indices of each beam of the second set of one or more beams, in the second list.

6. The method of claim 5, further comprising: 　　based on a beam from the second set of one or more beams being in the first list, removing the beam from the second list.

7. The method of any one of claims 1, 5 or 6, further comprising: 　　based on the leaving condition for an event associated with the first ID being fulfilled for the second set of one or more beams, initiating a procedure for the L1 measurement report.

8. The method of any one of claims 1-7, further comprising: 　　restarting a periodic reporting timer for the first ID.

9. The method of any one of claims 1-8, wherein the first ID is ltm-CSI-ReportConfigId.

10. The method of any one of claims 1-9, wherein the one or more lists comprises a measurement report list.

11. The method of any one of claims 1-10, wherein the L1 measurement report is an event triggered L1 measurement report.

12. The method of any one of claims 1-11, wherein the L1 measurement report is transmitted in a Media Access Control, MAC, Control Element, CE.

13. The method of claim 12, wherein the MAC CE comprises at least one of: 　　a second ID corresponding to the first ID associated with the L1 measurement report, 　　an indication of a type of a beam corresponding to a candidate cell in the L1 measurement report, wherein the type includes whether the entry condition is fulfilled, or whether the leaving condition is fulfilled, 　　at least either a Synchronization Signals, SS / Physical Broadcast Channel, PBCH, Block Resource indicator, SSBRI, or a Channel State Information Reference Signal, CSI-RS, resource indicator, CRI, of the beam, 　　a first L1- Reference Signal Received Power, RSRP, of a first beam, a differential measured quantity for the beam with reference to the first L1-RSRP, and a second L-RSRP of a current beam.

14. The method of claim 13, wherein the first L1-RSRP is indicated by 7 bits, and the differential measured quantity is indicated by 4 bits.

15. The method of any one of claims 1-14, wherein in a case where the RRC message comprises more than one first IDs with different values, 　　transmitting more than one MAC CEs corresponding to the more than one first IDs.

16. The method of any one of claims 1-15, further comprising: 　　determining priority of the L1 measurement report based on at least one of the first list and the second list.

17. A method performed by network node, the method comprising: 　　transmitting, to a User Equipment, UE, a Radio Resource Control, RRC, message comprising a first ID identifying a first configuration to configure the UE to perform an L1 measurement, wherein, 　　　　during a procedure for reporting the L1 measurement, one or more lists are maintained by the UE, and 　　　　the one or more lists comprise: 　　　　a first list indicating a first set of one or more beams for which an entry condition corresponding to the first ID is fulfilled; and 　　　　a second list indicating a second set of one or more beams for which a leaving condition corresponding to the first ID is fulfilled; and 　　receiving, from the UE, an L1 measurement report based on the L1 measurement.

Images