Methods and apparatus for supporting dynamic change for user equipment capability reporting in mobile communications

Abstract

Techniques pertaining to supporting dynamic change for user equipment (UE) capability reporting in mobile communications are described. An apparatus (e.g., a user equipment (UE)) communicates with a network to request to effect a capability change in the UE. The apparatus then operates with a changed capability responsive to the network accepting the capability change.

Description

METHODS AND APPARATUS FOR SUPPORTING DYNAMIC CHANGE FOR USER EQUIPMENT CAPABILITY REPORTING IN MOBILE COMMUNICATIONSCROSS REFERENCE TO RELATED PATENT APPLICATION (S)

[0001] The present disclosure claims the priority benefit of U.S. Patent Application No. 63 / 745,396, filed 15 January 2025, the content of which herein being incorporated by reference in its entirety.TECHNICAL FIELD

[0002] The present disclosure is generally related to mobile communications and, more particularly, to supporting dynamic change for user equipment (UE) capability reporting in mobile communications.BACKGROUND

[0003] In wireless communications such as mobile communications under the current 3rd Generation Partnership Project (3GPP) specification, in current 5th Generation (5G) New Radio (NR) systems a UE radio access capability (RAC) is deemed to be static and delivered in a pre-provisioned way that a radio access network (RAN) node typically acquires the static UE RAC from the UE only during a registration procedure. Then, the static UE RAC may be stored in a core network (CN) node so that the RAN node may retrieve the static UE RAC from the CN storage as needed in all subsequent connection phases. The design philosophy is to avoid high signaling load caused by UE capability transfer while benefiting a UE mobility model.

[0004] There are two standardized ways to change or update the UE RAC in different scopes and degrees across the RAN and the CN. The first standardized way is to initiate a particular non-access stratum (NAS) signaling procedure toward the CN node to delete the UE RAC storage so that the RAN is unable to retrieve an old UE RAC in a subsequent connection phase. That is, the RAN would re-acquire a new UE RAC. This approach allows the UE to change the full range UE RAC at the cost of a longer latency but with a guarantee that subsequent connections between the UE and the RAN would be established based on the new UE RAC. The second standardized way, under network permission, through involves a UE Assistance Information (UAI) procedure for indicating a temporary “capability preferences” to the network. The second way is not a mandatory feature and these “capability preferences” are not compulsory to the network even though doable. Particularly, the temporary “capability preferences” tend to cover only some of the UE RACs, thus resulting in faster (compared to the first way) effect within the RAN scope (with the UE RAC storage in the CN remaining unchanged) .

[0005] Despite the aforementioned two standardized ways, it would be beneficial to have method (s) and / or techniques that support a unified framework to change the UE RAC in a wide range of user scenarios in a UE-initiated way with immediate effect honored by the network, regardless of whether the RAC change is permanent or temporary and full or partial. Therefore, there is a need for a solution of supporting dynamic change for UE capability reporting in mobile communications.SUMMARY

[0006] The following summary is illustrative only and is not intended to be limiting in any way. That is, the following summary is provided to introduce concepts, highlights, benefits, and advantages of the novel and non-obvious techniques described herein. Select implementations are further described below in the detailed description. Thus, the following summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.

[0007] An objective of the present disclosure is to propose solutions or schemes that address the issue (s) described herein. More specifically, various schemes proposed in the present disclosure are believed to provide solutions pertaining to supporting dynamic change for UE capability reporting in mobile communications. It is believed that implementations of one or more of the schemes proposed herein may address or otherwise alleviate the issues described above.

[0008] In one aspect, a method may involve a UE communicating with a network to request to effect a capability change in the UE. The method may also involve the UE operating with a changed capability responsive to the network accepting the capability change.

[0009] In another aspect, a method may involve a network receiving, from a UE, a capability change request message including a set of capability change information requesting to effect a capability change in the UE. The method may also involve the network determining, based on the set of capability change information, a set of network response information comprising a control command and an information element (IE) . The method may further involve the network transmitting, to the UE, a capability change confirmation message including the set of network response information responsive to admitting the capability change as a step of a connection control procedure.

[0010] It is noteworthy that, although the description provided herein may be in the context of certain radio access technologies, networks, and network topologies such as 5th Generation (5G) New Radio (NR)  / Beyond Fifth-Generation (B5G)  / 6th Generation (6G) mobile communications, the proposed concepts, schemes and any variation (s)  / derivative (s) thereof may be implemented in, for and by other types of radio access technologies, networks and network topologies such as, for example and without limitation, next-generation communication systems, 4th Generation (4G)  / Long-Term Evolution (LTE) , LTE-Advanced, LTE-Advanced Pro, Internet-of-Things (IoT) , Narrow Band Internet of Things (NB-IoT) , Industrial Internet of Things (IIoT) , vehicle-to-everything (V2X) , and non-terrestrial network (NTN) communications. Thus, the scope of the present disclosure is not limited to the examples described herein.BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The accompanying drawings are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of the present disclosure. The drawings illustrate implementations of the disclosure and, together with the description, serve to explain the principles of the disclosure. It is appreciable that the drawings are not necessarily in scale as some components may be shown to be out of proportion than the size in actual implementation in order to clearly illustrate the concept of the present disclosure.

[0012] FIG. 1 is a diagram of an example network environment in which various solutions and schemes in accordance with the present disclosure may be implemented.

[0013] FIG. 2 is a diagram of an example scenario under a proposed scheme in accordance with the present disclosure.

[0014] FIG. 3 is a diagram of an example scenario under a proposed scheme in accordance with the present disclosure.

[0015] FIG. 4 is a diagram of an example scenario under a proposed scheme in accordance with the present disclosure.

[0016] FIG. 5 is a diagram of an example scenario under a proposed scheme in accordance with the present disclosure.

[0017] FIG. 6 is a diagram of an example scenario under a proposed scheme in accordance with the present disclosure.

[0018] FIG. 7 is a diagram of an example scenario under a proposed scheme in accordance with the present disclosure.

[0019] FIG. 8 is a diagram of an example scenario under a proposed scheme in accordance with the present disclosure.

[0020] FIG. 9 is a block diagram of an example communication system under a proposed scheme in accordance with the present disclosure.

[0021] FIG. 10 is a flowchart of an example process under a proposed scheme in accordance with the present disclosure.

[0022] FIG. 11 is a flowchart of an example process under a proposed scheme in accordance with the present disclosure. DETAILED DESCRIPTION OF PREFERRED IMPLEMENTATIONS

[0023] Detailed embodiments and implementations of the claimed subject matters are disclosed herein. However, it shall be understood that the disclosed embodiments and implementations are merely illustrative of the claimed subject matters which may be embodied in various forms. The present disclosure may, however, be embodied in many different forms and should not be construed as limited to the exemplary embodiments and implementations set forth herein. Rather, these exemplary embodiments and implementations are provided so that description of the present disclosure is thorough and complete and will fully convey the scope of the present disclosure to those skilled in the art. In the description below, details of well-known features and techniques may be omitted to avoid unnecessarily obscuring the presented embodiments and implementations. Overview

[0024] Implementations in accordance with the present disclosure relate to various techniques, methods, schemes and / or solutions pertaining to supporting dynamic change for UE capability reporting in mobile communications. According to the present disclosure, a number of possible solutions may be implemented separately or jointly. That is, although these possible solutions may be described below separately, two or more of these possible solutions may be implemented in one combination or another.

[0025] It is noteworthy that, while the various proposed schemes may be individually or separately described below, in actual implementations some or all of the proposed schemes may be utilized or otherwise implemented jointly. Of course, each of the proposed schemes may be utilized or otherwise implemented individually or separately.

[0026] FIG. 1 illustrates an example network environment 100 in which various solutions and schemes in accordance with the present disclosure may be implemented. FIG. 2 ～ FIG. 11 illustrate examples of implementation of various proposed schemes in network environment 100 in accordance with the present disclosure. The following description of various proposed schemes is provided with reference to FIG. 1 ～ FIG. 11.

[0027] Referring to FIG. 1, example network environment 100 may include a 6G wireless system with centralization of upper layers of NR radio stacks in accordance with embodiments of the present disclosure. FIG. 1 may pertain to a high-level network architecture showing logical network nodes including core network (CN) , central unit (CU) , distributed unit (DU) , and UE. A so-called “cell” may be formed by a radio unit (RU) , which may be integrated with a respective cell and not explicitly shown in FIG. 1, to serve the UE. On one hand, as per network request, the UE may report the UE capability information to the network. On the other hand, the UE may need to change its radio access capabilities due to one or more various reasons such as, for example and not limited to, overheating, power saving, one or more other use cases driven by an intent of a user of the UE, a variation in network connection configurations, and / or an availability of one or more subscriber identity modules (SIMs) . That is, the radio access capabilities of a UE may be dynamically changed according to variant connection configurations towards two networks (e.g., a 5G network and a 6G network) under different deployments scenarios. For example, the UE (e.g., UE2 in FIG. 1) may lower its maximum supported multi-input-multiple-output (MIMO) layer to throttle data throughput, thereby changing the UE’s radio access capabilities due to a high modem chip temperature when the UE connects to a cell (e.g., Cell 7 in FIG. 1) using carrier aggregation (CA) .

[0028] FIG. 2 illustrates an example scenario 200 under a proposed scheme in accordance with the present disclosure. Scenario 200 may pertain to an exemplary message sequence for a UE to send a capability change request message to a network so that a UE capability information transfer procedure may be initiated by the network under the proposed scheme.

[0029] Referring to FIG. 2, when connected to a network, a UE (e.g., UE1 or UE2 of FIG. 1) may send a UE-initiated capability change request to the network. More specifically, when the UE intends to change its radio access capabilities, the UE may first send a request message (UECapabilityChangeRequest) to the network. The network may then accept the UE capability change request by responding with an acceptance message (UECapabilityChangeAccept) . Subsequently, the changed UE capability may take effect and then a radio resource control (RRC) reconfiguration procedure may be expected. The network may honor the UE capability change if the UE confines the changed capability parameters to a predefined or a mutually-agreed scope (e.g., within a predefined scope) . When the capability change is permanent, the UE may use an indicator, or a flag carried in the UECapabilityChangeRequest message, to indicate and trigger the network to re-acquire the new (changed) UE capability information. Once the new (changed) UE capability information is received by the radio access network (RAN) , the RAN may further update a UE capability storage in the CN, in addition to updating a local UE context.

[0030] FIG. 3 illustrates an example scenario 300 under a proposed scheme in accordance with the present disclosure. Scenario 300 may pertain to an exemplary message sequence for a UE to send a capability change request message to a network so that a UE capability information transfer procedure may be initiated by piggybacking the UE capability enquiry message in a network response message under the proposed scheme.

[0031] Referring to FIG. 3, which may be an enhancement of scenario 200 of FIG. 2, a subsequent UE capability inquiry message (UECapabilityEnquiry) may be piggybacked in the UECapabilityChangeAccept message so that the entire UE capability change, as well as the transfer procedure, may be performed with a shorter latency.

[0032] FIG. 4 illustrates an example scenario 400 under a proposed scheme in accordance with the present disclosure. Scenario 400 may pertain to an exemplary message sequence for a UE to send a capability change request message with one or more changed parameters to a network directly under the proposed scheme. In scenario 400, the UE capability change may be temporary.

[0033] Referring to FIG. 4, a UE (e.g., UE1 or UE2 of FIG. 1) may directly include one or more changed capability parameters in the UECapabilityChangeRequest to the network. With the preconditions, the network may honor the UE capability change by responding with a UECapabilityChangeAccept message and update its local UE context without touching the CN storage. When the event requiring or otherwise causing UE capability change is over, the UE may send another UECapabilityChangeRequest to indicate the end of temporary capability change, either explicitly by an indication or flag, or implicitly by an empty message content.

[0034] FIG. 5 illustrates an example scenario 500 under a proposed scheme in accordance with the present disclosure. Scenario 500 may pertain to an exemplary message sequence for a UE to send a RRC reestablishment request message with a capability change indication to a network directly, while the network cannot accept it, such that a subsequent RRC setup procedure may be initiated followed by a UE capability information transfer procedure under the proposed scheme. Scenario 500 may be an alternative of the UE capability change procedure in scenario 200 of FIG. 2.

[0035] Referring to FIG. 5, a RRC reestablishment request message (RRCReestablishmentRequest) may be expanded to carry the UE capability change information including a request indication (e.g., a flag “ueCapabilityChangeNeeded” as shown in FIG. 5) and a change type (e.g., a type “permanent” as shown in FIG. 5) . In case that the network cannot accept the UE capability change on-the-fly, the network may use a RRC setup message (RRCSetup) to deliver a predefined basic connection configuration as a common fallback configuration in both sides for status synchronization guarantee, while a usual reestablishment procedure proceeds. This proposed scheme may be particularly beneficial in cases where the UE physically (and instantaneously) changes its radio access capability without sufficient time to align with the network (e.g., a folding phone use case) . The network may re-acquire the new (changed) UE capability right after the reestablishment of the RRC connection.

[0036] FIG. 6 illustrates an example scenario under a proposed scheme in accordance with the present disclosure. Scenario 600 may pertain to an exemplary message sequence for a UE to send a RRC reestablishment request message with a capability change indication and one or more changed capability parameters to a network, such that a subsequent RRC reestablishment message may carry one or more new configuration parameters accordingly, under the proposed scheme.

[0037] Referring to FIG. 6, the network may accept the temporary UE capability change through the RRC Reestablishment procedure. Similar with the aforesaid description, the change indication, change type, and the changed parameter (s) may be included in the RRCReestablishmentRequest. The network may honor the request and directly include the new (updated based on the changed UE capabilities) configuration through a RRC reestablishment message (RRCReestablishment) to the UE as an acknowledgement to the change request.

[0038] FIG. 7 illustrates an example scenario under a proposed scheme in accordance with the present disclosure. Scenario 700 may pertain to an exemplary message sequence for a UE in inter-radio access technology (inter-RAT) mobility to use a UE capability change procedure for UE capability coordination of two RAT networks under the proposed scheme.

[0039] In scenario 700, the UE capability change procedure in accordance with the present disclosure may be used between the UE’s two connections to a multi-RAT network (e.g., a 5G network and a 6G network) . Since the UE hardware and / or software resource is fixed and shared between two RATs, the UE-centric capability coordination between two RAT networks through the UE capability change procedure may be crucial for maximizing data throughput and performance in terms of user experience. This may improve the network key performance indicators (KPIs) for the sake of efficient radio resource management.

[0040] Referring to FIG. 7, a UE (e.g., UE1 or UE2 of FIG. 1) may initially be connected to a first network (e.g., 5G network) . The UE may send a UECapabilityChangeRequest to the first network to request for a temporary change of one or more parameters (e.g., so that the UE may also be able to simultaneously connect to a second network and the first network at a later time) . Upon acceptance by the first network, the UE may connect with the second network (e.g., 6G network) and send another UECapabilityChangeRequest to the second network to request for a temporary change of one or more parameters, which may be accepted by the second network.

[0041] FIG. 8 illustrates an example scenario under a proposed scheme in accordance with the present disclosure. Scenario 800 may pertain to an exemplary message sequence for a UE in a dual-SIM user scenario to use a UE capability change procedure for UE capability coordination of two camped networks under the proposed scheme.

[0042] In scenario 800, the UE capability change procedure in accordance with the present disclosure may be used between the UE’s two connections to multiple network nodes of the networks corresponding to multiple SIMs (e.g., a first SIM (SIM1) network and at least a second SIM (SIM2) network) . Since the UE hardware and / or software resource is fixed and shared between two or more (e.g., three, four, five or more) SIMs, the UE-centric capability coordination between two SIM networks through the UE capability change procedure may be crucial for maximizing data throughput and performance in terms of user experience. This may improve the network KPIs for the sake of efficient radio resource management.

[0043] Referring to FIG. 8, a UE (e.g., UE1 or UE2 of FIG. 1) may initially be connected to a first network associated with a first SIM (e.g., SIM1 network) . The UE may send a UECapabilityChangeRequest to the first network to request for a temporary change of one or more parameters (e.g., so that the UE may also be able to simultaneously connect to one or more additional networks (e.g., a second network) associated with one or more additional SIMs, including a second SIM (e.g., SIM2 network) ) . Upon acceptance by the first network, the UE may connect with the second network and send another UECapabilityChangeRequest to the second network to request for a temporary change of one or more parameters, which may be accepted by the second network.

[0044] Under the various proposed schemes in accordance with the present disclosure, a UE may determine, from one or more supported radio access capabilities, a set of capability change information of one or more changing parameters of the supported one or more radio access capabilities. The UE may transmit, to a network node of a network, the capability change request message including a set of capability change information. In response to sending the capability change request message, the UE may receive, from the network node, a capability change confirmation message including a set of network response information.

[0045] In some implementations, in determining, the UE may monitor a condition and compare the condition to a previous state. For instance, the UE may monitor associated with the UE and compare results in a sustained alteration, or a limited duration, of the radio access capabilities including a change type information to either permanence or temporariness.

[0046] In some implementations, the UE may also determine a user-intent-based priority information.

[0047] In some implementations, the capability change request message may include or otherwise indicate the change type information, the user-intent-based priority information, and / or the changing parameter (s) .

[0048] In some implementations, the sending of the capability change request message may be a step of a connection control procedure using a connection control message. In some implementations, the connection control message may include a capability change indication, the change type information, the user-intent-based priority information, and / or the changing parameters.

[0049] In some implementations, the network response information may include a UE capability transfer message to re-acquire the UE capability information.

[0050] In some implementations, the receiving of the capability change confirmation message may include receiving a connection control message, a medium access control (MAC) layer signaling, or a physical (PHY) layer signaling. In some implementations, the connection control message may include a connection configuration information in response to the capability change, from the first network node. In some implementations, the MAC layer signaling or the physical layer signaling may include the control information in response to the capability change, from the first network node.

[0051] Under the various proposed schemes in accordance with the present disclosure, a network node (e.g., a base station, eNB or gNB) of a network may receive, from a UE, a capability change request message including a set of capability change information. The network node may determine, from the set of capability change information, a network response information including a control command or an information element (IE) . The network node may admit or accept the request as a step of a connection control procedure. The network node may then send, to the UE, a capability change confirmation message including a set of network response information.

[0052] In some implementations, in determining the network response information, the network node may inspect the set of capability change information in view of the scope of the capability change, the current connection configuration, and the status of the network node operation.

[0053] In some implementations, in admitting or accepting, the network node may examine the user-intent-based priority information in accordance with results of the determining, as a decision of preparing one or more subsequent connection control procedures.

[0054] In some implementations, in sending the capability change confirmation message, the network may piggyback a UE capability transfer message in the capability change confirmation message.

[0055] In some implementations, the network node may also send, to the UE, a connection control message, a MAC layer signaling, or a PHY layer signaling including the control command or the IE.

[0056] In some implementations, the network node may further send, to the CN, an inter-node message including the UE capability information to update the storage.

[0057] In some implementations, the network node may further perform, with the UE, a RRC connection reestablishment procedure which is used when the capability change is not honored by the network node.

[0058] In some implementations, multiple network nodes of the network may be in the same RAT or multiple RATs in serving either the same SIM or the multiple SIMs, individually or simultaneously. Feature Highlight

[0059] In view of the above, certain features under various proposed schemes in accordance with the present disclosure are highlighted below.

[0060] In one aspect, a UE may initiate a capability change request to a network to temporarily or permanently change a UE RAC. In one embodiment, a capability change request may be sent by the UE to the network via a new RRC signaling. In one embodiment, the capability change request may be carried by a legacy RRC signaling. The temporary UE RAC change may take effect in a RAN node only if it is honored and accepted by the RAN node. As per deterministic network behaviors in response to the UE capability change, the UE may anticipate and handle one or more subsequent Layer 3 RRC procedures such as, for example, RRC reconfiguration (RRCReconfiguration) messages if an ongoing RRC connection reconfiguration is needed, or Layer 2 signaling such as, for example, MAC control element (CE) and Layer 1 signaling such as downlink control information (DCI) if the lower layers adjustment is sufficient, after the temporary UE RAC change initiated by the UE. The permanent UE RAC change may take effect in the scope of an entire registration area so that both non-access stratum (NAS) and access stratum (AS) (e.g., RRC) connections may be changed or otherwise updated, if necessary.

[0061] In another aspect, a network node of a network may receive a capability change request from a UE to temporarily or permanently change a UE RAC. In one embodiment, the permanent capability change request may be accepted and responded by a new RRC signaling (e.g., as an acknowledgement of the transaction) . The network may subsequently re-acquire the changed UE RAC and further forward it to the CN to replace a current UE RAC in a storage. In one embodiment, the temporary capability change request may be honored by a RAN node locally and acknowledged via a new RRC signaling as a confirmation. For the permanent UE RAC change, both NAS and AS (e.g., RRC) level connections may be affected so that they may be further reconfigured or otherwise updated according to the latest UE RAC. For the temporary UE RAC change, only the AS (e.g., RRC) level connection may be reconfigured accordingly.

[0062] In some embodiments, the scope of the capability change may encompass the full range of the UE RAC, e.g., all the capability parameters contained in the UE RAC. In different embodiments, the scope of the capability change may be limited to a part of the UE RAC, e.g., some of the capability parameters contained in the UE RAC.

[0063] The network’s refusal to the UE capability change request may be undefined if a mutual agreement between the UE and the network is reached on the capability change with a limited scope. In one embodiment, the network may always accept the UE capability change request as long as all the capabilities changed are within an agreed scope, e.g., only the limited capability parameters that the network accepts and agrees are allowed to be changed regardless temporarily or permanently on the UE side. In different embodiments, the network’s refusal may still be allowed if the network is not in a proper state for honoring the UE capability change request. If the UE receives the network’s refusal, the procedure stops immediately. Instead, UE may take implementation-based approaches and manage to handle the need of capability change.

[0064] The capability change information (e.g., the changed capability parameter (s) ) may be transferred along with the UE context when UE mobility occurs between the different network nodes. There may be a protection timer guarding against an abnormal situation where the capability change information is not properly transferred to the target network node. The UE may thus repeat the UE capability change request procedure toward the serving network node after mobility. Illustrative Implementations

[0065] FIG. 9 illustrates an example communication system 900 having at least an example apparatus 910 and an example apparatus 920 in accordance with an implementation of the present disclosure. Each of apparatus 910 and apparatus 920 may perform various functions to implement schemes, techniques, processes and methods described herein pertaining to supporting dynamic change for UE capability reporting in mobile communications, including the various schemes described above with respect to various proposed designs, concepts, schemes, systems and methods described above, including network environment 100, as well as processes described below.

[0066] Each of apparatus 910 and apparatus 920 may be a part of an electronic apparatus, which may be a network apparatus or a UE (e.g., UE1 or UE2 in FIG. 1) , such as a portable or mobile apparatus, a wearable apparatus, a vehicular device or a vehicle, a wireless communication apparatus or a computing apparatus. For instance, each of apparatus 910 and apparatus 920 may be implemented in a smartphone, a smart watch, a personal digital assistant, an electronic control unit (ECU) in a vehicle, a digital camera, or a computing equipment such as a tablet computer, a laptop computer or a notebook computer. Each of apparatus 910 and apparatus 920 may also be a part of a machine type apparatus, which may be an IoT apparatus such as an immobile or a stationary apparatus, a home apparatus, a roadside unit (RSU) , a wire communication apparatus or a computing apparatus. For instance, each of apparatus 910 and apparatus 920 may be implemented in a smart thermostat, a smart fridge, a smart door lock, a wireless speaker or a home control center. When implemented in or as a network apparatus, apparatus 910 and / or apparatus 920 may be implemented in an eNB in an LTE, LTE-Advanced or LTE-Advanced Pro network or in a gNB or TRP in a 5G network, an NR network, or an IoT network.

[0067] In some implementations, each of apparatus 910 and apparatus 920 may be implemented in the form of one or more integrated-circuit (IC) chips such as, for example and without limitation, one or more single-core processors, one or more multi-core processors, one or more complex-instruction-set-computing (CISC) processors, or one or more reduced-instruction-set-computing (RISC) processors. In the various schemes described above, each of apparatus 910 and apparatus 920 may be implemented in or as a network apparatus or a UE. Each of apparatus 910 and apparatus 920 may include at least some of those components shown in FIG. 9 such as a processor 912 and a processor 922, respectively, for example. Each of apparatus 910 and apparatus 920 may further include one or more other components not pertinent to the proposed scheme of the present disclosure (e.g., internal power supply, display device and / or user interface device) , and, thus, such component (s) of apparatus 910 and apparatus 920 are neither shown in FIG. 9 nor described below in the interest of simplicity and brevity.

[0068] In one aspect, each of processor 912 and processor 922 may be implemented in the form of one or more single-core processors, one or more multi-core processors, or one or more CISC or RISC processors. That is, even though a singular term “a processor” is used herein to refer to processor 912 and processor 922, each of processor 912 and processor 922 may include multiple processors in some implementations and a single processor in other implementations in accordance with the present disclosure. In another aspect, each of processor 912 and processor 922 may be implemented in the form of hardware (and, optionally, firmware) with electronic components including, for example and without limitation, one or more transistors, one or more diodes, one or more capacitors, one or more resistors, one or more inductors, one or more memristors and / or one or more varactors that are configured and arranged to achieve specific purposes in accordance with the present disclosure. In other words, in at least some implementations, each of processor 912 and processor 922 is a special-purpose machine specifically designed, arranged, and configured to perform specific tasks including those pertaining to supporting dynamic change for UE capability reporting in mobile communications in accordance with various implementations of the present disclosure.

[0069] In some implementations, apparatus 910 may also include a transceiver 916 coupled to processor 912. Transceiver 916 may be capable of wirelessly transmitting and receiving data. In some implementations, transceiver 916 may be capable of wirelessly communicating with different types of wireless networks of different radio access technologies (RATs) . In some implementations, transceiver 916 may be equipped with a plurality of antenna ports (not shown) such as, for example, four antenna ports. That is, transceiver 916 may be equipped with multiple transmit antennas and multiple receive antennas for multiple-input multiple-output (MIMO) wireless communications. In some implementations, apparatus 920 may also include a transceiver 926 coupled to processor 922. Transceiver 926 may include a transceiver capable of wirelessly transmitting and receiving data. In some implementations, transceiver 926 may be capable of wirelessly communicating with different types of UEs / wireless networks of different RATs. In some implementations, transceiver 926 may be equipped with a plurality of antenna ports (not shown) such as, for example, four antenna ports. That is, transceiver 926 may be equipped with multiple transmit antennas and multiple receive antennas for MIMO wireless communications.

[0070] In some implementations, apparatus 910 may further include a memory 914 coupled to processor 912 and capable of being accessed by processor 912 and storing data therein. In some implementations, apparatus 920 may further include a memory 924 coupled to processor 922 and capable of being accessed by processor 922 and storing data therein. Each of memory 914 and memory 924 may include a type of random-access memory (RAM) such as dynamic RAM (DRAM) , static RAM (SRAM) , thyristor RAM (T-RAM) and / or zero-capacitor RAM (Z-RAM) . Alternatively, or additionally, each of memory 914 and memory 924 may include a type of read-only memory (ROM) such as mask ROM, programmable ROM (PROM) , erasable programmable ROM (EPROM) and / or electrically erasable programmable ROM (EEPROM) . Alternatively, or additionally, each of memory 914 and memory 924 may include a type of non-volatile random-access memory (NVRAM) such as flash memory, solid-state memory, ferroelectric RAM (FeRAM) , magnetoresistive RAM (MRAM) and / or phase-change memory.

[0071] Each of apparatus 910 and apparatus 920 may be a communication entity capable of communicating with each other using various proposed schemes in accordance with the present disclosure. For illustrative purposes and without limitation, a description of capabilities of apparatus 910, as a UE (e.g., UE1 or UE2) , and apparatus 920, as a network node (e.g., eNB or gNB) of a network (e.g., a multi-RAT or multi-SIM network) , is provided below in the context of example processes 1000 and 1100. Illustrative Processes

[0072] FIG. 10 illustrates an example process 1000 in accordance with an implementation of the present disclosure. Process 1000 may represent an aspect of implementing various proposed designs, concepts, schemes, systems and methods described above. More specifically, process 1000 may represent an aspect of the proposed concepts and schemes pertaining to supporting dynamic change for UE capability reporting in mobile communications in accordance with the present disclosure. Process 1000 may include one or more operations, actions, or functions as illustrated by one or more of blocks 1010 and 1020. Although illustrated as discrete blocks, various blocks of process 1000 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks / sub-blocks of process 1000 may be executed in the order shown in FIG. 10 or, alternatively, in a different order. Furthermore, one or more of the blocks / sub-blocks of process 1000 may be executed repeatedly or iteratively. Process 1000 may be implemented by or in apparatus 910 and apparatus 920 as well as any variations thereof. Solely for illustrative purposes and without limiting the scope, process 1000 is described below in the context of apparatus 910 as a UE (e.g., UE1 or UE2) and apparatus 920 as a communication entity such as a network node (e.g., non-terrestrial network node or terrestrial network node) of a network (e.g., a multi-RAT or multi-SIM network) . Process 1000 may begin at block 1010.

[0073] At 1010, process 1000 may involve processor 912 of apparatus 910, as a UE, communicating, via transceiver 916, with a network (e.g., via apparatus 920 as a network node) to request to effect a capability change in the UE. Process 1000 may proceed from 1010 to 1020.

[0074] At 1020, process 1000 may involve processor 912 operating, via transceiver 916, with a changed capability responsive to the network accepting the capability change.

[0075] In some implementations, in communicating with the network, process 1000 may involve processor 912 performing certain operations. For instance, process 1000 may involve processor 912 determining, from one or more supported RACs, a set of capability change information of one or more changing parameters of the supported one or more RACs. Additionally, process 1000 may involve processor 912 transmitting, to the network, a capability change request message including the set of capability change information. Moreover, process 1000 may involve processor 912 receiving, from the network, a capability change confirmation message including a set of network response information.

[0076] In some implementations, in determining, process 1000 may involve processor 912 performing certain operations. For instance, process 1000 may involve processor 912 monitoring a condition associated with the UE. Furthermore, process 1000 may involve processor 912 comparing the condition to a previous state to determine information of either or both of: (a) a type of the capability change as being temporary or permanent; and (b) a user-intent-based priority.

[0077] In some implementations, the condition associated with the UE may include one or more of the following: a temperature of the UE, a power consumption status, a use case driven by an intent of a user, a variation in network connection configurations, and / or an availability of one or more SIMs.

[0078] In some implementations, the capability change request message may include at least one of the following: (a) the one or more changing parameters; and (b) the information of either or both of the type of the capability change as being temporary or permanent and the user-intent-based priority.

[0079] In some implementations, in transmitting the capability change request message, process 1000 may involve processor 912 transmitting a connection control message as a part of a connection control procedure. In such cases, the connection control message may include a capability change indication, a type of the capability change, a user-intent-based priority, and the one or more changing parameters.

[0080] In some implementations, in receiving the capability change confirmation message, process 1000 may involve processor 912 receiving a UE capability transfer message so that the network re-acquires UE capability information.

[0081] In some implementations, in receiving the capability change confirmation message, process 1000 may involve processor 912 receiving a connection control message, a MAC layer signaling, or a PHY layer signaling.

[0082] In some implementations, the capability change confirmation message may include a connection configuration information provided by the network to effect the capability change.

[0083] In some implementations, in operating with the changed capability, process 1000 may involve processor 912 communicating with multiple network nodes of a same RAT or different RATs as the multiple network nodes serve a SIM or multiple SIMs, individually or simultaneously.

[0084] FIG. 11 illustrates an example process 1100 in accordance with an implementation of the present disclosure. Process 1100 may represent an aspect of implementing various proposed designs, concepts, schemes, systems and methods described above. More specifically, process 1100 may represent an aspect of the proposed concepts and schemes pertaining to supporting dynamic change for UE capability reporting in mobile communications in accordance with the present disclosure. Process 1100 may include one or more operations, actions, or functions as illustrated by one or more of blocks 1110, 1120 and 1130. Although illustrated as discrete blocks, various blocks of process 1100 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks / sub-blocks of process 1100 may be executed in the order shown in FIG. 11 or, alternatively, in a different order. Furthermore, one or more of the blocks / sub-blocks of process 1100 may be executed repeatedly or iteratively. Process 1100 may be implemented by or in apparatus 910 and apparatus 920 as well as any variations thereof. Solely for illustrative purposes and without limiting the scope, process 1100 is described below in the context of apparatus 910 as a UE (e.g., UE1 or UE2) and apparatus 920 as a communication entity such as a network node (e.g., non-terrestrial network node or terrestrial network node) of a network (e.g., a multi-RAT or multi-SIM network) . Process 1100 may begin at block 1110.

[0085] At 1110, process 1100 may involve processor 922 of apparatus 920, as a network node of a network, receiving, via transceiver 926, from a UE (e.g., apparatus 910) a capability change request message including a set of capability change information requesting to effect a capability change in the UE. Process 1100 may proceed from 1110 to 1120.

[0086] At 1120, process 1100 may involve processor 922 determining, based on the set of capability change information, a set of network response information comprising a control command and an IE. Process 1100 may proceed from 1120 to 1130.

[0087] At 1130, process 1100 may involve processor 922 transmitting, via transceiver 926, to the UE a capability change confirmation message including the set of network response information responsive to admitting the capability change as a step of a connection control procedure.

[0088] In some implementations, in determining the set of network response information, process 1100 may involve processor 922 inspecting the set of capability change information in view of a scope of the capability change, a current connection configuration, and a status of the network node’s operation.

[0089] In some implementations, in determining the set of network response information, process 1100 may involve processor 922 determining whether to admit or accept the capability change based on the set of capability change information. Moreover, the set of capability change information may include a capability change indication, a type of the capability change, a user-intent-based priority, and one or more changing parameters.

[0090] In some implementations, in transmitting the capability change confirmation message, process 1100 may involve processor 922 piggybacking a UE capability transfer message in the capability change confirmation message.

[0091] In some implementations, process 1100 may further involve processor 922 transmitting, via transceiver 926, to the UE a connection control message, a MAC layer signaling, or a PHY layer signaling including the control command or the information element.

[0092] In some implementations, process 1100 may further involve processor 922 transmitting, via transceiver 926, to a CN an inter-node message including the UE’s capability information to update a storage.

[0093] In some implementations, process 1100 may further involve processor 922 performing, via transceiver 926, with the UE a RRC connection reestablishment procedure responsive to not admitting the capability change.

[0094] In some implementations, process 1100 may further involve processor 922 communicating, via transceiver 926, with the UE as the UE operates with a changed capability such that the UE communicates with multiple network nodes of a same RAT or different RATs in serving a SIM or multiple SIMs, individually or simultaneously. Additional Notes

[0095] The herein-described subject matter sometimes illustrates different components contained within, or connected with, different other components. It is to be understood that such depicted architectures are merely examples, and that in fact many other architectures can be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated can also be viewed as being "operably connected" , or "operably coupled" , to each other to achieve the desired functionality, and any two components capable of being so associated can also be viewed as being "operably couplable" , to each other to achieve the desired functionality. Specific examples of operably couplable include but are not limited to physically mateable and / or physically interacting components and / or wirelessly interactable and / or wirelessly interacting components and / or logically interacting and / or logically interactable components.

[0096] Further, with respect to the use of substantially any plural and / or singular terms herein, those having skill in the art can translate from the plural to the singular and / or from the singular to the plural as is appropriate to the context and / or application. The various singular / plural permutations may be expressly set forth herein for sake of clarity.

[0097] Moreover, it will be understood by those skilled in the art that, in general, terms used herein, and especially in the appended claims, e.g., bodies of the appended claims, are generally intended as “open” terms, e.g., the term “including” should be interpreted as “including but not limited to, ” the term “having” should be interpreted as “having at least, ” the term “includes” should be interpreted as “includes but is not limited to, ” etc. It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim recitation to implementations containing only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an, " e.g., “a” and / or “an” should be interpreted to mean “at least one” or “one or more; ” the same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number, e.g., the bare recitation of "two recitations, " without other modifiers, means at least two recitations, or two or more recitations. Furthermore, in those instances where a convention analogous to “at least one of A, B, and C, etc. ” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention, e.g., “a system having at least one of A, B, and C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. In those instances where a convention analogous to “at least one of A, B, or C, etc. ” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention, e.g., “a system having at least one of A, B, or C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. It will be further understood by those within the art that virtually any disjunctive word and / or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase “A or B” will be understood to include the possibilities of “A” or “B” or “A and B. ”

[0098] From the foregoing, it will be appreciated that various implementations of the present disclosure have been described herein for purposes of illustration, and that various modifications may be made without departing from the scope and spirit of the present disclosure. Accordingly, the various implementations disclosed herein are not intended to be limiting, with the true scope and spirit being indicated by the following claims.

Claims

1.A method of capability change in a user equipment (UE) , comprising:communicating, by a processor of the UE, with a network to request to effect a capability change in the UE; andoperating, by the processor, with a changed capability responsive to the network accepting the capability change.2.The method of Claim 1, wherein the communicating with the network comprises:determining, from one or more supported radio access capabilities (RACs) , a set of capability change information of one or more changing parameters of the supported one or more RACs;transmitting, to the network, a capability change request message including the set of capability change information; andreceiving, from the network, a capability change confirmation message including a set of network response information.3.The method of Claim 2, wherein the determining comprises:monitoring a condition associated with the UE; andcomparing the condition to a previous state to determine information of either or both of:a type of the capability change as being temporary or permanent; anda user-intent-based priority.4.The method of Claim 3, wherein the condition associated with the UE comprises one or more of a temperature of the UE, a power consumption status, a use case driven by an intent of a user, a variation in network connection configurations, or an availability of one or more subscriber identity modules (SIMs) .5.The method of Claim 3, wherein the capability change request message includes at least one of:the one or more changing parameters; andthe information of either or both of the type of the capability change as being temporary or permanent and the user-intent-based priority.6.The method of Claim 2, wherein the transmitting of the capability change request message comprises transmitting a connection control message as a part of a connection control procedure, and wherein the connection control message comprises a capability change indication, a type of the capability change, a user-intent-based priority, and the one or more changing parameters.7.The method of Claim 6, wherein the receiving of the capability change confirmation message comprises receiving a UE capability transfer message so that the network re-acquires UE capability information.8.The method of Claim 2, wherein the receiving of the capability change confirmation message comprises receiving a connection control message, a medium access control (MAC) layer signaling, or a physical (PHY) layer signaling.9.The method of Claim 2, wherein the capability change confirmation message comprises a connection configuration information provided by the network to effect the capability change.10.The method of Claim 1, wherein the operating with the changed capability comprises communicating with multiple network nodes of a same radio access technology (RAT) or different RATs as the multiple network nodes serve a subscriber identity module (SIM) or multiple SIMs, individually or simultaneously.11.A method of capability change in a network node of a network, comprising:receiving, by a processor of the network node, from the UE a capability change request message including a set of capability change information requesting to effect a capability change in the UE;determining, by the processor based on the set of capability change information, a set of network response information comprising a control command and an information element (IE) ; andtransmitting, by the processor, to the UE a capability change confirmation message including the set of network response information responsive to admitting the capability change as a step of a connection control procedure.12.The method of Claim 11, wherein the determining of the set of network response information comprises inspecting the set of capability change information in view of a scope of the capability change, a current connection configuration, and a status of the network node’s operation.13.The method of Claim 11, wherein the determining of the set of network response information comprises determining whether to admit or accept the capability change based on the set of capability change information, and wherein the set of capability change information comprises a capability change indication, a type of the capability change, a user-intent-based priority, and one or more changing parameters.14.The method of Claim 11, wherein the transmitting of the capability change confirmation message comprises piggybacking a UE capability transfer message in the capability change confirmation message.15.The method of Claim 11, further comprising:transmitting, by the processor, to the UE a connection control message, a medium access control (MAC) layer signaling, or a physical (PHY) layer signaling including the control command or the information element.16.The method of Claim 11, further comprising:transmitting, by the processor, to a core network (CN) an inter-node message including the UE’s capability information to update a storage.17.The method of Claim 11, further comprising:performing, by the processor, with the UE a radio resource control (RRC) connection reestablishment procedure responsive to not admitting the capability change.18.The method of Claim 11, further comprising:communicating, by the processor, with the UE as the UE operates with a changed capability such that the UE communicates with multiple network nodes of a same radio access technology (RAT) or different RATs in serving a subscriber identity module (SIM) or multiple SIMs, individually or simultaneously.19.An apparatus implementable in a user equipment (UE) , comprising:a transceiver configured to communicate wirelessly; anda processor coupled to the transceiver and configured to perform operations comprising:communicating, via the transceiver, with a network to request to effect a capability change in the UE; andoperating, via the transceiver, with a changed capability responsive to the network accepting the capability change.20.The apparatus of Claim 19, wherein the communicating with the network comprises:determining, from one or more supported radio access capabilities (RACs) , a set of capability change information of one or more changing parameters of the supported one or more RACs;transmitting, to the network, a capability change request message including the set of capability change information; andreceiving, from the network, a capability change confirmation message including a set of network response information.

Images