Method and apparatus for handling temporary UE capability change in MUSIM operation in wireless communication system
By introducing temporary capability restrictions and waiting timer processing for network-notified UEs in wireless communication systems, the problems of high signaling overhead and delay for UE capability changes in MUSIM operations are solved, achieving more efficient UE capability management and system stability.
Patent Information
- Application Number
- CN202480012524.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2023-02-16
- Filing Date
- 2024-02-13
- Publication Date
- 2025-09-12
AI Technical Summary
Existing 5G mobile communication systems suffer from improper network control, high signaling overhead, and high latency when handling temporary user equipment (UE) capability changes in Multiple User Identity Module (MUSIM) operations, especially when the UE needs to support multiple SIM cards simultaneously.
By introducing the network notification in the wireless communication system to the UE whether to allow the transmission of temporary capability restrictions during radio resource control (RRC) establishment and resumption, and handling the waiting timer during MUSIM operation, the reasonable allocation of UE capabilities and the dynamic adjustment of the network are ensured, especially when the target Node B does not support MUSIM dual-active operation, to achieve the switching and update of UE capabilities.
Effectively manage UE capabilities, reduce signaling overhead, lower latency, improve system efficiency, and ensure stable UE operation under MUSIM operation.
Smart Images

Figure CN120642376A_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to wireless communication networks and, more particularly, to a method and wireless network for handling temporary user equipment (UE) capability changes for Multiple User Identity Module (MUSIM) operations in a wireless network. Background Art
[0002] Fifth-generation (5G) mobile communication technology defines a wide frequency band, enabling high transmission rates and new services, and can be implemented not only in "sub-6 GHz" frequency bands such as 3.5 GHz, but also in "above 6 GHz" frequency bands, known as millimeter waves (mmWave), including 28 GHz and 39 GHz. Furthermore, consideration is being given to implementing sixth-generation (6G) mobile communication technology (referred to as a "super 5G system") in terahertz (THz) frequency bands (e.g., the 95 GHz to 3 THz band) in order to achieve transmission rates fifty times faster than 5G mobile communication technology and ultra-low latency one-tenth that of 5G mobile communication technology.
[0003] At the beginning of the development of 5G mobile communication technology, in order to support services and meet performance requirements related to enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (URLLC), and massive machine-type communications (mMTC), standardization has been carried out on beamforming and massive multiple-input multiple-output (MIMO) for mitigating radio wave path loss and increasing radio wave transmission range in mmWave, parameter sets supporting dynamic operation for efficient utilization of mmWave resources and time slot formats (e.g., operation of multiple subcarrier spacings), initial access technology for supporting multi-beam transmission and broadband, definition and operation of bandwidth parts (BWPs), new channel coding methods such as low-density parity-check (LDPC) codes for large-scale data transmission and polar codes for highly reliable transmission of control information, L2 preprocessing, and network slicing for providing dedicated networks dedicated to specific services.
[0004] Currently, in view of the services to be supported by 5G mobile communication technology, there are ongoing discussions on improvements and performance enhancements to initial 5G mobile communication technology, and there has been standardization of physical layers on technologies such as Vehicle-to-Everything (V2X) for assisting autonomous vehicles in making driving decisions based on information about the position and status of vehicles transmitted by the vehicles and for enhancing user convenience, New Radio Unlicensed (NR-U) for system operation in compliance with various regulatory requirements in unlicensed bands, New Radio (NR) User Equipment (UE) power saving, Non-Terrestrial Network (NTN) as UE-satellite direct communication for providing coverage in areas where communication with terrestrial networks is unavailable, and positioning.
[0005] In addition, there is ongoing standardization of air interface architecture / protocols, such as the Industrial Internet of Things (IIoT) for supporting new services through interworking and integration with other industries, Integrated Access and Backhaul (IAB) for providing nodes for network service area expansion by supporting wireless backhaul links and access links in an integrated manner, mobility enhancements including conditional handover and dual-active protocol stack (DAPS) handover, and two-step random access (NR's two-step random access channel (RACH)) for simplifying the random access procedure. There is also ongoing standardization of system architecture / services for 5G baseline architecture (e.g., service-based architecture or service-based interface) for combining network function virtualization (NFV) and software-defined networking (SDN) technologies, and mobile edge computing (MEC) for receiving services based on UE location.
[0006] With the commercialization of 5G mobile communication systems, the already exponentially growing number of connected devices will be connected to the communication network, and accordingly, it is expected that enhanced functionality and performance of 5G mobile communication systems and the integrated operation of connected devices will become necessary. To this end, new research related to extended reality (XR) is being planned to effectively support augmented reality (AR), virtual reality (VR), mixed reality (MR), etc., and to improve 5G performance and reduce complexity by utilizing artificial intelligence (AI) and machine learning (ML), AI service support, metaverse service support, and drone communications.
[0007] Furthermore, such development of 5G mobile communication systems will serve as a foundation for developing not only new waveforms for providing coverage in the terahertz band for 6G mobile communication technology, multi-antenna transmission technologies such as full-dimensional MIMO (FD-MIMO), array antennas, and massive antennas, metamaterial-based lenses and antennas for improving coverage of terahertz band signals, high-dimensional spatial multiplexing technologies using orbital angular momentum (OAM), and reconfigurable smart surfaces (RIS), but also full-duplex technologies for improving the frequency efficiency of 6G mobile communication technology and improving system networks, AI-based communication technologies for achieving system optimization from the design stage using satellites and artificial intelligence (AI) and internalizing end-to-end AI support functions, and next-generation distributed computing technologies for implementing services at a level of complexity that exceeds the limits of UE operating capabilities by utilizing ultra-high-performance communication and computing resources.
[0008] The above information is presented as background information only to assist with an understanding of the present disclosure. No determination has been made, and no assertion is made, as to whether any of the above might be applicable as prior art with respect to the present disclosure. Summary of the Invention
[0009] Solution to the problem
[0010] Aspects of the present disclosure are to address at least the above-mentioned problems and / or disadvantages and to provide at least the advantages described below. Accordingly, one aspect of the present disclosure is to provide a method and a wireless network for handling temporary UE capability change for MUSIM operation in a wireless network.
[0011] An additional aspect of the present disclosure is handling temporary capability limitations of dual active MUSIM devices.
[0012] An additional aspect of the present disclosure is to handle wait timers for handling temporary capacity limitations.
[0013] Additional aspects of the present disclosure disclose that the network notifies the UE whether the network is allowed to transmit temporary capability restrictions during radio resource control (RRC) establishment and RRC resumption.
[0014] An additional aspect of the present disclosure is to handle the scenario where the UE initiates the RRC establishment procedure / RRC recovery procedure when the network does not support MUSIM dual-active operation.
[0015] An additional aspect of the present disclosure is to perform a handover when it has received a MUSIM capability restriction, particularly when the target next generation Node B (gNB) does not support MUSIM dual active operation.
[0016] An additional aspect of the present disclosure is to disclose various operations at NWK-A for updating temporary capabilities due to MUSIM operation between different nodes in NWK-A and between NWK-A and UE-A, where, in the case of a MUSIM UE having two USIMs (i.e., two UEs in the same MUSIM device), UE-A (USIM-A) is in an RRC-CONNECTED state with NWK-A, and UE-B (USIM-B) is in an RRC_CONNECTED state with NWK-B or is moving to RRC_CONNECTED.
[0017] Additional aspects will be set forth in part in the description which follows and, in part, will be obvious from the description, or may be learned by practice of the presented embodiments.
[0018] According to one aspect of the present disclosure, a UE in a wireless communication system is provided. The UE includes a transceiver, a memory storing one or more computer programs, and one or more processors communicatively coupled to the transceiver and the memory, wherein the one or more computer programs include computer-executable instructions that, when executed by the one or more processors, cause the UE to receive a system information block (SIB) including a first indication regarding whether transmission of a second indication is permitted from a base station, identify that the UE capability is limited for a Multiple Universal Subscriber Identity Module (MUSIM) operation, and transmit a radio resource control (RRC) message to the base station including a second indication indicating temporary capability limitation of the UE due to the MUSIM operation.
[0019] According to another aspect of the present disclosure, a base station (BS) in a wireless communication system is provided. The BS includes a transceiver, a memory storing one or more computer programs, and one or more processors communicatively coupled to the transceiver and the memory, wherein the one or more computer programs include computer-executable instructions that, when executed by the one or more processors, cause the BS to transmit a system information block (SIB) including a first indication as to whether reception of a second indication is permitted to a user equipment (UE), and receive a radio resource control (RRC) message from the UE including a second indication indicating temporary capability restriction of the UE due to a multi-universal subscriber identity module (MUSIM) operation.
[0020] According to one aspect of the present disclosure, a method performed by a UE in a wireless communication system is provided. The method includes receiving a system information block (SIB) including a first indication regarding whether to allow transmission of a second indication from a base station, identifying that the UE capability is limited for a Multiple Universal Subscriber Identity Module (MUSIM) operation, and transmitting a radio resource control (RRC) message including a second indication indicating temporary capability limitation of the UE due to the MUSIM operation to the base station.
[0021] According to one aspect of the present disclosure, a method performed by a base station in a wireless communication system is provided. The method includes transmitting a system information block (SIB) including a first indication regarding whether reception of a second indication is permitted to a user equipment (UE), and receiving a radio resource control (RRC) message including a second indication indicating temporary capability restriction of the UE due to a multi-universal subscriber identity module (MUSIM) operation from the UE.
[0022] According to one aspect of the present disclosure, one or more non-transitory computer-readable storage media storing one or more computer programs including computer-executable instructions that, when executed by one or more processors of a user equipment (UE), cause the UE to perform operations. The operations include receiving a system information block (SIB) from a base station including a first indication as to whether transmission of a second indication is permitted, identifying that UE capabilities are limited for Multi-Universal Subscriber Identity Module (MUSIM) operation, and transmitting a radio resource control (RRC) message to the base station including a second indication indicating temporary capability limitation of the UE due to MUSIM operation.
[0023] According to one aspect of the present disclosure, one or more non-transitory computer-readable storage media storing one or more computer programs including computer-executable instructions that, when executed by one or more processors of a base station (BS), cause the BS to perform operations. The operations include sending a system information block (SIB) including a first indication of whether reception of a second indication is permitted to a user equipment (UE), and receiving a radio resource control (RRC) message from the UE including a second indication indicating temporary capability restriction of the UE due to a multi-universal subscriber identity module (MUSIM) operation.
[0024] Other aspects, advantages, and salient features of the present disclosure will become apparent to those skilled in the art from the following detailed description, which, taken in conjunction with the accompanying drawings, discloses various embodiments of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS
[0025] The above and other aspects, features and advantages of certain embodiments of the present disclosure will become more apparent through the following description in conjunction with the accompanying drawings, in which:
[0026] Figure 1A is a block diagram illustrating a wireless network for handling temporary UE capability changes for MUSIM operations according to an embodiment of the present disclosure;
[0027] Figure 1B is a block diagram illustrating a wireless network for handling temporary UE capability changes for MUSIM operations according to an embodiment of the present disclosure;
[0028] Figure 2 shows various hardware components of a UE according to an embodiment of the present disclosure;
[0029] Figure 3 illustrates various hardware components of a source network entity according to an embodiment of the present disclosure;
[0030] Figure 4is a flow chart illustrating a method implemented by a UE for handling a temporary UE capability change of a MUSIM UE in a wireless network according to an embodiment of the present disclosure;
[0031] Figure 5 is a flow chart illustrating a method implemented by a wireless network for handling a temporary UE capability change of a MUSIM UE in a wireless network according to an embodiment of the present disclosure;
[0032] Figure 6 is a flow chart illustrating a method implemented by a source network entity for handling a temporary UE capability change of a MUSIM UE in a wireless network according to an embodiment of the present disclosure;
[0033] Figure 7 A flow chart illustrating a source gNB notifying a target gNB of UE capabilities during handover based on temporary capabilities according to an embodiment of the present disclosure is shown;
[0034] Figure 8 A flowchart illustrating a UE processing capability change in RRC_IDLE mode according to an embodiment of the present disclosure is shown;
[0035] Figure 9 A flowchart of an RRC configuration process with temporary capabilities according to an embodiment of the present disclosure is shown;
[0036] Figure 10 is a flow chart depicting a process for handling concurrency for handover and temporary capability change according to an embodiment of the present disclosure;
[0037] Figure 11 and Figure 12 is a flow chart depicting a process for handling concurrency of DC operations and temporary capability changes according to various embodiments of the present disclosure;
[0038] Figure 13 is a flowchart depicting a process of handling a temporary capability change from UE-A that is not accepted by NWK-A according to an embodiment of the present disclosure;
[0039] Figure 14 A block diagram illustrating the structure of a UE according to an embodiment of the present disclosure is shown; and
[0040] Figure 15 A block diagram illustrating the structure of a base station according to an embodiment of the present disclosure is shown;
[0041] Throughout the drawings, it should be noted that like reference numbers are used to depict the same or similar elements, features, and structures. DETAILED DESCRIPTION
[0042] The following description, with reference to the accompanying drawings, is provided to facilitate a fuller understanding of the various embodiments of the present disclosure as defined by the claims and their equivalents. It includes various specific details to aid understanding, but these details are to be considered merely as exemplary. Therefore, those skilled in the art will recognize that various changes and modifications may be made to the various embodiments described herein without departing from the scope and spirit of the present disclosure. Furthermore, descriptions of well-known functions and structures may be omitted for clarity and conciseness.
[0043] The terms and words used in the following description and claims are not limited to the bibliographical meanings, but are merely used by the inventor to enable a clear and consistent understanding of the present disclosure. Therefore, it will be apparent to those skilled in the art that the following description of various embodiments of the present disclosure is provided for illustration purposes only and not for the purpose of limiting the present disclosure as defined by the appended claims and their equivalents.
[0044] It should be understood that the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to "a component surface" includes reference to one or more of such surfaces.
[0045] Furthermore, the various embodiments described herein are not necessarily mutually exclusive, as some embodiments can be combined with one or more other embodiments to form new embodiments.
[0046] As used herein, the term "or" refers to a non-exclusive or unless otherwise indicated. The examples used herein are intended only to facilitate understanding of how the embodiments herein may be practiced and to further enable those skilled in the art to practice the embodiments herein. Therefore, the examples should not be construed as limiting the scope of the embodiments herein.
[0047] For purposes of interpreting this specification, the definitions (as defined herein) will apply, and where appropriate, terms used in the singular will also include the plural, and vice versa. It should be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. Unless otherwise indicated, the terms "including," "having," and "comprising" are to be interpreted as open-ended terms.
[0048] The words / phrases "exemplary," "example," "illustrative," "in an example," "etc.," "for example," and "i.e." are used herein merely to mean "serving as an example, instance, or illustration." Any embodiment or implementation of the subject matter described herein using the words / phrases "exemplary," "example," "illustrative," "in an example," "etc.," "for example," and "i.e." are not necessarily to be construed as preferred or advantageous over other embodiments.
[0049] The embodiments herein may be described and illustrated in terms of blocks that perform one or more of the described functions. These blocks, which may be referred to herein as managers, units, modules, hardware components, etc., are physically implemented by analog and / or digital circuitry (such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hard-wired circuitry, etc.) and may optionally be driven by firmware. The circuitry may, for example, be embodied in one or more semiconductor chips or on a substrate support such as a printed circuit board. The circuitry comprising a block may be implemented by dedicated hardware, or by a processor (e.g., one or more programmed microprocessors and associated circuitry), or by a combination of dedicated hardware that performs some of the block's functions and a processor that performs other functions of the block. Each block of an embodiment may be physically separated into two or more interacting and discrete blocks without departing from the scope of the present disclosure. Similarly, the blocks of an embodiment may be physically combined into more complex blocks without departing from the scope of the present disclosure.
[0050] It should be noted that the elements in the accompanying drawings are shown for purposes of this description and ease of understanding, and may not necessarily be drawn to scale. For example, a flow chart / sequence diagram illustrates the method in terms of steps required to understand various aspects of the embodiments disclosed herein. Furthermore, with respect to the construction of an apparatus, one or more components of the apparatus may have been represented in the accompanying drawings by conventional symbols, and the accompanying drawings may only show those specific details relevant to understanding the embodiments so as not to obscure the drawings with details that would be readily apparent to one of ordinary skill in the art having the benefit of the description herein. Furthermore, with respect to a system, one or more components / modules comprising the system may have been represented in the accompanying drawings by conventional symbols, and the accompanying drawings may only show those specific details relevant to understanding the embodiments so as not to obscure the drawings with details that would be readily apparent to one of ordinary skill in the art having the benefit of the description herein.
[0051] The accompanying drawings are used to facilitate easy understanding of various technical features, and it should be understood that the embodiments presented herein are not limited by the accompanying drawings. Therefore, the present disclosure should be interpreted as extending to any modifications, equivalents, and alternatives other than those specifically set forth in the accompanying drawings and corresponding descriptions. The use of words such as first, second, and third to describe components / elements / steps is for the purpose of this description and should not be interpreted as sequential ordering / placement / appearance unless otherwise specified.
[0052] Generally speaking, multi-SIM (MUSIM) devices host more than one Subscriber Identity Module (SIM) and are capable of connecting to two or more different networks (NWs) to utilize different data plans. These devices offer features such as home and office user profiles, increased connectivity and reliability through multiple connections, and more. To save costs, the radio frequency (RF) circuitry used by the UE is common to multiple SIMs. This means that multiple SIMs must arbitrate and share common RF resources to perform their activities and / or utilize services. Effectively, in Release 17 of the 3rd Generation Partnership Project (3GPP) specifications, only one SIM and its associated protocol stack can be serviced. Meanwhile, all other SIMs and their associated protocol stacks must wait for RF resources to become available. One or more of the multiple SIMs may participate in paging, system information block (SIB) acquisition, measurements, data or voice calls, Multimedia Broadcast Multicast Service (MBMS), emergency calls, access stratum (AS) signaling, non-access stratum (NAS) signaling, and more.
[0053] MUSIM UEs operated without network control by creating arbitrary gaps until the 3rd Generation Partnership Project (3GPP) decided to introduce support for MUSIM device operation in Release 17. Starting in Release 17, the connected USIM in a MUSIM device (i.e., the USIM in the context of this patent disclosure means the radio protocol stack associated with the UE) can notify the connected mode network of a network switch for multi-SIM operation. Two types of network switches are supported. In one type, the connected USIM leaves the connected network and completely switches to the other USIM, i.e., the other USIM becomes connected. In the other type, the connected USIM requests a gap from its network for MUSIM operations, such as listening for paging or performing measurements on an idle USIM.
[0054] In Release 17, MUSIM UEs use the Radio Resource Control (RRC) UE Assistance Information (UAI) procedure to request a gap or notify a leave. The network (e.g., gNB) uses the "otherConfig" field in the RRC message to configure whether the UE can provide assistance information for MUSIM gaps or MUSIM leaves. The "Musim-GapAssistanceConfig" field in the "otherConfig" field informs the UE whether it can provide MUSIM assistance information for gap provision. In Release 17, MUSIM operation only supports per-UE gaps.
[0055] The following information is provided to provide clarity with respect to the present disclosure.
[0056] UE Capabilities: In technologies like fifth-generation (5G) New Radio (NR), different UEs may have varying hardware and software capabilities. Capabilities that vary across devices can include hardware capabilities, including RF capabilities (such as supported frequency bands or band combinations), processing capabilities (e.g., baseband computing capabilities), software capabilities (such as support for various features), Layer 1 capabilities, Layer 2 capabilities, and Layer 3 capabilities. Typically, a UE reports its UE radio access capabilities, which are static, at least when the network requests capabilities. To limit signaling overhead, a gNB (e.g., a 5G NR base station) can request that the UE provide NR capabilities for a restricted set of frequency bands. In response, if the corresponding UE capabilities are the same, the UE may skip a subset of the requested frequency band combinations. If supported by the UE and the network, the UE may provide an identifier (ID) in non-access stratum (NAS) signaling that indicates its radio capabilities for one or more RATs to reduce signaling overhead. The ID may be assigned by the manufacturer or the serving public land mobile network (PLMN). Manufacturer-assigned IDs correspond to a pre-provisioned capability set. In the case of PLMN-assigned IDs, the assignment occurs in NAS signaling. The detailed list of UE capabilities exchanged based on the above method is specified in the 3GPP technical specifications (such as TS 38.306).
[0057] The 5G gNB provides various configurations / features to the UE through RRC messages (such as RRC reconfiguration or RRC recovery) based on the reported UE capabilities.
[0058] RRC states: In NR, RRC can be in one of three states: RRC_IDLE, RRC_INACTIVE, or RRC_CONNECTED. In an RRC_CONNECTED state, the UE is CM-CONNECTED (i.e., connected to the 5G core network) and can conduct unicast and multicast / broadcast services with the network. The network stores the UE AS context, is aware of the UE at the cell level, and controls UE mobility. The UE can perform measurements and report to the network, providing channel quality and feedback information.
[0059] RRC_INACTIVE is a state in which the UE remains in CM-CONNECTED and can move within the area configured by the Next Generation Radio Access Network (NG-RAN) (a 5G RAN consisting of gNBs) without notifying the NG-RAN. In RRC_INACTIVE, the last serving gNB node maintains the UE context and the UE's associated NG connection (i.e., connection to the core network). Because the RRC configuration and connection to the core network remain in RRC_INACTIVE, the UE can immediately transition to the RRC_CONNECTED state and perform data transfer with the core network / applications. The UE initiates the transition from RRC_INACTIVE to RRC_CONNECTED by transmitting an RRC RESUME REQUEST.
[0060] In RRC_IDLE, the UE or gNB does not store any access stratum (AS) context. The UE is in CM_IDLE (no connection to the core network). The UE establishes a new connection by transmitting an RRC SETUP REQUEST message, and the gNB transmits an RRC SETUP message to transition to RRC CONNECTED. The UE and the NW (both the radio access network (RAN) and the core network) exchange messages to transition the UE to CM_CONNECTED. A UE in RRC_CONNECTED can communicate power headroom to the network in accordance with TS 38.321 and other relevant 3GPP specifications. This patent disclosure considers TS 38.321 v17.3.0 as relevant background.
[0061] Carrier Aggregation: In Carrier Aggregation (CA), two or more Component Carriers (CCs) are aggregated. A UE can receive or transmit simultaneously on one or more CCs depending on its capabilities: CA is supported for both contiguous and non-contiguous CCs. When CA is deployed, either the frame timing and system frame number (SFN) are aligned across the cells that can be aggregated (synchronous CA), or an offset of a multiple of the timeslot between the Pcell / PSCell and the Scell is configured to the UE (asynchronous CA). A UE in inactive mode can store the CA configuration. In CA, the Pcell or primary cell is the cell used for initial access, while the other cells are called Scells or secondary cells.
[0062] Multi-radio dual connectivity: 3gpp specifies dual connectivity or more technically multi-radio dual connectivity in specifications such as TS 37.340. An overview of the details of dual connectivity is given below.
[0063] NG-RAN supports Multi-Radio Dual Connectivity (MR-DC) operation, whereby a user equipment (UE) in RRC_CONNECTED is configured to utilize radio resources provided by two different schedulers located in two different NG-RAN nodes connected via a non-ideal backhaul. One scheduler provides NR (New Radio) access, and the other provides Evolved UMTS Terrestrial Radio Access (E-UTRA), or NR access. One node acts as a master node (MN), while the other acts as a secondary node (SN). The MN and SN are connected via a network interface, with at least the MN connected to the core network. NG-RAN supports NG-RAN E-UTRA-NR Dual Connectivity (NGEN-DC), in which the UE connects to one Next Generation Evolved Node B (ng-eNB) acting as the MN (an E-UTRA base station that can be connected to the 5G core) and one gNB (a 5G base station) acting as the SN. NG-RAN also supports NR-E-UTRA Dual Connectivity (NE-DC), in which the UE connects to one gNB acting as the MN and one ng-eNB acting as the SN. The primary cell of a primary or secondary cell group is called an SpCell. SpCells in the primary cell group are called Pcells, while SpCells in the secondary cell group are called PSCells. In MR-DC, the serving cell group associated with the primary node, including SpCells (Pcells) and optionally one or more Scells, is called an MCG or primary cell group. A group of serving cells associated with a secondary node (including SpCells (PSCells) and optionally one or more Scells) is called a secondary cell group (SCG) in MR-DC. The frame timing and SFN of cells in the MCG and SCG may not be aligned.
[0064] Framework for Supporting Capability Changes: Consider a MUSIM UE with two USIMs (i.e., two UEs in the same MUSIM device). UE-A (USIM-A) is in the RRC-CONNECTED state with NWK-A. UE-B (USIM-B) is moving to or transitioning to RRC_CONNECTED. UE-A provides NWK-A with information to release resources or update parameters for UE-B's operation. This information includes information about UE-A's capability changes, including the release and deactivation of an SCG or Scell in UE-A, information about whether an SCG or Scell can be set up or activated in UE-A, and information about measurement gap requirements (need for gaps / need for gaps or csg) in UE-A to facilitate UE-B's operation.
[0065] If UE-A's capabilities need to be changed due to UE-B, UE-A indicates the new capabilities to NW-A in the RRC Setup Request / RRC Resume Request. Alternatively, UE-A may simply indicate in the RRC Setup Request / RRC Resume Request that the capabilities have changed. NW-A may request UE-A to further communicate the changed capabilities, and UE-A may report the changed capabilities in an RRC message (e.g., RRC Setup Complete or RRC Resume Complete). NW-A may further configure the changed capabilities for the UE.
[0066] When UE-A is in RRC_CONNECTED mode and the UE capabilities change due to activity in UE-B, UE-A notifies NW-A of the capability change via an RRC message. This message can be UE assistance information, a new RRC message (e.g., UE Capability Update), or even any existing RRC message. UE-A can directly transmit the updated UE capabilities to NW-A in the aforementioned RRC message. Alternatively, UE-A can simply notify the network NW-A that the UE capabilities have changed, and NW-A can retrieve the capabilities through the UE Capability Retrieval procedure. NW-A transmits an RRC message similar to a UE Capability Query to UE-A, and UE-A transmits the updated capabilities in the UE Capability Information. NW-A can store the received capabilities. To reduce signaling overhead, UE-A can associate an ID with each capability set and share the ID along with the capabilities with NW-A. Thereafter, UE-A can simply share the capability ID to indicate that the capabilities have changed, and NW-A can retrieve the UE capabilities using the stored capabilities.
[0067] If UE-A's capabilities change due to UE-B changing the RRC state while UE-A is in RRC_IDLE or RRC_INACTIVE mode, a similar approach to that used in RRC_CONNECTED can be used. UE-A indicates the new capabilities to the NW-A in an RRC message such as RRC SETUP REQUEST / RRC RESUME REQUEST, or it can share the UE Capability ID. Alternatively, UE-A can simply indicate that the capabilities have changed in the RRC SETUP REQUEST / RRC RESUME REQUEST. The NW-A can request UE-A to further communicate the changed capabilities, and UE-A can report the changed capabilities in an RRC message such as RRC SETUP COMPLETE or RRC RESUME COMPLETE.
[0068] UE-A can report that its capabilities have changed or can report the changed capabilities based on specific actions taken by UE-B. When UE-B switches from a licensed frequency to an unlicensed frequency or from one frequency range (FR) to another, UE-A can report the capability change to NW-A. In another embodiment, NW-A can configure UE-A to report capabilities, for example, using the "otherConfig" field in an RRC reconfiguration message. Accordingly, the UE can use UE Assistance Information messages to report updated or changed capabilities. The information content in the UAI can involve MUSIM assistance information or MUSIM UE capability information. An inhibit timer can be configured to control the frequency with which the UE can report capability updates. Capability updates, such as scheduling mode and / or time division duplex (TDD) uplink (UL) / downlink (DL) configuration information related to UE-B's capability limitations (e.g., number of transmit (Tx) / receive (Rx) signals), are not static or completely prohibited. Therefore, the UE can initiate a UAI to process such updates when the inhibit timer is not running.
[0069] NW-A can configure filters for UE-A, and UE-A will report changes in capabilities based on the filters. For example, if a capability included in the filter changes, UE-A may report the capability change. If no capability in the filter changes due to UE-B action, UE-A may not initiate a message to indicate the UE capability change. An example set of IEs that can be included in the filter may be requestedFreqBandsNR-MRDC, requestedCapabilityNR, eutra-nr-only flag, and requestedCapabilityCommon, UE-CapabilityRequestFilterNR. Additionally, the source and target gNBs may exchange changed capabilities and requested filters during a handover or transition from RRC_INACTIVE or any other Xn (Xn is the interface between two gNBs) UE information retrieval procedure.
[0070] When supporting simultaneous RRC connections, NW-A may also indicate whether it supports one or more slices or services, such as V2X / MBS. If the MUSIM device decides to allow an RRC connection for UE-B, UE-A may request / notify NW-A to release the slice or service (or the RRC connection with NW-A). If the device decides to continue the service / slice in UE-A, the UE-B RRC will notify the UE-B NAS that the RRC connection cannot be established. If the UE-B NAS requests RRC connection establishment due to a paging message, the UE-B NAS may transmit a busy indication to its AMF. In some embodiments, the UE-B RRC may transmit a busy indication instead of the UE-B NAS.
[0071] If the frequency bands supported by the changed capabilities differ from the old capabilities, the NW-A can reconfigure the UE-A to release one or more SCells or SCGs, or perform a handover. The NW-A can also configure the UE-A to report any available measurements when the capabilities change. Because the changed capabilities may differ from the old capabilities, the NW-A may prefer to change SCells or SCGs rather than releasing them, or perform a handover to a different frequency. Measurements from the UE can help the network make such decisions.
[0072] Whenever an RRC_CONNECTED UE, such as UE-A in our example, reports modified capabilities, it transmits any available measurements to the gNB (NW-A). The measurements may be transmitted in the same RRC message that reports the change in capabilities, or a different RRC message similar to the measurement report may be transmitted along with the RRC message reporting the change in capabilities.
[0073] If any of the NAS capabilities change due to UE-B changing the RRC state, UE-A may transmit a NAS message similar to a Registration Request and trigger a re-registration with the changed capabilities. As in the RRC case, if the AMF cannot support certain services with the changed capabilities, the device needs to prioritize between the services of UE-A and UE-B.
[0074] Static or dynamic capability signaling reported by the UE may include the following and more:
[0075] Number of Rx links
[0076] Number of Tx links
[0077] Number of MIMO layers
[0078] Support CA or DC on NW B
[0079] Processing capabilities in terms of component carrier or dual connectivity support on NWA
[0080] Request for at least one of configuration, activation, deactivation and release of one or more Scells / SCGs on NW A.
[0081] Supported frequency bands or frequency band combinations
[0082] UL or DL TDD configuration
[0083] Scheduling information or configuration
[0084] DRX configuration on NW B
[0085] Measurement configuration on NW B
[0086] IDC related configuration or parameters
[0087] Power control or backoff parameters
[0088] Measurement gap requirements
[0089] The network utilizes the updated capabilities received from the UE and reconfigures the UE with the updated parameters. The network may update the configuration of dual connectivity, carrier aggregation, power control, interference coordination, DAPS (Dual Antenna Protocol Stack) configuration, number of layers, etc. based on capability information including supported frequency bands, supported frequency band combinations, scheduling mode, and / or TDD UL / DL configuration information.
[0090] The network may receive the updated capabilities thus received as temporary UE capabilities and the procedure for receiving these temporary capabilities, such as described above, as a temporary UE capability change or temporary UE capability change. When this procedure is used for MUSIM operation, it may be referred to as a temporary UE capability change for MUSIM. A temporary capability change for MUSIM may also be a temporary reduction in capabilities, which is also referred to as a temporary capability restriction. A temporary capability change for MUSIM may also be a temporary increase in capabilities, which is also referred to as a removal of a temporary capability restriction. These temporary capabilities may not be stored in the core network. UE capabilities stored in the AMF and reported via the UE capability information procedure (e.g., in 3GPP NR Release 17) may be referred to as permanent capabilities.
[0091] L3 Mobility and LTM: In wireless technologies like 5G NR, devices can move across different cells. Mobility is performed in RRC_IDLE mode using a process called cell reselection. Until NR Release 17, mobility was performed in RRC_CONNECTED mode using a process called handover. Network-controlled mobility applies to UEs in RRC_CONNECTED mode. It requires explicit RRC signaling triggered by the gNB in NR. Handover in NR typically consists of three steps: handover preparation, handover execution, and handover completion. The gNB can configure the UE to report measurements. Based on the reported measurements or its own understanding of the network topology, the gNB transmits an RRC reconfiguration message to handover the UE from the source cell to another cell, called the target cell. The UE accesses the target cell and transmits an RRC reconfiguration complete message. In an alternative approach introduced in 3GPP NR Release 16, the gNB can configure execution conditions for the UE to trigger the handover. Once the execution conditions are met, the UE can move to the target cell and transmit an RRC reconfiguration complete message. 3GPP also introduced a new handover called DAPS handover in Release 16. In Release 16, the DAPS handover procedure maintains the source gNB connection after receiving the RRC message for handover and until the source cell is released after successful random access to the target gNB. In the DAPS handover procedure, the UE continues receiving downlink user data from the source gNB until the source cell is released, and continues transmitting uplink user data to the source gNB until a successful random access procedure to the target gNB is completed. In all of these methods, the UE performs handover by transmitting Layer 3 (RRC) messages, which results in significant signaling overhead and latency. This patent disclosure may refer to handover and conditional handover (CHO) as Layer 3 mobility. In the case of dual connectivity, the UE may perform a PSCell change or a conditional PSCell change. In the context of dual connectivity, this patent disclosure may also refer to PSCell changes or conditional PSCell changes as Layer 3 mobility. That is, handover, conditional handover, PSCell change, conditional PSCell change, etc. refer to Layer 3 mobility. In embodiments, in the context of dual connectivity, PSCell change or conditional PSCell change are referred to as SCG Layer 3 mobility, and handover and CHO are referred to as MCG Layer 3 mobility.
[0092] 3GPP Release 18 is considering low-layer (L1 / L2) triggered mobility (also known as LTM) to address issues related to latency, signaling overhead, and other issues associated with Layer 3 mobility. According to 3GPP, the goal of LTM is to implement serving cell changes via L1 / L2 signaling to reduce latency, overhead, and disruption time. The network (gNB) can configure multiple candidate cells for the UE, allowing for rapid application of candidate cell configuration. The network can also transmit MAC CEs or L1 signaling to dynamically switch the UE from the source cell to one of the configured candidate cells. Furthermore, LTM can be triggered based on L1 measurements rather than L3 measurements.
[0093] 3GPP proposes to perform LTM without resetting lower layers (such as MAC) to avoid data loss and minimize the additional delay of data recovery.
[0094] The source gNB transmits the RRC inter-node message HandoverPreparationInformation message to the target gNB during handover. An example specification excerpt is given below:
[0095] This message is used to convey NR RRC information used by the target gNB during handover preparation or UE context retrieval, e.g. in case of resumption or re-establishment, including UE capability information. This message is also used to transfer information between the CU and DU.
[0096] Direction: Source gNB / source RAN to target gNB or CU to DU.
[0097] The following is the handoverPreparationInformation message.
[0098]
[0099]
[0100] In this disclosure, 3gpp specifications TS 38.300, TS 38.331, TS 38.321, TS 38.401 and v17.3.0 of TS 37.340 (including definitions and descriptions) are used as background.
[0101] Consider the case where a MUSIM UE has two USIMs (i.e., two UEs in the same MUSIM device). UE-A (USIM-A) is in the RRC-CONNECTED state with NWK-A. UE-B (USIM-B) is in the RRC_CONNECTED state with NWK-B or is in the process of moving to RRC_CONNECTED. This patent disclosure discusses various operations at NWK-A for updating temporary capabilities due to MUSIM operation between different nodes in NWK-A and between NWK-A and UE-A.
[0102] Embodiments disclosed herein provide a method for handling a temporary UE capability change for a MUSIM UE in a wireless network. The method includes receiving information, by a UE, from a network entity. The network entity broadcasts information in a SIB indicating whether the network entity supports handling temporary UE capability changes for MUSIM operations in the wireless network. The method also includes handling, by the UE, the temporary UE capability change for MUSIM operations in the wireless network based on the broadcasted information.
[0103] Embodiments disclosed herein provide a method and system for handling temporary UE capability changes for MUSIM. In this embodiment, the source network entity (source gNB in NR) applies the received temporary capability changes to the (permanent) UE capabilities, generates a UE-CapabilityRAT-List in HandoverPreparationInformation and transmits it to the target gNB. After reporting the temporary capabilities, the UE only accepts RRC messages with the configuration if it receives an RRC message based on the reported temporary capabilities. Otherwise, the RRC procedure fails, and the UE initiates an RRC re-establishment or moves to RRC_IDLE. In this embodiment, the network access key (NWK)-A broadcasts its support for temporary UE capability change handling in new system information, indicating whether it supports MUSIM operation. In this embodiment, the UE-A updates its UE capabilities by applying the reduced temporary capabilities and notifies the NWK-A.
[0104] In an embodiment, the source gNB in the Network Widget-A (NWK-A) is notified whether the target gNB supports handling of temporary UE capabilities or temporary UE capability changes. In an embodiment, the target gNB notifies the source gNB whether it supports handling of temporary UE capabilities or temporary UE capability changes. In an embodiment, this is accomplished via an Xn message, such as an Xn Setup message or an Xn message for configuration updates (NG-RAN Node Configuration Update or NG-RAN Node Configuration Update Complete). In an embodiment, the target gNB notifies the source gNB of its capabilities via an INM RRC message. In an embodiment, the Operations, Administration, and Maintenance (OAM) entity notifies the source gNB whether the target gNB supports handling of temporary UE capabilities or temporary UE capability changes. In an embodiment, the source gNB may be configured to determine whether the target gNB supports handling of temporary UE capabilities or temporary UE capability changes by the operator.
[0105] In an embodiment, during handover, the source gNB of NWK-A transmits HandoverPreparationInformation to the target gNB of NWK-A. This HandoverPreparationInformation includes the latest UE capabilities (permanent UE capabilities) and the request for a temporary UE capability change received from UE-A. The request for a temporary UE capability change can be received in multiple messages, such as an RRC message such as UAI or other RRC messages, or via a MAC CE. The source gNB transmits the temporary UE capability change thus received to the target gNB by including it in an INM message such as HandoverPreparationInformation.
[0106] In an embodiment, during handover, the source gNB of NWK-A transmits HandoverPreparationInformation to the target gNB of NWK-A, which HandoverPreparationInformation includes the latest UE capabilities (permanent UE capabilities) and a request for temporary UE capability change, the same as received from UE-A.
[0107] Referring now to the drawings, and more particularly to Figure 1A 、 Figure 1B and Figures 2 to 13 , where like reference numerals denote corresponding features consistently throughout the drawings, there are shown embodiments.
[0108] It should be understood that the blocks in each flowchart and the combination of flowcharts can be performed by one or more computer programs comprising instructions. The entirety of one or more computer programs can be stored in a single memory device, or one or more computer programs can be divided into different parts stored in different multiple memory devices.
[0109] Any functions or operations described herein may be processed by a processor or a combination of processors. A processor or a combination of processors is a circuit that performs processing and includes, for example, an application processor (AP, such as a central processing unit (CPU)), a communication processor (CP, such as a modem), a graphics processing unit (GPU), a neural processing unit (NPU) (such as an artificial intelligence (AI) chip), a Wi-Fi chip, a Bluetooth chip, or a combination of processors. ® Circuits of chips, global positioning system (GPS) chips, near field communication (NFC) chips, connectivity chips, sensor controllers, touch controllers, fingerprint sensor controllers, display driver integrated circuits (ICs), audio codec chips, universal serial bus (USB) controllers, camera controllers, image processing ICs, microprocessor units (MPUs), systems on chip (SoCs), integrated circuits (ICs), etc.
[0110] Figure 1A is a block diagram illustrating a wireless network (1000) for handling temporary UE capability changes for MUSIM operations according to an embodiment of the present disclosure.
[0111] Figure 1B is a block diagram illustrating a wireless network (1000) for handling temporary UE capability changes for MUSIM operations according to an embodiment of the present disclosure.
[0112] refer to Figure 1A , the UE (100) communicates with the source network entity (200). The source network entity (200) communicates with the target network entity (400) based on the requirements. Figure 1B , the UE (100) communicates with a network entity (500) and a core network (300). The network entity (500) is any one of a source network entity (200) and a target network entity (400).
[0113] In general, a wireless network (1000) includes a UE (100), a source network entity (200), a core network (300), and a target network entity (400) having a plurality of target network entities (400a-400n). Hereinafter, the target network entity is labeled 400.
[0114] The wireless network (1000) may be, for example, but not limited to, a fourth generation (4G) network, a fifth generation (5G) network, a 6G network, an open radio access network (ORAN), etc. The UE (100) may be, for example, but not limited to, a laptop, a smartphone, a desktop computer, a notebook, a device-to-device (D2D) device, a vehicle-to-everything (V2X) device, a foldable phone, a smart TV, a tablet, an immersive device, and an Internet of Things (IoT) device. The source network entity (200) may be, for example, but not limited to, a gNB, an eNB, a new radio (NR) transceiver, etc. The target network entity (400) may be, for example, but not limited to, a gNB, an eNB, a new radio (NR) transceiver, etc.
[0115] In an embodiment, a network entity broadcasts information indicating whether the network entity supports temporary UE capability change handling for MUSIM operation in a wireless network (1000). The information includes an NR system information block (SIB). Based on the broadcasted information, the network entity handles temporary UE capability change for MUSIM in the wireless network (1000).
[0116] In another embodiment, the target network entity (400) or the OAM entity notifies the source network entity (200) of whether the target network entity (400) supports processing temporary UE capabilities or temporary UE capability changes through one of an Xn message and an INM RRC message. Based on the one of the Xn message and the INM RRC message, the target network entity (400) or the OAM entity processes the temporary UE capability changes of the MUSIM in the wireless network (1000).
[0117] refer to Figure 7 In an embodiment, the source network entity (200) (e.g., source gNB in NR) generates a ue-CapabilityRAT-List in HandoverPreparationInformation by applying the received temporary capabilities to the (permanent) UE capabilities, and transmits it to the target network entity (e.g., target gNB, etc.) (400). The source network entity (200) (e.g., source gNB, etc.) updates the UE capabilities received from the core network (300) or the UE capabilities received during handover through the UE capability retrieval procedure or through handover preparation information, etc., according to the temporary UE capability change requested by the UE (and accepted by the gNB), and includes it in the ue-CapabilityRAT-List in the handover preparation information and transmits it to the target gNB.
[0118] In an embodiment, if the target network entity (400) (e.g., the target gNB in NR) does not support temporary UE capabilities or handling of temporary UE capability changes, the source network entity (200) (e.g., the source gNB in NR) generates a ue-CapabilityRAT-List in HandoverPreparationInformation by applying the received temporary capabilities to the (permanent) UE capabilities, and transmits it to the target network entity (400). If the target network entity (400) does not support temporary UE capabilities or handling of temporary UE capability changes, the source network entity (200) updates the UE capabilities received from the core network (300) during handover or the UE capabilities received through the UE capability retrieval procedure or through HandoverPreparationInformation, etc., according to the temporary UE capability changes requested by the UE (200) and accepted by the gNB, and includes them in the ue-CapabilityRAT-List in HandoverPreparationInformation and transmits it to the target network entity (400).
[0119] Power Headroom Report (PHR): In an embodiment, UE-A transmits UAI or other RRC message or MAC CE for notifying / requesting / communicating a temporary capability change, and receives confirmation / affirmation / corresponding configuration from NWK-A in an RRC message such as an RRC reconfiguration message or in a MAC CE, and upon receiving the confirmation / affirmation / corresponding configuration from NWK-A, UE-A transmits a power headroom MAC CE to NWK-A.
[0120] In an embodiment, the UE (100) triggers a PHR when a temporary capability change occurs due to MUSIM operation.
[0121] In an embodiment, NWK-A configures whether or how UE-A reports power headroom during the temporary capability change procedure (e.g., based on whether the change in power headroom exceeds a threshold) via an RRC message (such as an RRC reconfiguration message). If UE-A is configured for power headroom reporting during temporary capability change and meets the conditions for power headroom reporting during temporary capability change, it reports PHR to NWK-A.
[0122] NeedForGaps: In an embodiment, UE-A transmits a flag indicating that the measurement gap requirement has changed to NWK-A in an RRC message, which is used to notify a temporary UE capability change.
[0123] Reconfiguration processing: In an embodiment, UE-A transmits UAI or other RRC message or MAC CE for notifying / requesting / communicating temporary capability change, and receives confirmation / affirmation / corresponding configuration from NWK-A in an RRC message such as an RRC reconfiguration message or in a MAC CE, and switches a part of the capabilities used for operation in UE-B.
[0124] If UE-A receives in an RRC message such as RRCReconfiguration or RRCResume a configuration (some IEs) that is not supported in the changed temporary capabilities (although the configuration is supported in the permanent UE capabilities from NWK-A), UE-A fails the procedure (e.g. Figure 5 .3.5.1-2: Failure of RRC reconfiguration, TS 38.331 v17.3.0). In addition, UE-A initiates the RRC re-establishment procedure.
[0125] If UE-A transmits a UAI for notifying / requesting / communicating a temporary capability change, and UE-A receives confirmation / affirmation / corresponding configuration from NWK-A in an RRC message such as an RRCReconfiguration message, and the UE (100) performs a handover or moves to RRC_INACTIVE or performs an RRC re-establishment procedure and receives a changed temporary capability unsupported configuration (some IEs) (or the UE receives a changed temporary capability unsupported configuration (some IEs) before it moves out of RRC_CONNECTED), although the configuration is supported in the permanent UE capabilities from NWK-A, but UE-A fails the procedure (e.g., as Figure 5 .3.5.1-2: Failure of RRC reconfiguration, TS 38.331 v17.3.0). In addition, UE-A initiates the RRC re-establishment procedure.
[0126] refer to Figure 8 When the capability is changed to perform MUSIM operation in idle or inactive state, the UE (100) receives information of temporary capability change that the cell does not support MUSIM operation from the SIB. The UE (100) performs re-registration and updates the reduced capability to the network.
[0127] refer to Figure 9 , if UE-A transmits UAI for notifying / requesting / communicating temporary capability change, and UE-A receives confirmation / affirmation / corresponding configuration from NWK-A in an RRC message such as RRCReconfiguration message, and UE (100) performs RRC re-establishment and receives configuration (some IEs) that is not supported by the changed temporary capability (although the configuration is supported in the permanent UE capability from NWK-A), then UE-A fails the RRC re-establishment procedure and moves to RRC-IDLE.
[0128] If UE-A transmits a UAI for notifying / requesting / communicating a temporary capability change of MUSIM operation, and UE-A receives confirmation / affirmation / corresponding configuration from NWK-A in an RRC message (such as an RRCReconfiguration message), and UE (100) receives a configuration (some IE) not supported by the changed temporary capability before it moves out of RRC_CONNECTED, UE-A fails the procedure (e.g., as in the example above) although the configuration received from NWK-A is supported in the permanent UE capability from NWK-A. Figure 5 .3.5.1-2: RRC reconfiguration failure of TS 38.331 v17.3.0). And also initiate an RRC re-establishment procedure, wherein as if the UE transmits UAI for notifying a temporary capability change for other operations such as UE power saving, UE-A receives confirmation / affirmation / corresponding configuration from NWK-A in an RRC message such as RRCReconfiguration message, and the UE receives a configuration (some IEs) that is not supported according to the UAI transmission for power saving, the UE regards the procedure as successful and transmits RRC Reconfiguration Complete.
[0129] If UE-A transmits UAI for notifying / requesting / communicating temporary capability change, and UE-A receives confirmation / affirmation / corresponding configuration from NWK-A in an RRC message such as RRCReconfiguration message, and UE receives unsupported configuration (some IE) of the changed temporary capability before it moves out of RRC_CONNECTED, although it is supported in the permanent UE capability from NWK-A, then UE-A fails the procedure (e.g. Figure 5 .3.5.1-2: Failure of RRC reconfiguration, TS 38.331v17.3.0). In addition, UE-A initiates the RRC re-establishment procedure.
[0130] In an embodiment, if UE-A's capabilities change (a temporary UE capability change for MUSIM operation), UE-A in RRC_INACTIVE mode moves to RRC_IDLE mode. In an embodiment, UE-A in RRC_INACTIVE mode initiates a NAS recovery procedure upon the UE-A capability change. In an embodiment, UE-A initiates re-registration with NAS upon the UE-A capability change and transmits a NAS Registration Request message.
[0131] When UE-A receives an RRC reconfiguration message that it cannot comply with due to a temporary capability change for MUSIM operation, the UE initiates a reestablishment procedure. In an embodiment, if the reestablishment procedure is initiated due to a reconfiguration failure caused by MUSIM operation, the UE-A indicates to the NW-A as part of the RRCReestablishmentComplete message that the reconfiguration failure is due to a temporary change in capability. In an embodiment, the NW-A initiates one or a combination of the following procedures to collect the changed capabilities from the UE (100) to perform the reconfiguration:
[0132] UE capability query procedure, and / or
[0133] A new procedure to query temporary capabilities from the UE, and / or
[0134] UE Assistance Information Request procedure to obtain temporary or preferred capabilities from the UE.
[0135]
[0136] In another embodiment, the UE (100) includes temporary capabilities as part of RRCReestablishmentComplete, and the NW-A uses the temporary capabilities to perform further reconfiguration.
[0137]
[0138] Alternatively, a new reconfiguration cause musimReconfigFailure is introduced to indicate that the reconfiguration failed due to temporary capability limitations of MUSIM operation.
[0139]
[0140] In an embodiment, NWK-A broadcasts whether it supports temporary UE capability change handling for MUSIM operation. In an embodiment, NWK-A broadcasts whether it supports temporary UE capability change handling for MUSIM operation in an existing NR SIB (e.g., SIB2 or SIB1). In an embodiment, NWK-A broadcasts whether it supports temporary UE capability change handling for MUSIM operation in new system information.
[0141] In this embodiment, if a UE-A whose capabilities have changed while in RRC_INACTIVE or RRC_IDLE initiates an RRC connection establishment in NR to a cell that does not support temporary UE capability changes, the UE-A re-registers (reattaches, transmits a NAS Registration Request) with the NWK-A core network. During the registration procedure, the UE-A notifies the NWK-A of the updated UE capabilities. The UE-A updates its UE capabilities by applying the changed temporary capabilities and notifies the NWK-A.
[0142] In an embodiment, if UE-A, whose capabilities have been reduced due to a temporary UE capability change while in the RRC_INACTIVE or RRC_IDLE state, initiates an RRC connection establishment in NR to a cell that does not support temporary UE capability changes, UE-A performs re-registration (reattachment, transmission of a NAS Registration Request) with the NWK-A core network. UE-A notifies the NWK-A of the updated UE capabilities during the registration procedure. UE-A updates its UE capabilities by applying the reduced temporary capabilities and notifies the NWK-A.
[0143] In an embodiment, if UE-A, whose capabilities have been increased due to a temporary UE capability change while it is in RRC_INACTIVE or RRC_IDLE, initiates RRC connection establishment in NR into a cell that does not support temporary UE capability change, UE-A avoids performing re-registration (reattachment, transmitting NAS Registration Request) with the NWK-A core network.
[0144] like Figure 10 As shown, a process for handling handover and temporary capability change concurrently is depicted. In an embodiment, a source network entity (200) in NWK-A (such as a gNB in NR) receives a request for a temporary capability change for MUSIM operation (UAI or other RRC / MAC CE, etc.). When a handover is in progress (e.g., when handover preparation or handover execution (as described in TS 38.300, TS 38.401, TS 38.331, etc.) is in progress), cancels the ongoing handover. In an embodiment, when the aforementioned handover is an inter-gNB handover, the source gNB transmits an Xn Handover Cancel message to the target gNB to cancel the handover. In an embodiment, the aforementioned behavior is applied only when the request is for a decrease (reduction) of capability. In an embodiment, the aforementioned behavior is applied when the request is for a decrease or increase of capability. In an embodiment, the same behavior also applies to PSCell changes in dual connectivity.
[0145] In an embodiment, a source network entity (200) in NWK-A (such as a gNB in NR) that receives a request (UAI or other RRC / MAC CE, etc., as described above) for a temporary capability change for MUSIM operation while a handover is in progress (e.g., while handover preparation or handover execution (as described in TS 38.300, TS 38.401, TS 38.331, etc.) is in progress) ignores the received message and proceeds with the handover. In an embodiment, the aforementioned behavior is applied only when the request is for an increase in capability. In an embodiment, the aforementioned behavior is applied when the request is for a decrease or increase in capability. In an embodiment, the same behavior also applies to a PSCell change in dual connectivity. In an embodiment, for a PSCell change, instead of ignoring the received message, the master node transmits the message to the SN after the handover.
[0146] In an embodiment, if the handover occurs within a predefined time (such as 1 second), the UE (100) (which has transmitted a request for a temporary capability change for MUSIM operation (UAI or other RRC / MAC CE, etc., as mentioned in the background)) and has received a request for handover (e.g., for RRC reconfiguration, including ReconfigurationwithSync) or any other mobility to another PCell (e.g., LTM)) from the network retransmits the request. In an embodiment, the UE (100) retransmits the above request regardless of whether any timer prohibiting such transmission is running. In an embodiment, the UE (100) retransmits the above request regardless of whether any other conditions prohibiting such transmission exist. In an embodiment, the UE (100) modifies the above request based on the configuration of the new cell and requests and retransmits the request. In an embodiment, the UE (100) retransmits the above request regardless of whether any timer prohibiting such transmission is running or any conditions prohibiting such transmission exist. In an embodiment, the same behavior also applies to PSCell changes in dual connectivity.
[0147] In an embodiment, a source network entity (200) in NWK-A (such as a gNB in NR) (which receives a request for a temporary capability change for MUSIM operation (UAI or other RRC / MAC CE, etc.)) cancels conditional handover or LTM when conditional handover is configured or LTM is configured, respectively. In an embodiment, when the aforementioned handover is an inter-gNB handover, the source network entity (200) transmits an Xn handover cancel message to the target network entity (400) to cancel the handover. The source network entity (200) also transmits an RRC reconfiguration message to release any configured conditional handover at the UE (100). In an embodiment, the above behavior applies when the request is only for a decrease (reduction) of capability. In an embodiment, the above behavior applies when the request is for a decrease or increase of capability. In an embodiment, the same behavior is applied to conditional PSCell changes in dual connectivity.
[0148] In an embodiment, when conditional handover (as described in TS 38.300, TS 38.401, TS 38.331, etc.) is configured or LTM is configured, the source network entity (200) in NWK-A (such as a gNB in NR) which receives a request for a temporary capability change for MUSIM operation (UAI or other RRC / MAC CE, etc.) ignores the received message. In an embodiment, the above behavior applies when the request is only for an increase in capability. In an embodiment, the above behavior applies when the request is for a decrease or increase in capability. In an embodiment, the same behavior may apply to conditional PSCell changes in dual connectivity.
[0149] In an embodiment, if conditional handover execution or reception of a cell handover command for LTM occurs within a predefined time (such as 1 second), a UE (100) that has transmitted a request for a temporary capability change for MUSIM operation (UAI or other RRC / MAC CE, etc.) and has performed conditional handover or received a cell handover command for LTM retransmits the request. In an embodiment, the UE retransmits the above request regardless of whether any timer prohibiting such transmission is running. In an embodiment, the UE retransmits the above request regardless of whether there are any other conditions prohibiting such transmission. In an embodiment, the UE modifies the above request based on the configuration of the new cell and requests and retransmits the request. In an embodiment, the same behavior can be applied to conditional PSCell changes in dual connectivity.
[0150] In an embodiment, when a PSCell addition is in progress, a conditional PSCell addition (CPA) is configured, or a PSCell change is in progress, or a conditional PSCell change is configured, the master node (MN) in the NWK-A (e.g., a gNB in NR-NR DC) receives a request (e.g., UAI or other RRC / Media Access Control (MAC) Control Element (CE)) for a temporary capability change for MUSIM operation, and cancels the ongoing PSCell addition, configured PSCell addition, ongoing PSCell change, or configured PSCell change. In an embodiment, the aforementioned behavior is applied only when the request is for a decrease (reduction) in capability. In an embodiment, the aforementioned behavior is applied when the request is for a decrease or increase in capability.
[0151] In an embodiment, the master node (MN) in the NWK-A (e.g., the gNB in NR-NR DC) receives a request (e.g., UAI or other RRC / MAC CE) for a temporary capability change for MUSIM operation while a PSCell addition is in progress, a conditional PSCell addition (CPA) is configured, a PSCell change is in progress, or a conditional PSCell change is configured. In response to the UE accepting the request, the master node may further notify the SN of the changed capabilities once the PSCell addition, CPA, PSCell change, or CPC is complete. In an embodiment, the aforementioned behavior applies when the request is for an increase in capabilities. In an embodiment, the aforementioned behavior applies when the request is for a decrease or increase in capabilities.
[0152] DAPS Switchover and Temporary Capability Change Reporting:
[0153] In an embodiment, if the UE performs DAPS handover, the UE releases the configuration for temporary capability change reporting or reporting band conflict for MUSIM configured by the source gNB.
[0154] In an embodiment, if a DAPS bearer is configured, the target gNB skips configuring the UE for temporary capability change reporting or reporting band conflicts for MUSIM until the DAPS bearer is released.
[0155] In an embodiment, the source gNB releases the configuration for temporary capability change reporting or reporting band conflict for MUSIM when or before configuring the DAPS bearer.
[0156] Example specification changes of the above-described embodiment according to 3gpp specification TS 38.300 are given below.
[0157] Only the source and target PCells are used during DAPS handover. Configuration of CA, DC, SUL, multi-TRP, EHC, CHO, UDC, NR sidelink configuration, V2X sidelink configuration, and temporary capability change reporting or reporting band conflicts for MUSIM are released by the source gNB before the handover command is transmitted to the UE and are not configured by the target gNB until the DAPS handover is completed (i.e., at the earliest in the same message that releases the source PCell).
[0158] In an embodiment, the above behavior applies if the UE is configured to move to RRC_IDLE (or if the UE is to move to RRC_IDLE) in the absence of a response to a temporary capability change from the network.
[0159] Timeout for processing a request to release capabilities: In an embodiment, a UE (UE-A) configured for MUSIM temporary capability change reporting may be configured by the network with a timer (e.g., musim-LeaveWithoutResponseTimerforCapabilityChange or musim_WaitTimer). UE-A starts the timer and simultaneously initiates transmission of a temporary capability change request to the NWK-A. Upon expiration of the timer, if UE-A has not received a response from the NWK-A (or if the network has not yet reconfigured the UE for the changed capabilities, or more specifically, if the network has not yet reconfigured the UE for the changed capabilities and the existing configuration cannot handle the changed temporary capabilities), UE-A moves to the RRC-IDLE state. In an embodiment, for NR UEs, UE-A moves to RRC-IDLE as defined in clause 5.3.8.6 of TS 38.331. In another embodiment, upon expiration of the timer, the UE itself applies the requested temporary capabilities.
[0160] In an embodiment, musim-LeaveWithoutResponseTimerforCapabilityChange is the same timer as the NR timer musim-LeaveWithoutResponseTimer defined in the NRTS 38.331 V17.3.0 specification.
[0161] In an embodiment, musim-LeaveWithoutResponseTimerforCapabilityChange is a new RRC timer.
[0162] In an embodiment, UE-A stops the musim-LeaveWithoutResponseTimerforCapabilityChange when it receives an RRC message such as RRC reconfiguration from the network or a MAC CE indicating that the network has accepted the UE's request. In an embodiment, this can be an NR RRC reconfiguration message that reconfigures the UE according to the changed capabilities.
[0163] In an embodiment, UE-A starts the timer musim-LeaveWithoutResponseTimerforCapabilityChange only when a temporary capability change results in a reduction (reduction) in capability. In this case, the reduction in capability may be the release of an SCG, the release of an SCell, a reduction in the number of MIMO layers or RX bandwidth, etc.
[0164] In an embodiment, UE-A starts the timer musim-LeaveWithoutResponseTimerforCapabilityChange only when the temporary capability change results in a decrease (reduction) or increase in capability. In another embodiment, if the expiration of musim-LeaveWithoutResponseTimerforCapabilityChange is for a request to notify NWK-A of an increase in capability, the UE may not move to RRC_IDLE.
[0165] In an embodiment, UE-A starts the timer musim-LeaveWithoutResponseTimerforCapabilityChange only when UE-A cannot handle the current configuration according to the temporary capability change. In another embodiment, if UE-A can handle the current configuration even in the case of a temporary capability change, UE-A may start the timer but not move to RRC_IDLE.
[0166] In an embodiment, if the network does not accept (or responds to or configures UE-A with the changed temporary capabilities) a change in temporary capabilities, UE-A notifies the network of its preferred action (i.e., the action it can perform). In an embodiment, UE-A notifies the network that it prefers to leave NWK-A (or that it plans to leave NWK-A or will leave NWK-A) in case NWK-A does not accept (or responds to or configures UE-A with the changed temporary capabilities, etc.) a reconfiguration request in accordance with the temporary capabilities change. In another embodiment, UE-A notifies the network that its preferred action is to apply temporary capability restrictions upon expiration of a timer. This behavior may occur if the MUSIM device deems UE-B's operation, which is the reason UE-A communicates the temporary capabilities change, more important than UE-A's operation.
[0167] In an embodiment, if NWK-A does not accept (or responds to UE-A or configures UE-A according to the changed temporary capabilities, etc.), after UE-A has informed NWK-A of the preferred action as a change in temporary capabilities after leaving the network (i.e., MUSIM device is preferred to UE-B), UE-A moves to RRC_IDLE.
[0168] In an embodiment, if the UE prefers to leave NWK-A when NWK-A does not accept the temporary capability (or responds or configures UE-A according to the changed temporary capability), UE-A starts the timer musim-LeaveWithoutResponseTimerforCapabilityChange and leaves NWK-A when the timer expires.
[0169] The temporary capability change (temporary capability change) and related methods in this disclosure are primarily applicable to MUSIM scenarios. However, the embodiments herein do not preclude the use of temporary capability changes for any other scenarios. Similarly, the embodiments do not preclude the use of methods for any technology, such as 4G LTE or 6G.
[0170] Furthermore, any embodiments applicable to NWK-A also apply to NWK- B. That is, in some embodiments, both networks are interchangeable for purposes of the present disclosure.
[0171] Furthermore, any embodiments applicable to UE-A also apply to UE-B. That is, in some embodiments, the two UEs are interchangeable for the present disclosure.
[0172] Figure 2 Various hardware components of a UE (100) according to an embodiment of the present disclosure are shown.
[0173] In an embodiment, a UE (100) includes a processor (110), a communicator (120), a memory (130), and a temporary UE capability processing controller (140). The processor (110) is coupled with the communicator (120), the memory (130), and the temporary UE capability processing controller (140).
[0174] The temporary UE capability handling controller (140) receives information from the network entity (500). The network entity (500) broadcasts information indicating whether the network entity supports temporary UE capability change handling for MUSIM operation in the wireless network (1000) in a SIB. Based on the received information, the temporary UE capability handling controller (140) handles temporary UE capability change for MUSIM operation in the wireless network (1000).
[0175] In an embodiment, when the UE is in the RRC_INACTIVE state or the RRC_IDLE state, the temporary UE capability handling controller (140) determines that the capability has been reduced. In addition, the temporary UE capability handling controller (140) performs a re-registration with the core network (300) when initiating an RRC connection establishment procedure in a cell that does not support temporary UE capability changes based on the determination. In addition, the temporary UE capability handling controller (140) notifies the core network (300) of the updated UE capability by applying the reduced temporary capability during the registration procedure.
[0176] In another embodiment, the temporary UE capability handling controller (140) receives a configuration for reporting a temporary capability change, wherein the configuration includes a timer (e.g., an RRC timer, etc.). In addition, when the UE (100) is in the RRC_INACTIVE state or the RRC_IDLE state, the temporary UE capability handling controller (140) determines that the capability has been reduced. In addition, the temporary UE capability handling controller (140) initiates a transmission requesting a temporary capability change based on the reduced capability as a result of the determination. In addition, the temporary UE capability handling controller (140) starts a timer. In an embodiment, when the UE (100) cannot handle the current configuration based on the reduced temporary capability, the UE (100) starts the timer. For example, if the request for the temporary capability change includes a request to release an SCG or a serving cell or to reduce the capability within the serving cell or the SCG, the UE may start the timer. If the request for the temporary capability change only includes a request to reduce the capability of some frequency bands or frequency band combinations, the UE may skip starting the timer. In addition, the temporary UE capability handling controller (140) receives an RRCReconfiguration message. In an embodiment, if the reconfiguration message reconfigures the UE (100) based on the requested reduced capabilities, the temporary UE capability handling controller (140) stops the timer. In another embodiment, if the reconfiguration message does not reconfigure the UE (100) based on the requested reduced capabilities, the temporary UE capability handling controller (140) continues the timer. For example, if the UE has requested to release both the SCG and the SCell, and the reconfiguration is only for releasing the SCG, the timer continues to run. Similarly, if the UE has requested to reduce the maximum MIMO layers in both Scells and releases the reconfiguration for both Scells, the UE stops the timer. This ensures that the UE can gracefully allocate some resources to another UE during MUSIM operation.
[0177] The temporary UE capability processing controller (140) is implemented by analog and / or digital circuits, such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hard-wired circuits, etc., and may optionally be driven by firmware.
[0178] The processor (110) may include one or more processors. The one or more processors may be general-purpose processors (such as a central processing unit (CPU), an application processor (AP), etc.), graphics processing units (such as a graphics processing unit (GPU), a visual processing unit (VPU)), and / or AI-specific processors (such as a neural processing unit (NPU)). The processor (110) may include multiple cores and be configured to execute instructions stored in the memory (130).
[0179] In addition, the processor (110) is configured to execute instructions stored in the memory (130) and perform various processes. The communicator (120) is configured to communicate internally between internal hardware components and with external devices via one or more networks. The memory (130) also stores instructions to be executed by the processor (110). The memory (130) may include a non-volatile storage element. Examples of such non-volatile storage elements may include a magnetic hard disk, an optical disk, a floppy disk, a flash memory, or a form of electrically programmable memory (EPROM) or electrically erasable programmable memory (EEPROM). In addition, in some examples, the memory (230) may be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or propagating signal. However, the term "non-transitory" should not be interpreted as meaning that the memory (130) is non-removable. In some examples, a non-transitory storage medium may store data that may change over time (e.g., in random access memory (RAM) or cache memory).
[0180] In an embodiment, the communicator (120) includes electronic circuitry specific to a standard for implementing wired or wireless communications. The communicator (120) is configured to communicate internally between internal hardware components of the UE (100) and with external devices via one or more networks.
[0181] although Figure 2 Various hardware components of the UE (100) are shown, but it should be understood that other embodiments are not limited thereto. In other embodiments, the UE (100) may include fewer or greater numbers of components. Furthermore, the labels or names of the components are for illustrative purposes only and do not limit the scope of the present disclosure. One or more components may be combined to perform the same or substantially similar functions in the UE (100).
[0182] Figure 3 Various hardware components of a source network entity (200) according to an embodiment of the present disclosure are shown.
[0183] In an embodiment, the source network entity (200) includes a processor (210), a communicator (220), a memory (230), and a temporary UE capability processing controller (240). The processor (210) is coupled with the communicator (220), the memory (230), and the temporary UE capability processing controller (240).
[0184] The temporary UE capability handling controller (240) configures a configuration for reporting a temporary capability change at the UE (100). In addition, the temporary UE capability handling controller (240) receives a request for a temporary capability change for MUSIM operation while a handover is in progress. In an embodiment, when the handover is an inter-gNB handover, the temporary UE capability handling controller (240) transmits an Xn handover cancel message to the target network entity (400) to cancel the handover. In another embodiment, the temporary UE capability handling controller (240) releases the conditional handover configuration at the UE and the target gNB.
[0185] In an embodiment, the temporary UE capability handling controller (240) releases a configuration for reporting a temporary capability change before performing a dual active protocol stack (DAPS) switch.
[0186] In an embodiment, a temporary UE capability handling controller (240) transmits handover preparation information (HandoverPreparationInformation) to a target network entity (400). The HandoverPreparationInformation includes permanent UE capabilities received from the UE and a request for a temporary UE capability change. The request for a temporary UE capability change is received in an RRC message. Based on the HandoverPreparationInformation, the temporary UE capability handling controller (240) handles a temporary UE capability change for the MUSIM UE in the wireless network (1000).
[0187] The temporary UE capability processing controller (240) is implemented by analog and / or digital circuits, such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hard-wired circuits, etc., and may optionally be driven by firmware.
[0188] The processor (210) may include one or more processors. The one or more processors may be general-purpose processors (such as a central processing unit (CPU), an application processor (AP), etc.), graphics processing units (such as a graphics processing unit (GPU), a visual processing unit (VPU)), and / or AI-specific processors (such as a neural processing unit (NPU)). The processor (210) may include multiple cores and be configured to execute instructions stored in the memory (230).
[0189] In addition, the processor (210) is configured to execute instructions stored in the memory (230) and perform various processes. The communicator (220) is configured to communicate internally between internal hardware components and with external devices via one or more networks. The memory (230) also stores instructions to be executed by the processor (210). The memory (230) may include a non-volatile storage element. Examples of such non-volatile storage elements may include a magnetic hard disk, an optical disk, a floppy disk, a flash memory, or a form of electrically programmable memory (EPROM) or electrically erasable programmable memory (EEPROM). In addition, in some examples, the memory (230) may be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or propagating signal. However, the term "non-transitory" should not be interpreted as meaning that the memory (230) is non-removable. In some examples, a non-transitory storage medium may store data that may change over time (e.g., in random access memory (RAM) or cache memory).
[0190] In an embodiment, the communicator (220) includes electronic circuitry specific to a standard for implementing wired or wireless communications. The communicator (220) is configured to communicate internally between internal hardware components of the UE (100) and with external devices via one or more networks.
[0191] refer to Figure 3 , Figure 3 Various hardware components of the source network entity (200) are shown, but it should be understood that other embodiments are not limited thereto. In other embodiments, the source network entity (200) may include fewer or greater numbers of components. Furthermore, the labels or names of the components are for illustrative purposes only and do not limit the scope of the present disclosure. One or more components may be combined to perform the same or substantially similar functions in the source network entity (200).
[0192] Figure 4 is a flow chart (401) illustrating a method implemented by a UE (100) for handling temporary UE capability changes for MUSIM operations in a wireless network (1000) according to an embodiment of the present disclosure.
[0193] Operations 402 and 404 are handled by the Temporary UE Capability Handling Controller (140).
[0194] At operation 402, the method includes receiving information from a network entity. The network entity broadcasts information in a SIB indicating whether the network entity supports temporary UE capability change processing for MUSIM operation. At operation 404, the method includes processing temporary UE capability change for MUSIM operation in the wireless network (1000) based on the broadcasted information.
[0195] Figure 5 is a flow chart (501) illustrating a method implemented by a wireless network (1000) for handling a temporary UE capability change of a MUSIM UE in a wireless network (1000) according to an embodiment of the present disclosure.
[0196] At operation 502, the target network entity (400) notifies the source network entity (200) whether the target network entity (400) supports handling temporary UE capability changes. At operation 504, the source network entity (200) handles temporary UE capability changes of the MUSIM UE in the wireless network (1000) based on the received information.
[0197] Figure 6 6 is a flow chart (600) illustrating a method implemented by a source network entity (200) for handling temporary UE capability changes for MUSIM operation in a wireless network (1000) according to an embodiment of the present disclosure. Operations (602 to 608) are handled by a temporary UE capability handling controller (240).
[0198] At operation 602, the method includes configuring, at the UE (100), a configuration for reporting a temporary capability change. At operation 604, the method includes receiving a request for a temporary capability change for MUSIM operation while a handover is ongoing. In an embodiment, at operation 606, the method includes, when the handover is an inter-gNB handover, transmitting an Xn handover cancel message to the target network entity (400) to cancel the handover. In another embodiment, at operation 608, the method includes releasing the conditional handover configuration at the UE and the target network entity (200).
[0199] Figure 7 A flow chart (700) is shown for a source gNB to notify a target gNB of UE capabilities during handover based on temporary capabilities according to an embodiment of the present disclosure.
[0200] At operation 702, the method includes receiving a temporary capability change for MUSIM operation.At operation 704, the method includes generating UE capabilities to which the temporary capability change applies.
[0201] Figure 8 A flow chart (800) is shown of a UE (100) handling capability changes in RRC_IDLE according to an embodiment of the present disclosure.
[0202] At operation 802, the method includes receiving information from the SIB that the cell does not support temporary capability change for MUSIM operation when the capability is changed for MUSIM operation in IDLE mode or inactive mode. At operation 804, the method includes performing re-registration and updating the reduced capability.
[0203] Figure 9 A flow chart (900) of an RRC configuration process with temporary capabilities according to an embodiment of the present disclosure is shown.
[0204] At operation 902, the method includes transmitting a temporary capability change for MUSIM operation and receiving an acknowledgment. At operation 904, the method includes receiving an RRC message with a configuration that is not in accordance with the reported temporary capabilities. At operation 906, the method includes failing the RRC procedure and initiating an RRC reestablishment procedure or moving to RRC_IDLE mode.
[0205] Figure 10 is a flow chart at operation 1001 depicting a process of handling concurrency for handover and temporary capability change according to an embodiment of the present disclosure.
[0206] At operation 1002, the method includes receiving a temporary capability change for MUSIM operation during handover preparation or when CHO is configured. At operation 1004, the method includes canceling the ongoing handover.
[0207] Figure 11 and Figure 12 is a flow chart at operations 1100 and 1200 depicting a process of handling concurrency of DC operations and temporary capability changes according to various embodiments of the present disclosure.
[0208] refer to Figure 11 At operation 1102, the method includes receiving a temporary capability change for MUSIM operation when a PScell addition is in progress or a conditional PScell addition (CPA) is configured or a PScell change is in progress or a conditional PScell change is configured. At operation 1104, the method includes canceling the ongoing handover.
[0209] refer to Figure 12 At operation 1202, the method includes receiving a temporary capability change for MUSIM operation when PScell addition is in progress or conditional PScell addition (CPA) is configured or PScell change is in progress or conditional PScell change is configured. At operation 1204, the method includes continuing the ongoing operation and notifying the SN through CG-configInfo after the operation is completed.
[0210] Figure 13 is a flowchart depicting a process of handling a temporary capability change from UE-A that is not accepted by NWK-A according to an embodiment of the present disclosure.
[0211] At operation 1, the UE (100) receives an RRC reconfiguration message from the core network (300) with a configuration for transmitting a change in one or more temporary capabilities and a timer T. At operation 2, the UE 2 transmits an RRC reconfiguration complete message to the core network (300). At operation 3, the UE (100) transmits one or more UAIs with temporary capability reductions to the core network (300). At operation 4, the UE starts the timer T for the capability change. At operation 5, if the reconfiguration message reconfigures the UE based on the requested reduced capabilities, the UE 100 stops the timer T.
[0212] The various actions, actions, blocks, steps, etc. in the flowcharts (400-1200) may be performed in the order presented, in a different order, or simultaneously. Furthermore, in some embodiments, some of the actions, actions, blocks, steps, etc. may be omitted, added, modified, skipped, etc. without departing from the scope of the present disclosure.
[0213] Figure 14 A block diagram illustrating the structure of a UE according to an embodiment of the present disclosure is shown.
[0214] Figure 14 Corresponding to Figure 2 Example of UE.
[0215] refer to Figure 14 According to an embodiment, the UE may include a transceiver 1410, a memory 1420, and a processor (or controller) 1430. The transceiver 1410, memory 1420, and processor 1430 of the UE may operate according to the communication method of the UE described above. However, the components of the UE are not limited thereto. For example, the UE may include more or fewer components than those described above. In addition, the processor 1430, the transceiver 1410, and the memory 1420 may be implemented as a single chip. In addition, the processor 1430 may include at least one processor or at least one controller.
[0216] The transceiver 1410 is collectively referred to as a UE receiver and a UE transmitter, and can transmit and receive signals to and from a base station or a network entity. The signals transmitted to and received from the base station or network entity may include control information and data. The transceiver 1410 may include an RF transmitter for up-converting and amplifying the frequency of the transmitted signal, and an RF receiver for amplifying the low noise and down-converting the frequency of the received signal. However, this is merely an example of the transceiver 1410, and the components of the transceiver 1410 are not limited to the RF transmitter and the RF receiver.
[0217] In addition, the transceiver 1410 may receive a signal through a wireless channel and output a signal to the processor 1430 , and transmit a signal output from the processor 1430 through a wireless channel.
[0218] The memory 1420 may store programs and data required for the operation of the UE. In addition, the memory 1420 may store control information or data included in signals obtained by the UE. The memory 1420 may be a storage medium such as a read-only memory (ROM), a random access memory (RAM), a hard disk, a CD-ROM, and a DVD, or a combination of storage media.
[0219] The processor 1430 may control a series of processes so that the UE operates as described above. For example, the transceiver 1410 may receive a data signal including a control signal transmitted by a base station or a network entity, and the processor 1430 may determine a result of receiving the control signal and the data signal transmitted by the base station or the network entity.
[0220] Figure 15 A block diagram illustrating the structure of a base station according to an embodiment of the present disclosure is shown.
[0221] Figure 15 Corresponding to Figure 3 An example of a network entity.
[0222] refer to Figure 15 According to an embodiment, a base station may include a transceiver 1510, a memory 1520, and one or more processors (or controllers) 1530. The transceiver 1510, memory 1520, and processor 1530 of the base station may operate according to the communication method of the above-mentioned base station. However, the components of the base station are not limited thereto. For example, the base station may include more or fewer components than those described above. In addition, the processor 1530, transceiver 1510, and memory 1520 may be implemented as a single chip. In addition, the processor 1530 may include at least one processor and at least one controller.
[0223] The transceiver 1510 is collectively referred to as a base station receiver and a base station transmitter, and can transmit and receive signals to and from a terminal or network entity. The signals transmitted to and received from the terminal or network entity may include control information and data. The transceiver 1510 may include an RF transmitter for up-converting and amplifying the frequency of transmitted signals, and an RF receiver for low-noise amplification and down-conversion of received signals. However, this is merely an example of the transceiver 1510, and the components of the transceiver 1510 are not limited to an RF transmitter and an RF receiver.
[0224] In addition, the transceiver 1510 may receive a signal through a wireless channel and output the signal to the processor 1530 , and transmit a signal output from the processor 1530 through a wireless channel.
[0225] The memory 1520 may store programs and data required for the operation of the base station. In addition, the memory 1520 may store control information or data included in signals obtained by the base station. The memory 1520 may be a storage medium such as a read-only memory (ROM), a random access memory (RAM), a hard disk, a CD-ROM, and a DVD, or a combination of storage media.
[0226] The processor 1530 may control a series of processes so that the base station operates as described above. For example, the transceiver 1510 may receive a data signal including a control signal transmitted by a terminal, and the processor 1530 may determine a result of receiving the control signal and the data signal transmitted by the terminal.
[0227] Embodiments disclosed herein provide a method for handling temporary user equipment (UE) capability changes for a Multiple Universal Subscriber Identity Module (MUSIM) UE in a wireless network. The method includes receiving information, by the UE, from a network entity. The network entity broadcasts information in a System Information Block (SIB) indicating whether the network entity supports handling temporary UE capability changes for MUSIM operation in the wireless network. The method also includes handling, by the UE, temporary UE capability changes for MUSIM operation in the wireless network based on the broadcasted information.
[0228] In an embodiment, processing, by the UE, a temporary UE capability change for MUSIM operation in a wireless network includes determining, by the UE, that performance has been degraded while the UE is in an RRC_INACTIVE state or an RRC_IDLE state, performing, by the UE, a re-registration with a core network when initiating a radio resource control (RRC) connection establishment procedure in a cell that does not support the temporary UE capability change based on the determination, and notifying, by the UE, the core network of updated UE capability by applying the degraded temporary capability during a registration procedure.
[0229] In an embodiment, processing, by a UE, a temporary UE capability change for MUSIM operation in a wireless network includes: receiving, by the UE, a configuration for reporting a temporary capability change, wherein the configuration includes a timer, determining, by the UE, that capabilities have been reduced at the UE, initiating, by the UE, a transmission requesting a temporary capability change based on the reduced capabilities as a result of the determination, starting, by the UE, a timer, receiving, by the UE, an RRCReconfiguration message, and performing, by the UE, one of: stopping, by the UE, the timer if the reconfiguration message reconfigures the UE based on the requested reduced capabilities, and continuing, by the UE, the timer if the reconfiguration message does not reconfigure the UE based on the requested reduced capabilities.
[0230] In an embodiment, the timer is an RRC timer.
[0231] In an embodiment, when the UE cannot process the current configuration based on the reduced temporary capability, the UE starts a timer.
[0232] Embodiments disclosed herein provide a method for handling a temporary UE capability change for a MUSIM UE in a wireless network. The method includes notifying a source network entity, by a target network entity or an operations, administration, and maintenance (OAM) entity, whether the target network entity supports handling temporary UE capability changes. Furthermore, the method includes handling the temporary UE capability change for the MUSIM UE in the wireless network by the source network entity based on the received information.
[0233] In an embodiment, processing, by the source network entity, a temporary UE capability change of a MUSIM UE in a wireless network includes: transmitting, by the source network entity, HandoverPreparationInformation, handover preparation information, to a target network entity, wherein the HandoverPreparationInformation includes permanent UE capabilities and a request for a temporary UE capability change received from the UE, wherein the request for the temporary UE capability change is received in a radio resource control (RRC) message, and processing, by the target network entity, the temporary UE capability change of the MUSIM UE in the wireless network based on the HandoverPreparationInformation.
[0234] In an embodiment, when the target network entity does not support processing of temporary UE capability changes, transmitting HandoverPreparationInformation by the source network entity to the target network entity includes: generating a UE-CapabilityRAT-List in HandoverPreparationInformation by applying the received temporary capabilities to the permanent UE capabilities, and transmitting HandoverPreparationInformation including the UE-CapabilityRAT-List by the source network entity.
[0235] Embodiments disclosed herein provide a method for handling a temporary user equipment (UE) capability change for a MUSIM UE in a wireless network. The method includes, by a source network entity in the wireless network, configuring, at the UE, a configuration for reporting a temporary capability change. Furthermore, the method includes, while a handover is ongoing, receiving, by the source network entity, a request for a temporary capability change for MUSIM operation. Furthermore, the method includes, by the source network entity, performing at least one of: transmitting an Xn Handover Cancel message to a target network entity to cancel the handover when the handover is an inter-gNB handover, and releasing a conditional handover configuration at the UE and the target gNB.
[0236] In an embodiment, the source network entity releases a configuration for reporting a temporary capability change before performing a dual active protocol stack (DAPS) handover.
[0237] Embodiments disclosed herein provide a UE, including a temporary UE capability handling controller coupled to a processor and a memory. The temporary UE capability handling controller is configured to receive information from a network entity. The network entity broadcasts information in a SIB indicating whether the network entity supports temporary UE capability change processing for MUSIM operation in a wireless network. Furthermore, the temporary UE capability handling controller is configured to process temporary UE capability changes for MUSIM operation in the wireless network based on the broadcasted information.
[0238] Embodiments disclosed herein provide a wireless network including a target network entity that notifies a source network entity whether the target network entity supports handling temporary UE capability changes. Furthermore, the source network entity handles temporary UE capability changes for a MUSIM UE in the wireless network based on the received information.
[0239] Embodiments disclosed herein provide a source network entity, including a temporary UE capability handling controller coupled to a processor and a memory. The temporary UE capability handling controller is configured to configure a configuration for reporting a temporary capability change at a UE. Furthermore, the temporary UE capability handling controller is configured to receive a request for a temporary capability change for MUSIM operation while a handover is in progress or a PSCell addition is in progress. Furthermore, the temporary UE capability handling controller is configured to perform at least one of the following: when the handover is an inter-gNB handover, transmit an Xn Handover Cancel message to a target network entity to cancel the handover, and release conditional handover configurations at the UE and the target network entity.
[0240] These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and accompanying drawings. However, it should be understood that the following description, while indicating preferred embodiments and many of their specific details, is given by way of illustration and not limitation. Many changes and modifications may be made within the scope of the embodiments herein without departing from the scope of the embodiments herein, and the embodiments herein include all such modifications.
[0241] It should be understood that various embodiments of the present disclosure according to the claims and description in the specification can be realized in the form of hardware, software, or a combination of hardware and software.
[0242] Any such software may be stored in a non-transitory computer-readable storage medium that stores one or more computer programs (software modules) comprising computer-executable instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform the methods of the present disclosure.
[0243] Any such software may be stored in the form of volatile or non-volatile memory, such as a storage device like a read-only memory (ROM), whether erasable or rewritable, or in the form of a memory, such as a random access memory (RAM), a memory chip, device, or integrated circuit, or on an optically or magnetically readable medium, such as a compact disc (CD), a digital versatile disc (DVD), a magnetic disk, or a magnetic tape. It should be understood that the storage device and the storage medium are various embodiments of non-transitory machine-readable storage devices suitable for storing one or more computer programs comprising instructions that, when executed, implement various embodiments of the present disclosure. Accordingly, various embodiments provide a program comprising code for implementing an apparatus or method as claimed in any of the claims of this specification, as well as a non-transitory machine-readable storage device storing such a program.
[0244] While the present disclosure has been shown and described with reference to various embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present disclosure as defined by the appended claims and their equivalents.
Claims
1. A user equipment (UE) in a wireless communication system, the UE comprising: transceiver; A controller is coupled to the transceiver and is configured to: receiving, from a base station, a system information block (SIB) including a first indication as to whether transmission of a second indication is permitted, Identify that UE capabilities are restricted for Multi-Universal Subscriber Identity Module (MUSIM) operation, and A radio resource control (RRC) message including a second indication indicating a temporary capability limitation of the UE due to MUSIM operation is sent to the base station.
2. The UE according to claim 1, wherein The RRC message includes an RRC setup complete message or an RRC recovery complete message.
3. The UE according to claim 1, wherein: The controller is further configured to: receiving information configuring a timer associated with MUSIM operation from a base station, and In case the UE has UE temporary capability restriction configured on the UE: Sending a message to the base station requesting release of the UE's configuration, and Start the timer.
4. The UE according to claim 3, wherein: Upon receipt of the RRC reconfiguration message, the timer is stopped.
5. A base station (BS) in a wireless communication system, the BS comprising: transceiver; A controller is coupled to the transceiver and is configured to: transmitting a system information block (SIB) including a first indication regarding whether reception of the second indication is permitted to a user equipment (UE), and A radio resource control (RRC) message is received from the UE including a second indication indicating a temporary capability limitation of the UE due to a Multiple Universal Subscriber Identity Module (MUSIM) operation. The BS according to claim 5 , wherein: The RRC message includes an RRC setup complete message or an RRC recovery complete message.
7. The BS according to claim 5, wherein: The controller is further configured to: sending information configuring a timer associated with MUSIM operation to the UE, the timer being started if the UE has UE temporary capability restriction configured for the UE, and A message requesting to release a configuration of the UE is received from the UE.
8. The BS according to claim 7, wherein: Upon receipt of the RRC reconfiguration message, the timer is stopped.
9. A method performed by a user equipment (UE) in a wireless communication system, the method comprising: receiving, from a base station, a system information block (SIB) including a first indication as to whether transmission of a second indication is permitted; Identifying that UE capabilities are restricted for Multi-Universal Subscriber Identity Module (MUSIM) operations; and A radio resource control (RRC) message including a second indication indicating a temporary capability limitation of the UE due to MUSIM operation is sent to the base station.
10. The method according to claim 9, wherein: The RRC message includes an RRC setup complete message or an RRC recovery complete message.
11. The method according to claim 9, further comprising: receiving, from a base station, information configuring a timer associated with MUSIM operation; as well as In case the UE has UE temporary capability restriction configured on the UE: Sending a message to the base station requesting release of the UE's configuration; and Start the timer.
12. The method according to claim 11, wherein Upon receipt of the RRC reconfiguration message, the timer is stopped.
13. A method performed by a base station (BS) in a wireless communication system, the method comprising: sending a system information block (SIB) including a first indication regarding whether reception of a second indication is permitted to a user equipment (UE); as well as A radio resource control (RRC) message is received from the UE including a second indication indicating a temporary capability limitation of the UE due to a Multiple Universal Subscriber Identity Module (MUSIM) operation.
14. The method according to claim 13, wherein The RRC message includes an RRC setup complete message or an RRC recovery complete message.
15. The method according to claim 13, further comprising: sending information configuring a timer associated with MUSIM operation to the UE, the timer being started if the UE has UE temporary capability restriction configured for the UE; as well as receiving a message from the UE requesting release of the UE's configuration, When the RRC reconfiguration message is received, the timer is stopped.