WO2026027090A1 - Signalisation de capacités d'ia/ml d'ue - Google Patents

Signalisation de capacités d'ia/ml d'ue

Info

Publication number
WO2026027090A1
WO2026027090A1 PCT/EP2025/064246 EP2025064246W WO2026027090A1 WO 2026027090 A1 WO2026027090 A1 WO 2026027090A1 EP 2025064246 W EP2025064246 W EP 2025064246W WO 2026027090 A1 WO2026027090 A1 WO 2026027090A1
Authority
WO
WIPO (PCT)
Prior art keywords
network entity
capabilities
target network
relate
mobility
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/EP2025/064246
Other languages
English (en)
Inventor
Mahmood Reza ALIZADEH ASHRAFI
Endrit DOSTI
Sakira HASSAN
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Technologies Oy
Original Assignee
Nokia Technologies Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Technologies Oy filed Critical Nokia Technologies Oy
Publication of WO2026027090A1 publication Critical patent/WO2026027090A1/fr
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
    • H04W8/24—Transfer of terminal data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/16—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using machine learning or artificial intelligence
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0033—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0055—Transmission or use of information for re-establishing the radio link
    • H04W36/0064—Transmission or use of information for re-establishing the radio link of control information between different access points
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/08—Reselecting an access point
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/24—Reselection being triggered by specific parameters

Definitions

  • the following disclosure relates to the field of communication technology, in particular communication networks, in particular wireless communication networks.
  • the disclosure may for example relate to an apparatus, a method, a computer program, and a computer readable medium for transmitting and/or receiving information indicating one or more capabilities of a user equipment (UE) that relate to Artificial Intelligence (Al) and/or Machine Learning (ML), in particular during mobility of the UE.
  • UE user equipment
  • Al Artificial Intelligence
  • ML Machine Learning
  • Initial use cases include CS1 feedback enhancement (e.g., overhead reduction, improved accuracy), beam management (e.g., beam prediction in time, and/or spatial domain for overhead and latency reduction), and/or positioning accuracy enhancements.
  • CS1 feedback enhancement e.g., overhead reduction, improved accuracy
  • beam management e.g., beam prediction in time, and/or spatial domain for overhead and latency reduction
  • positioning accuracy enhancements e.g., positioning accuracy enhancements.
  • the features enabled by these initial use cases will instigate the new use cases such as Al/ML mobility.
  • the UE capability signaling framework is provisioned to be a main enabler of the Al/ML-based solutions over the air interface. Conditions, which identify AL/ML features/functionalities, can be signaled through the UE capability message.
  • the number of conditions and their potential content/values are extensive. Moreover, they are expected to only grow when new Al/ML use cases and functionalities are introduced. Furthermore, the concept of dynamic UE capability is considered, in other words, the UE capability is no longer static (with reference to the legacy functionality) and could change after some time. This will make it even more laborious to signal the conditions through a UE capability message (e.g., in the RRC configuration) and the corresponding synchronization from the network side to process, especially during mobility of the UE.
  • a UE capability message e.g., in the RRC configuration
  • a UE capability exchange framework for mobility events is proposed that, in various embodiments, allows to better serve entities, e.g., in terms of reduced signaling and message size and/or coordination overheads, where Al/ML features are enabled over the air interface.
  • a method e.g., performed by a network entity, comprising: transmitting, to a target network entity for layer 3 handover mobility of a UE, an inquiry about one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the target network entity; receiving, from the target network entity, information indicating one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the target network entity; transmitting, to the UE, based on the received information, information indicating the one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the target network entity.
  • a method e.g., performed by a network entity, comprising: receiving, from a serving network entity for layer 3 handover mobility of a UE, an inquiry about one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the network entity; transmitting, to the serving network entity, information indicating one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the network entity.
  • a method e.g., performed by a UE, comprising: receiving, from a serving network entity for layer 3 handover mobility of the UE, information indicating one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to a target network entity for the layer 3 handover mobility of the UE; based on the received information, determining functionality that relates to Al and/or Machine ML, and that is supported by the target network entity.
  • a network entity comprising: means for transmitting, to a target network entity for layer 3 handover mobility of a UE, an inquiry about one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the target network entity; means for receiving, from the target network entity, information indicating one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the target network entity; means for transmitting, to the UE, based on the received information, information indicating the one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the target network entity.
  • a network entity comprising: means for receiving, from a serving network entity for layer 3 handover mobility of a UE, an inquiry about one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the network entity; means for transmitting, to the serving network entity, information indicating one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the network entity.
  • a user equipment comprising: means for receiving, from a serving network entity for layer 3 handover mobility of the UE, information indicating one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to a target network entity for the layer 3 handover mobility of the UE; means for, based on the received information, determining functionality that relates to Al and/or ML, and that is supported by the target network entity.
  • a method e.g., performed by a network entity, comprising: transmitting, to one or more candidate target network entities for mobility of a UE, an inquiry about one or more capabilities of the UE that relate to Artificial Intelligence, Al, and/or Machine Learning, ML, and that are of interest to the respective candidate target network entity; receiving, from the one or more candidate target network entities, information indicating one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the respective candidate target network entity; transmitting, to the UE, based on the received information, information indicating the one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the respective candidate target network entity.
  • a method e.g., performed by a network entity, comprising: receiving, from the serving network entity for mobility of a UE, an inquiry about one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the network entity; transmitting, to the serving network entity, information indicating one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the network entity.
  • a method e.g., performed by a UE, comprising: receiving, from a serving network entity for mobility of the UE, information indicating one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to a respective candidate target network entity of one or more candidate target network entities for the mobility of the UE; based on the received information, determining functionality that relates to Al and/or ML, and that is supported by a target network entity selected from the one or more candidate target network entities.
  • a network entity comprising: means for transmitting, to one or more candidate target network entities for mobility of a UE, an inquiry about one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the respective candidate target network entity; means for receiving, from the one or more candidate target network entities, information indicating one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the respective candidate target network entity; means for transmitting, to the UE, based on the received information, information indicating the one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the respective candidate target network entity.
  • a network entity comprising: means for receiving, from a serving network entity for mobility of a UE, an inquiry about one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the network entity; means for transmitting, to the serving network entity, information indicating one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the network entity.
  • a user equipment comprising: means for receiving, from a serving network entity for mobility of the UE, information indicating one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to a respective candidate target network entity of one or more candidate target network entities for the mobility of the UE; means for, based on the received information, determining functionality that relates to Al and/or ML, and that is supported by a target network entity selected from the one or more candidate target network entities.
  • a method e.g., performed by a serving network entity for a mobility of a UE, comprising: receiving, from the UE, information indicating one or more capabilities of the UE that relate to Al and/or ML; based on the information received from the UE, transmitting, to one or more (e.g., candidate) target network entities of the mobility for the UE, a report of the one or more capabilities of the UE that relate to Al and/or ML
  • a method e.g., performed by a (e.g., candidate) target network entity for a mobility of a UE, comprising: receiving, from a serving network entity of the mobility of the UE, a report of one or more capabilities of the UE that relate to Al and/or ML.
  • any disclosure herein relating to any example aspect is to be understood to be equally disclosed with respect to any subject-matter according to the respective example aspect, e.g. relating to an apparatus, a method, a computer program, and a computer- readable medium.
  • any passage describing at least one processor; and at least one memory including instructions; the at least one memory and the instructions configured to, with the at least one processor, cause an apparatus at least to perform a step is to be understood as disclosing the step as a method step itself.
  • any passage describing a method or method step is to be understood as disclosing that at least one processor; and at least one memory including instructions; the at least one memory and the instructions configured to, with the at least one processor, cause an apparatus at least to perform the method or method step.
  • the disclosure of a method or a method step shall also be considered as a disclosure of means for performing and/or causing to perform the respective method or method step.
  • the disclosure of means for performing and/or causing to perform a method or method step shall also be considered as a disclosure of the method or method step itself.
  • an apparatus e.g., a network entity or UE
  • a network entity or UE configured to carry out, perform and/or control or comprising respective means for performing and/or controlling the method according to any of the above-mentioned example aspects.
  • an apparatus e.g., a UE or network entity
  • at least one processor comprising at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform the method according to any aspect.
  • the apparatus e.g., UE or network entity
  • the apparatus may comprise means for performing the specified method or steps.
  • the disclosed apparatus may comprise only (i.e., consist of) the disclosed components, for instance means, processor, memory, circuitry, or may further comprise one or more additional components.
  • the means may be implemented in hardware and/or software. They may comprise for instance at least one processor for executing processor instructions for performing the required functions, at least one memory storing the instructions, or both. Alternatively, they could comprise for instance circuitry that is designed or configured to implement the required functions, for instance implemented in a chipset or a chip, like an integrated circuit.
  • the means may comprise for instance one or more processing means or processors.
  • circuitry may refer to one or more or all of the following:
  • circuit(s) and or processor(s) such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.
  • software e.g., firmware
  • circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware.
  • circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device. Any apparatus mentioned herein may comprise circuitry.
  • a UE may be an apparatus that allows a user or an application access to network services.
  • a UE may be a cell phone, smartphone, tablet, laptop, TV or loT- device.
  • the link between the UE and the network may be a radio link.
  • a network entity may be a network entity of a communications network, for instance a TRP, a gNB, a RAN node, a base station, or part thereof.
  • a network entity may be a distributed unit (DU) of a gNB.
  • a network entity may be logically and/or physically distributed.
  • target network entity “candidate target network entity” and “source network entity” may be understood as terms serving to distinguishing different roles of network entities in the context of mobility. The different terms may, but do not necessarily imply that the network entities have different functionality.
  • a computer program product when executed by a processor of an apparatus (e.g., a UE) causing said apparatus to perform a method according to any example aspect.
  • a computer program when executed by a processor causing one or more apparatuses, for instance a UE or network entity, to perform and/or control the actions of the method according to any example aspect.
  • a computer readable storage medium e.g. tangible and/or non- transitory
  • the computer readable storage medium comprising at least one of the disclosed computer program products or computer programs.
  • the system may comprise at least one of the following: one or more UE and one or more network entities, e.g., a serving network entity for a mobility of the UE and a target network entity for the mobility of the UE (and optionally one or more candidate target network entities for the mobility of the UE).
  • network entities e.g., a serving network entity for a mobility of the UE and a target network entity for the mobility of the UE (and optionally one or more candidate target network entities for the mobility of the UE).
  • Al/ML also referred to as Al/ML or A1ML.
  • Al/ML algorithms are intended, inter alia, for enhancing performance and/or reducing complexity /overhead, e.g., in air-interface use cases.
  • the LCM may be functionality-based, involving, e.g., Al/ML functionality identification between the network and UE.
  • Al/ML functionality identification may allow the network and/or UE to transmit information regarding their Al/ML capabilities/functionality to the other entity. This identification process may, for example, enable the network to determine which Al/ML features can be activated for a particular UE.
  • functionality identification may be understood as a process/method of identifying an Al/ML functionality for the common understanding between the network (NW) and the UE.
  • Functionality may refer to an Al/ML-enabled feature or feature group enabled by one or more configurations, where the one or more configurations may be supported based on conditions indicated by one or more UE capabilities (which may be understood as a capability of the UE that relates to Al and/or ML).
  • a network entity in particular the serving network entity of the mobility
  • a network entity in a network already knows at least some of a UE’s capabilities and can share this information with other network entities that require it (e.g., the same UE capability and/or additional UE capability of the same UE), e.g., for synchronization (e.g., the target network entity and/or one or more candidate target network entities for the mobility).
  • a mobility of a UE may be understood as a transition of the UE from a source cell which is associated with a network entity (which may thus be called source network entity) to a target cell which is associated with a network entity (which may thus be called target network entity).
  • the source network entity may be a gNB and the target network entity may be another gNB, e.g., a neighboring gNB.
  • the source network entity may be a gNB-DU and the target network entity may be another gNB-DU, belonging to the same or another gNB as the source gNB-DU.
  • source cell and target cell are associated with the same network entity, e.g., the same gNB-DU for intra- gNB-DU mobility. Other combinations are possible.
  • the mobility management of a UE in networks may involve various mechanisms to facilitate the transition between different cells.
  • handover also known as layer 3 mobility
  • conditional handover and low-layer triggered mobility are prominent techniques.
  • Layer 3 handover mobility typically involves transferring an ongoing connection from one cell (corresponding to a serving network entity) to another (corresponding to the target network entity), e.g., as the UE moves across cell boundaries. This process may be initiated by the serving cell, e.g., based on measurements reported by the UE, which may include signal strength and/or quality of neighboring cells. The decision for handover may be made by the network's Radio Resource Management (RRM) function, which may consider factors such as signal degradation, load balancing, and/or user Quality of Service (QoS) requirements.
  • RRM Radio Resource Management
  • Conditional handover is an advanced mobility technique designed to enhance the reliability and efficiency of the handover process.
  • Conditional handover may involve pre-configuring target cell information, e.g., before the actual need for handover arises.
  • the network may pre-configure one or multiple potential target cells for the UE (corresponding to one or more candidate target network entities), e.g., based on its movement patterns and/or network conditions. This may allow for quicker decisionmaking when a handover is triggered.
  • Specific conditions and/or thresholds such as signal strength or quality metrics, may be defined under which the handover will be executed.
  • the latency associated with resource allocation and/or command processing may be reduced. This may result in a smoother transition. This method may be particularly beneficial in high-mobility scenarios, such as those involving high-speed trains where rapid and frequent handovers are necessary.
  • Low-layer triggered mobility refers to mobility mechanisms that may be initiated based on triggers from the lower layers of the network stack, primarily the physical (layer 1) and/or data link (layer 2) layers. This approach is designed to respond quickly to changing radio conditions. Mobility decisions may be based on low-layer metrics such as signal-to-noise ratio (SNR) and/or bit error rate (BER), allowing for a faster response to deteriorating signal conditions.
  • SNR signal-to-noise ratio
  • BER bit error rate
  • the reliance on low-layer triggers enables immediate responses to urgent radio conditions, reducing the likelihood of connection drops or significant performance degradation.
  • This method may complement higher-layer mobility management by ensuring optimal utilization of network resources and/or robust performance in dynamic environments, such as urban areas with high building density or environments with significant interference.
  • one or more candidate target cells may be pre-configured.
  • information exchange between the serving network entity and a target network entity and/or one or more candidate target network entities may be employed to reduce the amount of overhead, e.g., the information that a UE needs to exchange with the target network entity and/or the one or more candidate target network entities.
  • a UE may transmit, to a serving network entity, information indicating one or more capabilities of the UE that relate to Al and/or ML.
  • the serving network entity may receive, from the UE, the information indicating one or more capabilities of the UE that relate to Al and/or ML. This may happen, e.g., before RRC configuration and establishment between UE and the serving network entity. Moreover, this may happen before any mobility of the UE is planned and/or decided.
  • the information may be transmitted from the UE to the serving network entity, e.g., in response to an inquiry from the serving network entity.
  • the information may concern some or all of the capabilities of the UE that relate to Al and/or ML.
  • the serving network entity may transmit a report of the one or more capabilities of the UE that relate to Al and/or ML to one or more other network entities.
  • These one or more other network entities may be or comprise a target network entity of the mobility of the UE.
  • this transmission may happen after the HO decision has been taken, e.g., by the serving network entity.
  • the one or more other network entities may be candidate target network entities, e.g., when it has not yet been decided whether the mobility will take place and/or to which target network entity.
  • the target network entity or the one or more candidate target network entities may receive, from the serving network entity, the report of the one or more capabilities of the UE that relate to Al and/or ML.
  • the target network entity will already have at least some information relating to the UE’s capabilities and does not need to inquire this from the UE, e.g., after or during the mobility.
  • the report may be a complete or a partial (i.e., not complete) report of the UE’s capabilities that relate to Al and/or ML. This may have various reasons. For example, the serving network entity may have only inquired information about specific capabilities from the UE in the first place.
  • the serving network entity may transmit, to the target network entity or the one or more candidate target network entities, information indicating that the report is a partial UE capability report.
  • the target network entity or the one or more candidate target network entities may receive from the serving network entity, the information indicating that the report is a partial UE capability report.
  • the information indicating that the report is a partial UE capability report may be, e.g., a flag.
  • the target network entity or the candidate target network entity may thus be informed of how likely it is that the UE has further capabilities that relate to Al and/or ML. For example, when the received information indicates that the report is a partial UE capability report, the target network entity may decide to inquire information about further capabilities of the UE that relate to Al and/or ML.
  • the target network entity may decide to do so also when there is no indication that the report is a partial UE capability report or there is even information that the report is a complete UE capability report. This may make sense when the target network entity expects that UE has changed its capabilities after reporting them to the serving network entity. However, when there is no indication that the report is a partial UE capability report or there is even information that the report is a complete UE capability report, the target network entity may alternatively decide to not perform further inquiries, e.g., to reduce overhead.
  • the above-described process might be sufficient for sharing the UE’s capabilities relating to Al and/or ML with the (candidate) target network entity (s).
  • the target network entity e.g., when only a partial reportis exchanged, the target network entity (and/or one or more candidate target network entities) may be interested in further information.
  • the abovedescribed process is not performed at all, e.g., because the serving network entity has no information on UE’s capabilities stored (e.g., it never received them, could not process them, or has deleted them in the meantime) or no such procedure for sharing the UE’s capabilities as described above is defined, e.g., in a standard. Therefore, another mechanism may be used additionally or alternatively.
  • a serving network entity of a UE may transmit, to a target network entity for mobility of a UE, an inquiry about one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the target network entity.
  • the target network entity may receive, from the serving network entity for the mobility of the UE, the inquiry about the one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the target network entity.
  • the inquiry may be transmitted in a message.
  • the inquiry may be transmitted separately or together with an optional UE capability report described earlier.
  • the inquiry may correspond to a partial UE capability report that is sent.
  • a (candidate) target network entity receives a partial UE capability report, it will consider this partial UE capability report to implicitly signal an inquiry about one or more capabilities of the UE that relate to Artificial Intelligence, Al, and/or Machine Learning, ML, and that are of interest to the target network entity.
  • the one or more capabilities may be of interest to the target network entity because they concern one or more functionalities that the target network entity supports or wants the UE to use.
  • the target network entity may transmit, to the serving network entity, information indicating one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the network entity.
  • the serving network entity may receive, from the target network entity, the information indicating the one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the target network entity.
  • the information indicating the one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the target network entity may indicate one or more specific capabilities, e.g., by identifying these one or more specific capabilities. Additionally or alternatively, the information may indicate one or more groups of capabilities. A respective group could, for instance, comprise or consist of all capabilities relevant to a specific use case. Additionally or alternatively, the information may indicate one or more functionalities supported by the target network entity, thereby implicitly indicating one or more capabilities of the UE that are of interest to the target network entity. The UE may be able to identify the one or more capabilities that are of interest to the target node based on the information.
  • the serving network entity may transmit, to the UE, based on the received information, information indicating the one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the target network entity.
  • the UE may receive, from the serving network entity the information indicating the one or more capabilities of the UE that relate to Al and /or ML, and that are of interest to the target network entity.
  • the serving network entity may simply forward the information received from the target network entity, for example without processing and taking any sort of action on them. Additionally or alternatively, it may process the information. For example, the serving network entity may group received information and/or decide to forward only some of the information to the UE, e.g., due to message size constraints. It some embodiments the serving network entity may signal the information implicitly to the UE while receiving explicit information from the target network entity (or the other way around).
  • the UE may process the received information.
  • the UE may determine, based on the received information, functionality that relates to Artificial Intelligence, Al, and/or Machine Learning, ML, and that is supported by the target network entity.
  • functionality that relates to Artificial Intelligence, Al, and/or Machine Learning, ML, and that is supported by the target network entity.
  • the UE may support A, B, and C.
  • the UE may determine, based on the received information, that the target network entity supports B, C, D.
  • the UE may thus determine that a subset of its supported functionalities, namely only B and C, are relevant when communicating with the target network entity.
  • the UE may respond to the received information.
  • the UE may respond by transmitting information about each of the capabilities that are of interest to the target network entity, indicating for each of the capabilities whether it supports the capability.
  • the UE may respond by transmitting information only about some of the capabilities that are of interest to the target network entity.
  • the UE may respond, indicating those capabilities that are of interest to the target network entity and that the UE supports.
  • the UE may transmit its response to the serving network entity, e.g., before releasing the connection with the serving network entity.
  • the serving network entity may inform the target network entity about the content of the response. This way, the target network entity may learn which functionalities the UE supports. This may reduce the amount of overhead information that needs to be exchanged between UE and target network entity during/after the mobility.
  • the UE may transmit its response to the target network entity, e.g., during or after the mobility.
  • the UE does not need to respond to the received information, in particular not to the serving cell.
  • the UE can share the capabilities of interest (e.g., as per a configuration received from the source/serving gNB in the received information).
  • the information transmitted from the target network entity and received by the serving network entity comprise an indication of one or more additional conditions of the network entity that relate to Al and/or ML functionality.
  • the serving network entity may forward the indication to the UE.
  • the UE may base the determining of the functionality that relates to Artificial Intelligence, Al, and/or Machine Learning, ML, and that is supported by the target network entity, on the indication.
  • additional condition may be understood as referring to any aspect that is assumed for the training of a model but, e.g., is not a part of UE capability for an Al /ML- enabled feature/feature group to which the additional condition is associated. It does not imply that additional conditions are necessarily specified. Additional conditions can be divided into two categories: NW-side additional conditions and UE-side additional conditions. For inference for UE-side models, to ensure consistency between training and inference regarding NW-side additional conditions (if identified), one or more of the following options can be taken as potential approaches (e.g., when feasible and/or necessary):
  • Model identification to achieve alignment on the NW-side additional condition between NW-side and UE-side; Model training at NW and transfer to UE, where the model has been trained under the additional condition;
  • Consistency assisted by monitoring by UE and/or NW, the performance of UE- side candidate models/functionalities to select a model/functionality
  • the UE capabilities may change over time, e.g., because a model is updated or removed as it was outdated. Such changes may occur during a mobility.
  • a serving network entity may transmit, to the UE, information indicating to the UE to switch to fallback mode in case a (e.g., any or a specific) change is configured to occur during the mobility in one or more capabilities of the UE that relate to Al and/or ML.
  • the UE may receive, from the serving network entity, the information.
  • the fallback mode in the context of Al/ML-enabled features within cellular networks may be a safety and/or reliability mechanism. It may allow the UE and/or the network to revert to predefined, non-Al/ML-driven procedures and/or protocols when Al/ML systems fail or encounter issues.
  • Reverting to fallback mode may ensure that the UE can successfully complete the mobility and/or synchronize and/or communicate with the target network entity, even though the target network entity may have outdated information about the UE’s capabilities (e.g., from a previous UE capability report received from the serving network entity).
  • the UE may perform a change in one or more capabilities of the UE that relate to Al and/or ML during mobility and transmit, to the target network entity, information indicating the performed change.
  • the information may be transmitted to the target network entity, for instance, during or after the mobility.
  • the UE may transmit the information, for example, without the information being (implicitly and/or explicitly) inquired by the target network entity.
  • the target network entity may receive the information. This way, the target network entity may be informed of any changes.
  • the UE performing the change may comprise adding a new capability that relates to Al and/or ML, and that concerns a UE-side model.
  • a UE-side (Al/ML) model may be understood as an Al/ML model whose inference is performed entirely at the UE.
  • a UE-side (Al/ML) model may be, e.g., different from a two-sided (Al/ML) model which may be understood as a paired Al/ML model over which joint inference is performed, where joint inference may comprise Al/ML inference whose inference is performed jointly across the UE and the network, e.g., the first part of inference is firstly performed by UE and then the remaining part is performed by a network entity, or vice versa.
  • the UE may use the UE-side model at least during the mobility (and potentially afterwards). This is noteworthy since the target network entity may not yet be informed about the new capability, as explained above. This may happen, e.g., once the mobility is completed.
  • the UE, the serving network entity and the target network entity may complete the mobility.
  • the UE may be synchronized to the target network entity and may have released the connection to the serving network entity.
  • the UE’s and/or the target network entity’s capabilities relating to Al and/or ML may change.
  • the target network entity (now being synchronized with the UE) may transmit, to the UE, an inquiry about one or more further capabilities of the UE that relate to Al and/or ML.
  • the UE may receive, from the target network entity, the inquiry.
  • the UE may transmit, to the target network entity, information about the one or more further capabilities and the target network entity may receive, from the UE, information about the one or more further capabilities.
  • a target network entity may be a target network entity of a L3 handover mobility.
  • any and all aspects described above may also hold for a target network entity and/or a candidate target network entity in other types of mobility, e.g., in a CHO and/or LTM.
  • One potential difference between a L3 handover mobility and a CHO and/or LTM may be that in a L3 handover mobility a decision regarding a handover to a target network entity is taken by a serving network entity, e.g., when the handover is configured.
  • a CHO and/or LTM mobility one or more candidate target network entities may be configured. Whether there eventually will be a mobility and/or to which of the candidate target network entities the mobility will take place may depend on one or more conditions. In such a situation, one or more candidate target network entities (one of which will be selected as the target network entity) may be involved in the procedures described above and the procedures may be adapted to handling multiple candidate target network entities.
  • a serving network entity may transmit, to one or more candidate target network entities for mobility of a UE, an inquiry about one or more capabilities of the UE that relate to Artificial Intelligence, Al, and/or Machine Learning, ML, and that are of interest to the respective candidate target network entity.
  • the serving network entity may receive, from the one or more candidate target network entities, information indicating one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the respective candidate target network entity. Further, the serving network entity may transmit, to the UE, based on the received information, information indicating the one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the respective candidate target network entity.
  • the UE may receive, from a serving network entity for the mobility of the UE, the information indicating the one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to a respective candidate target network entity of one or more candidate target network entities for the mobility of the UE. Moreover, the UE may determine, based on the received information, functionality that relates to Al and/or ML, and that is supported by a target network entity selected from the one or more candidate target network entities. The UE may be able to distinguish which capabilities are of interest to which candidate target network entity.
  • the UE may determine the functionality that relates to Al and/or ML and that is supported by the (selected candidate) target network entity.
  • the UE may (e.g., only) transmit information regarding the one or more capabilities which are of interest to the (selected candidate) target network entity to the target network entity (e.g., during or after mobility) or to the serving network entity so that the serving network entity forwards the information to the target network entity.
  • the UE may transmit information regarding one or more capabilities which are of interest to a respective candidate target network entity to one or more of the candidate target network entities or to the serving network entity for forwarding to the respective candidate target network entities.
  • the serving network entity may receive, from the UE, the information indicating one or more capabilities of the UE that relate to Al and/or ML, and, based on the information received from the UE, transmit, to the one or more candidate target network entities, a report of the one or more capabilities of the UE that relate to Al and/or ML.
  • This may be a single report which is transmitted to only one of the candidate target network entities, namely the one which has been selected as the target network entity.
  • any or each of the candidate target network entities may perform the procedures described herein for a target network entity. It is to be understood that the presentation in this section is merely by way of examples and non-limiting. Each step described above may happen after or in response to another, e.g., the preceding step. However, a different order of steps is also possible.
  • Fig. 1 a schematic block diagram of a functional framework for AI/ML for a mobile communication air interface
  • Fig. 2 an example message exchange sequence for acquiring UE capabilities based on a network (NW) enquiry
  • Fig. 3 an example message sequence of a mobility of a UE from a source gNB to a target gNB;
  • Fig. 4 a flowchart showing an example embodiment of a method, e.g., performed by a serving network entity for layer 3 handover mobility of a UE;
  • Fig. 5 a flowchart showing an example embodiment of a method, e.g., performed by a target network entity for layer 3 handover mobility of a UE;
  • Fig. 6 a flowchart showing an example embodiment of a method, e.g., performed by a UE;
  • Fig. 7 an example message sequence according to an embodiment
  • Fig. 8 a flowchart showing an example embodiment of a method, e.g., performed by a serving network entity for CHO/LTM mobility of a UE;
  • Fig. 9 a flowchart showing an example embodiment of a method, e.g., performed by a target network entity for CHO/LTM mobility of a UE;
  • Fig. 10 a flowchart showing an example embodiment of a method, e.g., performed by a UE;
  • Fig. 11 an example message sequence according to an embodiment
  • Fig. 12 an example message sequence of a LTM for which embodiments can be used
  • Fig. 13 a schematic block diagram of an example of a RAN architecture
  • Fig. 14 a schematic block diagram of an apparatus according to an embodiment.
  • Fig. 1 shows a schematic block diagram of a functional framework 100 for Al/ML for a mobile communication air interface.
  • Al /ML in mobile communication networks may involve using Al /ML-enabled features, e.g., features where Al/ML may be used.
  • at least one Al/ML model may be used, e.g., a data driven algorithm that applies Al/ML techniques to generate a set of outputs based on a set of inputs.
  • a process of using a trained Al/ML model to produce a set of outputs based on a set of inputs may be referred to as Al/ML model inference.
  • the framework 100 in Fig. 1 is a general functional architecture. By way of example, it addresses functionality-based LCM, as described before, and additionally other LCM approaches, e.g., model-lD-based LCM.
  • Fig. 1 some of the functions or data/information/instruction flows (i.e., the arrows) shown in Fig. 1 might not always be relevant for a given LCM approach.
  • the network performs functionality-based LCM and where models are not identified in the network, while the UE concurrently performs model-level management (e.g., model selection/switching/(de)activation, etc.).
  • model-level management e.g., model selection/switching/(de)activation, etc.
  • the "Model Training" 103 or "Model Storage” 108 functions with their respective procedures may be regarded as irrelevant, at least from the network’s perspective.
  • the framework comprises a data collection function 101.
  • the data collection function 101 may be a process of collecting data by the network nodes, management entity, and/or UE for the purpose of Al/ML model training, data analytics and/or inference.
  • the data collection may provide input data to the model training 103, management 106, and/or inference functions 110.
  • Model training 103 may be a function that performs Al/ML model training, validation, and/or testing. It may comprise a process to train an Al/ML Model (e.g., by learning the input/ output relationship) in a data driven manner and obtain the trained Al /ML Model for inference.
  • the training may involve generating model performance metrics. These can potentially be used as part of the model testing procedure.
  • To evaluate the performance of a final Al/ML model a dataset different from one the used for model training and/or validation may be used. Testing does not necessarily assume subsequent tuning of the model.
  • Al/ML model validation may comprise subsequent tuning of the model.
  • the model training function 103 may also involve data preparation (e.g., data preprocessing, cleaning, formatting, and/or transformation) based on the training data 102 delivered by a data collection function 102.
  • the output of the model training function 103 may be a trained and/or updated model 104.
  • the model training function 103 may deliver the trained, validated, and/or tested Al/ML models 104 to the model storage function 108, and/or may deliver an updated version of a model to the model storage function 108.
  • the data collection function 101 may provide monitoring data 105 to the management function 106, e.g., data needed as input for the management 106 of Al/ML models or Al/ML functionalities.
  • Management 106 may be a function that oversees the operation (e.g., selection, (de) activation, switching, and/or fallback) and/or monitoring (e.g., performance) of Al/ML models and/or Al/ML functionalities. This function may be responsible for making decisions to ensure the proper inference operation, e.g., based on data received from the data collection function 101 (e.g., monitoring data 105) and the inference function 110 (e.g., inference output 111).
  • the data collection function 101 e.g., monitoring data 105
  • the inference function 110 e.g., inference output 111).
  • Fig. 1 further shows management instructions 112. These may comprise information needed as input to manage the inference function 110. This may involve information indicating selection, (de) activation, switching of Al/ML models and/or Al/ML-based functionalities, and/or fallback to non-Al/ML operation (e.g., not relying on inference process), etc.
  • Inference 110 may comprise a function that provides outputs from the process of applying one or more Al/ML models and/or Al/ML functionalities, e.g., using the data that is provided by the data collection function 101 (e.g., inference data 109) as an input.
  • the inference function 110 may also be responsible for data preparation (e.g., data pre- processing, cleaning, formatting, and/or transformation), for instance based on inference data 109 delivered by a data collection function 101.
  • the inference output 111 may comprise data used by the management function to monitor the performance of Al/ML models and/or Al/ML functionalities.
  • management function 106 may provide performance feedback and/or retraining requests 114. This may be, for example, information needed as input for the model training function 103, e.g., for model (re)training and/or updating purposes.
  • management function 106 may issue model transfer and/or delivery requests 107, e.g., to request one or more models to the model storage function 108.
  • Model storage 108 may be a function responsible for storing trained and/or updated models that can, e.g., be used to perform the inference function 110. It should be stressed that the model storage 108 is functional and does not encompass restricting the actual storage locations of models.
  • Al/ML model delivery may be understood as a generic term referring to delivery of an Al/ML model from one entity to another entity in any manner.
  • An entity could mean a network node/function (e.g., gNB, LMF, etc.), UE, proprietary server, etc.
  • Such a delivery may include a delivery of an Al/ML model over the air interface, for instance in a manner that is not transparent to 3GPP signaling.
  • parameters of a model structure known at the receiving end or a new model with parameters may be delivered.
  • the delivery may contain a full model or a partial model.
  • Use cases for the above-described framework may include one or more of: CSI feedback enhancement, e.g., for overhead reduction, improved accuracy, and/or prediction;
  • Beam management e.g., beam prediction in time, and/or spatial domain, e.g., for overhead and/or latency reduction, and/or beam selection accuracy improvement;
  • Positioning accuracy enhancements for different scenarios including, e.g., those with NLOS conditions.
  • the UE capability signaling framework is provisioned to be a main enabler of the Al/ML-based solutions over the air interface. This is reflected in the Technical Report (TR 38.843, V18.0.0 (2023-12)), in which it states the following in Section 4.2.1:
  • - UE indicates supported functionalities/functionality for a given sub-use-case.
  • functionality refers to an AI/ML-enabled Feature/FG enabled by configuration(s), where configuration(s) is(are) supported based on conditions indicated by UE capability.
  • functionality-based LCM operates based on, at least, one configuration of AI/ML-enabled Feature/FG or specific configurations of an AI/ML-enabled Feature/FG.
  • FIG. 2 shows an example message exchange sequence 200 for acquiring UE capabilities based on a network (NW) enquiry.
  • NW network
  • the message exchange sequence occurs between a UE 201 and the network 202.
  • the network 202 may transmit a UECapabilityEnquiry 203.
  • the UE 201 may compile its UE capability information upon receiving a UECapabilityEnquiry 203 from the network 202 and transmit UECapabilitylnformation 204 to the network 202.
  • the procedure could be a static UE capability enquiry procedure, e.g., it is done once when the UE 201 gets 1MS1 attached to the network 202 as the procedure is a heavy on air interface capacity. It may allow the network to query UE per-RAT capabilities. Furthermore, the request can include a filter to shape the size of the capability container. The filtering may allow to cut down the number of band, band combinations, component carrier specific properties. However, as the mechanism is static, other mechanisms may be needed for considering changes.
  • UE 201 and network 202 may perform a RRC reconfiguration 205 (e.g., potentially including multiple messages) and UE 201 may provide UEAssistancelnformation 206 to the network 202 to inform the network of one or more conditions and/or parameters.
  • This may be a semi-static procedure. It may allow the network 202 to configure the UE 201 to report temporary changes to the static capabilities. Temporary changes could be due to overheating, MUS1M operation, dual connectivity restrictions, and/or power limitations etc.
  • the procedure could also allow the UE 201 to indicate the need for gaps, e.g., in RRC reconfiguration complete.
  • Fig. 2 may not be ideal in some cases, e.g., in cases of mobility of UE 201, for example, L3 handover, CHO, or LTM.
  • Fig. 3 shows an example message sequence 300 of a mobility of a UE 301 from a source gNB 302 (an example of a network entity) to a target gNB 303 (another example of a network entity).
  • the mobility may be an inter-gNB handover procedure in RRC_CONNECTED state.
  • the source gNB 302 may initiate the handover and issue a HANDOVER REQUEST 304, e.g., over the Xn interface.
  • the target gNB 303 may perform admission control 305 and provide the new RRC configuration as part of the HANDOVER REQUEST ACKNOWLEDGE 306.
  • the source gNB 302 may provide the RRC configuration to the UE by forwarding the RRCReconfiguration message 307 received in the HANDOVER REQUEST ACKNOWLEDGE 306.
  • the RRCReconfiguration message may include at least cell ID and all information required to access the target cell so thatthe UE 301 can access the target cell without reading system information. For some cases, the information required for contention-based and contention-free random access can be included in the RRCReconfiguration message.
  • the access information to the target cell may include beam specific information, if any.
  • the UE 301 may move the RRC connection to the target gNB (i.e., switch to new cell 308) and reply with the RRCReconfigurationComplete 309.
  • UE 201 would first perform this with the source network entity 302. Then the UE 301 would potentially need to repeat some or all of the procedure shown in Fig. 2 with the target network entity 303 to which it wants to connect in the mobility or has already connected during the mobility to inform it of its capabilities. This may entail significant overhead, especially given the number of conditions that may need to be signaled. Some example conditions are shown in Tables 1-4 below. It is to be understood that there may be fewer or more conditions than those shown. Table 1: Conditions for general ML-enabled use cases/features.
  • the number of conditions and their potential content/values are extensive, and they are expected to only grow, when new Al/ML use cases and functionalities are introduced, which will make it even more laborious to signal them through the UE capability message (in the RRC configuration) and the corresponding synchronization from the network side to process.
  • the concept of dynamic UE capability may be of major importance, that is, if the UE capability, at least, changes in a semi-static manner, in other words, it may be that the UE capability is no longer static (with reference to the legacy), and could change after some time.
  • the UE may report a subset of its capabilities to a gNB, when it connects to a cell associated with that gNB. However, the UE may (want to) report a different set of capabilities to the target gNB during mobility. This may originate from different factors. Unlike in the legacy radio access framework, the addition of Al/ML capabilities brings intrinsic dynamicity to the radio scenarios. For instance, to support new functionalities, new ML models may be added, tuned, and/or changed, implying changes to the existing set of capabilities that the UE currently supports. Additionally or alternatively, based on the supported Al /ML functionalities of a gNB, the UE may not need to report a certain set of capabilities. Alternatively, the UE might realize that the models it has available have drifted and are no longer suitable. Therefore, addressing such semi-static behaviors (in particular regarding the UE’s Al/ML capabilities) is a crucial problem to be addressed.
  • having a dynamic UE capability framework may add an extra layer of processing complexity load onto the NW side, which is generally not desirable. While it may be unavoidable in some scenarios, e.g., to achieve other advantages, in other scenarios a semi-static approach would be an option.
  • NW Differentiation between NW types is also considered.
  • some network entities may not respond to Al/ML-enabled features on a UE, which can be due to several factors.
  • the NW is an Al/ML-enabled module and cannot process such signaling requests from the UE specifically for two-sided Al/ML features, or the NW is heavily congested at that point in time, and does not have enough resources to dedicate to Al/ML-enabled cases, or the NW knows that the incoming Al/ML-enabled UE has to be soon handed off to another NW entity and simply does not want to exchange the advance AI/ML capabilities with the incomings UEs.
  • embodiments are described in the following to provide a better UE capability signaling framework during mobility events and semi-static UE capability behavior, in terms of signaling and coordination overhead for the NWs on the UE capability exchange, and/or seamless handover executions, where Al/ML features over the air inter-face are enabled.
  • Fig. 4 is a flowchart showing an example embodiment of a method 400, e.g., performed by a serving network entity for layer 3 handover mobility of a UE.
  • the method comprises one or more of the following actions 401 to 403.
  • 401 Transmitting, to a target network entity for layer 3 handover mobility of a UE, an inquiry about one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the target network entity.
  • the inquiry may be transmitted as part of a handover request (e.g., in a same message) or as a separate message.
  • a report of one or more capabilities of the UE that relate to Al and/or ML may be transmitted to the target network entity.
  • the report may be transmitted in addition to the inquiry, e.g., in a separate message. Alternatively, the report may be transmitted in a same message as the inquiry.
  • the target network entity receives, from the target network entity, information indicating one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to the target network entity.
  • the information may be included in an RRC message.
  • the information may, for example, be included in a handover request acknowledge message or be a separate message from it.
  • the information may indicate that there are no capabilities of the UE that relate to Al and/or ML, and that are of interest to the target network entity, e.g., because the target network entity has received all relevant information through a previous report.
  • the information may be transmitted in a RRC message.
  • the target network entity also transmits additional conditions in response to the inquiry. These can be forwarded to the UE as well.
  • additional conditions may refer to any aspects that are assumed for the training of the model but are not a part of UE capability for the Al/ML-enabled feature/FG. It does not imply that additional conditions are necessarily specified.
  • Fig. 5 is a flowchart showing an example embodiment of a method 500, e.g., performed by a target network entity for layer 3 handover mobility of a UE.
  • the target network entity may be the one referred to in the context of Fig. 4.
  • the method 500 may include one or more of the following actions:
  • Fig. 6 a flowchart showing an example embodiment of a method 600, e.g., performed by a UE.
  • the UE may be the one referred to in the context of Figs. 4 and 5.
  • the method 600 may include one or more of the following actions:
  • 601 Receiving, from a serving network entity for layer 3 handover mobility of the UE, information indicating one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to a target network entity for the layer 3 handover mobility of the UE.
  • the explanations given with regard to action 403 apply here.
  • determining functionality that relates to Al and/or ML, and that is supported by the target network entity Based on the received information, determining functionality that relates to Al and/or ML, and that is supported by the target network entity. Additional conditions indicated by the target network entity may be taken into account as well.
  • Fig. 7 an example message sequence 700 according to an embodiment. It shows how a UE 790, a serving gNB 791 (as a non-limiting example of a serving network entity) and a target gNB 792 (as a non-limiting example of a target network entity) exchange messages.
  • the UE 790 performs the method 600
  • the serving gNB 791 performs the method 400
  • the target gNB 792 performs the method 500.
  • a layer 3 handover mobility is considered in Fig. 7.
  • the embodiment can be employed in other types of mobility.
  • Serving gNB 791 inquires the UE capability to be reported from the UE 790, e.g., using an (A1ML) UE capability inquiry. This may be a full or a subset of the capability report. This inquiry may be a UECapabilityEnquiry 203, as described regarding Fig. 2.
  • UE 790 responds to the inquired set of capabilities. For example, UE sends information indicating one or more (A1ML) UE capabilities. The information may be UECapabilitylnformation 204, as described regarding Fig. 2.
  • the UE 790 may start one or more measurements (e.g., L3 RSRP values). Optionally, the UE 790 may report information to the serving gNB 791 indicating one or more measurement results.
  • measurements e.g., L3 RSRP values.
  • the UE 790 may report information to the serving gNB 791 indicating one or more measurement results.
  • Serving gNB 791 decides to handover the UE 790 to the target gNB 792. The decision may be based on information received from the UE 790 that indicated one or more measurement results. For example, the indicated measurement results could be indicative of a weak signal reception from the serving gNB 791.
  • HO request is made to the target gNB 792.
  • the serving gNB 791 may transmit a UE capability report to the target gNB 792.
  • the UE capability report may include some or all information received previously by the serving gNB 791, e.g., in 702. If the serving gNB 791 has already received the full UE capability report (e.g., in 702), it can redirect it to the target gNB 792.
  • the serving gNB 791 may notify the target gNB 792 about it.
  • the serving gNB 791 may inform the target gNB 792 that it only has a partial UE capability report, e.g., using a flag (which may be designated for this purpose).
  • the target gNB 792 may be informed about the fact that the report is a partial UE capability report as part of at least one of the actions 706, 707 or in a separate action.
  • Serving gNB 791 may inquire the target gNB 792 about its intended UE capability requests. This is an example of actions 401, 501 described previously.
  • Target gNB 792 shares its intended UE capability report elements (e.g., the UE capabilities of interest) to the serving gNB 791. This is an example of actions 402, 502 described previously.
  • the information shared by the target gNB 792 may include one or more of target gNB’s 792 additional conditions.
  • Serving gNB 791 transmits information concerning the UE capabilities of interest to the target network node 792 to the UE 790. For example, serving gNB 791 forwards the target gNB’s 792 intended list to the UE 790. Further, the serving gNB 791 may transmit additional conditions of the target gNB 792 to the UE.
  • the UE 790 may respond to the received information 710 and provide requested information. For example, in various embodiments it may need to share the information requested with the list with the target gNB (e.g., by transmitting the information to the target gNB 792 or by transmitting the information to the serving gNB 791 which may forward the information to the target gNB 792).
  • the serving gNB 791 might also command the UE 790 to fallback in case the UE 790 wants to re-configure (e.g., make one or more changes in its capability) during the HO phase.
  • re-configure e.g., make one or more changes in its capability
  • UE 790 switches to fallback mode and then performs HO.
  • UE 790 may use the new capabilities anyway (e.g., for aspects concerning UE-side model). Further, it may report them after finishing the procedure with the new gNB 792. If there is radio link failure, this should be reported to the NW once the UE 790 reconnects.
  • 710 is an example of 403, 601 described before.
  • the UE 790 based on the received information from the serving gNB 791 on the target gNB’s 792 additional conditions and/or its UE capabilities of interest, determines one or more Al/ML functionalities that would be supported on the target gNB 792.
  • the NW-sided additional conditions could include associated ID, consistency between the training and/or the inference phases.
  • 711 is an example of 602 described earlier.
  • the target gNB 792 may inquire one or more additional sets of capability from the UE 790.
  • the UE 790 may respond to the inquiry. For example, UE 790 may send the difference (delta) in its capability report, e.g., the difference to what was reported in 702 and/or in response to 710.
  • gNB e.g., serving gNB 791 and/or target gNB 792
  • gNB configure the measurements and reporting parameters to UE 790 to perform inference operations. Therefore, UE 790 may not need to provide parameters and/or configuration related to training and/or monitoring.
  • the process described above may contribute to optimizing the overhead of UE capabilities signaling. Further, it may allow target gNB to identify whether more information on UE capability is needed or not and UE is already prepared (e.g., Inference operation) when it is attached to the target cell/gNB.
  • a layer 3 handover mobility was considered in Fig. 7.
  • embodiments will be considered that primarily concern other types of mobility, e.g., CHO and/or LTM.
  • Fig. 8 is a flowchart showing an example embodiment of a method 800, e.g., performed by a serving network entity for CHO/LTM mobility of a UE.
  • the method comprises one or more of the following actions 801 to 803. For each of the actions 801, 802, 803, the explanations made with respect to 401, 402, and 403 apply, respectively.
  • Fig. 9 is a flowchart showing an example embodiment of a method 900, e.g., performed by a candidate target network entity, e.g., for CHO/LTM mobility of a UE.
  • the candidate target network entity may be the one referred to in the context of Fig. 8.
  • the method 900 may include one or more of the following actions 901, 902. The explanations given with respect to 501, 502 apply, respectively.
  • Fig. 10 is a flowchart showing an example embodiment of a method, e.g., performed by a UE.
  • the UE may be the one referred to in the context of Figs. 8 and 9.
  • the method 1000 may include one or more of the following actions 1001, 1002. The explanations given with respect to 601, 602 apply, respectively.
  • 1001 Receiving, from a serving network entity for mobility of the UE, information indicating one or more capabilities of the UE that relate to Al and/or ML, and that are of interest to a respective candidate target network entity of one or more candidate target network entities for the mobility of the UE.
  • 1002 Based on the received information, determining functionality that relates to Al and/or ML, and that is supported by a target network entity selected from the one or more candidate target network entities.
  • Fig. 11 shows an example message sequence 1100 according to an embodiment.
  • the UE 1190 performs the method 1000, the serving gNB 1191 performs the method 800, and the target gNB 1192 and potentially one or more of the other candidate target gNBs 1193 perform the method 900.
  • Fig. 11 shows an exemplary implementation for the signaling diagram of conditional handover (CHO) mobility of a UE 1190 from a serving gNB 1191 (as a nonlimiting example of a serving network entity) to a target gNB 1192 (as a non-limiting example of a target network entity).
  • a serving gNB 1191 as a nonlimiting example of a serving network entity
  • a target gNB 1192 as a non-limiting example of a target network entity.
  • target gNB 1192 an exemplary implementation for the signaling diagram of conditional handover (CHO) mobility of a UE 1190 from a serving gNB 1191 (as a nonlimiting example of a serving network entity) to a target gNB 1192 (as a non-limiting example of a target network entity).
  • candidate target gNBs 1192, 1193 one of which is the target gNB 1192.
  • the example message sequence 1100 will be described using terminology from the CHO, it is to be
  • the message sequence 1100 shows the following actions: 1101: Serving gNB 1191 inquires a full or a subset of capability to be reported from the UE 1190, e.g., using an (A1ML) UE capability inquiry. This inquiry may be a UECapabilityEnquiry 203, as described regarding Fig. 2.
  • UE 1190 responds to the inquired set of capabilities. For example, UE sends information indicating one or more (A1ML) UE capabilities. The information may be UECapabilitylnformation 204, as described regarding Fig. 2.
  • the UE 1190 may start one or more measurements (e.g., L3 RSRP values). Optionally, the UE 1190 may report information to the serving gNB 1191 indicating one or more measurement results.
  • measurements e.g., L3 RSRP values.
  • the UE 1190 may report information to the serving gNB 1191 indicating one or more measurement results.
  • Serving gNB 1191 decides to establish the conditional handover. The decision may be based on information received from the UE 1190 that indicated one or more measurement results. For example, the indicated measurement results could be indicative of a weak signal reception from the serving gNB 1191.
  • Serving gNB 1191 makes the CHO request to a candidate target gNB 1192 (which will be the selected candidate, i.e., the target gNB 1192).
  • Serving gNB 1191 makes the CHO request to other candidate target gNBs 1193.
  • Actions 1106 and 1107 may be similar to action 706 described previously so that the corresponding explanations about 706 also apply here.
  • the serving gNB 1191 may transmit a UE capability report to the target gNB 1192.
  • serving gNB 1191 tells the target gNB 1192 that it only has a partial UE capability report.
  • the serving gNB 1191 may transmit a UE capability report to one or more of the candidate target gNBs 1193.
  • serving gNB 1191 tells these other (candidate) target gNBs 1193 that it only has a partial UE capability report.
  • Actions 1108 and 1109 may be similar to action 707 described previously so that the corresponding explanations about 707 also apply here.
  • Serving gNB 1191 may inquire the target gNB 1192 about its intended UE capability requests, and optionally also its NW-sided additional conditions.
  • Actions 1110 and 1111 may be like action 708 described previously so that the corresponding explanations about 708 also apply here.
  • Target gNB 1192 shares its intended UE capability report elements to the serving gNB 1191, optionally along with its NW-sided additional conditions.
  • Some or all other candidate target gNBs 1193 share their intended UE capability report elements to the serving gNB 1192, optionally along with NW-sided additional conditions.
  • Actions 1112 and 1113 may be like action 709 described previously so that the corresponding explanations about 709 also apply here.
  • Serving gNB 1191 forwards the collection of candidate target gNBs’ 1192, 1193 intended list that the candidate target gNBs 1192, 1193 support, are interested in, and/or that UE 1190, in some (but not all) embodiments, has to share with the target gNB 1192 (and/or the other candidate target gNBs 1193), and potentially the NW-sided additional conditions that the UE 1190 may have to consider.
  • UE 1190 evaluates the CHO (e.g., one or more conditions for the CHO). Based on the required UE capabilities of the candidate target gNBs 1192, 1193 and/or their NW- sided additional conditions, UE may determine which respective one or more Al/ML functionalities are supported on which gNBs 1192, 1193.
  • the CHO e.g., one or more conditions for the CHO.
  • UE 1190 detaches from the serving gNB 1190, CHO is completed and the target cell corresponding to the target gNB 1192 is selected.
  • the UE 1190 responds to the inquiry.
  • reconfiguration happens based on the new UE capabilities.
  • the number of candidates gNBs to be monitored and share information may be increased as compared to the L3HO case.
  • the increased signaling overhead between the serving and potential target gNBs can advantageously be tackled by implementation aspects of the network architecture.
  • Fig. 12 shows an example message sequence 1200 of a LTM for which embodiments can be used.
  • An example procedure for LTM may be as follows:
  • RRC_CONNECTED is established for UE 1290 with the gNB 1291.
  • the UE 1290 sends a MeasurementReport message to the gNB 1291.
  • the gNB 1291 decides to configure LTM and initiates LTM preparation.
  • the gNB 1291 transmits an RRCReconfiguration message to the UE 1290 including the LTM candidate configurations.
  • the UE 1290 stores the LTM candidate configurations transmits an RRCReconfigurationComplete message to the gNB 1291.
  • the UE 1290 may activate and deactivate TCI states of LTM candidate cell(s), as triggered by the gNB 1291.
  • 1207 The UE 1290 may perform UL synchronization with LTM candidate cell(s) before receiving the cell switch command, by using UE-based TA measurement, if configured, and/or by transmitting a preamble towards the candidate cell, as triggered by the gNB 1291.
  • the gNB 1291 decides to execute cell switch to a target cell.
  • the UE 1290 switches to the target cell and applies the candidate configuration indicated by the target configuration ID.
  • UE 1290 switches to the target cell (associated with a target network entity, e.g., a DU of the gNB 1291), an RRC connection had been established between UE 1290 and a (serving) network entity, e.g., another DU of the gNB 1291, e.g., like in step 1103 of message sequence 1100. Further, it is possible that the UE 1290 had already reported information indicating one or more of its (A1ML) UE capabilities, e.g., using the inquiry-response mechanism described in 1101, 1102 to the (serving) network entity.
  • A1ML inquiry-response mechanism described in 1101, 1102
  • the serving network entity may have exchanged information with one or more target network entities, as described in one or more of steps 1108 to 1113, and informed the UE 1290, in preparation of the LTM.
  • UE 1290 may have been informed of UE capabilities of interest to the one or more target network entities and potential additional conditions, and may have been able or is able to determine the AI/ML functionality supported by one or more of the candidate target network entities (and potentially their additional conditions).
  • the UE completes the LTM cell switch procedure by sending RRCReconfigurationComplete message to target cell. If the UE has performed a RA procedure in step 1212 the UE considers that LTM cell switch execution is successfully completed when the random access procedure is successfully completed. For RACH- less LTM, the UE considers that LTM cell switch execution is successfully completed when the UE determines that the network has successfully received its first UL data.
  • the procedure over the air interface may be applicable, e.g., to intra-gNB-DU LTM and/or inter-gNB- DU LTM.
  • a signaling framework is provided which may prove particularly useful for the case of semi-statically or dynamically changing UE A1ML capability report, that is, in particular when the UE capability may differ from the serving cell/gNB to the target one, which may be initiated due to the cases described earlier.
  • Conveying such information to the target gNB may contribute to enabling a seamless handover execution and reducing the amount of synchronization messages, as these would alternatively need to be exchanged after the UE is handed over. For instance, if in an environment/setup (e.g., FR2), a UE is expected to experience several Hos/mobilities, it would be beneficial to conduct synchronization before the HO/mobility occurrence to utilize the resources on the data payload instead of synchronization signals between the target gNB and the UE.
  • an environment/setup e.g., FR2
  • a UE is expected to experience several Hos/mobilities, it would be beneficial to conduct synchronization before the HO/mobility occurrence to utilize the resources on the data payload instead of synchronization signals between the target gNB and the UE.
  • the proposed solution makes use of a beneficial coordination between the serving gNB and the target gNB/candidate target gNBs (in case of the conditional handover or LTM) to convey UE capability message and/or information about the UE capability elements that the target gNB(s) would require beforehand to execute a fast and seamless handover execution.
  • Fig. 13 is an example of a RAN architecture 1300 according to an embodiment. While this example is described using terminology from the 5G standardization, it is to be understood that these are merely examples of more general architectural aspects, describing for example which entities may be comprised in a gNB.
  • NG-RAN 1302 comprises a set of gNBs 1303, 1304 connected to the 5GC 1301 through the NG interface.
  • NG-RAN could also comprise a set of ng-eNBs, where an ng-eNB may comprise an ng-eNB-CU and one or more ng-eNB-DU(s).
  • An gNB 1303, 1304 can support FDD mode, TDD mode and/or dual mode operation. gNBs 1303, 1304 can be interconnected through the Xn interface.
  • a gNB 1304 may comprise and/or consist of a gNB-CU 1305 and one or more gNB-DU(s) 1306, 1307.
  • a gNB-CU 1305 and a gNB-DU 1306, 1307 may be connected via Fl interface.
  • one gNB-DU 1306, 1307 is connected to only one gNB-CU 1305.
  • a gNB-DU 1306, 1307 may be connected to multiple gNB-CUs 1305 by appropriate implementation.
  • a gNB Central Unit comprises e.g. a logical node hosting e.g. RRC, SDAP and PDCP protocols of the gNB or RRC and PDCP protocols of the en-gNB that controls the operation of one or more gNB-DUs.
  • the gNB-CU terminates the Fl interface connected with the gNB-DU.
  • the gNB-CU and gNB-DU parts may e.g. be co-located or physically separated. gNB DU may even be split further, e.g. into two parts, e.g. one including processing equipment and one including an antenna.
  • a Central Unit (CU) may also be called BBU/REC/RCC/C- RAN/V-RAN, O-RAN, or part thereof.
  • a Distributed Unit (DU) may also be called RRH /RRU /RE /RU, or part thereof.
  • gNB-DU may support one or multiple cells, and could thus serve as e.g. a serving cell or serving network entity for UE. Similarly, a gNB-DU can serve as a target cell or target network entity.
  • a UE may include a wireless or mobile device, an apparatus with a radio interface to interact with a RAN (Radio Access Network), a smartphone, an in-vehicle apparatus, an loT device, a M2M device, or else.
  • a RAN Radio Access Network
  • Such UE or apparatus may comprise: at least one processor; and at least one memory including computer program code; wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to perform certain operations, like e.g. RRC connection to the RAN.
  • a UE is e.g. configured to generate a message (e.g. including a cell ID) to be transmitted via radio towards a RAN (e.g. to reach and communicate with a serving cell).
  • a UE may generate and transmit and receive RRC messages containing one or more RRC PDUs (Packet Data Units).
  • RRC PDUs Packet Data Units
  • Fig. 14 shows a schematic block diagram of an example of an apparatus 1400, e.g., a UE or a network entity or a part thereof, according to an embodiment.
  • Apparatus or network entity 1400 comprises a processor 1401, program memory 1402, working or main memory 1403, data memory, communication interface(s) 1404, and an optional user interface 1405.
  • Processor 1401 may for instance control at least one of the memories 1402 to 1403, the communication interface(s) 1404, and/or the optional user interface 1405.
  • Processor 1401 may for instance execute program code stored in program memory 1402, which may for instance represent a readable storage medium comprising program code that, when executed by processor 1401, causes the processor 1401 to perform the method according to any example aspect.
  • Processor 1401 may be a processor of any suitable type.
  • Processor 1401 may comprise but is not limited to one or more microprocessor(s), one or more processor(s) with accompanying one or more digital signal processor(s), one or more processor(s) without accompanying digital signal processor(s), one or more special-purpose computer chips, one or more field- programmable gate array(s) (FPGA(s)), one or more controller(s), one or more application-specific integrated circuit(s) (ASlC(s)), or one or more computer(s)/server(s).
  • FPGA field- programmable gate array
  • ASlC application-specific integrated circuit
  • Processor 1401 may for instance be an application processor that runs an operating system.
  • Program memory 1402 may also be included into processor 1401. This memory may for instance be fixedly connected to processor 1401, or be at least partially removable from processor 1401, for instance in the form of a memory card or stick. Program memory 1402 may for instance be non-volatile memory. It may for instance be a FLASH memory (or a part thereof), any of a ROM, PROM, EPROM and EEPROM memory (or a part thereof) or a hard disc (or a part thereof), to name but a few examples. Program memory 1402 may comprise an operating system for processor 1401. Program memory 1402 may comprise a firmware for apparatus or network entity 1400.
  • Communication interface(s) 1404 enable the apparatus 1400 to communicate with other entities, e.g., one or more UE or one or more network nodes.
  • the communication interface(s) 1404 may for instance comprise a wireless interface, e.g., a cellular radio communication interface and/or a WLAN interface) and/or wire-bound interface, e.g., an IP-based interface, for instance to communicate with entities via the Internet.
  • Communication interface(s) may enable apparatus 1400 to communicate with other entities, for instance one or more entities as comprised in a mobile communication network.
  • User interface 1405 is optional and may comprise a display for displaying information to a user and/or an input device (e.g. a keyboard, keypad, touchpad, mouse, etc.) for receiving information from a user.
  • an input device e.g. a keyboard, keypad, touchpad, mouse, etc.
  • Some or all of the components of the apparatus 1400 may for instance be connected via a bus. Some or all of the components of the apparatus or network entity 1400 may for instance be combined into one or more modules.
  • An apparatus 1400 may further comprise at least one of the following: a receiver, e.g., for receiving information, e.g., from a network entity or a UE, and a transmitter, e.g., for transmitting information, e.g., to a network entity or UE.
  • a receiver e.g., for receiving information, e.g., from a network entity or a UE
  • a transmitter e.g., for transmitting information, e.g., to a network entity or UE.
  • any presented connection in the described embodiments is to be understood in a way that the involved components are operationally coupled.
  • the connections can be direct or indirect with any number or combination of intervening elements, and there may be merely a functional relationship between the components.
  • any of the methods, processes and actions described or illustrated herein may be implemented using executable instructions in a general-purpose or specialpurpose processor and stored on a computer-readable storage medium (e.g., disk, memory, or the like) to be executed by such a processor.
  • a computer-readable storage medium e.g., disk, memory, or the like
  • References to a ‘computer- readable storage medium’ should be understood to encompass specialized circuits such as FPGAs, ASICs, signal processing devices, and other devices.
  • a and/or B is considered to comprise any one of the following three scenarios: (i) A, (ii) B, (hi) A and B.
  • article “a” is not to be understood as “one”, i.e., use of the expression “an element” does not preclude that also further elements are present.
  • the term “comprising” is to be understood in an open sense, i.e., in a way that an object that “comprises an element A” may also comprise further elements in addition to element A. Further, the term “comprising” may be understood to also disclose “consisting of”, i.e., consisting of only the specified elements.
  • the statement of a feature comprises at least one of the subsequently enumerated features is not mandatory in the way that the feature comprises all subsequently enumerated features, or at least one feature of the plurality of the subsequently enumerated features. Also, a selection of the enumerated features in any combination or a selection of only one of the enumerated features is possible. The specific combination of all subsequently enumerated features may as well be considered. Also, a plurality of only one of the enumerated features may be possible.
  • the sequence of all method steps presented above is not mandatory, also alternative sequences may be possible. Nevertheless, the specific sequence of method steps exemplarily shown in the drawings shall be considered as one possible sequence of method steps for the respective embodiment described by the respective drawing.
  • LTM L1/L2 triggered mobility also referred to as low-layer triggered mobility

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Artificial Intelligence (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Evolutionary Computation (AREA)
  • Medical Informatics (AREA)
  • Software Systems (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Est divulgué, entre autres choses, un procédé mis en œuvre par une entité de réseau, le procédé comprenant : la transmission, à une entité de réseau cible pour la mobilité de transfert intercellulaire de couche 3 d'un équipement utilisateur (UE), d'une interrogation concernant une ou plusieurs capacités de l'UE qui se rapportent à l'intelligence artificielle (IA) et/ou à l'apprentissage automatique (ML) et qui sont d'intérêt pour l'entité de réseau cible ; la réception, en provenance de l'entité de réseau cible, d'informations indiquant une ou plusieurs capacités de l'UE qui se rapportent à l'IA et/ou au ML et qui sont d'intérêt pour l'entité de réseau cible ; la transmission, à l'UE, sur la base des informations reçues, d'informations indiquant une ou plusieurs capacités de l'UE qui se rapportent à l'IA et/ou au ML et qui sont d'intérêt pour l'entité de réseau cible. D'autres procédés, appareils, programmes informatiques et supports lisibles par ordinateur correspondants sont divulgués.
PCT/EP2025/064246 2024-07-30 2025-05-23 Signalisation de capacités d'ia/ml d'ue Pending WO2026027090A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FI20245936 2024-07-30
FI20245936 2024-07-30

Publications (1)

Publication Number Publication Date
WO2026027090A1 true WO2026027090A1 (fr) 2026-02-05

Family

ID=95933734

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2025/064246 Pending WO2026027090A1 (fr) 2024-07-30 2025-05-23 Signalisation de capacités d'ia/ml d'ue

Country Status (1)

Country Link
WO (1) WO2026027090A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022235525A1 (fr) * 2021-05-02 2022-11-10 Intel Corporation Collaboration améliorée entre un équipement utilisateur et un réseau pour faciliter un apprentissage machine
WO2024028183A1 (fr) * 2022-08-05 2024-02-08 Telefonaktiebolaget Lm Ericsson (Publ) Configuration de capacité d'apprentissage automatique dans un réseau d'accès radio
WO2024068141A1 (fr) * 2022-09-30 2024-04-04 Nokia Technologies Oy Échange de capacité ml et autorisation pour rrm
US20240244420A1 (en) * 2021-02-02 2024-07-18 Honor Device Co., Ltd. Ue capability reporting method and apparatus
WO2024207411A1 (fr) * 2023-04-07 2024-10-10 Qualcomm Incorporated Gestion de capacité dynamique de caractéristiques d'intelligence artificielle (ia)/d'apprentissage automatique, d'identifiants de modèle et/ou d'informations d'assistance

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20240244420A1 (en) * 2021-02-02 2024-07-18 Honor Device Co., Ltd. Ue capability reporting method and apparatus
WO2022235525A1 (fr) * 2021-05-02 2022-11-10 Intel Corporation Collaboration améliorée entre un équipement utilisateur et un réseau pour faciliter un apprentissage machine
WO2024028183A1 (fr) * 2022-08-05 2024-02-08 Telefonaktiebolaget Lm Ericsson (Publ) Configuration de capacité d'apprentissage automatique dans un réseau d'accès radio
WO2024068141A1 (fr) * 2022-09-30 2024-04-04 Nokia Technologies Oy Échange de capacité ml et autorisation pour rrm
WO2024207411A1 (fr) * 2023-04-07 2024-10-10 Qualcomm Incorporated Gestion de capacité dynamique de caractéristiques d'intelligence artificielle (ia)/d'apprentissage automatique, d'identifiants de modèle et/ou d'informations d'assistance

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
TECHNICAL REPORT (TR 38.843, V18.0.0, December 2023 (2023-12-01)

Similar Documents

Publication Publication Date Title
US12273776B2 (en) Master node, secondary node and user equipment in mobile communication network and communication methods therebetween
US20230014613A1 (en) Device and method for performing handover in wireless communication system
US10959235B2 (en) Performance indicator for interworking radio access technologies
US8934902B2 (en) Method of notifying switching information and base station
EP2704476A1 (fr) Procédé, système et dispositif permettant la transmission de paramètres de configuration de mesure de la minimisation des essais d'excitation
US20230108496A1 (en) Triggering a Subsequent Handover during a Dual-Active Protocol Stack Handover
US20240406820A1 (en) Source and target node coordination for measurement configuration in pscell change
JP2021520689A (ja) 分割基地局におけるｒｒｃバージョンの処理
KR20210144785A (ko) 무선 통신 네트워크에서의 조건부 이동성
WO2024099719A1 (fr) Mobilité de couche 1 ou 2 dans des systèmes de communication sans fil
EP4569892A1 (fr) Gestion de mobilité dans des réseaux prenant en charge une double connectivité
US20240406808A1 (en) Confirming ue-triggered mobility using low-layer information
RU2619064C2 (ru) Способ уведомления node в при многоточечной передаче
WO2026027092A1 (fr) Signalisation de capacités ia/ml d'ue
WO2026027090A1 (fr) Signalisation de capacités d'ia/ml d'ue
JP2026507618A (ja) Ｌ１ｌ２トリガ式モビリティのための測定構成
US20240306219A1 (en) Method and apparatus for improvements in and relating to telecommunication systems
JP2025528096A (ja) 下位層モビリティのためのｌ１ビーム測定の構成
CN119631309A (zh) 小区间波束管理
US12593253B2 (en) Indicating UE-triggered mobility using low-layer information
US20260052442A1 (en) Multiple conditional configurations for the same handover request
US12457489B2 (en) Handling incompatible wireless devices
GB2639947A (en) Support for anticipated resource management between slices
WO2025209149A1 (fr) Procédé de communication et appareil associé
GB2642068A (en) Inter-radio access technology network slice switching

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 25729057

Country of ref document: EP

Kind code of ref document: A1