Method, device and system for user equipment capability confirmation query process

Abstract

A method, apparatus, and system for wireless communication capability confirmation are described. In one embodiment, a method performed by a wireless communication node for confirming capabilities of a wireless communication device includes: determining that a problem exists with a first capability of a first wireless communication device; sending a first capability confirmation query message to the first wireless communication device to query the first capability; receiving a capability confirmation reply message from the first wireless communication device, the capability confirmation reply message including information about the first capability; determining, based on the information about the first capability, that at least a portion of the first capability is a pseudo capability; and providing network resource configuration to avoid using or involving the pseudo capability of the first wireless communication device.

Description

Technical Field

[0001] The present disclosure relates generally to wireless communications, and more particularly, to methods, apparatuses, and systems for performing a user equipment (UE) capability confirmation query and subsequently configuring communications between the UE and a wireless communication network node (e.g., a base station (BS)) based on the query results. Background Art

[0002] In 3rd Generation Partnership Project (3GPP) cellular systems (such as Long Term Evolution (LTE) and New Radio (NR) systems), the network will configure network resources (e.g., time and frequency resources) for communicating with the UE based on the capabilities related to various features reported by the UE. As a specific example, a radio access network (RAN) node (e.g., gNB, ng-eNB, etc.) configures access stratum (AS) layer resources based on the radio access capabilities reported by the UE. In order to perform this configuration process securely, the network node initiates a "UE capability query" process, such as Figure 1 As shown. When a network node (e.g., gNB or ng-eNB) requires UE radio access capability information, the network node sends a UECapabilityEnquiry message to the UE when the UE is in the RRC_CONNECTED state. After receiving the UECapabilityEnquiry message (which may request capability information about certain UE features or aspects), the UE will report the UE capability information corresponding to these features or aspects via a UECapabiilityinformation message. Examples of UE radio access capability information include: "supportedBandCombinationList", "featureSets", and "featureSetCombinations" as known in the art.

[0003] Ideally, the capability information reported by the UE should reflect the real or actual capabilities of the UE, and the network can fully rely on these capabilities to configure specific features for the UE so that these features can be implemented or executed with expected behavior and performance characteristics. However, in reality, for specific air interface related features, even if the UE has reported its corresponding capabilities (e.g., support or non-support, and any further capability details) to the network node (e.g., base station), after the network later configures the UE to communicate with such features, the UE may not work or behave as expected. Traditionally, once the UE's capabilities are set and reported, the UE's hardware coding is fixed, so the UE cannot change its capability coding from, for example, "yes" to "no".

[0004] In addition to the above-mentioned "UE Capability Query" process, the UE can also report UE assistance information via the "UE Assistance Information" process after being enabled by the network via the Radio Resource Control (RRC) reconfiguration process, such as Figure 2 As shown. Traditionally, the purpose of this process is for the UE to notify the network of various types of information. Figure 2 As shown, the UE Assistance Information procedure is enabled or activated by the RRC reconfiguration procedure. The network node may enable the UE to send UE assistance information in an RRCReconfiguration message sent to the UE. Upon receiving the RRCReconfiguration message, the UE responds with an RRCReconfigurationComplete message. After being enabled in this way, the UE may initiate and report a UEAssistanceInformation message at any later time, which may then be used by the network to configure future communications with the UE.

[0005] However, currently, the "UE Assistance Information" procedure is not used to report UE capability information or any changes related to UE capabilities. Instead, the "UE Assistance Information" procedure is only used to report some AS configuration constraints or UE local expectations that the network should consider when configuring communications for the UE. In addition, the UE can locally change its encoding based on the assistance information according to the needs or characteristics of the UE.

[0006] As described above, for specific air interface related features, even if the UE has reported its corresponding feature capabilities (e.g., support or non-support, and any capability details) to a network node (e.g., a base station), when the network later configures network resources to support such UE features, the UE may not work or behave as expected. Currently, the network is unable to identify and debug the root cause of such performance degradation and deterioration of specific features, which may be due to certain defects and / or flaws associated with changes in UE capabilities related to the feature. For example, some capability details of the UE may not fully comply with the latest 3GPP standard version, or natural aging of the UE or hardware damage to the UE may cause performance degradation and "pseudo-capabilities" of the UE. As used herein, the term "pseudo-capability" refers to capability X that the UE should ideally support, as reported by the UE through the conventional "UE capability query" process, but in actual field operation, the UE does not support or only partially supports the capability X.

[0007] In current networks and mechanisms, for various practical reasons, the network cannot identify or know whether a UE is impaired. Consequently, the network cannot take appropriate adaptive measures to address the harmful effects of UE pseudo-capabilities. This prevents current networks from considering all possible "UE capability constraints" when configuring network resources for fully functional UEs, while also configuring network resources for impaired or defective UEs with pseudo-capabilities within security parameters. Summary of the Invention

[0008] The exemplary embodiments disclosed herein are intended to solve problems related to one or more problems raised in the prior art, as well as to provide additional features that will become apparent by reference to the following detailed description when taken in conjunction with the accompanying drawings. According to various embodiments, exemplary systems, methods, devices, and computer program products are disclosed herein. However, it should be understood that these embodiments are presented by way of example and not limitation, and it will be apparent to those of ordinary skill in the art reading this disclosure that various modifications may be made to the disclosed embodiments while remaining within the scope of this disclosure.

[0009] In some embodiments, the network can identify defective or flawed UEs with one or more pseudo-capabilities so that future configuration of such defective or flawed UEs within safety parameters can take such pseudo-capabilities into account, or avoid certain features that the UE no longer fully supports. In further embodiments, the network identifies and debugs the root cause of performance degradation of a particular feature due to a defect or flaw in the UE's related capabilities. In other embodiments, to identify defective or flawed UEs with one or more pseudo-capabilities, a novel method for performing UE capability confirmation queries is disclosed herein.

[0010] In some embodiments, a method for confirming the capabilities of a wireless communication device, performed by a wireless communication node, includes: determining that there is a problem with a first capability of a first wireless communication device; sending a first capability confirmation query message to the first wireless communication device to query the first capability; receiving a capability confirmation reply message from the first wireless communication device, the capability confirmation reply message including information about the first capability; based on the information about the first capability, determining that at least a portion of the first capability is a pseudo capability; and providing network resource configuration to avoid using or involving the pseudo capability of the first wireless communication device.

[0011] In some embodiments, a method performed by a wireless communication device for confirming the capabilities of the wireless communication device to a wireless communication node includes: receiving a first capability confirmation query message from the wireless communication node, the first capability confirmation query message querying a first capability reported by the wireless communication device; determining that at least a portion of the first capability is a pseudo-capability of the wireless communication device; and sending a capability confirmation reply message to the wireless communication node, the capability confirmation reply message including information about the pseudo-capability, wherein future communications with the wireless communication node no longer use or involve the pseudo-capability.

[0012] In a further embodiment, the wireless communication node includes: at least one processor configured to determine that there is a problem with a first capability of a first wireless communication device; and a transceiver configured to: send a first capability confirmation query message to the first wireless communication device to query the first capability; and receive a capability confirmation reply message from the first wireless communication device, the capability confirmation reply message including information about the first capability, wherein the at least one processor is further configured to: determine, based on the information about the first capability, that at least a portion of the first capability is a pseudo capability; and provide network resource configuration to avoid using or involving the pseudo capability of the first wireless communication device.

[0013] In some embodiments, a wireless communication device includes: a transceiver configured to receive a first capability confirmation query message from a wireless communication node, the first capability confirmation query message querying a first capability reported by the wireless communication device; and at least one processor configured to determine that at least a portion of the first capability is a pseudo-capability of the wireless communication device, wherein the transceiver is further configured to send a capability confirmation reply message to the wireless communication node, the capability confirmation reply message including information about the pseudo-capability, and wherein future communications with the wireless communication node no longer use or involve the pseudo-capability. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Various exemplary embodiments of the present disclosure are described in detail below with reference to the following drawings. The drawings are provided for illustrative purposes only and depict only exemplary embodiments of the present disclosure to facilitate the reader's understanding of the present disclosure. Therefore, the drawings should not be considered to limit the breadth, scope, or applicability of the present disclosure. It should be noted that for clarity and ease of illustration, these drawings are not necessarily drawn to scale.

[0015] Figure 1 A signaling diagram of a traditional UE capability query process is shown.

[0016] Figure 2 A signaling diagram of a conventional UE assistance information procedure is shown.

[0017] Figure 3A block diagram illustrating an exemplary communication network in which the techniques disclosed herein may be implemented, according to some embodiments of the present disclosure.

[0018] Figure 4 A flow chart of a method performed by a wireless communication node according to some embodiments of the present disclosure is shown.

[0019] Figure 5 A flowchart of a method performed by a wireless communication device according to some embodiments of the present disclosure is shown.

[0020] Figure 6 A signaling diagram illustrating a UE capability confirmation query procedure according to some embodiments of the present disclosure is shown.

[0021] Figure 7 A signaling diagram illustrating an enhanced UE capability query procedure according to some embodiments of the present disclosure is shown.

[0022] Figure 8 A signaling diagram of an enhanced UE assistance information procedure according to some embodiments of the present disclosure is shown.

[0023] Figure 9 A block diagram of a network node configured to perform the methods and techniques disclosed in this disclosure is shown, according to some embodiments. DETAILED DESCRIPTION

[0024] Various exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings to enable those of ordinary skill in the art to make and use the present disclosure. As will be apparent to those of ordinary skill in the art, after reading this disclosure, various changes or modifications may be made to the examples described herein without departing from the scope of the present disclosure. Therefore, the present disclosure is not limited to the exemplary embodiments and applications described and illustrated herein. In addition, the specific order and / or hierarchy of steps in the methods disclosed herein are merely exemplary methods. Based on design preferences, the specific order or hierarchy of steps of the disclosed methods or processes may be rearranged while remaining within the scope of the present disclosure. Therefore, it should be understood by those of ordinary skill in the art that the methods and techniques disclosed herein present various steps or actions in a sample order, and unless expressly stated otherwise, the present disclosure is not limited to the specific order or hierarchy presented.

[0025] A typical wireless communication network includes at least one base station (BS) that provides geographic wireless coverage, and at least one wireless user equipment terminal (UE) that can send and receive data within the wireless coverage area. In a wireless communication network, the BS and the UE can communicate with each other via a communication link, for example, via downlink radio frames from the BS to the UE and via uplink radio frames from the UE to the BS.

[0026] Figure 31 shows an exemplary communication network 100 in which the techniques disclosed herein may be implemented according to an embodiment of the present disclosure. Figure 1 As shown, exemplary communication network 100 includes a base station (BS) 101 and a plurality of UEs, UE 1 110, UE 2 120, ..., UE 3 130, wherein BS 101 can communicate with the UEs according to a wireless protocol. A UE can move into the coverage area of ​​BS 101 and intend to communicate with BS 101. To communicate with BS 101, the UE first performs an initial access to BS 101, for example, following a random access procedure.

[0027] As described herein, a "wireless communication node" may include or be implemented as a base station (BS), a next-generation node B (gNB), an E-UTRAN node B (eNB), a transmission reception point (TRP), an access point (AP), a donor node (DN), a relay node, a core network (CN) node, a RAN node, a master node, a slave node, a distributed unit (DU), a centralized unit (CU), etc., according to the common understanding of these terms in the art. In addition, as discussed herein, a "wireless communication device" may include or be implemented as a user equipment terminal (UE), a station (STA), a mobile terminal (MT), a mobile station (MS), etc., according to the common understanding of these terms in the art. In the following description of exemplary embodiments, a "base station" or "BS" is described as an exemplary embodiment of a "wireless communication node", while a "user equipment terminal" or "UE" is described as an exemplary embodiment of a "wireless communication device". However, it should be understood that the scope of the present disclosure is not limited to these exemplary embodiments.

[0028] According to various embodiments, BS 101 and UEs 110, 120, and 130 may each be equipped with multiple antennas (e.g., antenna arrays) configured to provide multiple-input multiple-output (MIMO) communication capabilities. In an alternative embodiment, BS 101 and UEs 110, 120, and 130 may each be equipped with phased array antennas capable of forming one or more wireless beams that can be electronically steered. Figure 1 Only a single BS 101 and only three UEs 110, 120, and 130 are shown in FIG. However, it should be understood that, according to various embodiments of the present disclosure, additional BSs and additional UEs may be present in the wireless network to implement the methods and techniques described herein. According to various embodiments, BS 101 and UEs 110, 120, and 130 may each utilize any precoding scheme to form transmission beams for downlink and uplink transmissions, respectively.

[0029] In some embodiments, BS 101 and UEs 110, 120, and 130 may each form a data transmission beam based on an estimated reference signal (RS) path loss, which describes the channel characteristics of the radio frequency (RF) link between the transmitter and the receiver. In addition, RS (e.g., CSI-RS) may represent the propagation state of the communication link from the transmitter to the receiver (such as the combined effects of scattering, fading, and power attenuation with distance). Typically, a receiver can estimate the path loss by tracking predefined signals (e.g., reference signals, training signals, or pilot signals) in received radio frames. Path loss RS tracking thus enables the transmission and configuration of network resources to be adjusted based on channel conditions, thereby enabling, for example, higher network throughput and spectrum efficiency in MIMO systems.

[0030] However, as mentioned above, sometimes the UE will not function properly or fully support previously reported capabilities, such as bandwidth capabilities. For example, such defects or flaws in the UE may be due to the UE's capability details not being fully compliant with the latest 3GPP standard release. Alternatively, due to normal "wear and tear", the UE may be damaged or worn (e.g., certain hardware components become damaged) and exhibit performance degradation relative to the reported capabilities, resulting in "pseudo-capabilities" of the UE.

[0031] Various exemplary embodiments of the present disclosure will now be described in detail below. It should be noted that the features of the embodiments and examples in the present disclosure can be combined with each other in any manner without conflict.

[0032] In order to solve the problem of UE pseudo-capability, in some embodiments, BS 101 and any one or more of UE 110, 120 and 130 may implement an enhanced version of the "UE capability query" procedure known in the art. As used herein, "enhanced UE capability query procedure" refers to an enhancement of the current UE capability query procedure, which includes new and additional signaling and / or information to implement the UE capability confirmation method and technology disclosed herein and described in further detail below. In addition, as used herein, "enhanced UECapabilityEnquiry message" refers to an enhanced version of the traditional UECapabilityEnquiry message, which includes new information for implementing the UE capability confirmation method and technology disclosed herein, and will be described in further detail below. Similarly, as used herein, "enhanced UECapabilityInformation message" refers to an enhanced version of the traditional UECapabilityInformation message, which includes new information for implementing the UE capability confirmation method and technology disclosed herein, and will be described in further detail below.

[0033] In some embodiments, any one or more of BS 101 and UEs 110, 120, and 130 may implement an enhanced version of a "UE assistance information" procedure known in the art. As used herein, an "enhanced UE assistance information procedure" refers to an enhancement of the current UE assistance information procedure that includes new and additional signaling and / or information to implement the UE capability confirmation methods and techniques disclosed herein and described in further detail below. In addition, as used herein, an "enhanced RRCReconfiguration message" refers to an enhanced version of a traditional RRCRecononfiguration message that includes new information to implement the UE capability confirmation methods and techniques disclosed herein and will be described in further detail below. Similarly, as used herein, an "enhanced UEAssistanceInformation message" refers to an enhanced version of a traditional UEAssistanceInformation message that includes new information to implement the UE capability confirmation methods and techniques disclosed herein and will be described in further detail below.

[0034] In an alternative embodiment, any one or more of BS 101 and UEs 110, 120, and 130 may implement a new radio resource control (RRC) procedure referred to herein as a "UE capability confirmation query" procedure. In this new procedure, new signaling and / or information is introduced to implement the UE capability confirmation methods and techniques disclosed herein, and will be described in further detail below.

[0035] Figure 4A flowchart of a method for confirming capabilities reported by a first UE, performed by a radio access network (RAN) node (e.g., a BS), according to some embodiments is shown. At operation 402, the BS may determine or detect that there is a problem with the capabilities reported by the first UE. In some embodiments, the BS utilizes upper layer protocol entities (e.g., MAC, RLC, PDCP, SDAP, RRC, or RRM layer) to evaluate possible pseudo-capabilities by analyzing historical communication performance records involving such pseudo-capabilities. If a possible pseudo-capability is detected, the BS will send a query to the UE regarding the possible pseudo-capabilities, as will be discussed in further detail below. In some embodiments, the BS may detect or determine one or more performance metrics (such as user data transmission throughput, packet error rate, radio link failure, etc.) based on one or more communication experiences with the UE. Upon determining that one or more performance metrics are not within a range of expected values ​​associated with the reported capabilities, the BS may determine that the UE has possible pseudo-capabilities associated with the reported capabilities. For example, if the UE has a pseudo capability associated with a reported BWP usage constraint, a reported TB size limit, or a reported maximum BW usage constraint, then, for example, scheduling and data transmission, packet data unit (PDU) formation, etc. may be adversely affected. Therefore, if the BS detects that the user data throughput is lower than expected, or the packet error rate is higher than expected, or a radio link failure occurs abnormally, the BS may determine that a pseudo capability exists.

[0036] Next, at operation 404, if it is detected that there may be a problem with the capabilities reported by the UE, the BS sends a first capability confirmation query message to the UE. In some embodiments, the first capability confirmation query message includes information about the reported capabilities (e.g., BWP usage constraints, TB size limitations, maximum BW usage constraints, etc.) and information indicating potential problems with the reported capabilities (e.g., transmission failure or high error rate when using a certain BWP, TB size, or BW), which triggers the UE to perform local analysis and self-test to determine whether it still fully supports the reported capabilities, as described below with reference to Figure 5 described in further detail.

[0037] Next, at operation 406, the BS receives a capability confirmation reply message from the UE, the confirmation reply message including information about the reported capabilities. In some embodiments, the information includes the results of a local analysis / self-test performed by the UE, which informs the BS whether at least a portion of the reported capabilities are pseudo-capabilities of the UE (i.e., the UE no longer supports or is unable to perform at least a portion of the reported capabilities).

[0038] Next, at operation 408, the BS will determine whether at least a portion of the reported capabilities are pseudo-capabilities based on the information contained in the capability confirmation reply message.

[0039] Next, at operation 410, if a pseudo capability is identified at operation 408, the BS provides a network resource configuration that avoids using or involving the pseudo capability in future communications with the first UE. In some embodiments, the BS provides the network resource configuration or reconfiguration by utilizing an RRC reconfiguration procedure, as is known in the art.

[0040] Next, at operation 412, the BS determines that the UE's pseudo capability may be a pseudo capability of other UEs in the area. Therefore, in some embodiments, operation 402 may be omitted and operations 404-410 may be repeated for one or more second UEs having the same reported capabilities as the first UE.

[0041] Figure 5 A flow chart illustrating a method performed by a UE to confirm the reported capabilities of the UE is shown. At operation 502, the UE receives a capability confirmation query message from a base station (BS), which queries the UE's reported capabilities. In some embodiments, the capability confirmation query message includes information about the reported capabilities (e.g., BWP usage constraints, TB size limits, maximum BW usage constraints, etc.) and information indicating potential issues with the reported capabilities (e.g., transmission failure or high error rate when using a certain BWP, TB size, or BW).

[0042] Next, at operation 504, the UE performs local analysis and / or self-testing to determine whether at least a portion of the reported capabilities are pseudo-capabilities. In some embodiments, the UE locally analyzes and evaluates the pseudo-capabilities of interest using an upper-layer protocol entity that analyzes communication history and performance records related to such pseudo-capabilities. Based on this analysis, the UE then reports the results, as discussed in further detail below. In some embodiments, the UE performs local analysis / self-testing based on one or more communication experiences with the BS using conventional methods by detecting or determining one or more performance metrics (such as user data transmission throughput, packet error rate, radio link failure, etc.). Upon determining that one or more performance metrics are not within a range of expected values ​​associated with the reported capabilities, the UE may determine that it has possible pseudo-capabilities associated with the reported capabilities. For example, if the UE has pseudo-capabilities associated with a reported BWP usage constraint, a reported TB size limit, or a reported maximum BW usage constraint, scheduling and data transmission, packet data unit (PDU) formation, etc. may be adversely affected. Therefore, if the UE detects that the user data throughput is lower than expected, or the packet error rate is higher than expected, or a radio link failure occurs abnormally, the UE may determine that there is a false capability.

[0043] Next, at operation 506, the UE sends a capability confirmation reply message to the BS, the capability confirmation reply message including information about the reported capabilities. In some embodiments, the capability confirmation reply message includes information about local analysis and / or self-test results, which enables the BS to determine whether some or all of the reported capabilities are now pseudo-capabilities.

[0044] Next, at operation 508, when at least a portion of the reported capabilities are pseudo capabilities, future communications with the BS do not use or involve pseudo capabilities. In some embodiments, the UE...

[0045] As described above, this document discloses a novel method for identifying pseudo capabilities of one or more UEs. After identifying such pseudo capabilities, network resources can be configured to avoid using or involving such pseudo capabilities in future communications between the one or more UEs and other network nodes (e.g., BSs).

[0046] Figure 6 FIG6 shows a signaling diagram between a UE 610 and a BS 620 for performing a method for confirming UE capability according to some embodiments of the present invention. The signaling may be a completely new signaling that is integrated into a protocol (eg, RRC protocol) for establishing a radio interface between the UE and the RAN. Figure 6 As shown, BS 620 sends a new UECapabilityConfirmationEnquiry message 601 to UE 610, which contains information that will trigger UE 610 to perform local analysis and / or self-test to determine whether UE 610 has pseudo-capabilities, as described above. In some embodiments, the new UECapabilityConfirmationEnquiry message 601 includes a new information element (IE) that identifies the UE's reported capabilities (e.g., BWP usage constraints with RACH BWP, TB size constraints, maximum BW usage constraints, and any related information, etc.), which activates / enables a new UE capability confirmation process, in which the UE will investigate and report whether at least part of the reported capabilities are pseudo-capabilities. In some embodiments, the new UECapabilityConfirmationEnquiry message 601 can be implemented as described above with respect to Figure 4 and Figure 5 After the UE 610 performs local analysis / self-test, the UE 610 will send a new UECapabilityConfirmationReply message 602 to the BS 620, which can be implemented as described above in conjunction with Figure 4 and Figure 5Discussion of the "UE Capability Confirmation Reply Message." In some embodiments, the new UECapabilityConfirmationReply message 602 contains information indicating to the BS 620 whether at least a portion of the reported capabilities of the UE 610 are pseudo-capabilities.

[0047] Figure 7 FIG. 7 shows a signaling diagram between a UE 710 and a BS 720 for performing a method for confirming UE capability according to an alternative embodiment of the present invention. Figure 7 In the RRC protocol, the signaling uses an enhanced version of the existing signaling used in the RRC protocol. Figure 7 As shown, BS 720 sends an enhanced UECapabilityEnquiry message 701 to UE 710, which can be the same as the traditional UECapabilityEnquiry message, except that it is enhanced to include additional information, which will trigger UE 710 to perform local analysis and / or self-test to determine whether UE 710 has pseudo-capabilities, as described above. In some embodiments, the enhanced UECapabilityEnquiry message 701 includes a new IE that identifies the UE's reported capabilities (e.g., BWP usage constraints with RACH BWP, TB size constraints, maximum BW usage constraints and any related information, etc.), which activates / enables an enhanced UE capability information procedure, in which the UE will investigate and report whether at least part of the reported capabilities are pseudo-capabilities. In some embodiments, the enhanced UECapabilityEnquiry message 701 can be implemented as described above with respect to Figure 4 and Figure 5 After the UE 710 performs local analysis / self-test, the UE 710 will send an enhanced UECapabilityInformation message 702 to the BS 720. The message can be implemented as described above in conjunction with Figure 4 and Figure 5 In some embodiments, the enhanced UECapabilityInformation message is identical to the conventional UECapabilityInformation message, except that it is enhanced to include additional information that will enable BS 720 to determine whether at least a portion of the capabilities reported by UE 710 are pseudo-capabilities. In some embodiments, the additional information indicates to BS 720 whether at least a portion of the capabilities reported by UE 710 are pseudo-capabilities.

[0048] Figure 8FIG. 8 shows a signaling diagram between UE 810 and BS 820 for performing a method for UE capability confirmation according to a further embodiment of the present invention. Figure 8 In the RRC protocol, the signaling uses an enhanced version of the existing signaling used in the RRC protocol. Figure 8 As shown, the BS sends an enhanced RRCReconfiguration message 801 to the UE, which can be the same as the conventional RRCReconfiguration message 801, except that it is enhanced to include additional information that will trigger and / or enable the UE to perform local analysis and / or self-test to determine whether the UE has a pseudo-capability, as described above. In some embodiments, the UE can perform local analysis and / or self-test at any later time when it detects a potential problem, as discussed in further detail below.

[0049] In some embodiments, BS 820 detects that there is a problem with the reported capabilities of UE 810, and then sends an enhanced RRCReconfiguration message 801 to UE 810 to query the problem before performing user data transmission with UE 810. In some embodiments, enhanced RRCReconfiguration message 801 includes a new IE that identifies the reported capabilities of the UE (e.g., BWP usage constraints with RACH BWP, TB size constraints, maximum BW usage constraints, and any related information, etc.), which activates / enables an enhanced UE assistance information procedure, in which the UE will investigate and report whether at least part of the reported capabilities are false capabilities.

[0050] In some embodiments, the enhanced RRCReconfiguration message 801 only enables the UE 810 to detect and report the pseudo capability at any time in the future that it deems necessary or desired. In some embodiments, the enhanced UECapabilityEnquiry message can be implemented as described above with respect to Figure 4 and Figure 5 In some embodiments, if the enhanced RRCReconfiguration message 801 only enables the UE 810 to initiate detection and report pseudo capabilities at any time in the future, then Figure 4 Operation 402 may be omitted, and the "first capability confirmation query message" is merely an enabling message that enables the UE to actively perform local analysis and report analysis results.

[0051] After receiving the enhanced RRCReconfiguration message 801, the UE 810 sends an RRCReconfiguration Response message 802 indicating that the enhanced RRR reconfiguration process is complete. In some embodiments, the RRCReconfiguration Response message 802 may be the same as a conventional RRCReconfigurationComplete message, as is known in the art. After sending the RRCReconfiguration Response message 802, or at any later time when the UE detects a possible problem, the UE may perform local analysis and / or self-test to determine whether it has one or more pseudo-capabilities. After the UE performs the local analysis / self-test, the UE will proactively initiate and send an enhanced UEAssistanceInformation message 803 to the BS 820, which may be implemented as described above in conjunction with Figure 4 and Figure 5 In some embodiments, the enhanced UEAssistanceInformation message 803 is identical to the conventional UEAssistanceInformation message, except that it is enhanced to include additional information that enables the BS to determine whether at least a portion of the UE's reported capabilities are pseudo-capabilities. In some embodiments, the additional information indicates that the UE still fully supports the reported capabilities, or that some or all portions of the reported capabilities are pseudo-capabilities.

[0052] According to various embodiments, various exemplary scenarios in which the present invention may be practiced are described below.

[0053] Example Scenario 1:

[0054] In one embodiment, a UE performs an initial access (e.g., a random access channel (RACH) procedure) in a specific 20 MHz bandwidth (BWP) in the cell in which it currently resides, and successfully establishes its radio link with the network. However, at a later time, when the BS schedules and transmits / receives user data using the specific 20 MHz BWP for RACH, the UE cannot correctly receive or transmit any user data. On the other hand, when the BS schedules and transmits and / or receives user data in a different BWP (e.g., 40 / 60 / 80 MHz) in the same cell (which may overlap with the BWP above the original 20 MHz), the UE can correctly receive or transmit user data. Based on a series of failed user data transmission experiences, both the BS and the UE may analyze and determine that such a UE may have "pseudo-capability" within at least a portion of its reported BWP usage constraints. Thus, as described above, the BS may perform Figure 4Step 402, and as described above, the UE may perform Figure 5 In some embodiments, when performing the above steps Figure 4-8 Following one or more of the methods and techniques described herein, the BS will provide a network resource configuration to avoid using or involving pseudo-capabilities in future communications between the BS and the UE. Thereafter, the BS may determine that such "pseudo-capabilities" may also exist in other UEs operating in the field. Thus, in some embodiments, the BS may provide the same network resource configuration to the other UEs, for example, avoiding using the same 20 MHz BWP with the RACH procedure for data transmission. In some embodiments, the BS will implement with the other UEs Figure 4 Steps 404-410 are performed to determine whether they have the same or similar pseudo capabilities.

[0055] Example Scenario 2:

[0056] In another embodiment, the UE has successfully established a wireless link with the BS. However, at a later time, when the BS schedules the transmission / reception of user data with a specific transport block (TB) size, the user data transmission fails. On the other hand, when the BS schedules the transmission of user data with other TB sizes, the user data transmission succeeds. Based on a series of failed user data transmission experiences, both the BS and the UE can analyze and determine that such UE may have "pseudo-capability" within its reported TB size capability. In this way, the BS can perform Figure 4 Step 402, and the UE may perform Figure 5 In some embodiments, when performing the above steps Figure 4-8 Following one or more of the methods and techniques described herein, the BS will provide a network resource configuration to avoid using or involving pseudo-capabilities in future communications between the BS and the UE. Thereafter, the BS may determine that such "pseudo-capabilities" may also exist in other UEs operating in the field. Thus, in some embodiments, the BS may provide the same network resource configuration to other UEs, for example, to avoid using the same TB size for data transmission. In some embodiments, the BS will implement the same network resource configuration with other UEs. Figure 4 Steps 404-410 are performed to determine whether they have the same or similar pseudo capabilities.

[0057] Example Scenario 3:

[0058] In another embodiment, the UE has successfully established a wireless link with the BS. However, at a later time, when the BS schedules the transmission / reception of user data within a certain bandwidth (e.g., 2500–2700 MHz reported as supported by the UE), the user data transmission is unsuccessful. On the other hand, when the BS schedules the transmission of user data within a portion of the above bandwidth (e.g., 2540–2660 MHz), the user data transmission is successful. Based on a series of failed user data transmission experiences, both the BS and the UE may analyze and determine that such UE may have "pseudo-capability" within its reported maximum BW capability constraint. In this way, the BS can perform Figure 4 Step 402, and the UE may perform Figure 5 In some embodiments, when performing the above steps Figure 4-8 Following one or more of the methods and techniques described herein, the BS will provide a network resource configuration to avoid using or involving pseudo-capabilities (e.g., avoiding using BWs other than 2540–2660 MHz BW) in future communications between the BS and the UE. Thereafter, the BS may determine that such "pseudo-capabilities" may also exist in other UEs operating in the field. Thus, in some embodiments, the BS may provide the same network resource configuration to the other UEs, e.g., avoiding using BWs other than 2540–2660 MHz BW. In some embodiments, the BS will implement the same network resource configuration with the other UEs. Figure 4 Steps 404-410 are performed to determine whether they have the same or similar pseudo capabilities.

[0059] Figure 9 A block diagram of a network node (NN) 900 according to various embodiments of the present disclosure is shown. NN 900 is an example of a wireless communication device or wireless communication node that can be configured to implement the various methods described herein. In some embodiments, NN 900 can be a wireless communication node such as a base station (BS) as described herein. In other embodiments, NN 900 can be a wireless communication device such as a user equipment terminal (UE) as described herein. Figure 9 As shown, NN 900 includes a housing 940 containing a system clock 902 , a processor 904 , a memory 906 , a transceiver 910 including a transmitter 912 and a receiver 914 , a power module 908 , and a wireless communication device capability confirmation (CC) module 920 .

[0060] In this embodiment, system clock 902 provides timing signals to processor 904 for controlling the timing of all operations of NN 900. Processor 904 controls the general operation of NN 900 and may include one or more processing circuits or modules, such as a central processing unit (CPU) and / or any combination of a general-purpose microprocessor, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), a programmable logic device (PLD), a controller, a state machine, gating logic, discrete hardware components, dedicated hardware finite state machines, or any other suitable circuit, device, and / or structure that can perform computations or other manipulations of data.

[0061] The memory 906, which may include a read-only memory (ROM) and a random access memory (RAM), may provide instructions and data to the processor 904. A portion of the memory 906 may also include a non-volatile random access memory (NVRAM). The processor 904 typically performs logic and arithmetic operations based on program instructions stored in the memory 906. The instructions (also referred to as software) stored in the memory 906 may be executed by the processor 904 to perform the methods described herein. The processor 904 and the memory 906 together form a processing system that stores and executes software. As used herein, "software" refers to any type of instruction, whether referred to as software, firmware, middleware, microcode, etc., which can configure a machine or device to perform one or more desired functions or processes. Instructions may include code (e.g., in source code format, binary code format, executable code format, or any other suitable code format). When executed by one or more processors, the instruction causes the processing system to perform the various functions described herein.

[0062] The transceiver 910, including a transmitter 912 and a receiver 914, allows the NN 900 to transmit and receive data to and from external network nodes (e.g., a UE or AP). Antenna 950 is typically attached to the housing 940 and electrically coupled to the transceiver 910. In various embodiments, the NN 900 includes (not shown) multiple transmitters, multiple receivers, and multiple transceivers. In some embodiments, the antenna 950 includes a multi-antenna array that can form multiple beams based on MIMO beamforming technology, each beam pointing in a different direction.

[0063] The CC module 920 may be implemented as part of the processor 904 that is programmed to perform the functions herein, or it may be a separate module implemented in hardware, firmware, software, or a combination thereof. According to various embodiments, the NN 900 is a wireless communication node, and the CC module 920 and the transceiver 910 are configured to perform the functions described above. Figure 4In a further embodiment, the NN 900 is a wireless communication device, and the CC module 920 and the transceiver 910 are configured to perform the above-described Figure 5 In some embodiments, the CC module 920 may be implemented as software (i.e., computer-executable instructions) stored in a non-transitory computer-readable medium, which, when executed by the processor 904, converts the processor 904 into a special-purpose computer to perform the wireless communication device capability confirmation methods and operations described herein.

[0064] The various components and modules within the housing 940 are coupled together via a bus system 930. The bus system 930 may include a data bus and, in addition to the data bus, for example, a power bus, a control signal bus, and / or a status signal bus. It will be understood that the modules of the NN 900 may be operably coupled to each other using any suitable technology and medium. It will also be understood that additional modules (not shown) may be included in the NN 900 without departing from the scope of the present disclosure.

[0065] Although various embodiments of the present disclosure have been described above, it should be understood that they are presented by way of example only and not by way of limitation. Similarly, various figures may depict exemplary architectures or configurations, which are provided to enable those of ordinary skill in the art to understand the exemplary features and functions of the present disclosure. However, such persons should understand that the present disclosure is not limited to the exemplary architectures or configurations shown, but may be implemented using various alternative architectures and configurations. In addition, as will be understood by those of ordinary skill in the art, one or more features of an embodiment may be combined with one or more features of another embodiment described herein. Therefore, the breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments.

[0066] It should also be understood that any reference to an element herein using designations such as "first," "second," etc., does not generally limit the quantity or order of those elements. Rather, these designations may be used herein as a convenient method of distinguishing between two or more elements or instances of an element. Thus, a reference to a first and a second element does not imply that only two elements may be used or that the first element must precede the second element in some manner.

[0067] Furthermore, those skilled in the art will appreciate that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, and symbols referenced in the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0068] Those skilled in the art will further understand that any of the various illustrative logical blocks, modules, processors, devices, circuits, methods, and functions described in connection with the aspects disclosed herein may be implemented by electronic hardware (e.g., digital implementations, analog implementations, or a combination of both), firmware, various forms of programs or design code containing instructions (which, for convenience, may be referred to herein as "software" or "software modules"), or any combination of these technologies.

[0069] In order to clearly illustrate this interchangeability of hardware, firmware and software, various illustrative components, blocks, modules, circuits and steps have been generally described above with respect to their functions. Whether such functionality is implemented as hardware, firmware, or as software, or as a combination of these technologies, depends on the specific application and the design constraints imposed on the entire system. A skilled person can implement the described functionality in various ways for each specific application, but such implementation decisions do not result in deviation from the scope of this disclosure. According to various embodiments, processors, devices, components, circuits, structures, machines, modules, etc. can be configured to perform one or more functions described herein. The terms "configured to" or "configured for" used herein with respect to a specified operation or function refer to a processor, device, component, circuit, structure, machine, module, etc. that is physically constructed, programmed and / or arranged to perform the specified operation or function.

[0070] In addition, it will be understood by those of ordinary skill in the art that the various illustrative logic blocks, modules, devices, components, and circuits described herein may be implemented within or performed by an integrated circuit (IC), which may include a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic device, or any combination thereof. The logic blocks, modules, and circuits may also include antennas and / or transceivers to communicate with various components within a network or within a device. A general-purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, or state machine. The processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor), multiple microprocessors, one or more microprocessors in combination with a DSP core, or any other suitable configuration for performing the functions described herein.

[0071] If implemented in software, these functions may be stored as one or more instructions or codes on a computer-readable medium. Thus, the steps of the methods or algorithms disclosed herein may be implemented as software stored on a computer-readable medium. Computer-readable media include computer storage media and communication media, including any media that can be enabled to send a computer program or code from one place to another. The storage medium can be any available medium that can be accessed by a computer. By way of example and not limitation, such computer-readable media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired program code in the form of instructions or data structures and that can be accessed by a computer.

[0072] In this application, the term "module" as used herein refers to software, firmware, hardware, and any combination of these elements for performing the relevant functions described herein. In addition, for the purpose of discussion, various modules are described as separate modules; however, as is apparent to those skilled in the art, two or more modules can be combined to form a single module that performs the relevant functions according to embodiments of the present disclosure.

[0073] In addition, memory or other storage devices and communication components can be used in the embodiments of the present disclosure. It should be understood that, for the sake of clarity, the above description describes the embodiments of the present disclosure with reference to different functional units and processors. However, it is apparent that any appropriate distribution of functions between different functional units, processing logic elements or domains can be used without departing from the present disclosure. For example, a function illustrated as being performed by a separate processing logic element or controller can be performed by the same processing logic element or controller. Therefore, a reference to a specific functional unit is merely a reference to an appropriate device for providing the function, rather than indicating a strict logical or physical structure or organization.

[0074] Various modifications to the embodiments described in this disclosure will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments without departing from the scope of this disclosure. Therefore, the present disclosure is not intended to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the novel features and principles disclosed herein, as set forth in the following claims.

Claims

1. A method, performed by a wireless communication node, for confirming capabilities of a wireless communication device, the method comprising: detecting whether there is a possible pseudo capability associated with a first capability of a first wireless communication device, where the pseudo capability represents a capability reported as supported by the wireless communication device but actually not supported or partially supported by the wireless communication device; In response to detecting the possible pseudo-capability, sending a first capability confirmation query message to the first wireless communication device to query the first capability; receiving a capability confirmation reply message from the first wireless communication device, the capability confirmation reply message including information about the first capability; determining, based on the information about the first capability, that at least a portion of the first capability is a pseudo capability; as well as A network resource configuration is provided to the wireless communication device to avoid using or involving spurious capabilities of the first wireless communication device.

2. The method according to claim 1, further comprising: determining that the pseudo capability can be a pseudo capability of at least one second wireless communication device; as well as A second capability confirmation query message is sent to the second wireless communication device to query the first capability of the second wireless communication device.

3. The method according to claim 1, wherein The first capability confirmation query message is included in an enhanced UECapabilityEnquiry message, and wherein the capability confirmation reply message is included in an enhanced UECapabilityInformation message sent by the first wireless communication device.

4. The method according to claim 1, wherein The first capability confirmation query message is included in an enhanced RRCReconfiguration message sent by the wireless communication node, wherein the enhanced RRCReconfiguration message enables the first wireless communication device to proactively initiate transmission of the capability confirmation reply message at a future time determined by the first wireless communication device, and wherein the capability confirmation reply message is included in an enhanced UEAssistanceInformation message sent by the first wireless communication device.

5. The method according to claim 1, wherein: The first capability is defined by a bandwidth part (BWP) usage constraint reported by the first wireless communication device; the information about the first capability indicating that at least one BWP identified in the BWP usage constraint as supported by the first wireless communication device is a pseudo capability of the first wireless communication device; and The avoiding use of or reference to a pseudo capability of the first wireless communication device includes avoiding use of the at least one BWP for future communications with the first wireless communication device.

6. The method according to claim 1, wherein: The first capability is defined by a transport block (TB) size constraint reported by the first wireless communication device; the information about the first capability indicating that at least one TB size identified in the TB size constraint as supported by the first wireless communication device is a pseudo capability of the first wireless communication device; and Providing the network resource configuration includes avoiding use of the at least one TB size for future communications with the first wireless communication device.

7. The method according to claim 1, wherein: The first capability is defined by a bandwidth (BW) constraint reported by the first wireless communication device; the information about the first capability indicates that at least one BW range identified in the BW constraint as supported by the first wireless communication device is a pseudo capability of the first wireless communication device; and The avoiding use of or reference to the pseudo capability of the first wireless communication device comprises avoiding use of the at least one BW range for future communications with the first wireless communication device.

8. A method, performed by a wireless communication device, for confirming capabilities of the wireless communication device to a wireless communication node, the method comprising: receiving a first capability confirmation query message from the wireless communication node, the first capability confirmation query message querying a first capability reported by the wireless communication device, wherein the first capability confirmation query message is sent in response to a possible pseudo capability associated with the first capability of the wireless communication device being detected at the wireless communication node, the pseudo capability representing a supported capability reported by the wireless communication device but actually not supported or partially supported by the wireless communication device; determining that at least a portion of the first capabilities are pseudo-capabilities of the wireless communication device; Sending a capability confirmation reply message to the wireless communication node, wherein the capability confirmation reply message includes information about the pseudo capability; A network resource configuration is received from the wireless communication node such that future communications with the wireless communication node no longer utilize or involve the dummy capability.

9. The method according to claim 8, wherein The first capability confirmation query message is included in an enhanced UECapabilityEnquiry message, and wherein the capability confirmation reply message is included in an enhanced UECapabilityInformation message sent by the wireless communication device.

10. The method according to claim 8, wherein The first capability confirmation query message is included in an enhanced RRCReconfiguration message sent by the wireless communication node, wherein the enhanced RRCReconfiguration message enables the wireless communication device to proactively initiate transmission of the capability confirmation reply message at a future time determined by the wireless communication device, and wherein the capability confirmation reply message is included in an enhanced UEAssistanceInformation message sent by the wireless communication device.

11. The method according to claim 8, wherein: The first capability is defined by a bandwidth part (BWP) usage constraint reported by the wireless communication device; The pseudo-capability includes at least one BWP identified in the BWP usage constraint as supported by the wireless communication device; and Future communications between the wireless communication device and the wireless communication node avoid using the at least one BWP.

12. The method according to claim 8, wherein: The first capability is defined by a transport block (TB) size constraint reported by the wireless communication device; The pseudo-capabilities include at least one TB size identified in the TB size constraints as supported by the wireless communication device; and Future communications between the wireless communication device and the wireless communication node avoid using the at least one TB size.

13. The method according to claim 8, wherein: The first capability is defined by a bandwidth (BW) constraint reported by the wireless communication device; The pseudo-capability includes at least one BW range identified in the BW constraint as supported by the wireless communication device; and Future communications between the wireless communication device and the wireless communication node avoid using the at least one BW range.

14. A non-transitory computer-readable medium having stored thereon computer-executable instructions for performing the method according to any one of claims 1 to 13.

15. A wireless communication node, comprising: at least one processor configured to detect whether there is a possible pseudo capability associated with a first capability of a first wireless communication device, the pseudo capability representing a capability reported as supported by the wireless communication device but not actually supported or partially supported by the wireless communication device; and A transceiver, the transceiver being configured to: In response to the possible pseudo-capability being detected, sending a first capability confirmation query message to the first wireless communication device to query the first capability; and receiving a capability confirmation reply message from the first wireless communication device, the capability confirmation reply message including information about the first capability, Wherein, the at least one processor is further configured to: determining, based on the information about the first capability, that at least a portion of the first capability is a pseudo capability; and A network resource configuration is provided to the wireless communication device to avoid using or involving spurious capabilities of the first wireless communication device.

16. The wireless communication node according to claim 15, wherein: The at least one processor is further configured to: determining that the pseudo capability can be a pseudo capability of at least one second wireless communication device; as well as A second capability confirmation query message is sent to the second wireless communication device to query about the first capability of the second wireless communication device.

17. The wireless communication node according to claim 15, wherein: The first capability confirmation query message is included in an enhanced UECapabilityEnquiry message, and the capability confirmation reply message is included in an enhanced UECapabilityInformation message sent by the first wireless communication device.

18. The wireless communication node according to claim 15, wherein: The first capability confirmation query message is included in an enhanced RRCReconfiguration message sent by the wireless communication node, wherein the enhanced RRCReconfiguration message enables the first wireless communication device to proactively initiate transmission of the capability confirmation reply message at a future time determined by the first wireless communication device, and wherein the capability confirmation reply message is included in an enhanced UEAssistanceInformation message sent by the first wireless communication device.

19. The wireless communication node of claim 15, wherein: The first capability is defined by a bandwidth part (BWP) usage constraint reported by the first wireless communication device; the information about the first capability indicating that at least one BWP identified in the BWP usage constraint as supported by the first wireless communication device is a pseudo capability of the first wireless communication device; and The avoiding use of or reference to a pseudo capability of the first wireless communication device includes avoiding use of the at least one BWP for future communications with the first wireless communication device.

20. The wireless communication node of claim 15, wherein: The first capability is defined by a transport block (TB) size constraint reported by the first wireless communication device; the information about the first capability indicating that at least one TB size identified in the TB size constraint as supported by the first wireless communication device is a pseudo capability of the first wireless communication device; and The avoiding use of or reference to the pseudo capability of the first wireless communication device includes avoiding use of the at least one TB size for future communications with the first wireless communication device.

21. The wireless communication node of claim 15, wherein: The first capability is defined by a bandwidth (BW) constraint reported by the first wireless communication device; the information about the first capability indicating that at least one BW range identified in the BW constraint as supported by the first wireless communication device is a pseudo capability of the first wireless communication device; and The avoiding use of or reference to the pseudo capability of the first wireless communication device comprises avoiding use of the at least one BW range for future communications with the first wireless communication device.

22. A wireless communication device comprising: a transceiver configured to receive a first capability confirmation query message from a wireless communication node, the first capability confirmation query message querying a first capability reported by the wireless communication device, wherein the wireless communication node sends the first capability confirmation query message in response to detecting a possible pseudo capability associated with the first capability of the wireless communication device, the pseudo capability representing a supported capability reported by the wireless communication device but actually not supported or partially supported by the wireless communication device; and at least one processor configured to determine that at least a portion of the first capabilities are pseudo capabilities of the wireless communication device, wherein The transceiver is further configured to send a capability confirmation reply message to the wireless communication node, wherein the capability confirmation reply message includes information about the pseudo capability. The transceiver is further configured to receive a network resource configuration from the wireless communication node such that future communications with the wireless communication node no longer use or involve the dummy capability.

23. The wireless communication device according to claim 22, wherein: The first capability confirmation query message is included in an enhanced UECapabilityEnquiry message, and the capability confirmation reply message is included in an enhanced UECapabilityInformation message sent by the wireless communication device.

24. The wireless communication device of claim 22, wherein: The first capability confirmation query message is included in an enhanced RRCReconfiguration message sent by the wireless communication node, wherein the enhanced RRCReconfiguration message enables the wireless communication device to actively initiate the transmission of the capability confirmation reply message at a future time determined by the wireless communication device, and the capability confirmation reply message is included in an enhanced UEAssistanceInformation message sent by the wireless communication device.

25. The wireless communication device of claim 22, wherein: The first capability is defined by a bandwidth part (BWP) usage constraint reported by the wireless communication device; The pseudo-capability includes at least one BWP identified in the BWP usage constraint as supported by the wireless communication device; and The future communications between the wireless communication device and the wireless communication node avoid using the at least one BWP.

26. The wireless communication device of claim 22, wherein: The first capability is defined by a transport block (TB) size constraint reported by the wireless communication device; The pseudo-capabilities include at least one TB size identified in the TB size constraints as supported by the wireless communication device; and The future communications between the wireless communication device and the wireless communication node avoid using the at least one TB size.

27. The wireless communication device of claim 22, wherein: The first capability is defined by a bandwidth (BW) constraint reported by the wireless communication device; The pseudo-capability includes at least one BW range identified in the BW constraint as supported by the wireless communication device; and The future communications between the wireless communication device and the wireless communication node avoid using the at least one BW range.

Images