Method for handling wireless devices having different capabilities, wireless device and network node

Abstract

A method performed by a network node (130) of a wireless communication network (100) is disclosed. The method comprises receiving, from a user equipment, UE, (140) wirelessly connected to a network node (130), a chipset identifier indicating a chipset type of the UE (140), determining how to process the UE (140) based on the received chipset identifier, and communicating with the UE (140) in accordance with the determination. By receiving an identifier indicating a chipset type on which a UE (140) is built, a network node (130) may accommodate its processing of the UE according to the chipset type.

Description

Technical Field

[0001] The present disclosure generally relates to methods, wireless devices and network nodes for handling wireless devices with different capabilities. The present disclosure also relates to computer programs and carriers corresponding to the above methods, wireless devices and nodes. Background Art

[0002] The air interface of modern cellular technologies (such as New Radio (NR), i.e. 5G) is very complex, with complex standard specifications covering many functions. It is mandatory for wireless devices to implement certain specified functions. Such functions are referred to as "mandatory without capability signaling" in 3GPP. In NR, a wireless device may be referred to as a user equipment (UE), for which reason the terms UE or wireless device may be used interchangeably in this disclosure. In addition, a wireless device has a lot of freedom to implement only a subset of the specified functions. Therefore, the UE indicates to the network node (which is called gNodeB (gNB) in NR) via UE capability signaling which functions it supports and the related restrictions on the functions, such as the maximum number of supported resources, the maximum number of ports, the frequency bands that can be used in combination, etc. Such functions are referred to as "mandatory features with capability parameters" or "optional features with capability parameters" in 3GPP. The definition of these terms can be found in 3GPP TS 38.306, Version 17.0.0, March 2022, Section 4.2.1.

[0003] A network software release includes multiple commercial features for different use cases that may be of interest to a network operator. Each feature includes or is built from one or more functions or functionalities, where each function may be associated with one or more capabilities. There are many possible example features, among which some worth mentioning include NR voice, reciprocity-based beamforming, UE battery saving using bandwidth fractions, discrete Fourier transform spread orthogonal frequency division multiplexing (DFTS-OFDM), etc. Usually in interoperability testing of new features, the UE is tested to correctly support the feature and report its related capabilities before the UE is commercially released.

[0004] However, there is no one-to-one mapping between features and capabilities. Even several completely different features implemented by different network providers may rely on the same basic UE capabilities. However, how the related functions are used may vary greatly between different features.

[0005] Therefore, legacy UEs already deployed in wireless communication networks have problems with certain functionalities that the UEs should support according to the 3GPP specifications and according to their reported UE capabilities. In order to also be able to handle such legacy UEs today, the wireless communication network may need to adapt to such UEs, which may result in that more advanced UEs will not be able to use all the features that they should be able to use and that the wireless communication network can actually provide, because the network nodes (in NR, gNB) cannot distinguish between UEs that correctly support the functionality and UEs that do not. Therefore, improved methods of matching features to actual UE constraints are needed. Summary of the invention

[0006] The object of the present invention is to solve at least some of the above problems and difficulties. It is an object of embodiments of the present invention to achieve an improved method of matching features to UE capabilities. Another object is to achieve an improved method of understanding actual UE constraints and taking these constraints into account when interacting with the UE. These and other objects may be achieved by using methods, network nodes and wireless devices as defined in the attached independent claims.

[0007] According to one aspect, a method performed by a network node of a wireless communication network is provided. The method includes receiving a chipset identifier indicating a chipset type of a UE from a UE wirelessly connected to the network node, determining how to handle the UE based on the received chipset identifier, and communicating with the UE based on the determination.

[0008] According to another aspect, a method performed by a UE wirelessly connected to a network node of a wireless communication network is provided. The method includes sending a chipset identifier indicating a chipset type of the UE to the network node, so that the network node can determine how to handle the UE according to the chipset type of the UE.

[0009] According to another aspect, a network node is provided, which is configured to operate in a wireless communication network, the network node comprising a processing circuit and a memory. The memory stores instructions executable by the processing circuit, whereby the network node is operable to receive a chipset identifier indicating a chipset type of a UE from a UE wirelessly connected to the network node, determine how to handle the UE based on the received chipset identifier, and communicate with the UE based on the determination.

[0010] According to another aspect, a UE is provided, which is configured for wireless communication with a network node of a wireless communication network, the UE comprising a processing circuit and a memory. The memory stores instructions executable by the processing circuit, whereby the UE is operable to send a chipset identifier indicating a chipset type of the UE to the network node, thereby enabling the network node to determine how to process the UE according to the chipset type of the UE.

[0011] According to other aspects, a computer program and a carrier are also provided, the details of which will be described in the claims and the detailed description.

[0012] Further possible features and advantages of the solution will become apparent from the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The solution will now be described in more detail by means of exemplary embodiments and with reference to the accompanying drawings, in which:

[0014] Figure 1 is a schematic diagram of a wireless communication network in which the present invention may be used.

[0015] Figure 2 is a flow chart illustrating a method performed by a network node according to a possible embodiment.

[0016] Figure 3 is a flow chart illustrating a method performed by a wireless device according to a possible embodiment.

[0017] Figure 4 is a signaling diagram illustrating an embodiment of a procedure according to a further possible embodiment.

[0018] Figure 5 is a block diagram illustrating a network node in more detail according to a further possible embodiment.

[0019] Figure 6 is a block diagram illustrating a UE in more detail according to further possible embodiments. DETAILED DESCRIPTION

[0020] Figure 1 A wireless communication network 100 is shown comprising a radio access network (RAN) node, also known as a network node 130, which is in or adapted to communicate wirelessly with wireless communication devices, also known as wireless devices, also known as user equipment (UE) 140. The network node 130 provides radio access in a cell 150 covering a geographical area.

[0021] The wireless communication network 100 may be any type of wireless communication network capable of providing radio access to wireless devices. Examples of such wireless communication networks are networks based on Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), Universal Mobile Telecommunications System (UMTS), Code Division Multiple Access 2000 (CDMA 2000), Long Term Evolution (LTE), Advanced LTE, Wireless Local Area Network (WLAN), Worldwide Interoperability for Microwave Access (WiMAX), Advanced WiMAX, and fifth generation (5G) wireless communication networks based on technologies such as New Radio (NR), and any possible future sixth generation (6G) wireless communication networks.

[0022] The network node 130 may be any type of network node capable of providing wireless access to the wireless device 140 alone or in combination with another network node. Examples of the network node 130 are a base station (BS), a radio BS, a base transceiver station, a BS controller, a network controller, a Node B (NB), an evolved Node B (eNB), a gNodeB (gNB), a multi-cell / multicast coordination entity, a relay node, an access point (AP), a radio AP, a remote radio unit (RRU), a remote radio head (RRH), and a multi-standard BS (MSRBS).

[0023] The wireless device 140 may be any type of device capable of wirelessly communicating with the network node 130 using radio signals. For example, the wireless device 140 may be a user equipment (UE), a machine-type UE or a UE capable of machine-to-machine (M2M) communication, a sensor, a tablet, a mobile terminal, a smartphone, a laptop embedded equipment (LEE), a laptop mounted equipment (LME), a USB dongle, a customer premises equipment (CPE), an Internet of Things (IoT) device, etc.

[0024] As mentioned in the background, there is a problem that UEs that have been deployed in wireless communication networks have problems with certain functions, even though the UE should support the function according to the 3GPP specifications and its reported UE capabilities. While digging deeper into this problem, the inventors discussed the fact that the vast majority of air interface related functions are implemented by the vendors of UE chipsets, on which UE equipment vendors build their UEs. In addition, it often happens that UE chipsets are identified as not working as expected, considering their reported UE capabilities and what behaviors the 3GPP specifications mandate for such UEs. Sometimes, this happens during interoperability testing before the UE chipsets are commercially released, in which case the UE chipset implementation is simply corrected. However, it may also happen that UEs built on these problematic chipsets have already been released into commercial operation. It is very difficult to push software corrections to all affected UEs, which may prevent the introduction of new features, because if the feature is activated in the network, then legacy UEs in commercial operation will start to experience problems. The problem may be related to mandatory functions without any related capability signaling, or to functions related to capability signaling. Without actual testing of the functionality, it is almost impossible to guarantee in advance that a functionality will work as expected. During interoperability testing, it usually happens that some issues are found that require updates on the UE side.

[0025] For special handling of certain devices with faulty implementations, IMEI-SV or TAC can be used for identification. However, this requires the operator to manage a database of all the different versions, which can be very complex as there may be many different devices built on a single faulty UE chipset version. There is a strong reluctance among operators to rely on International Mobile Equipment Identity - Software Version (IMEI-SV) ​​or Type Allocation Code (TAC) to identify faulty devices.

[0026] Furthermore, as the number of chipset versions increases, identification of UE chipsets based on their "capability fingerprints" (i.e., certain combinations of existing capability information elements (IEs) that are only signaled by a specific chipset) becomes increasingly difficult. As a result, clearly identifying such capability fingerprints (which correctly identify that a UE is of a certain type) becomes very difficult or even impossible.

[0027] However, by storing rules about how to treat a UE based on the chipset type on which the UE is built and an identifier of the chipset type, and having the UE report its chipset type to the network side, the feature or features provided to a specific UE can be adapted based on the chipset type on which the UE is built. This chipset type information and rules can be used together with conventional UE capability information to improve the matching of features to UEs. A typical rule might be "UEs based on chipset type X should not be configured with feature Y, regardless of what the UE's capability information indicates". Rules can be created from problems reported by UEs built on specific chipsets. For example, for the above rule, if it has been reported that many UEs built on chipsets of type X obtain high block error rates (BLER) when configured with feature Y, then a rule as described above can be set.

[0028] Therefore, by the UE reporting its chipset type to the network node, the network node can use this information to determine how to handle the UE.Therefore, there may be a better way to determine which features should be implemented for which UEs.

[0029] Figure 2 Combination Figure 1 A method performed by a network node 130 of a wireless communication network 100 is shown. The method includes receiving 202 a chipset identifier indicating a chipset type of the UE 140 from a UE 140 wirelessly connected to the network node 130, determining 204 how to handle the UE 140 based on the received chipset identifier, and communicating 206 with the UE 140 based on the determination 204. By receiving an identifier indicating the chipset type on which the UE is built, the network node can adapt its handling of the UE based on the chipset type. For example, the network node can use the chipset identifier to determine that a certain feature should not be used to communicate with the UE. The network node can access rules or other types of information that instruct the network node how to handle the UE based on the chipset type of the UE. Such rules can overrule any UE capability information sent by the UE to the network node. Therefore, the network node can identify indications of actual UE constraints that are not shown in conventional UE capability information but depend on the chipset type, so the network node can take these constraints into account when interacting with the UE.

[0030] According to an embodiment, determining 204 comprises comparing the received chipset identifier with chipset identifiers stored in the wireless communication network together with information about any feature constraints for each stored chipset identifier, and determining how to handle the UE 140 based on any stored feature constraints for the chipset identifiers of the stored chipset identifiers that match the received chipset identifier. In other words, the network node takes the chipset identifier it receives, checks the chipset type it indicates, and finds out whether there are any feature constraints stored for the chipset type. If there are any such constraints, the network node determines that the features for which there are constraints will not be provided to the UE, or a limited version of the feature may be provided to the UE if the constraints allow limited versions. "Limited version" may be interpreted as a version of the feature that has some restrictions on the original version of the feature. According to an embodiment, information about any feature constraints for chipset identifiers / chipset types may be hard-coded in the network node. According to an embodiment, feature constraints may be based on the association of different chipset types with different UE groups. Then, different behaviors, i.e., allowed features for different UE groups, may be defined. The network operator may be allowed to determine which chipset types belong to which UE groups.

[0031] According to an embodiment, the determination 204 is further based on one or more of UE capabilities, network node configuration, and requirements for specific features.

[0032] According to another embodiment, determining 204 includes determining whether to use a specific feature for the UE based on the chipset identifier and the requirement of the specific feature. In addition, communicating 206 further includes selectively using the feature for communicating with the UE depending on the determination.

[0033] According to yet another embodiment, determining 204 comprises determining, based on the chipset identifier, to avoid using the feature for the UE, although the UE has indicated that it has the capability to support the feature.

[0034] According to another embodiment, the received chipset identifier includes information about a chipset supplier and one or more of: a hardware version and a software version of the chipset.

[0035] According to another embodiment, a chipset identifier is received 202 in a UE capability information message, the UE capability information message further comprising standardized information of UE capabilities. The standardized information of UE capabilities may be the information described in Section 6.3.3 of TS 38.331 Version 17.0.0, wherein the definition of UE capabilities is described in 3GPP TS 38.306. The UE capability information message may be sent as a radio resource control (RRC) message. The UE capability information message may include one or more capability containers containing UE capability information. The one or more capability containers may be one or more of the following: UE-EUTRA-capability, UE-NR-capability, UE-MRDC-capability. EUTRA stands for Evolved Universal Terrestrial Radio Access. MRDC stands for Multi-RAT Dual Connectivity.

[0036] According to yet another embodiment, the UE capability information message comprises a first field indicating whether the chipset identifier is present in the UE capability information message and a second field comprising the chipset identifier.

[0037] According to another embodiment, the UE capability information message is a standardized UE capability information message, and the chipset identifier is received 202 in one or more information elements (IEs) indicated as dummy fields in the standardized UE capability information message. In RRC, there are some "dummy field" capability IEs that have been deprecated, for example because 3GPP RAN2 realized that they were added to the wrong place in the capability structure, or because of an initial misunderstanding of what capabilities needed to be defined. Such dummy field IEs are still part of the specification, but there is no specified behavior associated with them. The UE is allowed to send them, and the gNB must accept that the Abstract Syntax Symbol 1 (ASN1) received from the UE may contain them. The inventors have realized that using such dummy fields to send the chipset identifier would be an efficient use of communication resources.

[0038] According to yet another embodiment, the first field of the UE capability information message is a mac-ParametersCommon / dummy information element IE, and the second field of the UE capability information message is a mimo-ParametersPerBand / dummy4 IE.

[0039] According to another embodiment, the method further comprises sending 203 an identifier of the network node to the UE 140 only when the chipset identifier has been received 202. The UE 140 may also benefit from knowing which type of network node it is communicating with so that the UE can adapt its behavior to the network node type. For example, the UE may adapt its channel state information (CSI) feedback to adapt to the link adaptation algorithm of the network node. Certain RRC configuration IEs sent by the network node may be used to convey the network node identifier, such as dummy field IEs. However, using the RRC configuration IE sent to the UE to convey the network node identifier may be problematic because there are not many dummy field configuration IEs, and there are always risks involved in changing the configuration signaling for legacy UEs. One solution to this problem is to ensure by testing that all UEs that send the chipset identifier also understand the network node identifier, and then have the network node only send the network node identifier as part of the configuration message to the UE that has already included the chipset identifier in its capability signaling. The network node identifier may define one or more of the following: network node supplier or manufacturer, network node type, software release version, etc.

[0040] Figure 3 Combination Figure 1 A method is shown performed by a UE 140 wirelessly connected to a network node 130 of a wireless communication network 100. The method comprises sending 302 a chipset identifier indicating a chipset type of the UE 140 to the network node 130, thereby enabling the network node 130 to determine how to handle the UE 140 in dependence on the chipset type of the UE.

[0041] According to an embodiment, the chipset identifier comprises information about the chipset supplier and one or more of: a hardware version and a software version of the chipset.

[0042] According to another embodiment, the chipset identifier is sent 302 in a UE capability information message, the UE capability information message further comprising standardized information of the UE capabilities.

[0043] According to another embodiment, the UE capability information message includes a first field indicating whether a chipset identifier is present in the UE capability information message and a second field including the chipset identifier.

[0044] According to a further embodiment, the UE capability information message is a standardized UE capability information message.Furthermore, the chipset identifier is sent 302 in one or more IEs indicated as dummy fields in the standardized UE capability information message.

[0045] According to yet another embodiment, the first field of the UE capability information message is a mac-ParametersCommon / dummy IE, and the second field of the UE capability information message is a mimo-ParametersPerBand / dummy4 IE.

[0046] According to another embodiment, the method further comprises receiving 304 a network node identifier from the network node 130 only if the chipset identifier has been sent 302 .

[0047] Figure 4 An embodiment of a process for handling UEs with different capabilities by the UE notifying a network node of its chipset type is shown. Figure 4 The process is shown for an NR network, so NR terminology is used, however, the process is easily adapted to other wireless network technologies. The process begins with the UE 140 sending 1.1UE chipset identifier to the gNodeB (gNB) 130. The chipset identifier indicates the type of chipset on which the UE 140 is built. The chipset identifier is included in the existing UE capability signaling from the UE 140 to the network node 130, for example, in a capability container within a UECapabilityInformation message sent over RRC.

[0048] According to an embodiment, the chipset identifier has the following format: "ChipsetIdentifier = {Vendor, Major, Minor}", where "Vendor" = chipset vendor, "Major" = major variant of the chipset, such as hardware (HW) generation and / or major software (SW) release, and "Minor" = minor variant of the chipset, such as bug fix level above major SW version. The detailed usage of the Major / Minor fields can be determined by the chipset or UE vendor, but the vendor identifier requires ecosystem alignment so that different vendors use unique identifiers.

[0049] The dummy field capability IE available in existing standards (e.g., 3GPP TS 38.331) can be used to convey the chipset identifier. Examples of available dummy field capability IEs as part of the UE-NR-Capability container include: "mac-ParametersCommon / dummy" (formerly known as "pucch-SpatialRelInfoMAC-CE") and "mimo-ParametersPerBand / dummy4" (formerly known as "csi-RS-ForTracking"). "mimo-ParametersPerBand / dummy4" has the following content: burstLength INTEGER (1..2), maxSimultaneousResourceSetsPerCC INTEGER (1..8), maxConfiguredResourceSetsPerCC INTEGER (1..64), and maxConfiguredResourceSetsAllCC INTEGER (1..128). It is known that the UE does not report anything in the IE “mac-ParametersCommon / dummy”, so the presence of this IE can be used to indicate that the UE 140 is signaling the chipset identifier in the IE “mimo-ParametersPerBand / dummy4”. In other words, the presence of the IE “mac-ParametersCommon / dummy” indicates the presence of the chipset identifier in the IE “mimo-ParametersPerBand / dummy4”.

[0050] There are other dummy field IEs that can be used for the same purpose. However, some of the other dummy field IEs are reported by some early UEs and are therefore more difficult to rely on.

[0051] UE 140 may use the above IE to send the chipset identifier to gNB 140 in the following manner: 1. Include IE "mac-ParametersCommon / dummy" to indicate that the chipset identifier is sent in the message, and 2. Define the chipset identifier in IE "mimo-ParametersPerBand / dummy4" (or other equivalent IE).

[0052] According to an embodiment, the IE "mimo-ParametersPerBand / dummy4" is included in at least the first BandNR instance in supportedBandListNR. In addition, the value of the included IE reflects the chipset identifier {provider, primary, secondary}, where provider = (burstLength-1)*8+dummy4 / maxSimultaneousResourceSetsPerCC (16 values), primary = dummy4 / maxConfiguredResourceSetsPerCC (64 values) and secondary = dummy4 / maxConfiguredResourceSetsAllCC (128 values).

[0053] The gNB 140 may access information storing 1.0 chipset type identifiers along with feature constraints for each chipset type. In other words, there is a storage device where a specific chipset type is linked to feature constraints. Before sending 1.1 the chipset type identifier to the gNB 140, such chipset type-feature constraint links have been stored 1.0. Thus, the gNB 140, upon knowing the chipset type, may obtain feature constraint information for that specific chipset type. The feature constraint-chipset type links may be hard-coded in the gNB 140, or they may be stored in a storage device where the gNB can easily retrieve them.

[0054] After receiving 1.1 the UE capability container including the chipset type identifier, the gNB identifies 1.2 the UE chipset type based on the chipset type identifier. For UEs that do not send a chipset identifier, it is assumed that the chipset identifier = unknown.

[0055] Given a chipset identifier, and possibly UE capabilities, gNB configuration and feature activation, gNB 130 behavior for handling UE 140 may be adapted 1.3 to take the chipset identifier value into account. At a high level, this may include one or more of: blocking configuration of features for UE 140 based on the chipset identifier of UE 140 and information stored for the chipset identifier; allowing configuration of features for UE 140 based on the chipset of UE 140; adapting detailed configuration of features for UE 140 based on the chipset of UE 140, and adapting dynamic interactions with UE 140, such as scheduling and link adaptation, based on the chipset of UE 140.

[0056] An example of possible Adaptation 1.3 for gNB behavior to handle UE when chipset identifier {provider,primary,secondary} is used is: ●Override capability IE capX used to determine whether feature X can be configured – If “provider” == 3 and “primary” <= 5, feature X cannot be configured even if the UE indicates support for capX; – If “provider” == 4 and “primary” == 14 and 10 <= “secondary” <= 22, feature X cannot be configured even if the UE indicates support for capX; – If "chipsetIdentifier" == unknown, feature X cannot be configured even if the UE indicates support for capX; – if "provider" == 5 and 7 <= "primary" <= 12 and the UE indicates support for capX, feature X may be configured using adaptation where parameter Y must be set to 2; – if "supplier" == 7 and "primary" <= 8, then the value of capX should be assumed to be 4 instead of the signaled capability value; ● Adapt gNB behavior to avoid issues with mandatory features without capability IEs – If “supplier” == 2 and “primary” <= 3, do not configure feature Y - If "supply" == 3 and "primary" <= 4, then adapt link adaptation to be more conservative when determining MCS.

[0057] Note that it is not necessary for the chipset identifier to influence the configuration of a particular feature. If there are no known interoperability issues with the feature, the feature can be configured based on normal rules, for example, if the feature is activated in the network and the UE supports the associated capabilities. However, if interoperability issues are identified, the chipset identifier can become part of the criteria for when and how the feature is configured.

[0058] According to an embodiment, in a gNB implementation, the gNB behavior may be hard-coded for different chipset identifiers.

[0059] According to another embodiment, different UE groups with different behaviors may be defined and the chipset identifier may determine in which UE group a particular UE should be placed. The network operator may be allowed to define the UE groups. For example, the following two UE groups may be defined: "UEs that should be configured with feature X according to normal rules" and "UEs that should never be configured with feature X". Rules for chipsets belonging to each UE group may then be defined. The gNB 130 will then perform actions according to the rules defined for the relevant UE group when configuring feature X for a particular UE 140. This allows the operator to have the final say on what rules to apply. For example, there may be different UEs that all signal the same chipset identifier, but only a subset of these UEs have problems with a particular feature. One operator may have many problematic UEs in its network and may wish to disable the feature for this chipset identifier value, while another operator may have no or few such problematic devices in its network and may prefer to activate the feature.

[0060] Figure 5 Combination Figure 1 A network node 130 configured to operate in a wireless communication network 100 is described, the network node 130 comprising a processing circuit 603 and a memory 604. The memory 604 stores instructions executable by the processing circuit, whereby the network node 130 is operable to receive a chipset identifier indicating a chipset type of the UE 140 from a UE 140 wirelessly connected to the network node 130, determine how to handle the UE 140 based on the received chipset identifier, and communicate with the UE 140 in accordance with the determination.

[0061] According to an embodiment, the network node 130 is operable to determine how to handle the UE 140 by comparing the received chipset identifier with chipset identifiers stored in the wireless communication network together with information about any feature constraints for each stored chipset identifier, and determining how to handle the UE 140 based on any stored feature constraints for chipset identifiers of the stored chipset identifiers that match the received chipset identifier.

[0062] According to another embodiment, the network node 130 is further operable to determine how to handle the UE 140 based on one or more of UE capabilities, network node configuration, and requirements of specific features.

[0063] According to another embodiment, the network node 130 is operable to determine how to handle the UE 140 by determining whether to use a specific feature for the UE based on the chipset identifier and the requirement of the specific feature, and is operable to communicate with the UE by selectively using the feature for communicating with the UE depending on the determination.

[0064] According to yet another embodiment, the network node 130 is operable to determine how to handle the UE 140 by determining based on the chipset identifier to avoid using a feature for the UE, although the UE has indicated that it has the capability to support the feature.

[0065] According to another embodiment, the received chipset identifier includes information about a chipset supplier and one or more of: a hardware version and a software version of the chipset.

[0066] According to a further embodiment, the network node 130 is operable to receive the chipset identifier by receiving the chipset identifier in a UE capability information message, the UE capability information message further comprising standardized information of the UE capabilities.

[0067] According to yet another embodiment, the UE capability information message comprises a first field indicating whether the chipset identifier is present in the UE capability information message and a second field comprising the chipset identifier.

[0068] According to a further embodiment, the UE capability information message is a standardized UE capability information message.Furthermore, the network node is operable to receive the chipset identifier in one or more Information Elements (IEs) indicated as dummy fields in the standardized UE capability information message.

[0069] According to another embodiment, the first field of the UE capability information message is a mac-ParametersCommon / dummy information element IE, and the second field of the UE capability information message is a mimo-ParametersPerBand / dummy4 IE.

[0070] According to yet another embodiment, the network node 130 is further operative to send the identifier of the network node to the UE 140 only if the chipset identifier has been received.

[0071] According to other embodiments, the network node 130 may further include a communication unit 602, which may be considered to include conventional means for wireless communication with the wireless device 140, such as a transceiver for wireless transmission and reception of signals in a communication network. The communication unit 602 may also include conventional means for communicating with other network nodes of the wireless communication network 100. The instructions executable by the processing circuit 603 may be arranged as a computer program 605 stored, for example, in the memory 604. The processing circuit 603 and the memory 604 may be arranged in a sub-device 601. The sub-device 601 may be a microprocessor and appropriate software and memory, so that a programmable logic device PLD or other electronic component / processing circuit is configured to perform the above method. The processing circuit 603 may include one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or a combination of these suitable for executing instructions.

[0072] The computer program 605 may be arranged so that when its instructions are executed in the processing circuit, they cause the network node 130 to perform the steps described in any of the described embodiments of the network node 130 and its method. The computer program 605 may be carried by a computer program product connectable to the processing circuit 603. The computer program product may be a memory 604, or at least arranged in a memory. The memory 604 may be implemented as, for example, a RAM (random access memory), a ROM (read only memory) or an EEPROM (electrically erasable programmable ROM). In some embodiments, a carrier may contain the computer program 605. The carrier may be one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electrical signal, a radio signal, a microwave signal or a computer-readable storage medium. The computer-readable storage medium may be, for example, a CD, a DVD or a flash memory, from which the program may be downloaded into the memory 604. Alternatively, the computer program may be stored on a server or any other entity that the network node 130 may access via the communication unit 602. Then, the computer program 605 may be downloaded from the server into the memory 604.

[0073] Figure 6 Combination Figure 1 A UE 140 configured to communicate wirelessly with a network node 130 of a wireless communication network 100 is described, the UE 140 comprising a processing circuit 703 and a memory 704. The memory 704 stores instructions executable by the processing circuit 703, whereby the UE 140 is operable to send a chipset identifier indicating a chipset type of the UE 140 to the network node 130, thereby enabling the network node 130 to determine how to handle the UE 140 in accordance with the chipset type of the UE.

[0074] According to an embodiment, the chipset identifier comprises information about the chipset supplier and one or more of: a hardware version and a software version of the chipset.

[0075] According to another embodiment, the UE 140 is operable to send the chipset identifier in a UE capability information message, the UE capability information message further comprising standardized information of the UE capabilities.

[0076] According to another embodiment, the UE capability information message includes a first field indicating whether a chipset identifier is present in the UE capability information message and a second field including the chipset identifier.

[0077] According to yet another embodiment, the UE capability information message is a standardized UE capability information message.Furthermore, the UE 140 is operable to send the chipset identifier in one or more IEs indicated as dummy fields in the standardized UE capability information message.

[0078] According to another embodiment, the first field of the UE capability information message is a mac-ParametersCommon / dummy information element IE, and the second field of the UE capability information message is a mimo-ParametersPerBand / dummy4 IE.

[0079] According to yet another embodiment, the UE 140 is further operable to receive the network node identifier from the network node 130 only if the chipset identifier has been sent.

[0080] According to other embodiments, the UE 140 may further include a communication unit 702, which may be considered to include conventional means for wireless communication with the network node 130, such as a transceiver for wireless transmission and reception of signals. The instructions executable by the processing circuit 703 may be arranged as a computer program 705 stored in, for example, a memory 704. The processing circuit 703 and the memory 704 may be arranged in a sub-device 701. The sub-device 701 may be a microprocessor and appropriate software and memory, so that a programmable logic device PLD or other electronic component / processing circuit is configured to perform the above method. The processing circuit 703 may include one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or a combination of these suitable for executing instructions. The UE 140 may also include a battery 706 for providing power to the UE.

[0081] The computer program 705 may be arranged so that when its instructions are run in the processing circuit, they cause the UE 140 to perform the steps described in the described embodiments of the UE 140 and its method. The computer program 705 may be carried by a computer program product that can be connected to the processing circuit 703. The computer program product may be a memory 704, or at least arranged in a memory. The memory 704 may be implemented as, for example, a RAM (random access memory), a ROM (read-only memory), or an EEPROM (electrically erasable programmable ROM). In some embodiments, the carrier may contain the computer program 705. The carrier may be one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electrical signal, a radio signal, a microwave signal, or a computer-readable storage medium. The computer-readable storage medium may be, for example, a CD, a DVD, or a flash memory, from which the program may be downloaded to the memory 704. Alternatively, the computer program may be stored on a server or any other entity that the UE 140 can access via the communication unit 702. Then, the computer program 705 may be downloaded from the server to the memory 704.

[0082] Although the above description contains multiple specificities, it should not be interpreted as limiting the scope of the concepts described herein, but should be interpreted as providing only an illustration of some exemplary embodiments of the concepts. It should be understood that the scope of the concepts described at present fully encompasses other embodiments that may be obvious to those skilled in the art, and therefore the scope of the concepts described at present should not be limited. Unless explicitly stated, references to singular elements do not mean "one and only one", but "one or more". All structural and functional equivalents of the elements of the above-mentioned embodiments known to those skilled in the art are expressly incorporated herein by reference and are intended to be covered thereby. In addition, the device or method may not solve every problem that the concept currently described attempts to solve, and is covered thereby for this purpose. In the exemplary figure, the dotted line generally indicates that the feature within the dotted line is optional.

Claims

1. A method performed by a network node (130) of a wireless communication network (100), the method comprising: receiving (202) from a user equipment UE (140) wirelessly connected to the network node (130) a chipset identifier indicating a chipset type of the UE (140), determining (204) how to handle the UE (140) based on the received chipset identifier, and Communicating (206) with the UE (140) based on the determination (204).

2. The method according to claim 1, wherein: The determining (204) includes comparing the received chipset identifier to chipset identifiers stored in the wireless communication network along with information about any feature constraints for each stored chipset identifier, and determining how to handle the UE (140) based on any stored feature constraints for chipset identifiers of the stored chipset identifiers that match the received chipset identifier.

3. The method according to claim 1 or 2, wherein: The determination (204) is also based on one or more of UE capabilities, network node configuration, and requirements for specific features.

4. The method according to any one of claims 1 to 3, wherein: The determining (204) includes determining whether to use the specific feature for the UE based on the chipset identifier and a requirement for the specific feature, and the communicating (206) further includes selectively using the feature for communicating with the UE depending on the determining.

5. The method according to any one of claims 1 to 3, wherein: The determining (204) includes determining, based on the chipset identifier, to avoid using a feature for the UE even though the UE has indicated that it has the capability to support the feature.

6. A method according to any one of the preceding claims, wherein: The received chipset identifier includes information about a chipset supplier and one or more of: a hardware version and a software version of the chipset.

7. A method according to any one of the preceding claims, wherein: The chipset identifier is received (202) in a UE capability information message, the UE capability information message further comprising standardized information of the UE capabilities.

8. The method according to claim 7, wherein: The UE capability information message includes a first field and a second field, the first field indicating whether the chipset identifier exists in the UE capability information message, and the second field including the chipset identifier.

9. The method according to claim 7 or 8, wherein: The UE capability information message is a standardized UE capability information message, and the chipset identifier is received (202) in one or more information elements IEs indicated as dummy fields in the standardized UE capability information message.

10. A method according to claim 9 as appended to claim 8, wherein: The first field of the UE capability information message is a mac-ParametersCommon / dummy information element IE, and the second field of the UE capability information message is a mimo-ParametersPerBand / dummy4 IE.

11. The method according to any one of the preceding claims, further comprising: Only when the chipset identifier has been received (202), the identifier of the network node is sent (203) to the UE (140).

12. A method performed by a user equipment UE (140) wirelessly connected to a network node (130) of a wireless communication network (100), the method comprising: A chipset identifier indicating a chipset type of the UE (140) is sent (302) to the network node (130), thereby enabling the network node (130) to determine how to handle the UE (140) in accordance with the chipset type of the UE.

13. The method according to claim 12, wherein: The chipset identifier includes: information about a chipset supplier and one or more of: a hardware version and a software version of the chipset.

14. The method according to claim 12 or 13, wherein: The chipset identifier is sent (302) in a UE capability information message, the UE capability information message further comprising standardized information of the UE capabilities.

15. The method according to claim 14, wherein: The UE capability information message includes a first field and a second field, the first field indicating whether the chipset identifier exists in the UE capability information message, and the second field including the chipset identifier.

16. The method according to claim 14 or 15, wherein: The UE capability information message is a standardized UE capability information message, and the chipset identifier is sent (302) in one or more information elements IEs indicated as dummy fields in the standardized UE capability information message.

17. A method according to claim 16 when appended to claim 15, wherein: The first field of the UE capability information message is a mac-ParametersCommon / dummy information element IE, and the second field of the UE capability information message is a mimo-ParametersPerBand / dummy4 IE.

18. The method according to any one of claims 12 to 17, further comprising: A network node identifier is received (304) from the network node (130) only if the chipset identifier has been sent (302).

19. A network node (130) configured to operate in a wireless communication network (100), the network node (130) comprising a processing circuit (603) and a memory (604), the memory storing instructions executable by the processing circuit, whereby the network node (130) is operable to: receiving, from a user equipment UE (140) wirelessly connected to the network node (130), a chipset identifier indicating a chipset type of the UE (140), determining how to handle the UE based on the received chipset identifier (140), and Communicating with the UE (140) based on the determination.

20. The network node (130) of claim 19, operable to determine how to handle the UE (140) by comparing the received chipset identifier with chipset identifiers stored in the wireless communication network together with information about any feature constraints for each stored chipset identifier, and determining how to handle the UE (140) based on any stored feature constraints for chipset identifiers of the stored chipset identifiers that match the received chipset identifier.

21. A network node (130) according to claim 19 or 20, operable to determine how to handle the UE (140) further based on one or more of UE capabilities, network node configuration and requirements of specific features.

22. A network node (130) according to any one of claims 19-21, operable to determine how to handle the UE (140) by determining whether to use the specific feature for the UE based on the chipset identifier and the requirement of the specific feature, and operable to communicate with the UE by selectively using the feature for communication with the UE depending on the determination.

23. A network node (130) according to any one of claims 19-21, operable to determine how to handle the UE (140) by: based on the chipset identifier, determining to avoid using a feature for the UE even though the UE has indicated that it has the capability to support the feature.

24. The network node (130) according to any one of claims 19 to 23, wherein: The received chipset identifier includes information about a chipset supplier and one or more of: a hardware version and a software version of the chipset.

25. The network node (130) according to any of claims 19-24, operable to receive the chipset identifier by receiving the chipset identifier in a UE capability information message, the UE capability information message further comprising standardized information of the UE capabilities.

26. The network node (130) of claim 25, wherein: The UE capability information message includes a first field and a second field, the first field indicating whether the chipset identifier exists in the UE capability information message, and the second field including the chipset identifier.

27. The network node (130) according to claim 25 or 26, wherein: The UE capability information message is a standardized UE capability information message, and the network node is operable to receive the chipset identifier in one or more information elements IEs indicated as dummy fields in the standardized UE capability information message.

28. The network node (130) of claim 27 as appended to claim 26, wherein: The first field of the UE capability information message is a mac-ParametersCommon / dummy information element IE, and the second field of the UE capability information message is a mimo-ParametersPerBand / dummy4 IE.

29. The network node (130) according to any of claims 19-28, further operable to send an identifier of the network node to the UE (140) only if the chipset identifier has been received.

30. A user equipment UE (140) configured to perform wireless communications with a network node (130) of a wireless communication network (100), the UE (140) comprising a processing circuit (703) and a memory (704), the memory storing instructions executable by the processing circuit, whereby the UE (140) is operable to: send a chipset identifier indicating a chipset type of the UE (140) to the network node (130), thereby enabling the network node (130) to determine how to process the UE (140) based on the chipset type of the UE.

31. The UE (140) according to claim 30, wherein: The chipset identifier includes: information about a chipset supplier and one or more of: a hardware version and a software version of the chipset.

32. The UE (140) of claim 30 or 31 , operable to send the chipset identifier in a UE capability information message, the UE capability information message further comprising standardized information of the UE capabilities.

33. The UE (140) according to claim 32, wherein: The UE capability information message includes a first field and a second field, the first field indicating whether the chipset identifier exists in the UE capability information message, and the second field including the chipset identifier.

34. The UE (140) according to claim 32 or 33, wherein: The UE capability information message is a standardized UE capability information message, and the UE is operable to send the chipset identifier in one or more information elements IEs indicated as dummy fields in the standardized UE capability information message.

35. The UE (140) of claim 34 as appended to claim 33, wherein: The first field of the UE capability information message is a mac-ParametersCommon / dummy information element IE, and the second field of the UE capability information message is a mimo-ParametersPerBand / dummy4 IE.

36. The UE (140) according to any of claims 30-35, further operable to receive a network node identifier from the network node (130) only if the chipset identifier has been sent.

37. A computer program (605) comprising instructions which, when executed by at least one processing circuit (603) of a network node (130) of a wireless communication network (100), cause the network node (130) to perform the following steps: receiving, from a user equipment UE (140) wirelessly connected to the network node (130), a chipset identifier indicating a chipset type of the UE (140), determining how to handle the UE based on the received chipset identifier (140), and Communicating with the UE (140) based on the determination.

38. A carrier storing a computer program (605) according to claim 37, wherein: The carrier is one of an electronic signal, an optical signal, a radio signal, an electrical signal or a computer-readable storage medium.

39. A computer program (705) comprising instructions, which, when executed by at least one processing circuit (703) of a user equipment UE (140) connected to a network node (130) of a wireless communication network (100), causes the UE (140) to perform the following steps: sending a chipset identifier indicating a chipset type of the UE (140) to the network node (130), thereby enabling the network node (130) to determine how to process the UE (140) based on the chipset type of the UE.

40. A carrier storing a computer program (705) according to claim 39, wherein: The carrier is one of an electronic signal, an optical signal, a radio signal, an electrical signal, or a computer-readable storage medium.

Images