Radio terminal, radio access network node, and methods for same

By associating wireless terminals with predefined UE capability sets based on device type and use case, the signaling overhead and implementation costs are reduced, ensuring efficient resource allocation in 6G systems.

WO2026034178A1PCT designated stage Publication Date: 2026-02-12NEC CORP
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
PCT/JP2025/025994
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2024-08-08
Filing Date
2025-07-22
Publication Date
2026-02-12

AI Technical Summary

Technical Problem

The challenge in future 6G specifications is defining signaling for various UE capability parameters related to different device types and use cases, which can lead to over-implementation and increased costs due to unnecessary support of more capabilities than necessary.

Method used

A wireless terminal informs a radio access network of a predefined UE capability set associated with its device type and intended use case, reducing the need to specify individual parameter values and minimizing signaling data.

Benefits of technology

This approach reduces signaling overhead and implementation costs by allowing UEs to support only necessary capabilities, avoiding excessive functionality and optimizing resource allocation.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure JP2025025994_12022026_PF_FP_ABST
    Figure JP2025025994_12022026_PF_FP_ABST
Patent Text Reader

Abstract

This radio terminal notifies a RAN of an identification of a first terminal capability set associated with one or both of an intended use case from a plurality of predefined use cases and a device type of the terminal from a plurality of predefined device types. The first terminal capability set is one of a plurality of predefined terminal capability sets. Each terminal capability set is predefined in association with one or both of at least one of a plurality of predefined use cases and at least one of a plurality of predefined device types. The terminal capability sets define respective values of the plurality of terminal capability parameters. This can provide, for example, signaling suitable for notifying a radio access network (RAN) of values of a plurality of terminal capability parameters pertaining to at least one of various device types, at least one of various use cases, or both, from the radio terminal.
Need to check novelty before this filing date? Find Prior Art

Description

Wireless terminal, radio access network node, and methods thereof

[0001] TECHNICAL FIELD The present disclosure relates to wireless communication systems, and more particularly to processing or transferring data relating to the capabilities, functions, or characteristics of wireless terminals.

[0002] Non-Patent Document 1 defines Evolved Universal Terrestrial Radio Access (E-UTRA) User Equipment (UE) Radio Access Capability Parameters. Only parameters for which the UE may signal different values ​​are considered as UE radio access capability parameters. Therefore, mandatory features that are common to all UEs and therefore do not have capability parameters are not included in the list of E-UTRA UE radio access capability parameters described in Non-Patent Document 1. Capabilities that are optional or conditionally mandatory for the UE to implement but do not have UE radio access capability parameters are also listed in Non-Patent Document 1. The UE informs the radio access network (i.e., eNB) of its UE radio access capability parameters using a Radio Resource Control (RRC) message, specifically the UE Capability Information message. The radio access network must respect the signaled UE radio access capability parameters during UE configuration and UE scheduling.

[0003] The UE category (ue-Category) is one of the E-UTRA radio access capability parameters defined in Non-Patent Document 1. The E-UTRA UE category defines the combined capabilities of uplink and downlink. The E-UTRA UE category indicates a combination of values ​​of downlink transport channel parameters, uplink transport channel parameters, downlink physical channel parameters, and uplink physical channel parameters.

[0004] Besides the UE category, the E-UTRA radio access capability parameters include various parameters such as Packet Data Convergence Protocol (PDCP) parameters, Radio Link Control (RLC) parameters, Medium Access Control (MAC) parameters, physical layer parameters, Radio Frequency (RF) parameters, measurement parameters, and Dual Connectivity parameters. In addition, the E-UTRA radio access capability parameters include parameters related to a specific UE type or use case, such as Licensed-Assisted Access (LAA) parameters, Coverage Enhancement (CE) parameters, and Narrow Band Internet of Things Non-Terrestrial Network (NB-IoT NTN) parameters.

[0005] Non-Patent Document 2 defines NR UE radio access capability parameters. Similar to the definition of E-UTRA UE radio access capability parameters in Non-Patent Document 1, only parameters for which the UE may signal different values ​​are considered as UE radio access capability parameters. Therefore, mandatory characteristics that are common to all UEs and therefore do not have capability parameters are not included in the list of NR UE radio access capability parameters described in Non-Patent Document 2. The UE informs the radio access network (i.e., gNB) of its UE radio access capability parameters using an RRC message, specifically the UE Capability Information message. The radio access network must respect the signaled UE radio access capability parameters during UE configuration and UE scheduling.

[0006] NR radio access capability parameters include various parameters such as general parameters, Service Data Adaptation Protocol (SDAP) parameters, PDCP parameters, RLC parameters, MAC parameters, and measurement parameters. General parameters include parameters indicating whether the UE supports various features (e.g., RRC inactive state, Signaling Radio Bearer 3 (SRB3), Mobile-terminated Small Data Transmission (MT-SDT)). In addition, NR radio access capability parameters include parameters related to specific UE device types or use cases, such as Reduced Capability (RedCap) UE parameters, Network Controlled Repeater (NCR) Mobile termination (NCR-MT) parameters, and Aerial UE parameters.

[0007] 3GPP TS 36.306 V18.1.0 (2024-03) "3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) radio access capabilities (Release 18)", March 2024 3GPP TS 38.306 V18.1.0 (2024-03) "3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NR; User Equipment (UE) radio access capabilities (Release 18)", March 2024

[0008] The 3rd Generation Partnership Project (3GPP®) fifth-generation mobile communication system (5G system) has introduced device types and use cases such as RedCap UE, two-antenna port (2Rx) eXtended Reality (XR) UE, Uncrewed Aerial Vehicle (UAV), and NTN. Support for additional device types and use cases (e.g., Ambient IoT) in the 5G system is currently under discussion. Future 6G systems are expected to support a wider variety of device types and use cases. In particular, low-end IoT devices will be supported from the first release of the 6G specifications to prepare for the replacement of older 4G Category M or NB-IoT devices or for their use by other types of devices. Additionally, 6G will require much higher peak values ​​for various UE capability parameters than 5G. These parameters include peak data rate, mobility performance (e.g., movement speed), latency, and reliability. However, these peak values ​​may not need to be achieved for all use cases and device types, and particular use cases or particular device types may only support more relaxed peak values.

[0009] It is unclear how future 6G specifications should define signaling for informing the radio access network of numerous UE capability parameter values ​​related to at least one of various device types, at least one of various use cases, or both. To reduce the amount of data in UE capability-related signaling, it would be useful to define common mandatory functions for all UEs or to define common default values ​​for some capability parameters. However, it is not easy to define common mandatory functions or default values ​​for many device types and use cases. Furthermore, defining common mandatory functions for different device types corresponding to various use cases could lead to over-implementation (e.g., support for more capabilities than necessary) for some device types. This may also increase the implementation costs of devices.

[0010] One of the objectives to be achieved by the embodiments disclosed in this specification is to provide an apparatus, a method, and a program that contribute to providing signaling suitable for a UE to notify a radio access network of values ​​of a plurality of UE capability parameters relating to at least one of various device types, at least one of various use cases, or both. It should be noted that this objective is only one of multiple objectives to be achieved by the multiple embodiments disclosed in this specification. Other objectives or problems and novel features will become apparent from the description of this specification or the accompanying drawings.

[0011] In a first aspect, a wireless terminal is configured to inform a radio access network of the identity of a first terminal capability set associated with one or both of an intended use case among a plurality of predefined use cases and its own device type among a plurality of predefined device types, the first terminal capability set being one of a plurality of predefined terminal capability sets, each terminal capability set being predefined in association with at least one of the plurality of predefined use cases and at least one of the plurality of predefined device types, each terminal capability set defining respective values ​​for a plurality of terminal capability parameters.

[0012] In a second aspect, a method performed by a wireless terminal includes signaling to a radio access network an identification of a first terminal capability set associated with one or both of an intended use case among a plurality of predefined use cases and the wireless terminal's own device type among a plurality of predefined device types, the first terminal capability set being one of a plurality of predefined terminal capability sets, each terminal capability set being predefined in association with at least one of the plurality of predefined use cases and at least one of the plurality of predefined device types, each terminal capability set defining respective values ​​for a plurality of terminal capability parameters.

[0013] In a third aspect, a radio access network node is configured to receive from a radio terminal an identification of a first terminal capability set associated with one or both of an intended use case from a plurality of predefined use cases and a device type of the radio terminal from a plurality of predefined device types, the first terminal capability set being one of a plurality of predefined terminal capability sets, each terminal capability set being predefined in association with at least one of the plurality of predefined use cases and at least one of the plurality of predefined device types, each terminal capability set defining respective values ​​for a plurality of terminal capability parameters.

[0014] In a fourth aspect, a method performed by a radio access network node includes receiving, from a wireless terminal, an identification of a first terminal capability set associated with one or both of an intended use case from a plurality of predefined use cases and a device type of the wireless terminal from a plurality of predefined device types, the first terminal capability set being one of a plurality of predefined terminal capability sets, each terminal capability set being predefined in association with at least one of the plurality of predefined use cases and at least one of the plurality of predefined device types, each terminal capability set defining respective values ​​for a plurality of terminal capability parameters.

[0015] In a fifth aspect, a program includes a group of instructions (software code) that, when loaded into a computer, causes the computer to perform the method according to the second or fourth aspect described above.

[0016] According to the above-described aspects, an apparatus, a method, and a program can be provided that contribute to providing signaling suitable for a UE to inform a radio access network of values ​​of a plurality of UE capability parameters relating to at least one of various device types, at least one of various use cases, or both.

[0017] 1 illustrates an example configuration of a wireless communication system according to one or more embodiments. 2 illustrates an example signaling between a UE and a radio access network node according to one or more embodiments. 3 illustrates an example definition of multiple UE capability sets according to one or more embodiments. 4 illustrates a flowchart of an example operation of a UE according to one or more embodiments. 5 illustrates an example operation of a UE and a radio access network node according to one or more embodiments. 6 illustrates an example operation of a UE and a radio access network node according to one or more embodiments. 7 illustrates an example operation of a UE and a radio access network node according to one or more embodiments. 8 illustrates an example operation of a UE and a radio access network node according to one or more embodiments. 9 illustrates an example operation of a UE and a radio access network node according to one or more embodiments. 10 illustrates an example operation of a UE and a radio access network node according to one or more embodiments. 11 illustrates an example operation of a UE and a radio access network node according to one or more embodiments. 12 illustrates an example operation of a UE and a radio access network node according to one or more embodiments. 13 illustrates an example format of configuration information provided from a radio access network to a UE according to one or more embodiments. 14 illustrates an example format of configuration information provided from a radio access network node to a UE according to one or more embodiments. 15 illustrates an example format of configuration information provided from a radio access network to a UE according to one or more embodiments. 16 illustrates an example signaling between a UE and a radio access network node according to one or more embodiments. Figure 1 illustrates an example of the operation of a UE and a radio access network node, in accordance with one or more embodiments; Figure 2 illustrates an example of the operation of a UE and a radio access network node, in accordance with one or more embodiments; Figure 3 illustrates an example of the operation of a UE and a radio access network node, in accordance with one or more embodiments; Figure 4 illustrates an example of the operation of a UE and a radio access network node, in accordance with one or more embodiments; Figure 5 illustrates an example of the configuration of a UE, in accordance with one or more embodiments;FIG. 2 is a block diagram illustrating an example configuration of a radio access network node according to one or more embodiments.

[0018] Hereinafter, specific embodiments will be described in detail with reference to the drawings. In each drawing, the same or corresponding elements are designated by the same reference numerals, and for clarity of explanation, duplicate explanations will be omitted as necessary.

[0019] The multiple embodiments described below may be used independently, or two or more embodiments may be combined as appropriate. These multiple embodiments may have different novel features. Therefore, these multiple embodiments may contribute to achieving different objectives or solving different problems, and may contribute to achieving different effects.

[0020] Each drawing is merely an example for describing one or more embodiments. Each drawing may not relate to only one particular embodiment, but may also relate to one or more other embodiments. As will be understood by those skilled in the art, various features or steps described with reference to any one drawing can be combined with features or steps shown in one or more other drawings to create, for example, an embodiment not explicitly shown or described. Not all features or steps shown in any one drawing are necessary to describe an exemplary embodiment, and some features or steps may be omitted. The order of steps described in any drawing may be changed as appropriate.

[0021] The following embodiments are described primarily for a 3GPP mobile communication system, such as a future 3GPP Beyond 5G system or 6G system, but may also be applied to other wireless communication systems.

[0022] As used herein, depending on the context, "if" may be interpreted to mean "when," "while," "at or around the time," "after," "upon," "in response to determining," "in accordance with a determination," or "in response to detecting." These expressions may be interpreted to have the same meaning, depending on the context.

[0023] First, the configurations and operations of several network elements common to several embodiments will be described. Fig. 1 shows an example configuration of a wireless communication system related to several embodiments. In the example of Fig. 1, the wireless communication system includes a wireless terminal (i.e., UE) 1 and a Radio Access Network (RAN) node (e.g., gNB) 2. Each element (network function) shown in Fig. 1 can be implemented, for example, as a network element on dedicated hardware, as a software instance running on dedicated hardware, or as a virtualized function instantiated on an application platform.

[0024] The UE 1 has at least one radio transceiver and is configured to perform radio communication with the RAN node 2. The UE 1 is connected to the RAN node 2 via an air interface 101. The UE 1 may also be referred to by other terms such as a radio terminal, a mobile terminal, a mobile station, or a wireless transmit receive unit (WTRU).

[0025] The RAN node 2 is configured to manage a cell and perform wireless communication with multiple UEs, including the UE 1, using a cellular communication technology (e.g., NR Radio Access Technology (RAT)). The RAN node 2 may be referred to by other terms, such as a base station, a radio station, or an access point. The UE 1 may be simultaneously connected to multiple RAN nodes, including the RAN node 2, for dual connectivity (DC). The RAN node 2 may be a RAN node in a future 3GPP Beyond 5G system or 6G system, such as an improved or enhanced gNB.

[0026] The RAN node 2 may be a Central Unit (CU) in a cloud RAN (C-RAN) deployment, or a combination of a CU and one or more Distributed Units (DUs). Furthermore, a CU may include a Control Plane (CP) Unit and one or more User Plane (UP) Units. Thus, the RAN node 2 may be a CU-CP or a combination of a CU-CP and a CU-UP. The CU may be a logical node that hosts the Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and Packet Data Convergence Protocol (PDCP) protocols of the RAN node (or the RRC and PDCP protocols of the RAN node). The DU may be a logical node that hosts the Radio Link Control (RLC), Medium Access Control (MAC), and Physical (PHY) layers of the RAN node. The DU may host the high PHY layer, and the low PHY layer may be located in one or more Transmission-Reception Points (TRPs) connected to the DU. The TRP may also be called a Radio Unit (RU) or a Remote Radio Head (RRH).

[0027] <First Embodiment> A configuration example of a wireless communication system according to this embodiment is similar to the configuration example described with reference to Fig. 1. This embodiment provides an example of signaling for a UE 1 to inform a radio access network of values ​​of a plurality of UE capability parameters relating to at least one of various device types, at least one of various use cases, or both.

[0028] 2 shows an example of signaling for notification of UE capability parameters. In step 201, UE1 informs or notifies a radio access network (e.g., RAN node 2) of the identity (e.g., identification information, identifier) ​​of a first UE capability set. Specifically, UE1 transmits data or information indicating or corresponding to the identity of the first UE capability set to RAN node 2.

[0029] The first UE capability set is one of a plurality of predefined UE capability sets. Each UE capability set is predefined to be associated with at least one of a plurality of predefined use cases and at least one of a plurality of predefined device types. The first UE capability set is associated with a use case intended by the UE from the plurality of predefined use cases. Alternatively, the first UE capability set is associated with the UE's own device type from the plurality of predefined device types. Alternatively, the first UE capability set is associated with both an intended use case from the plurality of predefined use cases and the UE's own device type from the plurality of predefined device types.

[0030] Each of the plurality of predefined UE capability sets, including the first UE capability set, defines a respective value of a plurality of UE capability parameters, the plurality of UE capability parameters including one or more mandatory features, one or more constraints or restrictions imposed on the one or more mandatory features, one or more default radio settings, or any combination thereof.

[0031] The term "UE capability set" may be replaced with other terms, such as, but not limited to, a feature set, a UE feature set, a category, a feature category, a UE category, a UE feature category, a UE capability group, a UE feature group, a UE capability class, a UE feature class, a UE capability pattern, a UE feature pattern, etc.

[0032] The association of each UE capability set with at least one use case and / or at least one device type may be defined in a (future) 3GPP specification. Specifically, the 3GPP specification may define multiple use cases, multiple device types, and multiple UE capability sets. The definition of the multiple UE capability sets specifies the association of each UE capability set with at least one predefined use case and / or at least one predefined device type. In addition, the definition of the multiple UE capability sets specifies the respective values ​​of multiple UE capability parameters included in each UE capability set.

[0033] Use cases predefined in the 3GPP specifications may include two or more of enhanced Mobile Broadband (eMBB), Ultra-Reliable and Low Latency Communications (URLLC), immersive (or XR), NTN, IoT, UAV, and vehicle-to-everything (V2X). Device types predefined in the 3GPP specifications may include two or more of handheld devices, robotics devices, wearable devices, sensor devices, and automotive devices.

[0034] Each UE capability set predefined in the 3GPP specifications may include any combination of general parameters, SDAP parameters, PDCP parameters, RLC parameters, MAC parameters, and measurement parameters. General parameters include parameters indicating whether the UE supports various functions (e.g., RRC inactive state, SRB3, MT-SDT). Additionally or alternatively, one or more of the UE capability sets predefined in the 3GPP specifications may include parameters associated with a specific UE device type. For example, a UE capability set may define values ​​for radio access capability parameters associated with a specific UE device type. A UE capability set may define values ​​indicating that one or more functions for a specific UE device type must be supported by the UE. Additionally or alternatively, one or more of the UE capability sets predefined in the 3GPP specifications may include parameters associated with a specific use case. For example, a UE capability set may define values ​​for radio access capability parameters associated with a specific use case. A UE capability set may define values ​​indicating that one or more functions for a specific use case must be supported by the UE.

[0035] A combination of UE capability parameters whose values ​​are defined by one of the predefined UE capability sets (e.g., a first UE capability set) may differ from a combination of UE capability parameters whose values ​​are defined by another of the predefined UE capability sets. For example, at least one of the UE capability parameters whose values ​​are defined by a first UE capability set may not be included in a plurality of UE capability parameters whose values ​​are defined by a second UE capability set different from the first UE capability set. A UE capability set defined in association with a specific use case may include at least one capability parameter that is different from any of the capability parameters included in other UE capability sets defined in association with other specific use cases. A UE capability set defined in association with a specific device type may include at least one capability parameter that is different from any of the capability parameters included in other UE capability sets defined in association with other specific device types.

[0036] According to the operations of UE1 and RAN node 2 described above with reference to FIG. 2 , UE1 informs or notifies RAN node 2 of the “identification” (e.g., identification information, identifier) ​​of a first UE capability set, which is one of a plurality of predefined UE capability sets. Here, each UE capability set is predefined in association with at least one of a plurality of predefined use cases and at least one of a plurality of predefined device types. The first UE capability set is a UE capability set associated with at least one of an intended use case among the plurality of predefined use cases and / or UE1's own device type among the plurality of predefined device types. This means that for the plurality of UE capability parameters included in the first UE capability set, UE1 does not need to specify whether UE1 supports them or the maximum or minimum values ​​that UE1 supports for each UE capability parameter. In other words, UE1 does not need to send a list indicating the respective values ​​of a large number of UE capability parameters to RAN node 2. This can contribute to reducing the amount of signaling data required for the UE 1 to inform the RAN node 2 of values ​​of multiple UE capability parameters related to at least one of various device types, at least one of various use cases, or both. This also means that UEs corresponding to various use cases and / or UEs of various different device types only need to support their respective required or appropriate UE capabilities. In other words, this can contribute to avoiding excessive implementation of UEs (e.g., supporting more capabilities than necessary) and thus increasing implementation costs, which may occur when various UEs define common required functions.

[0037] FIG. 3 illustrates an example of the definition of multiple UE capability sets. As described above, the definition of multiple UE capability sets may be specified in the 3GPP specifications. In the example of FIG. 3, eight UE capability sets are defined, and these eight UE capability sets are associated with six defined device types and seven defined use cases. The dotted lines in FIG. 3 indicate how each of the eight UE capability sets may be associated with one of the predefined use cases and one or more predefined device types. Other use cases and / or device types not shown in FIG. 3 may be predefined. For example, the multiple predefined use cases may include voice (e.g., voice over IP (VoIP)). The "Voice" use case may be associated with "handheld" device types (e.g., high-end handheld and / or low-end handheld). The multiple predefined UE capability sets may include another UE capability set associated with the "Voice" use case.

[0038] As described above, each UE capability set defines respective values ​​for a plurality of UE capability parameters. The plurality of UE capability parameters may include one or more mandatory features, one or more constraints or restrictions imposed on one or more mandatory features, one or more default radio configurations, or any combination thereof. In the example of Figure 3, UE capability set #1 includes RF capability parameters, baseband processing capability parameters, radio configuration capability parameters, measurement capability parameters, and other parameters.

[0039] The RF capability parameters may include one or more of the number of receivers in UE1, the number of transmitters in UE1, and the maximum channel bandwidth supported by UE1. The baseband processing capability parameters may include one or both of the maximum number of multiple-input multiple-output (MIMO) layers supported by UE1 and the maximum modulation order supported by UE1. The radio configuration capability parameters may include one or both of the size of Layer 2 sequence numbers supported by UE1 and the number of radio bearers supported by UE1. The measurement capability parameters may include the number of neighbor cells that UE1 can store in association with a measurement object (e.g., #minCellperMeasObjectNR).

[0040] The combination of UE capability parameters included in each of UE capability sets #2 to #8 may be the same as or different from that included in UE capability set #1. For example, each UE capability set may include one or more capability parameters specific to the associated use case. For example, UE capability set #4 may define values ​​for one or more XR-related parameters specific to the associated XR service. Meanwhile, the remaining UE capability sets #1 to #3 and #5 to #8 may not define values ​​for these XR-related parameters.

[0041] 4 illustrates an example of the operation of UE1. In step 401, UE1 selects a first UE capability set from a plurality of predefined UE capability sets based on one or both of an intended use case and its device type. UE1 may select the first UE capability set from a plurality of predefined UE capability sets based on an intended use case and based on its device type. In step 402, UE1 informs or signals to RAN node 2 the identity of the selected first UE capability set.

[0042] In step 401, UE1 may select a first UE capability set each time a radio connection (e.g., an RRC connection) is set up, based on the intended use case when the radio connection is set up. UE1 may transmit an identification of the first UE capability set to the RAN (e.g., RAN node 2) each time the radio connection is set up. In this case, the first UE capability set indicated by UE1 to the RAN (e.g., RAN node 2) may change each time the radio connection is set up. Therefore, the first UE capability set indicated by UE1 to the RAN (e.g., RAN node 2) may be valid only for the lifetime of the radio connection. For example, if UE1 supports multiple use cases, UE1 may select a UE capability set associated with the intended use case when requesting the setup of the radio connection and transmit an identification of the selected UE capability set to RAN node 2.

[0043] 5 through 7 illustrate several examples of how the identification of a first UE capability set may be signaled from UE 1 to RAN node 2. In one example, UE 1 may signal the identification of the first UE capability set to RAN node 2 by using random access resources associated with the first UE capability set. The random access resources may be Random Access Channel (RACH) occasions, RACH preambles, or a combination thereof. FIG. 5 illustrates an example of identifying the first UE capability set using random access resources. In step 501, RAN node 2 transmits system information (System Information Block (SIB)) including RACH partitioning configurations for multiple predefined UE capability sets. RAN node 2 may broadcast the system information in its cell. The RACH partitioning configuration indicates a partition or pool of RACH resources allocated to each of the multiple predefined UE capability sets. In step 502, UE 1 transmits a RACH preamble transmission using resources associated with the first UE capability set.

[0044] In another example, UE1 may inform RAN node 2 of the identification of the first UE capability set by transmitting information identifying the first UE capability set to RAN node 2. As shown in FIG. 6, UE1 may transmit information identifying the first UE capability set using the Logical Channel ID (LCID) field of the MAC subheader (step 601). In other words, the LCID field in the MAC subheader may include a value identifying the first UE capability set. This MAC subheader may be included in a MAC Protocol Data Unit (PDU) carrying the first RRC message (e.g., RRC Setup Request) sent in the third random access message. In another example, as shown in FIG. 7, UE1 may transmit an RRC message including the identification (e.g., identification information, identifier) ​​of the first UE capability set to RAN node 2 (step 701). The RRC message may be a UE Capability Information message.

[0045] Figure 8 shows an example of signaling for notification of UE capability parameters. Figure 8 provides a variation or more detail of the signaling shown in Figure 2. Step 801 is similar to step 201 in Figure 2. In step 801, UE1 informs or notifies the radio access network (e.g., RAN node 2) of the identity (e.g., identification information, identifier) ​​of the first UE capability set. Specifically, UE1 transmits data or information indicating or corresponding to the identity of the first UE capability set to RAN node 2.

[0046] In step 802, RAN node 2 generates configuration information (e.g., RRC configuration) for UE1 based on the first UE capability set. RAN node 2 transmits the generated configuration information to UE1. RAN node 2 may transmit the configuration information to UE1 using an RRC message (e.g., RRC Reconfiguration). UE1 receives the generated configuration information (e.g., RRC configuration) based on the first UE capability set from RAN node 2. UE1 stores and applies (or uses) the configuration information.

[0047] According to the operations illustrated in Figure 8, UE1 may provide to RAN node 2 an identification of a first UE capability set, which is one of a plurality of predefined UE capability sets for a plurality of predefined use cases and / or a plurality of predefined device types, and RAN node 2 may respect or take into account the first UE capability set signaled by UE1 during configuration of UE1.

[0048] Second Embodiment A configuration example of a wireless communication system according to this embodiment is similar to the configuration example described with reference to FIG.

[0049] FIG. 9 illustrates an example of signaling between UE 1 and RAN node 2. In step 901, RAN node 2 broadcasts a support indication in the cell. The support indication indicates one or more use cases supported by the cell, one or more device types supported by the cell, or both. In one example, the support indication may include a list indicating one or more supported use cases, a list indicating one or more supported device types, or both. The support indication may include a combined list indicating one or more supported use cases and one or more supported device types. Alternatively, the support indication may include a bitmap indication, where each bit in the bitmap indication corresponds to a particular device type or use case. The support indication may be included in a Master Information Block (MIB), SIB type 1 (SIB1), or other SIB.

[0050] Additionally or alternatively, the support indicator may indicate one or more UE capability sets supported by the cell. The support indicator may be associated with the UE capability sets. The concept of the UE capability set in this embodiment is similar to that described in the first embodiment.

[0051] For example, if the support indication is expressed as a list, it may be a list of UE capability set identities (e.g., identification information, identifiers). Similarly, if the support indication is a bitmap indication, each bit may represent the identity of a UE capability set. Note that, for example, if the support indication is a bitmap indication, the length of the bitmap is predefined, and it includes one or more bits corresponding to use cases or device types that are not supported in the cell. In this case, some or all of these bits may be associated with use cases or device types that will be defined in the future. In other words, forward compatibility with use cases and / or device types that will be defined in the future may be guaranteed.

[0052] UE1 receives the support indication via broadcast in the cell. UE1 may consider the support indication in cell selection. For example, based on the support indication, UE1 may select a cell in which the intended use case, its own device type, or the intended UE capability set is supported. Additionally or alternatively, UE1 may consider the support indication in selecting the first UE capability set described in the first embodiment. For example, based on the support indication received in the cell, UE1 may select the first UE capability set to be signaled to RAN node 2 to include only use cases, device types, or UE capability sets supported in the cell. These operations of UE1 may be performed before the operations described in the first embodiment (e.g., step 201 in FIG. 2 and step 801 in FIG. 8).

[0053] The support indication broadcast in the cell by the RAN node 2 may further indicate one or more use cases supported in the neighboring cells, one or more device types supported in the neighboring cells, one or more terminal capability sets supported in the neighboring cells, or any combination thereof, so as to facilitate, for example, during cell selection or cell reselection, the UE 1 to select a cell in which the intended use case, its device type, or the intended UE capability set is supported.

[0054] 10 shows an example of signaling between RAN nodes. In step 1001, RAN node 2A sends information about use cases, device types, UE capability sets, or any combination thereof, supported in one or more cells managed by the RAN node 2A to RAN node 2B. In step 1002, RAN node 2A receives information about use cases, device types, UE capability sets, or any combination thereof, supported in one or more cells managed by RAN node 2B from RAN node 2B. This allows RAN node 2B to know the use cases, device types, UE capability sets, or any combination thereof, supported in the cells managed by RAN node 2A. Similarly, RAN node 2A can know the use cases, device types, UE capability sets, or any combination thereof, supported in the cells managed by RAN node 2B. RAN nodes 2A and 2B may exchange the information of steps 1001 and 1002 as part of a procedure for exchanging or updating application-level configuration data necessary for RAN nodes 2A and 2B to properly interoperate over the RAN-to-RAN node control plane interface.

[0055] <Third Embodiment> A configuration example of a wireless communication system according to this embodiment is the same as the configuration example described with reference to Fig. 1. This embodiment provides an example of RRC configuration suitable for the case where the concept of a UE capability set is introduced.

[0056] The concept of the UE capability set in this embodiment is similar to that described in the first embodiment. That is, multiple UE capability sets are predefined. Each UE capability set is predefined in association with at least one of multiple predefined use cases and / or at least one of multiple predefined device types. Each UE capability set defines respective values ​​of multiple UE capability parameters. The multiple UE capability parameters include one or more mandatory features, one or more constraints or restrictions imposed on the one or more mandatory features, one or more default radio settings, or any combination thereof.

[0057] The term "UE capability set" may be replaced with other terms, such as, but not limited to, a feature set, a UE feature set, a category, a feature category, a UE category, a UE feature category, a UE capability group, a UE feature group, a UE capability class, a UE feature class, a UE capability pattern, a UE feature pattern, etc.

[0058] The association of each UE capability set with at least one use case and / or at least one device type may be defined in a (future) 3GPP specification. Specifically, the 3GPP specification may define multiple use cases, multiple device types, and multiple UE capability sets. The definition of the multiple UE capability sets specifies the association of each UE capability set with at least one predefined use case and / or at least one predefined device type. In addition, the definition of the multiple UE capability sets specifies the respective values ​​of multiple UE capability parameters included in each UE capability set.

[0059] Use cases predefined in the 3GPP specifications may include two or more of eMBB, URLLC, immersive (or XR), NTN, IoT, UAV, and V2X. Device types predefined in the 3GPP specifications may include two or more of handheld devices, robotics devices, wearable devices, sensor devices, and automotive devices.

[0060] Each UE capability set predefined in the 3GPP specifications may include any combination of general parameters, SDAP parameters, PDCP parameters, RLC parameters, MAC parameters, and measurement parameters. Additionally or alternatively, one or more of the UE capability sets predefined in the 3GPP specifications may include parameters associated with a particular UE device type. Additionally or alternatively, one or more of the UE capability sets predefined in the 3GPP specifications may include parameters associated with a particular use case.

[0061] A combination of UE capability parameters whose values ​​are defined by one of the predefined UE capability sets may differ from a combination of UE capability parameters whose values ​​are defined by another of the predefined UE capability sets. For example, a UE capability set defined in association with a particular use case may include at least one capability parameter that differs from any of the capability parameters included in other UE capability sets defined in association with other specific use cases. A UE capability set defined in association with a particular device type may include at least one capability parameter that differs from any of the capability parameters included in other UE capability sets defined in association with other specific device types.

[0062] FIG. 11 shows an example of an RRC configuration provided to UE1 by RAN node 2. The RRC configuration shown in FIG. 11 may be a UE-specific configuration provided by a UE-dedicated RRC message. In the example of FIG. 11, the condition "Cond Cat1" (1101) of field B in the RRC-Config information element means that this field is mandatory if UE1 is in a specific UE capability set #1 or category #1 (Cat1). Otherwise, this field is optional, and UE1 may treat it as "need R," or UE1 may not retain a value. "need R" means "Release" and is used for fields that are stored by the UE, i.e., are not one-shot (configuration). When UE1 receives a message in which a field designated as "need R" does not exist, UE1 releases the current value. The condition "Cond Cat1" (1101) can be used for any UE capability set. When this is used with respect to UE Capability Set #N, it may be written as condition "Cond CatN".

[0063] The condition "Need ExCat2" (1102) of field C in the RRC-Config information element means that this field is optionally present and treated as "need M" if UE1 is not in a specific UE capability set #2 or category #2 (Cat2). "Need M" means "Maintain" and is used for fields that are stored by the UE, i.e., not one-shot (configuration). If UE1 receives a message in which a field with "need M" is not present, UE1 maintains the current value. Otherwise, this field is not present, and UE1 may treat it as "need R", or UE1 may not retain the value. The condition "Need ExCat2" (1102) can be used for any UE capability set. If it is used for UE capability set #N, it may be written as the condition "Need ExCatN".

[0064] The condition "Cond Cat3-OrCat4" (1103) of field D in the RRC-Config information element means that this field is optionally present and treated as "need M" if UE1 is in a specific UE capability set #3 or category #3 (Cat3) or UE capability set #4 or category #4 (Cat4). Otherwise, this field is optionally present, and UE1 may treat it as "need R", or UE1 may not retain a value. The condition "Cond Cat3-OrCat4" (1103) can be used for any UE capability set. When it is used for UE capability sets #M and #N, it may be written as the condition "Cond CatM-OrCatN".

[0065] The conditions 1101, 1102, and 1103 described with reference to Fig. 11 may be included in one RRC configuration as shown in Fig. 11, or may be included in two or more separate RRC configurations. The conditions 1101, 1102, and 1103 can be used independently. There may be an RRC configuration in which one of the conditions 1101, 1102, and 1103 is used, or there may be an RRC configuration in which two of the conditions 1101, 1102, and 1103 are used.

[0066] UE1 may receive the RRC configuration as described with reference to Figure 11. Based on the received RRC configuration, UE1 may perform the above-mentioned conditional processing (e.g., decoding) depending on the category (i.e., UE capability set) to which UE1 belongs or the category (i.e., UE capability set) targeted by the RRC configuration.

[0067] The RAN node 2 may generate an RRC configuration for UE1 as described with reference to Fig. 11 and transmit the generated RRC configuration to UE1. If UE capability set #1 is applied to UE1, then in generating the RRC configuration, the RAN node 2 may necessarily include a field in which the condition "Cond Cat1" (1101) is used in the RRC configuration. If a UE capability set other than UE capability set #1 is applied to UE1, then in generating the RRC configuration, the RAN node 2 may or may not include a field in which the condition "Cond Cat1" (1101) is used in the RRC configuration.

[0068] FIG. 12 shows another example of the RRC configuration provided to UE 1 by RAN node 2. The RRC configuration shown in FIG. 12 may be a common configuration included in RRC signaling or a message (e.g., system information, SIB) common to multiple UEs or common to a cell. In the example of FIG. 12, field A in the DownlinkConfigCommonSIB information element includes a FieldA-Config information element (1201). The FieldA-Config information element (1201) includes a FieldA-apply field (1202). The FieldA-apply field (1202) specifies one or more UE capability sets to which the FieldA-Config information element (1201) applies, among multiple predefined UE capability sets. The FieldA-apply field (1202) is a bit string of a predetermined length. Each bit corresponds to one of multiple UE capability sets and indicates whether the FieldA-Config information element (1201) applies to the corresponding UE capability set. For example, if a bit is set to '1', this may mean that the setting applies to UEs with the corresponding UE capability set, and if the bit is set to '0', this may mean that the setting does not apply to UEs with the corresponding UE capability set. Alternatively, the bit values ​​'1' and '0' may have opposite meanings.

[0069] In the specific example shown in Figure 12, the fieldA-apply field (1202) is an 8-bit string, and each bit corresponds to one of eight possible UE capability sets. The eight possible UE capability sets may be, for example, the eight possible UE capability sets shown in Figure 3.

[0070] UE1 checks the bit corresponding to its own UE capability set or the UE capability set selected by UE1, for example, the first UE capability set described in the first embodiment, and then, depending on the value of the corresponding bit, UE1 decides whether to store (or use) the configuration specified by the FieldA-Config information element (1201).

[0071] Figure 13 shows yet another example of RRC configuration provided to UE1 by RAN node 2. The RRC configuration shown in Figure 13 may be UE-specific configuration provided by a UE-dedicated RRC message. In the example of Figure 13, the FieldB-Config information element includes an enumerated field B. The meaning of the same bit string indicated by field B differs between at least two terminal capability sets included in multiple predefined terminal capability sets. UE1 determines the meaning of the same bit string based on its own UE capability set or a UE capability set selected by UE1, for example, the first UE capability set described in the first embodiment.

[0072] In the specific example shown in Figure 13, if UE1 is in a specific UE capability set #1 or category #1 (Cat1), UE1 understands that the bit string "00" in field B means 1. On the other hand, if UE1 is in a specific UE capability set #2 or category #2 (Cat2), UE1 understands that the bit string "00" in field B means 8.

[0073] One or more of the RRC configuration examples described in this embodiment, for example, one or both of the examples in FIG. 11 and FIG. 13 , may be used in the RRC configuration (e.g., step 802 in FIG. 8 ) generated based on the UE capability signaling described in the first embodiment. However, the RRC configuration examples described in this embodiment may also be used without the UE capability signaling described in the first embodiment. For example, the UE capability set supported by UE1, intended by UE1, or associated with UE1 may be predefined in the Universal Subscriber Identity Module (USIM) of UE1 and linked to Non-Access Stratum (NAS) capabilities. In this case, the core network may indicate the UE capability set of UE1 to the RAN node 2. This allows the RAN node 2 to know the UE capability set of UE1 without explicit signaling from UE1.

[0074] <Fourth embodiment> A configuration example of a wireless communication system according to this embodiment is similar to the configuration example described with reference to Fig. 1. This embodiment provides an example of signaling by which the UE 1 informs the radio access network of multiple UE capability sets supported (or intended or selected) by the UE 1, and an example of the operation of the UE 1 and the RAN node 2 related to this signaling.

[0075] 14 shows an example of signaling for notification of UE capability parameters. In step 1401, UE1 informs or notifies a radio access network (e.g., RAN node 2) of identities (e.g., identification information, identifiers) of UE capability sets supported (or intended or selected) by UE1. Specifically, UE1 transmits data or information indicating or corresponding to the identities of the UE capability sets to RAN node 2. UE1 may notify RAN node 2 of the identities of the UE capability sets using a single RRC message.

[0076] The concept of UE capability sets in this embodiment is similar to that described in the first embodiment. The UE capability sets, the identification of which is signaled by the UE 1 to the RAN node 2, are included in a plurality of predefined UE capability sets. Each UE capability set is predefined to be associated with at least one of a plurality of predefined use cases and / or at least one of a plurality of predefined device types.

[0077] If UE1 supports, desires, or selects multiple use cases, UE1 may send identification of multiple UE capability sets associated with these multiple use cases to RAN node 2 in step 1401. In this case, UE1 and RAN node 2 may operate as in the first or second example below.

[0078] (First Example) UE1 simultaneously supports the union of multiple UE capability parameters included in multiple UE capability sets. If a UE capability parameter is commonly included in two or more UE capability sets, UE1 supports the value corresponding to the highest performance among two or more values ​​of the UE capability parameter in these two or more UE capability sets. For example, if the UE capability parameter is a peak datalet parameter, UE1 supports the largest value among two or more values ​​of the peak datalet parameter in two or more UE capability sets. For example, if the UE capability parameter is a latency parameter, UE1 supports the smallest value among two or more values ​​of the latency parameter in two or more UE capability sets.

[0079] RAN node 2 (or the network including RAN node 2) recognizes that UE 1 (simultaneously) supports the union of multiple UE capability parameters included in multiple UE capability sets signaled by UE 1. If there is a UE capability parameter that is commonly included in two or more UE capability sets, RAN node 2 (or the network) recognizes that UE 1 supports the value that corresponds to the highest performance among two or more values ​​of that UE capability parameter in the two or more UE capability sets.

[0080] The UE 1 and the RAN node 2 (or the network) communicate based on the values ​​of the UE capability parameters determined as described above, without the UE 1 and the RAN node 2 (or the network) being particularly aware of which use case (or service) the communication relates to.

[0081] (Second Example) UE1 and RAN node 2 (or a network including RAN node 2) use or apply multiple UE capability sets for different use cases. UE1 and RAN node 2 (or a network) consider that there are different UE capability sets corresponding to multiple use cases.

[0082] The combination of UE capability parameters (e.g., RF capability, baseband processing capability, and radio configuration parameters) that UE1 should support or should have may differ for each service (e.g., for each radio bearer, for each Quality of Service (QoS) flow, for each PDU session, or for each slice). The value of a certain UE capability parameter that UE1 should support or should have may differ for each service (e.g., for each radio bearer, for each Quality of Service (QoS) flow, for each PDU session, or for each slice).

[0083] When communication or service relating to one of a plurality of use cases is performed, the UE 1 and the RAN node 2 (or network) communicate based on the values ​​of a plurality of capability parameters defined in the UE capability set corresponding to that use case.

[0084] When multiple communications or services relating to multiple use cases are performed simultaneously, the UE 1 and the RAN node 2 (or the network) perform each of the multiple communications based on the values ​​of multiple capability parameters defined in a corresponding UE capability set. Additionally or alternatively, constraints on the simultaneous support of multiple use cases may be predefined. For example, this may be a constraint that when a specific first use case is used, a specific second use case cannot be used simultaneously.

[0085] According to the operation shown in Figure 14, UE1 can provide multiple identifications of multiple UE capability sets to RAN node 2. RAN node 2 can respect or take into account the multiple UE capability sets signaled by UE1 when configuring UE1.

[0086] Fifth Embodiment A configuration example of a wireless communication system according to this embodiment is the same as the configuration example described with reference to Fig. 1. In this embodiment, a UE1 identifies a UE capability set corresponding to a service (or use case) requested or triggered from a higher layer (e.g., an application layer or a PDU layer), and sets up Layer 2 (or an AS layer) based on the identified UE capability set. Specifically, the UE1 determines an access category or an access identity, or both, corresponding to the requested or triggered service (or use case), identifies a UE capability set corresponding to the determined access category or access identity, or both, and sets up Layer 2 (or an AS layer) based on the identified UE capability set.

[0087] Figure 15 shows an example of the operation of the UE 1 and the RAN node 2. In step 1501, the NAS layer 11 of the UE 1 is triggered or requested for a service from a higher layer (eg, application layer or PDU layer).

[0088] In step 1502, the UE NAS layer 11 determines or selects an access category or an access identity, or both, corresponding to the trigger or the requested service. The definitions of the access category and the access identity may be similar to those of 5G NR. The UE NAS layer 11 sends or passes the determined access category or the access identity, or both, to the Access Stratum (AS) layer 12 of the UE 1. The UE AS layer 12 includes an RRC layer.

[0089] An access category and / or access identity is associated with a use case. The association between an access category and / or access identity and a use case may be defined in a (future) 3GPP specification. Alternatively, this association may be pre-configured in the UE 1 by the RAN node 2 or by the core network via the RAN node 2.

[0090] In step 1503, the UE AS layer 12 identifies a corresponding UE capability set based on the received access category and / or access identity. The association between the access category and / or access identity and the UE capability set may be defined in a (future) 3GPP specification. Alternatively, this association may be pre-configured in the UE 1 by the RAN node 2 or by the core network via the RAN node 2.

[0091] The concept of a UE capability set in this embodiment is similar to that described in the first embodiment. The UE capability set may be referred to by other terms, such as, but not limited to, a feature set, a UE feature set, a category, a feature category, a UE category, a UE feature category, a UE capability group, a UE feature group, a UE capability class, a UE feature class, a UE capability pattern, or a UE feature pattern.

[0092] In step 1504, the UE AS layer 12 performs or initiates layer 2 (L2) protocol setup based on the identified UE capability set. L2 protocol setup may also be referred to as AS layer protocol setup. L2 protocol setup includes setting up, establishing, configuring, or preparing layer 2 (or AS layer) so that the layer 2 (or AS layer) is configured in accordance with the identified UE capability set.

[0093] The UE AS layer 12 may configure Layer 2 mandatory functionality (optionally with default settings) based on the identified UE capability set. The UE AS layer 12 may also configure Layer 2 default radio configuration (optionally with default values ​​for some parameters) based on the identified UE capability set.

[0094] Additionally or alternatively, the UE AS layer 12 may perform an adaptation of the Layer 2 architecture or protocol stack. This L2 adaptation may include any one or any combination of the following four examples:

[0095] In a first example, based on the identified UE capability set, the UE AS layer 12 determines or knows whether to include a particular sublayer in Layer 2 (eg, a PDCP sublayer or an RLC sublayer or both).

[0096] In a second example, based on the identified UE capability set, the UE AS layer 12 determines or recognizes whether to use a first number of sublayers in Layer 2 or a second number of sublayers that is less than the first number in Layer 2. The second number of sublayers may be realized by transferring or integrating at least one function provided by one or more sublayers included in the first number of sublayers (e.g., RLC sublayers) into one or more other sublayers (e.g., PDCP sublayers or MAC sublayers, or both).

[0097] In a third example, based on the identified UE capability set, the UE AS layer 12 determines or knows whether to enable or disable at least one feature within at least one sub-layer included in Layer 2.

[0098] In a fourth example, based on the identified UE capability set, the UE AS layer 12 selects a number of functions to be used at layer 2 from a set of predefined layer 2 functions.

[0099] Through the coordinated operation of the UE NAS layer 11 and the UE AS layer 12 in steps 1502 to 1504, the UE 1 can identify the UE capability set corresponding to the requested or triggered service and can set up Layer 2 (or AS layer) based on the UE capability set.

[0100] The UE AS layer 12 communicates with the RAN node 2 for L2 protocol setup. The UE AS layer 12 may inform the RAN node 2 of the identified UE capability set. This may be similar to the operation of the UE 1 described in the first or fourth embodiment (e.g., FIG. 2, FIG. 5, FIG. 6, FIG. 7, FIG. 8, or FIG. 14). The UE AS layer 12 may receive L2 layer configuration from the RAN node 2. This may be similar to the operation of the UE 1 described in the first embodiment (e.g., FIG. 8). For example, as shown in steps 1505 to 1507 in FIG. 15, the UE AS layer 12 may set up, establish, configure, or prepare Layer 2 (or the AS layer) through RRC connection setup (step 1505), receiving an RRC Reconfiguration message (step 1506), and sending an RRC Reconfiguration Complete message (step 1507).

[0101] 16 shows another example of the operation of the UE 1 and the RAN node 2. In step 1601, the NAS layer 11 of the UE 1 is triggered or requested for a service from a higher layer (eg, application layer or PDU layer).

[0102] In step 1602, the UE NAS layer 11 determines or selects an access category or an access identity, or both, corresponding to the trigger or the requested service. The definitions of the access category and the access identity may be similar to those of 5G NR. The UE NAS layer 11 sends or passes the determined access category or the access identity, or both, to the UE AS layer 12.

[0103] The access category and / or access identity is associated with a UE capability set. The association between the access category and / or access identity and the UE capability set may be defined in a (future) 3GPP specification. Alternatively, this association may be pre-configured in the UE 1 by the RAN node 2 or by the core network via the RAN node 2.

[0104] In step 1603, the UE AS layer 12 performs or initiates layer 2 (L2) protocol setup based on the received access category or access identity. L2 protocol setup may also be referred to as AS layer protocol setup. L2 protocol setup includes setting up, establishing, configuring, or preparing layer 2 (or AS layer) so that the layer 2 (or AS layer) is configured according to the UE capability set corresponding to the access category or access identity. Examples of L2 protocol setup are similar to those described with reference to FIG. 15.

[0105] Through the coordinated operation of the UE NAS Layer 11 and the UE AS Layer 12 in steps 1602 and 1603, the UE 1 can set up Layer 2 (or AS layer) based on the UE capability set corresponding to the requested or triggered service.

[0106] Steps 1604 to 1606 are similar to steps 1505 to 1507 in FIG.

[0107] Sixth Embodiment A configuration example of a wireless communication system according to this embodiment is the same as the configuration example described with reference to Fig. 1. In this embodiment, UE1 identifies a UE capability set corresponding to a service requested or triggered from a higher layer (e.g., an application layer or a PDU layer) and sets up Layer 2 (or an AS layer) based on the identified UE capability set. Specifically, UE1 determines a network slice or network slice identification information corresponding to the requested or triggered service (or use case), identifies a UE capability set corresponding to the determined network slice or network slice identification information, and sets up Layer 2 (or an AS layer) based on the identified UE capability set.

[0108] Figure 17 shows an example of the operation of the UE 1 and the RAN node 2. In step 1701, the NAS layer 11 of the UE 1 is triggered or requested for a service from a higher layer (eg, application layer or PDU layer).

[0109] In step 1702, the UE NAS layer 11 determines or selects a network slice or network slice identification information corresponding to the triggered or requested service. The UE NAS layer 11 sends or passes the determined network slice identification information to the AS layer 12 of the UE 1. The UE AS layer 12 includes an RRC layer.

[0110] The network slice or the network slice identity is associated with a use case. The association between the network slice or the network slice identity and the use case may be pre-configured in the UE 1 by the RAN node 2 or by the core network via the RAN node 2.

[0111] The network slice identity may be Single Network Slice Selection Assistance Information (S-NSSAI). Additionally or alternatively, the network slice identity may be Network Slice Access Stratum Group (NSAG) ID. The NSAG information is provided to the UE 1 from the core network at the NAS layer. The NSAG information includes a list of NSAGs, and for each NSAG, includes an NSAG ID, a list of S-NSSAI(s), and a priority value associated with the NSAG.

[0112] In step 1703, the UE AS layer 12 identifies a corresponding UE capability set based on the received network slice identification information. The association between the network slice identification information and the UE capability set may be pre-configured in the UE 1 by the RAN node 2 or by the core network via the RAN node 2.

[0113] The concept of a UE capability set in this embodiment is similar to that described in the first embodiment. The UE capability set may be referred to by other terms, such as, but not limited to, a feature set, a UE feature set, a category, a feature category, a UE category, a UE feature category, a UE capability group, a UE feature group, a UE capability class, a UE feature class, a UE capability pattern, or a UE feature pattern.

[0114] In step 1704, the UE AS layer 12 performs or initiates layer 2 (L2) protocol setup based on the identified UE capability set. L2 protocol setup may also be referred to as AS layer protocol setup. L2 protocol setup includes setting up, establishing, configuring, or preparing layer 2 (or AS layer) so that the layer 2 (or AS layer) is configured in accordance with the identified UE capability set. Examples of L2 protocol setup are similar to those described with reference to FIG. 15 in the fifth embodiment.

[0115] Through the coordinated operation of the UE NAS layer 11 and the UE AS layer 12 in steps 1702 to 1704, the UE 1 can set up Layer 2 (or AS layer) based on the UE capability set corresponding to the requested or triggered service.

[0116] Steps 1705 to 1707 are similar to steps 1505 to 1507 in FIG.

[0117] 18 shows another example of the operation of the UE 1 and the RAN node 2. In step 1801, the NAS layer 11 of the UE 1 is triggered or requested for a service from a higher layer (eg, application layer or PDU layer).

[0118] In step 1802, the UE NAS layer 11 determines or selects a network slice or network slice identification information corresponding to the triggered or requested service. The UE NAS layer 11 sends or passes the determined network slice identification information to the UE AS layer 12. The network slice identification information may be an S-NSSAI. Additionally or alternatively, the network slice identification information may be an NSAG ID.

[0119] The network slice or network slice identity is associated with a UE capability set. The association between the network slice or network slice identity and the UE capability set may be pre-configured in the UE 1 by the RAN node 2 or by the core network via the RAN node 2.

[0120] In step 1803, the UE AS layer 12 performs or initiates layer 2 (L2) protocol setup based on the received network slice identification information. The L2 protocol setup may also be referred to as AS layer protocol setup. The L2 protocol setup includes setting up, establishing, configuring, or preparing the layer 2 (or AS layer) so that the layer 2 (or AS layer) is configured according to the UE capability set corresponding to the network slice identification information. Examples of the L2 protocol setup are similar to those described with reference to FIG. 15.

[0121] Through the coordinated operation of the UE NAS Layer 11 and the UE AS Layer 12 in steps 1802 and 1803, the UE 1 can set up Layer 2 (or AS layer) based on the UE capability set corresponding to the requested or triggered service.

[0122] Steps 1804 to 1806 are similar to steps 1705 to 1707 in FIG.

[0123] Next, exemplary configurations of a UE 1 and a RAN node 2 related to the above-described embodiments will be described. FIG. 19 is a block diagram showing an exemplary configuration of a UE 1. An RF transceiver 1901 performs analog RF signal processing for communication with a RAN node 2. The RF transceiver 1901 may include multiple transceivers. The analog RF signal processing performed by the RF transceiver 1901 includes frequency up-conversion, frequency down-conversion, and amplification. The RF transceiver 1901 is coupled to an antenna array 1902 and a baseband processor 1903. The RF transceiver 1901 receives modulation symbol data (or orthogonal frequency-division multiplexing (OFDM) symbol data) from the baseband processor 1903, generates a transmit RF signal, and provides the transmit RF signal to the antenna array 1902. The RF transceiver 1901 also generates a baseband receive signal based on the receive RF signal received by the antenna array 1902 and provides the baseband receive signal to the baseband processor 1903. The RF transceiver 1901 may include an analog beamformer circuit for beamforming, which may include, for example, multiple phase shifters and multiple power amplifiers.

[0124] The baseband processor 1903 performs digital baseband signal processing (data plane processing) and control plane processing for wireless communication. Digital baseband signal processing may include (a) data compression / decompression, (b) data segmentation / concatenation, (c) transmission format (transmission frame) generation / decomposition, (d) transmission path coding / decoding, (e) modulation (symbol mapping) / demodulation, and (f) generation of OFDM symbol data (baseband OFDM signal) using Inverse Fast Fourier Transform (IFFT). Meanwhile, control plane processing may include communication management of Layer 1 (e.g., transmit power control), Layer 2 (e.g., radio resource management and hybrid automatic repeat request (HARQ) processing), and Layer 3 (e.g., signaling related to attachment, mobility, and call management).

[0125] For example, the digital baseband signal processing by the baseband processor 1903 may include signal processing of a PDCP layer, an RLC layer, a MAC layer, and a PHY layer. Also, the control plane processing by the baseband processor 1903 may include processing of a Non-Access Stratum (NAS) protocol, an RRC protocol, MAC Control Elements (CEs), and Downlink Control Information (DCIs).

[0126] The baseband processor 1903 may perform MIMO encoding and precoding for beamforming.

[0127] The baseband processor 1903 may include a modem processor (e.g., a Digital Signal Processor (DSP)) that performs digital baseband signal processing and a protocol stack processor (e.g., a Central Processing Unit (CPU) or a Micro Processing Unit (MPU)) that performs control plane processing. In this case, the protocol stack processor that performs control plane processing may be shared with the application processor 1904, which will be described later.

[0128] The application processor 1904 is also referred to as a CPU, MPU, microprocessor, or processor core. The application processor 1904 may include multiple processors (multiple processor cores). The application processor 1904 executes a system software program (operating system (OS)) and various application programs (e.g., a calling application, a web browser, a mailer, a camera operation application, and a music playback application) read from the memory 1906 or other memories, thereby realizing various functions of the UE 1.

[0129] In some implementations, the baseband processor 1903 and the application processor 1904 may be integrated on a single chip, as indicated by the dashed line (1905) in Figure 19. In other words, the baseband processor 1903 and the application processor 1904 may be implemented as a single System on Chip (SoC) device 1905. An SoC device may also be called a system Large Scale Integration (LSI) or chipset.

[0130] The memory 1906 is volatile memory, nonvolatile memory, or a combination thereof. The memory 1906 may include multiple physically independent memory devices. The volatile memory may be, for example, static random access memory (SRAM), dynamic RAM (DRAM), or a combination thereof. The nonvolatile memory may be mask read only memory (MROM), electrically erasable programmable ROM (EEPROM), flash memory, a hard disk drive, or any combination thereof. For example, the memory 1906 may include an external memory device accessible from the baseband processor 1903, the application processor 1904, and the SoC 1905. The memory 1906 may also include an internal memory device integrated within the baseband processor 1903, the application processor 1904, or the SoC 1905. Furthermore, the memory 1906 may include memory within a Universal Integrated Circuit Card (UICC).

[0131] The memory 1906 may store one or more software modules (computer programs) 1907 containing instructions and data for processing by the UE 1. In some implementations, the baseband processor 1903 or the application processor 1904 may be configured to read and execute the software modules 1907 from the memory 1906 to perform the processing of the UE 1 described in one or more of the embodiments.

[0132] It should be noted that the control plane processing and operations performed by UE 1 described in the above embodiment can be realized by elements other than the RF transceiver 1901 and the antenna array 1902, namely, at least one of the baseband processor 1903 and the application processor 1904, and the memory 1906 storing the software module 1907.

[0133] FIG. 20 is a block diagram showing an example configuration of a RAN node 2. Referring to FIG. 20, the RAN node 2 includes an RF transceiver 2001, a network interface 2003, a processor 2004, and a memory 2005. The RF transceiver 2001 performs analog RF signal processing for communication with UEs 1. The RF transceiver 2001 may include multiple transceivers. The RF transceiver 2001 is coupled to an antenna array 2002 and a processor 2004. The RF transceiver 2001 receives modulation symbol data from the processor 2004, generates a transmit RF signal, and provides the transmit RF signal to the antenna array 2002. The RF transceiver 2001 also generates a baseband receive signal based on the receive RF signal received by the antenna array 2002 and provides the baseband receive signal to the processor 2004. The RF transceiver 2001 may include an analog beamformer circuit for beamforming. The analog beamformer circuit includes, for example, multiple phase shifters and multiple power amplifiers.

[0134] The network interface 2003 is used to communicate with network nodes (e.g., other RAN nodes, and control and forwarding nodes of the core network), and may include, for example, a network interface card (NIC) compliant with the IEEE 802.3 series.

[0135] The processor 2004 performs digital baseband signal processing (data plane processing) and control plane processing for wireless communication. The processor 2004 may include multiple processors. For example, the processor 2004 may include a modem processor (e.g., a Digital Signal Processor (DSP)) that performs digital baseband signal processing and a protocol stack processor (e.g., a CPU or MPU) that performs control plane processing. The processor 2004 may include a digital beamformer module for beamforming. The digital beamformer module may include a MIMO encoder and a precoder.

[0136] The memory 2005 is configured by a combination of volatile memory and non-volatile memory. The volatile memory is, for example, SRAM or DRAM, or a combination thereof. The non-volatile memory is, for example, MROM, EEPROM, flash memory, or a hard disk drive, or any combination thereof. The memory 2005 may include storage located remotely from the processor 2004. In this case, the processor 2004 may access the memory 2005 via the network interface 2003 or another I / O interface.

[0137] The memory 2005 may store one or more software modules (computer programs) 2006 containing instructions and data for processing by the RAN node 2. In some implementations, the processor 2004 may be configured to read and execute the software modules 2006 from the memory 2005 to perform the processing of the RAN node 2 described in one or more of the embodiments.

[0138] It should be noted that the control plane processing and operations performed by the RAN node 2 described in the above embodiment can be realized by elements other than the RF transceiver 2001 and the antenna array 2002, namely the processor 2004 and the memory 2005 storing the software module 2006.

[0139] As described with reference to Figures 19 and 20, each of the processors included in the UE 1 and the RAN node 2 according to the above-described embodiments may execute one or more programs including instructions for causing a computer to perform the algorithms described with reference to the drawings. The programs include instructions (or software code) that, when loaded into a computer, cause the computer to perform one or more functions described in the embodiments. The programs may be stored on a non-transitory computer-readable medium or a tangible storage medium. By way of example and not limitation, computer-readable media or tangible storage media include random-access memory (RAM), read-only memory (ROM), flash memory, solid-state drive (SSD) or other memory technology, CD-ROM, digital versatile disk (DVD), Blu-ray disc or other optical disk storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage device. The programs may also be transmitted on a transitory computer-readable medium or a communication medium. By way of example and not limitation, transitory computer-readable media or communication media include electrical, optical, acoustic, or other forms of propagated signals.

[0140] The above-described embodiments are merely examples of application of the technical ideas obtained by the inventors of the present invention. In other words, the technical ideas are not limited to the above-described embodiments, and various modifications are possible.

[0141] For example, some or all of the embodiments can be applied when the UE capability specifications themselves are significantly changed compared to those of E-UTRA and 5G, or when the protocol configuration (e.g., Layer 2 protocol stack) is changed.

[0142] For example, some or all of the above embodiments may also be described as, but are not limited to, the following appendices. Some or all of the elements (e.g., configurations and functions) described in appendices directed to devices (e.g., wireless terminals, RAN nodes) may naturally also be described as appendices directed to methods and programs. For example, some or all of the elements described in appendices 2-18, which are dependent on appendices 1-18, may also be described as appendices dependent on appendices 19 and 20, respectively, due to the same dependency relationship as appendices 2-18. Similarly, some or all of the elements described in appendices 22-33, which are dependent on appendices 22-33, may also be described as appendices dependent on appendices 34 and 35, respectively, due to the same dependency relationship as appendices 22-33. Some or all of the elements described in any appendice may be applicable to various hardware, software, recording means for recording software, systems, and methods.

[0143] (Supplementary Note 1) A wireless terminal comprising: means for informing a radio access network of an identification of a first terminal capability set associated with one or both of an intended use case among a plurality of predefined use cases and its own device type among a plurality of predefined device types, the first terminal capability set being one of a plurality of predefined terminal capability sets, each terminal capability set being predefined in association with one or both of at least one of the plurality of predefined use cases and at least one of the plurality of predefined device types, and each terminal capability set defining respective values ​​of a plurality of terminal capability parameters. (Supplementary Note 2) The wireless terminal of Supplementary Note 1, wherein the first terminal capability set is associated with both the intended use case and its own device type. (Supplementary Note 3) The wireless terminal of Supplementary Note 1, further comprising means for selecting the first terminal capability set from the plurality of predefined terminal capability sets based on one or both of the intended use case and the own device type. (Supplementary Note 4) The wireless terminal according to Supplementary Note 2, further comprising means for selecting the first terminal capability set from the plurality of predefined terminal capability sets based on the intended use case and based on the wireless terminal's own device type. (Supplementary Note 5) The wireless terminal according to Supplementary Note 3 or 4, wherein the selecting means is configured to select the first terminal capability set each time a wireless connection is set up, based on a use case intended at the time of setting up the wireless connection. (Supplementary Note 6) The wireless terminal according to any one of Supplements 1 to 5, wherein association of each terminal capability set with at least one use case and / or at least one device type is defined in a Third Generation Partnership Project (3GPP) specification. (Supplementary Note 7) The wireless terminal according to any one of Supplements 1 to 6, wherein at least one of a plurality of terminal capability parameters for which the first terminal capability set defines values ​​is not included in a plurality of terminal capability parameters for which a second terminal capability set different from the first terminal capability set defines values.(Supplementary Note 8) The wireless terminal according to any one of Supplements 1 to 7, wherein the plurality of predefined use cases include two or more of enhanced Mobile Broadband (eMBB), Ultra-Reliable and Low Latency Communications (URLLC), eXtended Reality (XR), Non-Terrestrial Networks (NTN), Internet of Things (IoT), Uncrewed Aerial Vehicles (UAV), and vehicle-to-everything (V2X). (Supplementary Note 9) The wireless terminal according to any one of Supplements 1 to 8, wherein the plurality of predefined device types include two or more of handheld device, robotics device, wearable device, sensor device, and automotive device. (Supplementary Note 10) The wireless terminal of any one of Supplements 1 to 9, wherein the plurality of terminal capability parameters include one or more mandatory features, one or more constraints or restrictions imposed on one or more mandatory features, one or more default radio settings, or any combination thereof. (Supplementary Note 11) The wireless terminal of any one of Supplements 1 to 10, wherein the signaling means is configured to signal an identification of the first terminal capability set to the radio access network by using a random access resource associated with the first terminal capability set. (Supplementary Note 12) The wireless terminal of any one of Supplements 1 to 11, wherein the signaling means is configured to signal an identification of the first terminal capability set to the radio access network by transmitting information identifying the first terminal capability set to the radio access network.(Supplementary Note 13) The wireless terminal according to Supplementary Note 12, wherein the means for notifying is configured to transmit the information using a Logical Channel ID (LCID) field of a Medium Access Control (MAC) subheader or using a Radio Resource Control (RRC) message. (Supplementary Note 14) The wireless terminal according to any one of Supplements 1 to 13, further comprising: means for receiving configuration information generated based on the first terminal capability set from the radio access network. (Supplementary Note 15) The wireless terminal according to any one of Supplements 1 to 13, further comprising: means for receiving configuration information from the radio access network, wherein meanings of the same bit sequence indicated by a predetermined field included in the configuration information differ between at least two terminal capability sets included in the plurality of predefined terminal capability sets. (Supplementary Note 16) The wireless terminal according to Supplementary Note 15, further comprising means for determining meanings of the same bit sequence based on the first terminal capability set. (Supplementary Note 17) The wireless terminal of any one of Supplements 1 to 16, further comprising means for receiving a support indication broadcasted in a cell, the support indication indicating one or more use cases supported in the cell, one or more device types supported in the cell, or both. (Supplementary Note 18) The wireless terminal of Supplementary Note 17, wherein the support indication further indicates one or more use cases supported in a neighboring cell, one or more device types supported in the neighboring cell, or both.(Supplementary Note 19) A method performed by a wireless terminal, comprising informing a radio access network of an identification of a first terminal capability set associated with one or both of an intended use case among a plurality of predefined use cases and its own device type among a plurality of predefined device types, wherein the first terminal capability set is one of a plurality of predefined terminal capability sets, each terminal capability set being predefined in association with one or both of at least one of the plurality of predefined use cases and at least one of the plurality of predefined device types, and each terminal capability set defining respective values ​​of a plurality of terminal capability parameters. (Supplementary Note 20) A program that, when loaded into a computer, causes a computer to perform a method for a wireless terminal, comprising informing a radio access network of an identification of a first terminal capability set associated with one or both of an intended use case among a plurality of predefined use cases and the wireless terminal's own device type among a plurality of predefined device types, wherein the first terminal capability set is one of a plurality of predefined terminal capability sets, each terminal capability set being predefined in association with one or both of at least one of the plurality of predefined use cases and at least one of the plurality of predefined device types, and each terminal capability set defining respective values ​​of a plurality of terminal capability parameters. (Supplementary Note 21) A radio access network node comprising: means for receiving from a wireless terminal an identification of a first terminal capability set associated with one or both of an intended use case of a plurality of predefined use cases and a device type of the wireless terminal of a plurality of predefined device types; the first terminal capability set being one of a plurality of predefined terminal capability sets; each terminal capability set being predefined in association with one or both of at least one of the plurality of predefined use cases and at least one of the plurality of predefined device types; and each terminal capability set defining respective values ​​of a plurality of terminal capability parameters.(Supplementary Note 22) The radio access network node according to Supplementary Note 21, wherein the first terminal capability set is associated with both the intended use case and a device type of the radio terminal. (Supplementary Note 23) The radio access network node according to Supplementary Note 21 or 22, wherein the receiving means is configured to receive, at each setup of a radio connection, the first terminal capability set selected by the radio terminal based on a use case intended at setup of the radio connection. (Supplementary Note 24) The radio access network node according to any one of Supplements 21 to 23, wherein the association of each terminal capability set with at least one use case and / or at least one device type is defined in a Third Generation Partnership Project (3GPP) specification. (Supplementary Note 25) The radio access network node according to any one of Supplements 21 to 24, wherein at least one of a plurality of terminal capability parameters for which the first terminal capability set defines values ​​is not included in a plurality of terminal capability parameters for which a second terminal capability set different from the first terminal capability set defines values. (Supplementary Note 26) The radio access network node according to any one of Supplementary Notes 21 to 25, wherein the plurality of predefined use cases include two or more of enhanced Mobile Broadband (eMBB), Ultra-Reliable and Low Latency Communications (URLLC), eXtended Reality (XR), Non-Terrestrial Networks (NTN), Internet of Things (IoT), Uncrewed Aerial Vehicles (UAV), and vehicle-to-everything (V2X). (Supplementary Note 27) The radio access network node according to any one of Supplementary Notes 21 to 26, wherein the plurality of predefined device types include two or more of handheld device, robotics device, wearable device, sensor device, and automotive device.(Supplementary Note 28) The radio access network node according to any one of Supplements 21 to 27, wherein the plurality of terminal capability parameters include one or more mandatory features, one or more constraints or restrictions imposed on one or more mandatory features, one or more default radio settings, or any combination thereof. (Supplementary Note 29) The radio access network node according to any one of Supplements 21 to 28, further comprising: means for transmitting configuration information generated based on the first terminal capability set to the radio terminal. (Supplementary Note 30) The radio access network node according to any one of Supplements 21 to 28, further comprising: means for transmitting configuration information to the radio terminal, wherein meanings of the same bit sequence indicated by a predetermined field included in the configuration information differ between at least two terminal capability sets included in the plurality of predefined terminal capability sets. (Supplementary Note 31) The radio access network node according to any one of Supplements 21 to 30, further comprising means for broadcasting a support indication in a cell, the support indication indicating one or more use cases supported in the cell, one or more device types supported in the cell, one or more terminal capability sets supported in the cell, or any combination thereof. (Supplementary Note 32) The radio access network node according to Supplementary Note 31, the support indication further indicating one or more use cases supported in a neighbouring cell, one or more device types supported in the neighbouring cell, one or more terminal capability sets supported in the neighbouring cell, or any combination thereof. (Supplementary Note 33) The radio access network node according to Supplementary Note 31 or 32, further comprising means for notifying other radio access network nodes of one or more use cases supported in the cell, one or more device types supported in the cell, one or more terminal capability sets supported in the cell, or any combination thereof.(Supplementary Note 34) A method performed by a radio access network node, comprising receiving from a wireless terminal an identification of a first terminal capability set associated with one or both of an intended use case from a plurality of predefined use cases and a device type of the wireless terminal from a plurality of predefined device types, wherein the first terminal capability set is one of a plurality of predefined terminal capability sets, each terminal capability set being predefined in association with one or both of at least one of the plurality of predefined use cases and at least one of the plurality of predefined device types, and each terminal capability set defining respective values ​​of a plurality of terminal capability parameters. (Supplementary Note 35) A program that, when loaded into a computer, causes a computer to perform a method for a radio access network node, comprising receiving from a wireless terminal an identification of a first terminal capability set associated with one or both of an intended use case among a plurality of predefined use cases and a device type of the wireless terminal among a plurality of predefined device types, wherein the first terminal capability set is one of a plurality of predefined terminal capability sets, each terminal capability set being predefined in association with one or both of at least one of the plurality of predefined use cases and at least one of the plurality of predefined device types, and each terminal capability set defining respective values ​​of a plurality of terminal capability parameters.

[0144] This application claims priority based on Japanese Patent Application No. 2024-133367, filed August 8, 2024, the disclosure of which is incorporated herein in its entirety by reference.

[0145] 1 UE 2, 2A, 2B RAN node 1903 Baseband processor 1904 Application processor 1906 Memory 1907 Modules 2004 Processor 2005 Memory 2006 Modules

Claims

1. A wireless terminal comprising: means for signaling to a radio access network the identity of a first terminal capability set associated with one or both of an intended use case among a plurality of predefined use cases and its own device type among a plurality of predefined device types; the first terminal capability set being one of a plurality of predefined terminal capability sets, each terminal capability set being predefined in association with one or both of at least one of the plurality of predefined use cases and at least one of the plurality of predefined device types, and each terminal capability set defining respective values ​​for a plurality of terminal capability parameters.

2. The wireless terminal of claim 1, wherein the first terminal capability set is associated with both the intended use case and the wireless terminal's own device type.

3. The wireless terminal of claim 1, further comprising: means for selecting the first terminal capability set from the plurality of predefined terminal capability sets based on one or both of the intended use case and the wireless terminal's device type.

4. The wireless terminal of claim 2, further comprising: means for selecting the first terminal capability set from the plurality of predefined terminal capability sets based on the intended use case and based on the wireless terminal's device type.

5. The wireless terminal according to claim 3 or 4, wherein the selecting means is configured to select the first terminal capability set each time a wireless connection is set up based on a use case intended when the wireless connection is set up.

6. The wireless terminal of any one of claims 1 to 5, wherein the association of each terminal capability set with at least one use case and / or at least one device type is defined in a Third Generation Partnership Project (3GPP) specification.

7. A wireless terminal according to any one of claims 1 to 6, wherein at least one of a plurality of terminal capability parameters whose values ​​are defined by the first terminal capability set is not included in a plurality of terminal capability parameters whose values ​​are defined by a second terminal capability set different from the first terminal capability set.

8. The wireless terminal according to any one of claims 1 to 7, wherein the plurality of predefined use cases include two or more of enhanced Mobile Broadband (eMBB), Ultra-Reliable and Low Latency Communications (URLLC), eXtended Reality (XR), Non-Terrestrial Networks (NTN), Internet of Things (IoT), Uncrewed Aerial Vehicles (UAV), and vehicle-to-everything (V2X).

9. The wireless terminal according to any one of claims 1 to 8, wherein the plurality of predefined device types includes two or more of a handheld device, a robotics device, a wearable device, a sensor device, and an automotive device.

10. A wireless terminal according to any one of claims 1 to 9, wherein the plurality of terminal capability parameters include one or more mandatory features, one or more constraints or restrictions imposed on one or more mandatory features, one or more default radio settings, or any combination thereof.

11. A wireless terminal according to any one of claims 1 to 10, wherein the signalling means is configured to signal an identity of the first terminal capability set to the radio access network by using a random access resource associated with the first terminal capability set.

12. A wireless terminal according to any one of claims 1 to 11, wherein the informing means is configured to inform the radio access network of the identity of the first terminal capability set by transmitting information identifying the first terminal capability set to the radio access network.

13. The wireless terminal of claim 12, wherein the means for informing is configured to transmit the information using a Logical Channel ID (LCID) field of a Medium Access Control (MAC) subheader or using a Radio Resource Control (RRC) message.

14. A wireless terminal according to any one of claims 1 to 13, further comprising means for receiving configuration information generated based on said first terminal capability set from said radio access network.

15. A wireless terminal according to any one of claims 1 to 13, further comprising means for receiving configuration information from the radio access network, wherein the meaning of the same bit string indicated by a predetermined field included in the configuration information differs between at least two terminal capability sets included in the plurality of predefined terminal capability sets.

16. The wireless terminal of claim 15, further comprising: means for determining the meaning of said same bit string based on said first terminal capability set.

17. A wireless terminal according to any one of claims 1 to 16, further comprising means for receiving a support indication broadcast in a cell, the support indication indicating one or more use cases supported in the cell, one or more device types supported in the cell, or both.

18. The wireless terminal of claim 17, wherein the support indication further indicates one or more use cases supported in the neighboring cell, one or more device types supported in the neighboring cell, or both.

19. A method performed by a wireless terminal, comprising: informing a radio access network of an identification of a first terminal capability set associated with one or both of an intended use case among a plurality of predefined use cases and its own device type among a plurality of predefined device types, wherein the first terminal capability set is one of a plurality of predefined terminal capability sets, each terminal capability set being predefined in association with one or both of at least one of the plurality of predefined use cases and at least one of the plurality of predefined device types, and each terminal capability set defining respective values ​​for a plurality of terminal capability parameters.

20. A program that, when loaded into a computer, causes a computer to perform a method for a wireless terminal, comprising informing a radio access network of the identity of a first terminal capability set associated with one or both of an intended use case among a plurality of predefined use cases and the wireless terminal's own device type among a plurality of predefined device types, wherein the first terminal capability set is one of a plurality of predefined terminal capability sets, each terminal capability set being predefined in association with one or both of at least one of the plurality of predefined use cases and at least one of the plurality of predefined device types, and each terminal capability set defining respective values ​​for a plurality of terminal capability parameters.

21. A radio access network node comprising: means for receiving from a wireless terminal an identification of a first terminal capability set associated with one or both of an intended use case from a plurality of predefined use cases and a device type of the wireless terminal from a plurality of predefined device types, wherein the first terminal capability set is one of a plurality of predefined terminal capability sets, each terminal capability set being predefined in association with one or both of at least one of the plurality of predefined use cases and at least one of the plurality of predefined device types, and each terminal capability set defining respective values ​​for a plurality of terminal capability parameters.

22. The radio access network node of claim 21, wherein the first terminal capability set is associated with both the intended use case and a device type of the wireless terminal.

23. A radio access network node according to claim 21 or 22, wherein the receiving means is configured to receive, at each setup of a radio connection, the first terminal capability set selected by the radio terminal based on a use case intended at the setup of the radio connection.

24. A radio access network node according to any one of claims 21 to 23, wherein the association of each terminal capability set with at least one use case and / or at least one device type is defined in a Third Generation Partnership Project (3GPP) specification.

25. A radio access network node according to any one of claims 21 to 24, wherein at least one of a plurality of terminal capability parameters for which the first terminal capability set defines values ​​is not included in a plurality of terminal capability parameters for which a second terminal capability set different from the first terminal capability set defines values.

26. The radio access network node of any one of claims 21 to 25, wherein the plurality of predefined use cases comprises two or more of enhanced Mobile Broadband (eMBB), Ultra-Reliable and Low Latency Communications (URLLC), eXtended Reality (XR), Non-Terrestrial Networks (NTN), Internet of Things (IoT), Uncrewed Aerial Vehicles (UAV), and vehicle-to-everything (V2X).

27. A radio access network node according to any one of claims 21 to 26, wherein the plurality of predefined device types includes two or more of a handheld device, a robotics device, a wearable device, a sensor device, and an automotive device.

28. A radio access network node according to any one of claims 21 to 27, wherein the plurality of terminal capability parameters comprise one or more mandatory features, one or more constraints or restrictions imposed on one or more mandatory features, one or more default radio settings, or any combination thereof.

29. A radio access network node according to any one of claims 21 to 28, further comprising means for transmitting configuration information generated based on said first terminal capability set to said radio terminal.

30. A radio access network node according to any one of claims 21 to 28, further comprising means for transmitting configuration information to the radio terminal, wherein the meaning of the same bit string indicated by a predetermined field included in the configuration information differs between at least two terminal capability sets included in the plurality of predefined terminal capability sets.

31. A radio access network node according to any one of claims 21 to 30, further comprising means for broadcasting a support indication in a cell, the support indication indicating one or more use cases supported in the cell, one or more device types supported in the cell, one or more terminal capability sets supported in the cell, or any combination thereof.

32. The radio access network node of claim 31 , wherein the support indication further indicates one or more use cases supported in the neighboring cell, one or more device types supported in the neighboring cell, one or more terminal capability sets supported in the neighboring cell, or any combination thereof.

33. A radio access network node according to claim 31 or 32, further comprising means for notifying other radio access network nodes of one or more use cases supported in the cell, one or more device types supported in the cell, one or more terminal capability sets supported in the cell, or any combination thereof.

34. A method performed by a radio access network node, comprising receiving from a wireless terminal an identification of a first terminal capability set associated with one or both of an intended use case from a plurality of predefined use cases and a device type of the wireless terminal from a plurality of predefined device types, wherein the first terminal capability set is one of a plurality of predefined terminal capability sets, each terminal capability set being predefined in association with at least one of the plurality of predefined use cases and at least one of the plurality of predefined device types, and each terminal capability set defining respective values ​​for a plurality of terminal capability parameters.

35. A program that, when loaded onto a computer, causes a computer to perform a method for a radio access network node, comprising receiving from a wireless terminal an identification of a first terminal capability set associated with one or both of an intended use case from a plurality of predefined use cases and a device type of the wireless terminal from a plurality of predefined device types, wherein the first terminal capability set is one of a plurality of predefined terminal capability sets, each terminal capability set being predefined in association with one or both of at least one of the plurality of predefined use cases and at least one of the plurality of predefined device types, and each terminal capability set defining respective values ​​for a plurality of terminal capability parameters.

Citation Information

Patent Citations

  • Communication method, device and system

    CN114125877A

  • Information processing method and apparatus, device, and storage medium

    JP2023512969A

  • Distributed unit (DU) and method therefor

    JP2024036676A

  • Cell reselection method, terminal and readable storage medium

    JP2024508179A