WO2020162802A1 - Handling user equipment capability information by a core network node and an access network node of a wireless communication network - Google Patents

Handling user equipment capability information by a core network node and an access network node of a wireless communication network Download PDF

Info

Publication number
WO2020162802A1
WO2020162802A1 PCT/SE2019/050768 SE2019050768W WO2020162802A1 WO 2020162802 A1 WO2020162802 A1 WO 2020162802A1 SE 2019050768 W SE2019050768 W SE 2019050768W WO 2020162802 A1 WO2020162802 A1 WO 2020162802A1
Authority
WO
WIPO (PCT)
Prior art keywords
capability
capability information
access
node
core network
Prior art date
Application number
PCT/SE2019/050768
Other languages
French (fr)
Inventor
Svante ALNÅS
Original Assignee
Sony Corporation
Sony Mobile Communications Ab
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corporation, Sony Mobile Communications Ab filed Critical Sony Corporation
Publication of WO2020162802A1 publication Critical patent/WO2020162802A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0033—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information

Definitions

  • This disclosure relates to methods and devices for handling capabilities of a terminal in a wireless communication system including a core network, an access network and one or more terminals. More specifically, solutions are provided for identification and transmission of identification of capabilities between various entities within the network.
  • a wireless terminal or wireless communication device
  • UE User Equipment
  • a base station defines a cell and is operative to serve a surrounding area with radio access for UEs, by providing radio access to UEs within a cell.
  • a base station is also referred to herein as a node or access node, and various terms are used in 3GPP for different types of systems or specification.
  • An access network typically includes a plurality of access nodes, and is connected to a Core Network (CN) which inter alia provides access to other communication networks.
  • CN Core Network
  • NodeB is used to denote an access node
  • 4G specifications also referred to as Long-Term
  • LTE Long Term Evolution
  • eNodeB eNodeB
  • UEs can have many different capabilities, such as radio capabilities, e.g., associated with modem properties or supported functionality in the UE or combination of frequency bands that the UE does not have good coverage for.
  • radio capabilities e.g., associated with modem properties or supported functionality in the UE or combination of frequency bands that the UE does not have good coverage for.
  • the UE indicates its capabilities to the wireless network. This is typically accomplished when the UE registers with the wireless communication network.
  • the capabilities can be indicated in different formats, e.g., in terms of parameters or indicators listed in one or more information elements of a message.
  • the UE may indicate multiple different capabilities, which may for example concern frequency bands of a wireless communications system, supported frequency band combinations, support of different modulation and demodulation formats, maximum data demodulation rate, 3GPP release version, or specific functions such as relaying or the support of device-to-device communication.
  • the UE capabilities are indicated in a rather static manner to the network. The capabilities may be indicated upon initial network registration and in some handover scenarios, in response to the network sending a UE capability enquiry. For initiating an update of the capability information from the UE side, the UE may need to re-register in the network.
  • capabilities are always transferred when the UE register to the network and usually only a filtered set of capabilities.
  • the new base station may request if additional capability is supported and add that to the UE’s Radio Capability that exist in the network.
  • Capability handling in the wireless network has involved nodes and UEs sending only a usable set of UE capabilities that is very small (2-8kB) in size. This means that for every new base station that handles the UE then additional UE Radio Capabilities may need to be requested from the UE.
  • the data size of the UE capabilities continues to grow. Current 3GPP releases already have problems with the size of the capabilities.
  • RACS radio capability signaling
  • a general object is to provide improved solutions for handling UE capability information in a wireless communication system.
  • an aspect of this object is to minimize latency associated with transfer of capability data within the
  • method for use in a core network node for handling user equipment, UE, capability information in a wireless
  • a communication system including at least one UE and an access network, comprising receiving, from the access network, a capability message comprising UE capability information of said UE;
  • determining includes retrieving stored capability ID matching the capability information; or creating a determined capability ID, responsive to not having access to stored capability ID matching the capability information.
  • capability ID By configuring the core network node to create capability ID where none is previously provided, convenient use of capability IDs may be employed even for legacy UEs not configured to provide a capability ID.
  • determining includes
  • the determined capability ID is created in said core network node based on said capability information.
  • the method comprises
  • the method comprises
  • the searching comprises
  • said hash at least forms part of the determined capability ID.
  • a method for use in a first access node for handling user equipment, UE, capability information in an access network of a wireless communication system including a core network node and at least one UE, comprising
  • the method comprises
  • the method comprises
  • the method comprises
  • a core network node for handling user equipment, UE, capability information in a wireless communication system including at least one UE and an access network, comprising
  • a logic configured to execute computer program code to control the core network node to carry out any of the steps outlined above.
  • an access node for handling user equipment, UE, capability information in an access network of a wireless
  • a logic configured to execute computer program code to control the access node to carry out any of the steps outlined above.
  • Fig. 1 schematically illustrates a network of a wireless communication system including networks nodes according to various embodiments
  • FIG. 2 schematically illustrates elements included in a UE configured in accordance with various embodiments
  • Figs 3A-3B schematically illustrate elements included in access nodes configured in accordance with various embodiments
  • FIG. 3C schematically illustrate elements included in a core network node configured in accordance with various embodiments
  • Fig. 4A shows a signaling scheme including several method steps carried out in various nodes in a wireless communication system, where different steps may be included in different embodiments as outlined in further detail below;
  • Fig. 4B shows a signaling scheme including several method steps carried out in a core network node in different embodiments.
  • embodiments of the invention should not be construed as limited to the particular shapes and relative sizes of regions illustrated herein but are to include deviations in shapes and/or relative sizes that result, for example, from different operational constraints and/or from manufacturing constraints.
  • the elements illustrated in the figures are schematic in nature and their shapes are not intended to illustrate the actual shape of a region of a device and are not intended to limit the scope of the invention.
  • Fig. 1 schematically illustrates a wireless communication system 60, including an access network 200.
  • the access network 200 is in turn connected to a core network (CN) 100, which provides access to other communication networks, such as the
  • the access network 200 may include a plurality of access nodes 10, 20, 30 configured to serve various cells.
  • the access network 200 may e.g. be a Radio Access Network (RAN).
  • RAN Radio Access Network
  • a UE 1 is a wireless device configured to communicate wirelessly with access nodes of the access network 200, such as by radio. UEs may be stationary or mobile.
  • Each access node 10, 20, 30 may in various embodiments be referred to as a base station, serving one cell each.
  • the access network 200 may comprise a number of subareas, which may be referred to as RAN Notification Areas (RNA).
  • RNA RAN Notification Areas
  • Each RNA may consist of a number of cells, where each cell is served by one access node 20.
  • One of those cells may be referred to as an anchor cell.
  • the anchor cell includes the access node 20 that has configured interface to the core network 100 for Control plane and User plane, referred to as N2 and N3 interfaces in 5G. Corresponding interfaces Sl-C and Sl-U are provided in LTE.
  • the access nodes 10, 30 of the other cells of the RNA may be connected to the anchor cell 20 by means of a logical inter- node interface 20 E
  • this interface, or set of interfaces is referred to as Xn interface, and has a similar purpose as the X2 interface defined for LTE.
  • the CN 100 may include various core network nodes 120 in the form of or comprising entities, nodes or functions 110, 111, 112, defined in accordance with a certain 3GPP release or in accordance with another set of wireless communication standards.
  • Such CN entities may e.g. include a node 110 for handling mobility of UEs, such as an Access & Mobility management Function (AMF) and Session Management Function (SMF).
  • the CN may further include a User Plane Function UPF 112, or gateways 111, such as one or more of a Serving Gateway and a PDN Gateway.
  • the CN may also include, or have a communication interface to, a data storage 128 accessible through a database and configured to store data associated with UE capability information.
  • Fig. 2 schematically illustrates a UE 1.
  • the UE 1 may be configured for communication with an access network 200, and comprise a transceiver 2, such as a radio receiver and transmitter for communicating with the access network 200 through at least an air interface.
  • the terminal 1 further comprises a logic 3.
  • the logic 3 may comprise for example a controller or microprocessor 4.
  • the logic may also comprise or be connected to a data storage device 5 configured to include a computer readable storage medium.
  • the data storage device 5 may include a memory and may be, for example, one or more of a buffer, a flash memory, a hard drive, a removable media, a volatile memory, a non-volatile memory, a random access memory (RAM), or other suitable device.
  • RAM random access memory
  • the data storage device 5 includes a non volatile memory for long term data storage and a volatile memory that functions as system memory for the controller 4.
  • the data storage device 5 may exchange data with a processor 4 of the logic 3 over a data bus.
  • the data storage device 5 is considered a non-transitory computer readable medium.
  • One or more processors of the logic 3 may execute instructions stored in the data storage device or a separate memory in order to carry out operation of the UE 1, as outlined herein.
  • the UE 1 may further comprise a data memory 6 for storing UE capability information and associated data.
  • the data memory 6 may be or form part of the data storage device 5, or be a separate entity, but is specifically indicated in the drawing to identify the intended difference between storing code associated with a computer program or operating system in data storage 5 used for controlling and operating the UE 1, from capability data which can be accessed and sent to other nodes of the wireless system 60. It may be noted that the UE 1 clearly may include other features and functions than those identified, such as e.g. one or more antennas, a user interface, a power source and so on, but these components are not shown in Fig. 2 for clarity reasons.
  • Fig. 3A schematically illustrates an access node 20, also referred to herein as a first access node 20, whereas Fig. 3B which schematically illustrates another access node 30, also referred to herein as a second access node 30.
  • the first 20 and second 30 access nodes may be similar or even identical. In other embodiments, they may be more or less different, and have different radio capabilities in terms of e.g. supported radio access technology (RAT), supported frequency bands and band combinations.
  • RAT radio access technology
  • the first 20 and second 30 access nodes comprise corresponding elements or functions.
  • each access node 20, 30 comprise an access node logic 24, 34.
  • the access node logic 24, 34 may comprise for example a controller or microprocessor 25, 35.
  • the logic 24, 34 may also comprise or be connected to a data storage device 26, 36 configured to include a computer readable storage medium.
  • the data storage device 26, 36 may include a memory and may be, for example, one or more of a buffer, a flash memory, a hard drive, a removable media, a volatile memory, a non-volatile memory, a random access memory (RAM), or other suitable device.
  • the data storage device 26, 36 includes a non-volatile memory for long term data storage and a volatile memory that functions as system memory for the control unit.
  • the data storage device 26, 36 may exchange data with a processor of the logic 24, 34 over a data bus.
  • the data storage device is considered a non-transitory computer readable medium.
  • One or more processors 25, 35 of the logic 24, 34 may execute instructions stored in the data storage device or a separate memory in order to carry out operation of the access node 20, 30, as outlined herein.
  • Each access node 20, 30 may comprise more components, for example a power supply, but these components are not shown in Figs 3A and 3B for clarity reasons.
  • the access nodes 20, 30 may further comprise one or more communication interfaces 27, 37 for communication with other entities. For example, the
  • the communication interfaces 27, 37 may comprise a radio transceiver connected to an antenna arrangement (not shown), for communication over an air interface with the UE 1. Moreover, the communication interfaces 27, 37 may define one or more interfaces to the core network 100.
  • the access nodes 20, 30 may further comprise a data storage 28, 38 for storing UE capability information and associated data, preferably for a plurality of UEs.
  • the data storage 28, 38 may form part of the data storage device 26, 36 or be a separate entity. Indeed, the data storage 28, 38 may be located centrally accessible for a number of access nodes 10, 20, 30, e.g. in a storage 28, 38 dedicated to several access nodes that may or may not be part of the same RNA. Fig.
  • FIG. 3C schematically illustrates a core network (CN) node 120, which may include one or more parts of the nodes 110, 111, 112 outlined with reference to Fig. 1.
  • the core network node 120 which comprises a CN node logic 124.
  • the CN node logic 124 may comprise for example a controller or microprocessor 125.
  • the logic 124 may also comprise or be connected to a data storage device 126 configured to include a computer readable storage medium.
  • the data storage device 126 may include a memory and may be, for example, one or more of a buffer, a flash memory, a hard drive, a removable media, a volatile memory, a non-volatile memory, a random access memory (RAM), or other suitable device.
  • RAM random access memory
  • the data storage device 126 includes a non-volatile memory for long term data storage and a volatile memory that functions as system memory for the control unit.
  • the data storage device 126 may exchange data with a processor of the logic 124 over a data bus.
  • the data storage device is considered a non-transitory computer readable medium.
  • One or more processors 125 of the logic 124 may execute instructions stored in the data storage device or a separate memory in order to carry out operation of the CN node 120, as outlined herein.
  • the CN node 120 may comprise more components, for example a power supply, but these components are not shown in Fig. 3C for clarity reasons.
  • the CN node 120 may further comprise one or more transceivers or interfaces 127 for communication with other entities.
  • the interface 127 may comprise an interface for communication with other networks, e.g. the Internet. Moreover, the interface or transceiver 127 may define one or more interfaces to the access network 200.
  • the CN node 120 may further comprise a data storage 128, or a communication interface to an external data storage 128, for storing UE capability information and associated data, preferably for a plurality of UEs.
  • UE capability data of the data storage 128 may physically be stored in a separate memory unit, centrally in the CN 100, whereas the data storage 128 may form a database pointing to or giving access to such separately stored UE capability data.
  • a UE 1 may transmit UE capability information, e.g. stored in storage 6, to the access network 200. This may e.g. be accomplished by transmitting a bitmap to indicate its capabilities to the wireless communication network.
  • the receiving access network may store the capability information in data storage 28 and may further convey that data to the CN for central storage in data storage 128.
  • the UE 1 may send a bitmap to an access node 20. This may be accomplished upon initial registration of the UE 1 with the access network 200. However, in some scenarios the bitmap could also be transmitted at a later point of time. For example, the UE 1 could transmit the bitmap while maintaining a connection to the access network 200, e.g., for indicating an update of its capabilities.
  • the bitmap may include a plurality of bits from which subsets of one or more bits indicate whether or not, and optionally also in which way, a certain capability is supported by the UE 1. For example, a single bit of "1 " could indicate that the capability is supported. A subset of multiple bits could indicate one of multiple options of supporting a certain capability, a level of support, e.g. distinguishing between no, basic, and full support, and/or one or more parameters related to the capability, e.g. a maximum supported bitrate when using the capability.
  • the mapping of capabilities to bit positions in the bitmap may be preconfigured in the UE 1 and the access node 20. Such pre-configuration may be based on a telecommunication standard and may be based on factory settings or on operator defined settings.
  • the support of a certain capability may be indicated in a binary manner (e.g., by a single bit indicating either "supported” or “unsupported"), but also be indicated by multiple bits, e.g., to indicate a level of support, a selected option, or one or more parameters related to the capability.
  • a UE capability report is sent over the radio interface from the UE 1 to the RAN node of the serving cell, such as access node 20, when the UE 1 registers to the network 200.
  • the network 200 requests the UE 1 to send the relevant capabilities in the message“UE Capability Enquiry”.
  • the UE responds with the message“UE Capability Information”.
  • the UE Capability Enquiry may typically contain the filters which the uplink UE capability information is based on. Data associated with the UE capability information can be sent between the RAN nodes 10, 20, 30 every time the UE makes a handover to another RAN node. Thereby there is no need for the UE 1 to send the capability every time.
  • an ID is allocated to a certain set of capabilities by the network 200 where the UE 1 is registered. Then, when the UE 1 has sent the capabilities to the network 200 it will receive an ID in response which can be used as long as the UE 1 is within the PLMN.
  • Another possibility is that there is a global database where phone makers present capabilities of their models and a global ID of the set of capabilities is generated.
  • the Capability ID is defined by a vendor unique ID that identify the vendor and one ID assigned by that vendor.
  • the vendor unique ID may not be a single ID to identify that vendor, it may be the part of the TAC code that is assigned to a specific vendor. If the distribution of capabilities utilizing capability ID within the network 200 is employed, the signaling of the full capabilities over the radio interface can be rare. The distribution of the capabilities between the access nodes 10, 20, 30 can be done through the IDs and then the next access node 30 in a handover can fetch the correct set of capabilities based on the ID. However, before all access nodes in the network 200 and all UEs 1 uses any such database with the updated IDs there may be a mixed setup of distributing capabilities. Moreover, the wireless system 60 may also have to support legacy UEs which are not configured to employ capability ID signaling, or models of UEs which are not provided with vendor- specific capability IDs.
  • a method and a system solution is provided such that it is possible to always create a capability ID in the network for all UEs and use that capability ID in the network’s internal interfaces.
  • This will optimize the signaling in the network, including core network 100 and access network 200, since in any handover or switching between states (Idle and Connected) the capability ID may be used in signaling instead of additional large set of capability data (>64kB).
  • the size of the data is not the biggest problem, it is instead the time it takes to transfer the capability data during handover in the existing infrastructure. With that large amount of data, the latency to perform handover will increase too much with the existing bandwidth between RAN Nodes 10, 20 & 30.
  • the CN such as a core network node 120 including AMF
  • capability ID an already assigned capability ID.
  • the proposed solution will not be dependent on UEs being adapted for capability ID signaling. Rather, it will provide a beneficial improvement in terms of minimizing latency issues between nodes of the access network and the core network, regardless of whether the UE signals to the network 100, 200 that it has support for capability ID signaling, such as RACS.
  • creation or reuse of a capability ID may be done via creating a hash of the capabilities received from the UE. The hash may subsequently be used, e.g. by the AMF, to search in a capability database after an existing match.
  • a complementary step of matching may further be performed by comparing the received capability information with a full capability information set stored linked to the found hash.
  • Such a step may be carried out if the hash has a comparatively limited size, created with a relatively non-complex algorithm to obtain a small and hand hash of e.g. 3 bytes. This may be beneficial for searching purposes. However, this may also mean that the stored hash cannot be guaranteed to a sufficient level to uniquely represent exactly the same stored capability information as the hash created from the received capability information.
  • core network node 120 may assign a new capability ID. If, on the other hand, it is determined that capability information was already known and stored, an existing stored capability ID is used. The process of finding existing or assigning a new capability ID is not so time critical, since this is typically only done the first time the UE registers to a new network (PLMN). As soon the CN (AMF) has mapped the UE’s capability set to a capability ID then the capability ID should be used within and between nodes of the core network 100 and the access network 200. This allows an operator to use existing infrastructure and keep the latency during handover on acceptable levels.
  • Fig. 4A schematically illustrates a signaling scheme, in which method steps for and communication between various parts of a wireless communication system 60 are outlined.
  • the signaling scheme provides steps related to a UE 1, a first access node 20 a core network node 120, and a second access node 30.
  • the access nodes 20, 30 form part of an access network 200 of the wireless communication system 60 and may configured to operate as base stations for different cells of a cellular communication system 60.
  • Core network node 120 forms part of the core network 100.
  • the access network 200 and the core network 100 form part of a common PLMN network.
  • the UE 1 is configured to convey information to the network about its capability, such as radio capabilities.
  • a UE 1 may be set into connection with the network, by establishment of an RRC connection 401.
  • a step of authentication 402 may further be carried out, at which a user context may be defined, preferably by the access node 20 with which the UE 1 communicates.
  • the first access node 20 may transmit a capability enquiry message 43 to the UE 1, typically over an air interface. This step may be carried out the first time the UE 1 registers to the network, or if the UE 1 for some reason has a reason to convey updated capability information.
  • the capability enquiry message 43 may further identify a first parameter filter 41, associated with the capability information required by the first access node 20.
  • the first parameter filter may include a list of one or more parameters for which capability information of the UE 1 is requested, such as e.g. a RAT or frequency band list.
  • such a list may be included in the capability enquiry message 43, whereas in other embodiments, the capability enquiry message 43 may include a code or other data which may be linked or mapped to the list in the UE 1, e.g. by means of a lookup table, or by using a hash function stored in the UE 1.
  • step 404 the UE 1 receives the capability enquiry message 43.
  • Step 404 may include a step of compiling a capability response, in response to receiving the capability enquiry message 43. If a parameter filter 41 is received, this may involve retrieving that information by processing the parameter filter 41 in the UE 1, e.g. by means of addressing a lookup table or decoding the first parameter filter 41, as exemplified. This step may alternatively, or additionally, comprise preparing parts or details of the complete UE capabilities of the UE 1.
  • the UE 1 may transmit a capability information message 44 to the first access node 20.
  • the capability information message 44 identifies capability information, and optionally also association with the received parameter filter 41, such as an indication of what filter has been applied or simply an indication that the data is filtered.
  • the capability information message 44 may specifically identify if one or more features, such as one or more RAT types, are supported by the UE 1.
  • the first access node 20 receives the capability information message 44 from the UE 1.
  • the first access node 20 may store capability information 45 associated with the UE 1, as received in the capability information message 44 in step 407.
  • the capability information 45 may e.g. be stored in a data storage 28 of the access node 20, or in a separate but local data storage accessible through an interface of the first access node 20.
  • a method for use in a core network node 120 for handling UE capability information in a wireless communication system 60 including at least one UE 1 and an access network 200.
  • the method comprises
  • a capability message 46 comprising UE capability information 45 of said UE 1, wherein the capability message may be transmitted 409 from the first access node 20 in accordance with Fig. 4A;
  • determining 411 a capability ID 47 associated with the capability information determining 411 a capability ID 47 associated with the capability information; and transmitting 412 the determined capability ID to the access network, in a capability ID message 48, e.g. to be received 413 in the first access node 20 from which the capability information was received.
  • the first access node 20 may locally store the received capability ID 47, e.g. associated with the related capability information 45 in the data storage 28.
  • This method and a core network node 120 configured to operate according to this method, provides that a capability ID is determined associated with capability for a UE. It is subsequently sufficient to transmit the capability ID, rather than the full capability information, between various nodes of the PLMN, including the core network node 120 and different access nodes 20, 30 of the access network 200, at least as long as the corresponding capability information 45 is stored such that it is locally accessible in the node receiving the capability ID. This way, latency issues associated with transmitting large sets of capability information between the nodes 120, 20, 30 may be improved.
  • the network nodes are not confined to only obtain this latency relief for UEs supporting transmission of capability IDs, such as RACS, or vendor models for which there is a pre-defined capability ID.
  • the UE context is typically maintained in the connected access node 20 and moved to a second access node 30 if a handover 415 to that access node 30 is initiated, which is indicated in Fig. 4A.
  • a corresponding situation may be that a UE 1 is set to a semi-connected state, such as RRC_INACTIVE, at which connection to the access network 200 is lost, while an active interface is maintained between the core network 100 and the access network.
  • the UE context may then be maintained in an anchor node of e.g.
  • RNA such as the first access node 20.
  • the UE context may be transferred from the anchor node, e.g. the first access node 20, to the access node with which connection is resumed, e.g. access node 30.
  • the UE context is typically transferred to the core network 100.
  • a triggering event may be detected to set the UE 1 to connected mode, (e.g.
  • a triggering event to enter a connected state may be data to be transmitted in the downlink, wherein a paging process from the access network 200 is initiated.
  • the triggering event may be that the UE 1 has data for transmission in the uplink and transmits a service request to the access network 200.
  • the access node 30 setting up the connection with the UE 1 will then retrieve the UE context from either the first access node 20 or from the core network 100, dependent on the state as just outlined.
  • the UE context is preferably transmitted between the nodes 20, 30, 120 within the network together with the capability ID 47, and not the full capability information.
  • a handover scenario 415 is initiated, wherein connection to the UE 1 is transferred from the first access node 20 to the second access node 30.
  • this includes transmitting the capability ID 47 from the first access node 20 to the second access node 30, where it is received 417.
  • the second access node further stores the received capability ID as associated with the UE 1 in a data storage 38.
  • the transmission of the capability ID may be accomplished as a message or signal 49 provided over an inter-access node interface, such as an Xn interface.
  • the transmission of the capability ID 47 may be carried out in a common message 49 as the UE context of the UE 1, or otherwise associated with or linked to transmission of the UE context.
  • Fig. 4B illustrates various embodiments associated with the step 411 of determining the capability ID. In one embodiment, this may involve
  • the core network node 120 such as the AMF, will ensure that every set of capability information is provided with a capability ID 47. Either, if that capability ID 47 is already defined, it may be accessed from a data storage 128 where it is associated with the capability information 45; or if no such previously defined capability ID is available and found, a capability ID 47 is created by the core network node 120.
  • the core network node 120 has received capability information 45 associated with a UE 1.
  • a hash 50 may be created 4111 from the capability information 45.
  • the hash 50 may be calculated using a predetermined hash mechanism based on the data of the capability information 45.
  • the hash mechanism may e.g. be SHA-2 or SHA-3, where SHA denotes Secure Hash Algorithm.
  • the hash 50 will always have a specific number of bits, determined by the algorithm, and constitutes a fingerprint of the data of the capability information 45.
  • a device such an access node 20, may be able to calculate exactly the same hash using the hash mechanism as another device, such as the core network node 120, once they have access to the same data.
  • the complexity of the hash function is such that merely having access to the hash and the hash function is not sufficient to reconstruct the data.
  • the hash 50 created in step 4111 from the capability information 45 is or forms part of the capability ID 47 associated with that capability information 45.
  • a less complex hash 50 is created for the purpose of convenient search in a database associated with the data storage 128.
  • the core network node 120 accesses the database of storage 128 containing stored capability data, to search for a stored capability ID matching the capability information 45.
  • this may involve using different database searches in different data memories 128, associated with vendor- specific IDs and operator or network- specific IDs.
  • this access and search may be carried out using said hash 50.
  • the whole capability ID, or parts of it may be used as input for search.
  • step 4113 continuation of the method is determined dependent on outcome of the search of step 4112.
  • the core network node 120 proceeds to retrieve the associated capability ID 47 from the data storage 128.
  • a further step of more extensive comparison 4114 may be carried out. This may e.g. be the case when the hash 50 is carried out with a less exact algorithm than what is used to determine the capability ID 47 from the capability information 45, or where at least the search input, e.g. the hash 50, is different from the associated capability ID 47 in the database.
  • the received capability information 45 may be compared to stored capability information in the data storage 128, associated by means of the corresponding database.
  • an associated capability ID 47 may be retrieved 4116 from the database associated with the data storage 128.
  • a step of creating 4117 a capability ID 47 is carried out, based on the capability information 45. This step is may be carried out in a standardized manner, or alternatively using a network or vendor- specific process. The important thing is that the created capability ID 47 is unique in at least the PLMN network of the wireless system 60.
  • a step of storing 4118 the created capability ID 47 and the associated UE capability information 45 in said database is then carried out, where the data of that database is stored in the data storage 128. The created capability ID 47 is then available for search and access in a subsequent process according to step 411 for another UE.
  • the proposed solutions provide several benefits. Generally, the proposed solutions serve to minimize the amount of data that has to be transmitted between various nodes of a wireless communication system 60, for handling UE capability. Specifically, latency problems in the network may be overcome using the solutions provided herein. According to these solutions, it is irrelevant whether or not UE signals to the network 100, 200 that it has support for capability ID signaling, such as RACS.
  • the core network 100 such as the AMF 110 of a core network node 120 should always allocate a capability ID to every UE, for subsequent use in signaling between nodes of the network 100, 200.
  • the capability ID uniquely identifies the capability information in the network 100, 200, preferably at least radio capabilities associated with the access network 200. For handover, and when a UE switches between IDLE and CONNECTED, the interface between access nodes 20, 30 and between access nodes 20, 30 and the core network node 120 such as the AMF, should always include capability ID instead of the actual capability information.

Abstract

A method for use in a core network node (120) for handling user equipment, UE, capability information in a wireless communication system (60) including at least one UE (1) and an access network (200). The method comprises receiving (410), from the access network, a capability message (46) comprising UE capability information (45) of said UE (1); determining (411) a capability ID associated with the capability information; transmitting (412) the determined capability ID to the access network.

Description

HANDLING USER EQUIPMENT CAPABILITY INFORMATION BY A CORE NETWORK NODE AND AN ACCESS NETWORK NODE OF A WIRELESS
COMMUNICATION NETWORK
Technical Field
This disclosure relates to methods and devices for handling capabilities of a terminal in a wireless communication system including a core network, an access network and one or more terminals. More specifically, solutions are provided for identification and transmission of identification of capabilities between various entities within the network.
Background
In wireless communication systems, such as various generations provided through the 3rd Generation Partnership Project (3GPP), various generations of specifications have been provided for setting up common rules for setting up and operating both a wireless radio interface between a wireless terminal and a base station, and various levels of operation of the wireless network. In 3GPP documentation, a wireless terminal, or wireless communication device, is commonly referred to as a User Equipment (UE). A base station defines a cell and is operative to serve a surrounding area with radio access for UEs, by providing radio access to UEs within a cell. A base station is also referred to herein as a node or access node, and various terms are used in 3GPP for different types of systems or specification. An access network, or Radio Access Network (RAN), typically includes a plurality of access nodes, and is connected to a Core Network (CN) which inter alia provides access to other communication networks. In the so-called 3G specifications, also referred to as the Universal Mobile Telecommunications System (UMTS), the term NodeB is used to denote an access node, whereas in the so-called 4G specifications, also referred to as Long-Term
Evolution (LTE), the term eNodeB (eNB) is used. A further developed set of specifications for radio communication are referred to as the 5G type radio
communication system (5GS), including the New Radio (NR) technology, wherein the term gNB is used to denote an access node. UEs can have many different capabilities, such as radio capabilities, e.g., associated with modem properties or supported functionality in the UE or combination of frequency bands that the UE does not have good coverage for. In order to make various entities of the wireless network aware of the capabilities supported by a certain UE, the UE indicates its capabilities to the wireless network. This is typically accomplished when the UE registers with the wireless communication network. The capabilities can be indicated in different formats, e.g., in terms of parameters or indicators listed in one or more information elements of a message.
In general, the UE may indicate multiple different capabilities, which may for example concern frequency bands of a wireless communications system, supported frequency band combinations, support of different modulation and demodulation formats, maximum data demodulation rate, 3GPP release version, or specific functions such as relaying or the support of device-to-device communication. In the existing technology, the UE capabilities are indicated in a rather static manner to the network. The capabilities may be indicated upon initial network registration and in some handover scenarios, in response to the network sending a UE capability enquiry. For initiating an update of the capability information from the UE side, the UE may need to re-register in the network.
Historically, capabilities are always transferred when the UE register to the network and usually only a filtered set of capabilities. During mobility and context transfer to different base stations the new base station may request if additional capability is supported and add that to the UE’s Radio Capability that exist in the network. Capability handling in the wireless network has involved nodes and UEs sending only a usable set of UE capabilities that is very small (2-8kB) in size. This means that for every new base station that handles the UE then additional UE Radio Capabilities may need to be requested from the UE. With the increasing amount of UEs operating in the wireless networks, and the concurrently increasing number of supportable services, features, radio frequency bands etc., the data size of the UE capabilities continues to grow. Current 3GPP releases already have problems with the size of the capabilities.
Solutions related to radio capability signaling, RACS, have therefore been discussed, e.g. in 3GPP documents TR 23.743. Studies approved within 3GPP to investigate ways of improvement have suggested allocating static capabilities ID per vendor & model or hash for the complete set of capabilities. With RACS it is expected in case of a PLMN-assigned ID that a capability ID is sent to the UE after the UE capability information has been reported by the UE, and after that only the capability ID is transferred when the UE reports its capabilities. If a UE Manufacturer-assigned capability ID is used, the operator may only support a limited set of vendor’s external servers for the most common UE models. The operator may also have UEs not supporting RACS but still have requirements to support low latency with existing infrastructure.
Accordingly, there is a need for techniques that allow for efficiently indicating supported capabilities of a UE or similar wireless communication device to the wireless communication network and in an efficient way communicate this internally within the 3 GPP network, both within the access network and to/from the core network.
Summary
A general object is to provide improved solutions for handling UE capability information in a wireless communication system. In particular, an aspect of this object is to minimize latency associated with transfer of capability data within the
communication system during handover of a UE from one access node to another. These and other objects are targeted by means of the solutions laid out in the independent claims. Further advantageous embodiments are laid out in the dependent claims.
In accordance with a first aspect, method is provided for use in a core network node for handling user equipment, UE, capability information in a wireless
communication system including at least one UE and an access network, comprising receiving, from the access network, a capability message comprising UE capability information of said UE;
determining a capability ID associated with the capability information;
transmitting the determined capability ID to the access network.
This way, a capability ID will be provided for every UE, for subsequent use in signaling between nodes of the network, thereby minimizing latency caused by transmission of extensive capability information for example between access nodes.
In one embodiment, determining includes retrieving stored capability ID matching the capability information; or creating a determined capability ID, responsive to not having access to stored capability ID matching the capability information.
By configuring the core network node to create capability ID where none is previously provided, convenient use of capability IDs may be employed even for legacy UEs not configured to provide a capability ID.
In one embodiment, determining includes
searching a capability database for a stored capability ID matching the capability information. Hence, a new capability ID does not need to be created if a Capability ID matching the UE’s capabilities already exists.
In one embodiment, the determined capability ID is created in said core network node based on said capability information.
In one embodiment, the method comprises
storing the created capability ID and the associated UE capability information in said database.
In one embodiment, the method comprises
comparing the received UE capability information with stored UE capability information to determine whether to retrieve or create the determined capability ID.
In one embodiment, the searching comprises
creating for example a hash from the received UE capability information;
searching a database for a corresponding hash and associated stored UE capability information and capability ID.
In one embodiment, said hash at least forms part of the determined capability ID. According to a second aspect, a method is provided for use in a first access node for handling user equipment, UE, capability information in an access network of a wireless communication system including a core network node and at least one UE, comprising
receiving, from said UE, a capability message comprising UE capability information;
transmitting said UE capability information to the core network node;
receiving a capability ID associated with the UE capability information.
In one embodiment, the method comprises
storing the capability ID. In one embodiment, the method comprises
detecting initiation of a handover of said UE from the first access node to a second access node;
transmitting the capability ID to the second access node.
In one embodiment, the method comprises
detecting a state change of the UE to an idle state;
initiating UE context transfer from the first access node to the core network node; transmitting the capability ID to the core network node in association with the UE context.
According to a third aspect, a core network node is provided for handling user equipment, UE, capability information in a wireless communication system including at least one UE and an access network, comprising
a logic configured to execute computer program code to control the core network node to carry out any of the steps outlined above.
According to a fourth aspect, an access node is provided for handling user equipment, UE, capability information in an access network of a wireless
communication system including a core network and at least one UE, comprising
a logic configured to execute computer program code to control the access node to carry out any of the steps outlined above.
Brief description of the drawings
Various embodiments will be described with reference to the drawings, in which
Fig. 1 schematically illustrates a network of a wireless communication system including networks nodes according to various embodiments;
Fig. 2 schematically illustrates elements included in a UE configured in accordance with various embodiments;
Figs 3A-3B schematically illustrate elements included in access nodes configured in accordance with various embodiments;
Fig. 3C schematically illustrate elements included in a core network node configured in accordance with various embodiments; Fig. 4A shows a signaling scheme including several method steps carried out in various nodes in a wireless communication system, where different steps may be included in different embodiments as outlined in further detail below;
Fig. 4B shows a signaling scheme including several method steps carried out in a core network node in different embodiments.
Detailed description of embodiments
The invention will be described more fully hereinafter with reference to the accompanying drawings, in which embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.
It will be understood that, when an element is referred to as being“connected” to another element, it can be directly connected to the other element or intervening elements may be present. In contrast, when an element is referred to as being“directly connected” to another element, there are no intervening elements present. Like numbers refer to like elements throughout. It will furthermore be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and, similarly, a second element could be termed a first element, without departing from the scope of the present invention. As used herein, the term“and/or” includes any and all combinations of one or more of the associated listed items.
Well-known functions or constructions may not be described in detail for brevity and/or clarity. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense expressly so defined herein. Embodiments of the invention are described herein with reference to schematic illustrations of idealized embodiments of the invention. As such, variations from the shapes and relative sizes of the illustrations as a result, for example, of manufacturing techniques and/or tolerances, are to be expected. Thus, embodiments of the invention should not be construed as limited to the particular shapes and relative sizes of regions illustrated herein but are to include deviations in shapes and/or relative sizes that result, for example, from different operational constraints and/or from manufacturing constraints. Thus, the elements illustrated in the figures are schematic in nature and their shapes are not intended to illustrate the actual shape of a region of a device and are not intended to limit the scope of the invention.
Fig. 1 schematically illustrates a wireless communication system 60, including an access network 200. The access network 200 is in turn connected to a core network (CN) 100, which provides access to other communication networks, such as the
Internet. The access network 200 may include a plurality of access nodes 10, 20, 30 configured to serve various cells. The access network 200 may e.g. be a Radio Access Network (RAN). A UE 1 is a wireless device configured to communicate wirelessly with access nodes of the access network 200, such as by radio. UEs may be stationary or mobile.
Each access node 10, 20, 30 may in various embodiments be referred to as a base station, serving one cell each. The access network 200 may comprise a number of subareas, which may be referred to as RAN Notification Areas (RNA). Each RNA may consist of a number of cells, where each cell is served by one access node 20. One of those cells may be referred to as an anchor cell. The anchor cell includes the access node 20 that has configured interface to the core network 100 for Control plane and User plane, referred to as N2 and N3 interfaces in 5G. Corresponding interfaces Sl-C and Sl-U are provided in LTE. The access nodes 10, 30 of the other cells of the RNA may be connected to the anchor cell 20 by means of a logical inter- node interface 20 E In 5G, this interface, or set of interfaces, is referred to as Xn interface, and has a similar purpose as the X2 interface defined for LTE.
The CN 100 may include various core network nodes 120 in the form of or comprising entities, nodes or functions 110, 111, 112, defined in accordance with a certain 3GPP release or in accordance with another set of wireless communication standards. Such CN entities may e.g. include a node 110 for handling mobility of UEs, such as an Access & Mobility management Function (AMF) and Session Management Function (SMF). The CN may further include a User Plane Function UPF 112, or gateways 111, such as one or more of a Serving Gateway and a PDN Gateway. The CN may also include, or have a communication interface to, a data storage 128 accessible through a database and configured to store data associated with UE capability information.
Fig. 2 schematically illustrates a UE 1. The UE 1 may be configured for communication with an access network 200, and comprise a transceiver 2, such as a radio receiver and transmitter for communicating with the access network 200 through at least an air interface. The terminal 1 further comprises a logic 3. The logic 3 may comprise for example a controller or microprocessor 4. The logic may also comprise or be connected to a data storage device 5 configured to include a computer readable storage medium. The data storage device 5 may include a memory and may be, for example, one or more of a buffer, a flash memory, a hard drive, a removable media, a volatile memory, a non-volatile memory, a random access memory (RAM), or other suitable device. In a typical arrangement, the data storage device 5 includes a non volatile memory for long term data storage and a volatile memory that functions as system memory for the controller 4. The data storage device 5 may exchange data with a processor 4 of the logic 3 over a data bus. The data storage device 5 is considered a non-transitory computer readable medium. One or more processors of the logic 3 may execute instructions stored in the data storage device or a separate memory in order to carry out operation of the UE 1, as outlined herein. The UE 1 may further comprise a data memory 6 for storing UE capability information and associated data. The data memory 6 may be or form part of the data storage device 5, or be a separate entity, but is specifically indicated in the drawing to identify the intended difference between storing code associated with a computer program or operating system in data storage 5 used for controlling and operating the UE 1, from capability data which can be accessed and sent to other nodes of the wireless system 60. It may be noted that the UE 1 clearly may include other features and functions than those identified, such as e.g. one or more antennas, a user interface, a power source and so on, but these components are not shown in Fig. 2 for clarity reasons.
Fig. 3A schematically illustrates an access node 20, also referred to herein as a first access node 20, whereas Fig. 3B which schematically illustrates another access node 30, also referred to herein as a second access node 30. In various embodiments, the first 20 and second 30 access nodes may be similar or even identical. In other embodiments, they may be more or less different, and have different radio capabilities in terms of e.g. supported radio access technology (RAT), supported frequency bands and band combinations. In terms of functional entities, the first 20 and second 30 access nodes comprise corresponding elements or functions. In this respect, each access node 20, 30 comprise an access node logic 24, 34. The access node logic 24, 34 may comprise for example a controller or microprocessor 25, 35. The logic 24, 34 may also comprise or be connected to a data storage device 26, 36 configured to include a computer readable storage medium. The data storage device 26, 36 may include a memory and may be, for example, one or more of a buffer, a flash memory, a hard drive, a removable media, a volatile memory, a non-volatile memory, a random access memory (RAM), or other suitable device. In a typical arrangement, the data storage device 26, 36 includes a non-volatile memory for long term data storage and a volatile memory that functions as system memory for the control unit. The data storage device 26, 36 may exchange data with a processor of the logic 24, 34 over a data bus. The data storage device is considered a non-transitory computer readable medium. One or more processors 25, 35 of the logic 24, 34 may execute instructions stored in the data storage device or a separate memory in order to carry out operation of the access node 20, 30, as outlined herein. Each access node 20, 30 may comprise more components, for example a power supply, but these components are not shown in Figs 3A and 3B for clarity reasons. The access nodes 20, 30 may further comprise one or more communication interfaces 27, 37 for communication with other entities. For example, the
communication interfaces 27, 37 may comprise a radio transceiver connected to an antenna arrangement (not shown), for communication over an air interface with the UE 1. Moreover, the communication interfaces 27, 37 may define one or more interfaces to the core network 100. The access nodes 20, 30 may further comprise a data storage 28, 38 for storing UE capability information and associated data, preferably for a plurality of UEs. The data storage 28, 38 may form part of the data storage device 26, 36 or be a separate entity. Indeed, the data storage 28, 38 may be located centrally accessible for a number of access nodes 10, 20, 30, e.g. in a storage 28, 38 dedicated to several access nodes that may or may not be part of the same RNA. Fig. 3C schematically illustrates a core network (CN) node 120, which may include one or more parts of the nodes 110, 111, 112 outlined with reference to Fig. 1. The core network node 120 which comprises a CN node logic 124. The CN node logic 124 may comprise for example a controller or microprocessor 125. The logic 124 may also comprise or be connected to a data storage device 126 configured to include a computer readable storage medium. The data storage device 126 may include a memory and may be, for example, one or more of a buffer, a flash memory, a hard drive, a removable media, a volatile memory, a non-volatile memory, a random access memory (RAM), or other suitable device. In a typical arrangement, the data storage device 126 includes a non-volatile memory for long term data storage and a volatile memory that functions as system memory for the control unit. The data storage device 126 may exchange data with a processor of the logic 124 over a data bus. The data storage device is considered a non-transitory computer readable medium. One or more processors 125 of the logic 124 may execute instructions stored in the data storage device or a separate memory in order to carry out operation of the CN node 120, as outlined herein. The CN node 120 may comprise more components, for example a power supply, but these components are not shown in Fig. 3C for clarity reasons. The CN node 120 may further comprise one or more transceivers or interfaces 127 for communication with other entities. For example, the interface 127 may comprise an interface for communication with other networks, e.g. the Internet. Moreover, the interface or transceiver 127 may define one or more interfaces to the access network 200. The CN node 120 may further comprise a data storage 128, or a communication interface to an external data storage 128, for storing UE capability information and associated data, preferably for a plurality of UEs. UE capability data of the data storage 128 may physically be stored in a separate memory unit, centrally in the CN 100, whereas the data storage 128 may form a database pointing to or giving access to such separately stored UE capability data.
As noted, a UE 1 may transmit UE capability information, e.g. stored in storage 6, to the access network 200. This may e.g. be accomplished by transmitting a bitmap to indicate its capabilities to the wireless communication network. The receiving access network may store the capability information in data storage 28 and may further convey that data to the CN for central storage in data storage 128. For indicating its capabilities to the wireless communication network, the UE 1 may send a bitmap to an access node 20. This may be accomplished upon initial registration of the UE 1 with the access network 200. However, in some scenarios the bitmap could also be transmitted at a later point of time. For example, the UE 1 could transmit the bitmap while maintaining a connection to the access network 200, e.g., for indicating an update of its capabilities. The bitmap may include a plurality of bits from which subsets of one or more bits indicate whether or not, and optionally also in which way, a certain capability is supported by the UE 1. For example, a single bit of "1 " could indicate that the capability is supported. A subset of multiple bits could indicate one of multiple options of supporting a certain capability, a level of support, e.g. distinguishing between no, basic, and full support, and/or one or more parameters related to the capability, e.g. a maximum supported bitrate when using the capability. The mapping of capabilities to bit positions in the bitmap may be preconfigured in the UE 1 and the access node 20. Such pre-configuration may be based on a telecommunication standard and may be based on factory settings or on operator defined settings. Accordingly, the support of a certain capability may be indicated in a binary manner (e.g., by a single bit indicating either "supported" or "unsupported"), but also be indicated by multiple bits, e.g., to indicate a level of support, a selected option, or one or more parameters related to the capability.
In 3GPP terminology, e.g. as employed in technical specification TR 38.331, a UE capability report is sent over the radio interface from the UE 1 to the RAN node of the serving cell, such as access node 20, when the UE 1 registers to the network 200. The network 200 requests the UE 1 to send the relevant capabilities in the message“UE Capability Enquiry”. The UE responds with the message“UE Capability Information”. The UE Capability Enquiry may typically contain the filters which the uplink UE capability information is based on. Data associated with the UE capability information can be sent between the RAN nodes 10, 20, 30 every time the UE makes a handover to another RAN node. Thereby there is no need for the UE 1 to send the capability every time.
As will be discussed further below, various embodiments may involve sending IDs that refers to different sets of UE capabilities, rather than the full data of the UE capability information. Different solutions may be employed for this purpose. In one example, an ID is allocated to a certain set of capabilities by the network 200 where the UE 1 is registered. Then, when the UE 1 has sent the capabilities to the network 200 it will receive an ID in response which can be used as long as the UE 1 is within the PLMN. Another possibility is that there is a global database where phone makers present capabilities of their models and a global ID of the set of capabilities is generated. Another alternative is that the Capability ID is defined by a vendor unique ID that identify the vendor and one ID assigned by that vendor. The vendor unique ID may not be a single ID to identify that vendor, it may be the part of the TAC code that is assigned to a specific vendor. If the distribution of capabilities utilizing capability ID within the network 200 is employed, the signaling of the full capabilities over the radio interface can be rare. The distribution of the capabilities between the access nodes 10, 20, 30 can be done through the IDs and then the next access node 30 in a handover can fetch the correct set of capabilities based on the ID. However, before all access nodes in the network 200 and all UEs 1 uses any such database with the updated IDs there may be a mixed setup of distributing capabilities. Moreover, the wireless system 60 may also have to support legacy UEs which are not configured to employ capability ID signaling, or models of UEs which are not provided with vendor- specific capability IDs.
For these reasons, it is hereby proposed that regardless of whether or not a UE supports signaling of capability IDs, such as using RACS, a method and a system solution is provided such that it is possible to always create a capability ID in the network for all UEs and use that capability ID in the network’s internal interfaces. This will optimize the signaling in the network, including core network 100 and access network 200, since in any handover or switching between states (Idle and Connected) the capability ID may be used in signaling instead of additional large set of capability data (>64kB). According to some operators the size of the data is not the biggest problem, it is instead the time it takes to transfer the capability data during handover in the existing infrastructure. With that large amount of data, the latency to perform handover will increase too much with the existing bandwidth between RAN Nodes 10, 20 & 30.
The idea is that in all cases the UE does not send a capability ID to the access network 200 then the CN, such as a core network node 120 including AMF
functionality, should create or reuse an already assigned capability ID. The proposed solution will not be dependent on UEs being adapted for capability ID signaling. Rather, it will provide a beneficial improvement in terms of minimizing latency issues between nodes of the access network and the core network, regardless of whether the UE signals to the network 100, 200 that it has support for capability ID signaling, such as RACS. From an implementation point of view, creation or reuse of a capability ID may be done via creating a hash of the capabilities received from the UE. The hash may subsequently be used, e.g. by the AMF, to search in a capability database after an existing match.
This may be accomplished by finding the same hash.
When a matching hash is found, a complementary step of matching may further be performed by comparing the received capability information with a full capability information set stored linked to the found hash. Such a step may be carried out if the hash has a comparatively limited size, created with a relatively non-complex algorithm to obtain a small and hand hash of e.g. 3 bytes. This may be beneficial for searching purposes. However, this may also mean that the stored hash cannot be guaranteed to a sufficient level to uniquely represent exactly the same stored capability information as the hash created from the received capability information.
If the received capability information is a new set of capabilities, then core network node 120 may assign a new capability ID. If, on the other hand, it is determined that capability information was already known and stored, an existing stored capability ID is used. The process of finding existing or assigning a new capability ID is not so time critical, since this is typically only done the first time the UE registers to a new network (PLMN). As soon the CN (AMF) has mapped the UE’s capability set to a capability ID then the capability ID should be used within and between nodes of the core network 100 and the access network 200. This allows an operator to use existing infrastructure and keep the latency during handover on acceptable levels.
Fig. 4A schematically illustrates a signaling scheme, in which method steps for and communication between various parts of a wireless communication system 60 are outlined. Specifically, the signaling scheme provides steps related to a UE 1, a first access node 20 a core network node 120, and a second access node 30. In various embodiments, a subset of the steps of Fig. 4, may be included, whereas other embodiments may include more, or all, step provided in the drawing. With reference to Fig. 1, the access nodes 20, 30 form part of an access network 200 of the wireless communication system 60 and may configured to operate as base stations for different cells of a cellular communication system 60. Core network node 120 forms part of the core network 100. The access network 200 and the core network 100 form part of a common PLMN network. In order to operate conveniently with the access network 200, the UE 1 is configured to convey information to the network about its capability, such as radio capabilities.
As an introduction to the context of the invention, a UE 1 may be set into connection with the network, by establishment of an RRC connection 401.
When a UE 1 connects to and registers to the network, a step of authentication 402 may further be carried out, at which a user context may be defined, preferably by the access node 20 with which the UE 1 communicates.
In step 403, the first access node 20 may transmit a capability enquiry message 43 to the UE 1, typically over an air interface. This step may be carried out the first time the UE 1 registers to the network, or if the UE 1 for some reason has a reason to convey updated capability information. The capability enquiry message 43 may further identify a first parameter filter 41, associated with the capability information required by the first access node 20. In various embodiments, the first parameter filter may include a list of one or more parameters for which capability information of the UE 1 is requested, such as e.g. a RAT or frequency band list. In some embodiments, such a list may be included in the capability enquiry message 43, whereas in other embodiments, the capability enquiry message 43 may include a code or other data which may be linked or mapped to the list in the UE 1, e.g. by means of a lookup table, or by using a hash function stored in the UE 1.
In step 404, the UE 1 receives the capability enquiry message 43.
Step 404 may include a step of compiling a capability response, in response to receiving the capability enquiry message 43. If a parameter filter 41 is received, this may involve retrieving that information by processing the parameter filter 41 in the UE 1, e.g. by means of addressing a lookup table or decoding the first parameter filter 41, as exemplified. This step may alternatively, or additionally, comprise preparing parts or details of the complete UE capabilities of the UE 1.
In step 406, the UE 1 may transmit a capability information message 44 to the first access node 20. The capability information message 44 identifies capability information, and optionally also association with the received parameter filter 41, such as an indication of what filter has been applied or simply an indication that the data is filtered. In this respect, the capability information message 44 may specifically identify if one or more features, such as one or more RAT types, are supported by the UE 1. In step 407, the first access node 20 receives the capability information message 44 from the UE 1.
In step 408, the first access node 20 may store capability information 45 associated with the UE 1, as received in the capability information message 44 in step 407. The capability information 45 may e.g. be stored in a data storage 28 of the access node 20, or in a separate but local data storage accessible through an interface of the first access node 20.
In accordance with various embodiments, a method is provided for use in a core network node 120 for handling UE capability information in a wireless communication system 60 including at least one UE 1 and an access network 200. In these
embodiments, the method comprises
receiving 410, from the access network 200, a capability message 46 comprising UE capability information 45 of said UE 1, wherein the capability message may be transmitted 409 from the first access node 20 in accordance with Fig. 4A;
determining 411 a capability ID 47 associated with the capability information; and transmitting 412 the determined capability ID to the access network, in a capability ID message 48, e.g. to be received 413 in the first access node 20 from which the capability information was received.
In step 414, the first access node 20 may locally store the received capability ID 47, e.g. associated with the related capability information 45 in the data storage 28.
This method, and a core network node 120 configured to operate according to this method, provides that a capability ID is determined associated with capability for a UE. It is subsequently sufficient to transmit the capability ID, rather than the full capability information, between various nodes of the PLMN, including the core network node 120 and different access nodes 20, 30 of the access network 200, at least as long as the corresponding capability information 45 is stored such that it is locally accessible in the node receiving the capability ID. This way, latency issues associated with transmitting large sets of capability information between the nodes 120, 20, 30 may be improved. Moreover, by determining the capability ID in the core node 120, the network nodes are not confined to only obtain this latency relief for UEs supporting transmission of capability IDs, such as RACS, or vendor models for which there is a pre-defined capability ID. The UE context is typically maintained in the connected access node 20 and moved to a second access node 30 if a handover 415 to that access node 30 is initiated, which is indicated in Fig. 4A. A corresponding situation may be that a UE 1 is set to a semi-connected state, such as RRC_INACTIVE, at which connection to the access network 200 is lost, while an active interface is maintained between the core network 100 and the access network. The UE context may then be maintained in an anchor node of e.g. an RNA, such as the first access node 20. If active connection between the access network 200 and the UE 1 is resumed, responsive to a triggering event, the UE context may be transferred from the anchor node, e.g. the first access node 20, to the access node with which connection is resumed, e.g. access node 30.
In an alternative scenario, when the UE 1 is configured to enter an idle mode or state, the UE context is typically transferred to the core network 100. At any later time, a triggering event may be detected to set the UE 1 to connected mode, (e.g.
RRC_CONNECTED).
A triggering event to enter a connected state may be data to be transmitted in the downlink, wherein a paging process from the access network 200 is initiated.
Alternatively, the triggering event may be that the UE 1 has data for transmission in the uplink and transmits a service request to the access network 200. The access node 30 setting up the connection with the UE 1 will then retrieve the UE context from either the first access node 20 or from the core network 100, dependent on the state as just outlined.
In these embodiments of handover 415, entering a connected state from an idle state, and resuming a connected state from an inactive state, the UE context is preferably transmitted between the nodes 20, 30, 120 within the network together with the capability ID 47, and not the full capability information.
In the particular embodiment of Fig. 4A, a handover scenario 415 is initiated, wherein connection to the UE 1 is transferred from the first access node 20 to the second access node 30.
In step 416, this includes transmitting the capability ID 47 from the first access node 20 to the second access node 30, where it is received 417. Preferably, the second access node further stores the received capability ID as associated with the UE 1 in a data storage 38. The transmission of the capability ID may be accomplished as a message or signal 49 provided over an inter-access node interface, such as an Xn interface. The transmission of the capability ID 47 may be carried out in a common message 49 as the UE context of the UE 1, or otherwise associated with or linked to transmission of the UE context.
Fig. 4B illustrates various embodiments associated with the step 411 of determining the capability ID. In one embodiment, this may involve
retrieving 4116 stored capability ID 47 matching the capability information 45; or creating 4117 a determined capability ID 47, responsive to or upon not having access to stored capability ID matching the capability information.
In this process, the core network node 120, such as the AMF, will ensure that every set of capability information is provided with a capability ID 47. Either, if that capability ID 47 is already defined, it may be accessed from a data storage 128 where it is associated with the capability information 45; or if no such previously defined capability ID is available and found, a capability ID 47 is created by the core network node 120.
Various aspects that may be included in this embodiment will now be outlined, by describing the process of Fig. 4B. It should thus be understood that not all these steps need to be included in an embodiment, unless leaving such step out is contradictory.
In a preceding step 410, the core network node 120 has received capability information 45 associated with a UE 1.
In order to search for a stored capability ID 47 matching the received capability information 45, a hash 50 may be created 4111 from the capability information 45. The hash 50 may be calculated using a predetermined hash mechanism based on the data of the capability information 45. The hash mechanism may e.g. be SHA-2 or SHA-3, where SHA denotes Secure Hash Algorithm. The hash 50 will always have a specific number of bits, determined by the algorithm, and constitutes a fingerprint of the data of the capability information 45. Specifically, a device, such an access node 20, may be able to calculate exactly the same hash using the hash mechanism as another device, such as the core network node 120, once they have access to the same data. On the other hand, the complexity of the hash function is such that merely having access to the hash and the hash function is not sufficient to reconstruct the data.
In one embodiment, the hash 50 created in step 4111 from the capability information 45 is or forms part of the capability ID 47 associated with that capability information 45. In another embodiment, a less complex hash 50 is created for the purpose of convenient search in a database associated with the data storage 128.
In step 4112, the core network node 120 accesses the database of storage 128 containing stored capability data, to search for a stored capability ID matching the capability information 45. In various embodiments, this may involve using different database searches in different data memories 128, associated with vendor- specific IDs and operator or network- specific IDs. Where a preceding step 4111 is included, this access and search may be carried out using said hash 50. In an alternative embodiment, the whole capability ID, or parts of it, may be used as input for search.
In step 4113, continuation of the method is determined dependent on outcome of the search of step 4112.
If a match is made (Y), i.e. that an entry in the database related to data stored in the data storage 128 matches the search criteria, such as the hash 50, the core network node 120 proceeds to retrieve the associated capability ID 47 from the data storage 128.
In an embodiment where the search criteria, e.g. the hash 50, is not identical to the matching capability ID 47, a further step of more extensive comparison 4114 may be carried out. This may e.g. be the case when the hash 50 is carried out with a less exact algorithm than what is used to determine the capability ID 47 from the capability information 45, or where at least the search input, e.g. the hash 50, is different from the associated capability ID 47 in the database. In this comparison, the received capability information 45 may be compared to stored capability information in the data storage 128, associated by means of the corresponding database.
If a match is made (Y), i.e. that the entry found in the database in the search 4112 points to capability information which is identical, or to a predetermined degree matches, the received capability information, an associated capability ID 47 may be retrieved 4116 from the database associated with the data storage 128.
If a match is not made (N), either in the step of searching 4112 or in the step of comparing 4114, a step of creating 4117 a capability ID 47 is carried out, based on the capability information 45. This step is may be carried out in a standardized manner, or alternatively using a network or vendor- specific process. The important thing is that the created capability ID 47 is unique in at least the PLMN network of the wireless system 60. A step of storing 4118 the created capability ID 47 and the associated UE capability information 45 in said database is then carried out, where the data of that database is stored in the data storage 128. The created capability ID 47 is then available for search and access in a subsequent process according to step 411 for another UE.
The proposed solutions provide several benefits. Generally, the proposed solutions serve to minimize the amount of data that has to be transmitted between various nodes of a wireless communication system 60, for handling UE capability. Specifically, latency problems in the network may be overcome using the solutions provided herein. According to these solutions, it is irrelevant whether or not UE signals to the network 100, 200 that it has support for capability ID signaling, such as RACS. The core network 100, such as the AMF 110 of a core network node 120 should always allocate a capability ID to every UE, for subsequent use in signaling between nodes of the network 100, 200. Preferably, the capability ID uniquely identifies the capability information in the network 100, 200, preferably at least radio capabilities associated with the access network 200. For handover, and when a UE switches between IDLE and CONNECTED, the interface between access nodes 20, 30 and between access nodes 20, 30 and the core network node 120 such as the AMF, should always include capability ID instead of the actual capability information.

Claims

1. A method for use in a core network node (120) for handling user equipment, UE, capability information in a wireless communication system (60) including at least one UE (1) and an access network (200), comprising
receiving (410), from the access network, a capability message (46) comprising UE capability information (45) of said UE (1);
determining (411) a capability ID associated with the capability information; transmitting (412) the determined capability ID to the access network.
2. The method of claim 1, wherein determining includes
retrieving (4116) stored capability ID matching the capability information; or creating (4117) a determined capability ID, responsive to not having access to stored capability ID matching the capability information.
3. The method of claim 2, wherein determining includes
searching (4112) a capability database (128) for a stored capability ID matching the capability information.
4. The method of any preceding claim, wherein the determined capability ID is created (4117) in said core network node based on said capability information.
5. The method of any of claims 2-4, comprising
storing (4118) the created capability ID and the associated UE capability information in said database.
6. The method of any preceding claim, comprising
comparing (4115) the received UE capability information with stored UE capability information to determine whether to retrieve or create the determined capability ID.
7. The method of claim 2 or 3, wherein searching comprises
creating (4111) a hash (50) from the received UE capability information; searching (4113) a database for a corresponding hash and associated stored UE capability information.
8. The method of claim 7, wherein said hash at least forms part of the determined capability ID.
9. A method for use in a first access node (20) for handling user equipment, UE, capability information in an access network (200) of a wireless communication system (60) including a core network node (120) and at least one UE (1), comprising
receiving (407), from said UE, a capability message (44) comprising UE capability information (45);
transmitting (409) said UE capability information to the core network node; receiving (413) a capability ID (47) associated with the UE capability
information.
10. The method of claim 9, comprising
storing (414) the capability ID.
11. The method of claim 9 or 10, comprising
detecting initiation of a handover (415) of said UE from the first access node (20) to a second access node (30);
transmitting (416) the capability ID to the second access node.
12. The method of claim 9 or 10, comprising
detecting (415) a state change of the UE to an idle state;
initiating UE context transfer (49) from the first access node (20) to the core network node (120);
transmitting (416) the capability ID to the core network node in association with the UE context.
13. A core network node (120) for handling user equipment, UE, capability information in a wireless communication system (40) including at least one UE (1) and an access network (200), comprising a logic (124) configured to execute computer program code to control the core network node to carry out any of the steps of claims 1-8.
14. An access node (20) for handling user equipment, UE, capability information in an access network (200) of a wireless communication system (40) including a core network (100) and at least one UE (1), comprising
a logic (24) configured to execute computer program code to control the access node to carry out any of the steps of claims 9-12.
PCT/SE2019/050768 2019-02-08 2019-08-21 Handling user equipment capability information by a core network node and an access network node of a wireless communication network WO2020162802A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
SE1950145-1 2019-02-08
SE1950145 2019-02-08

Publications (1)

Publication Number Publication Date
WO2020162802A1 true WO2020162802A1 (en) 2020-08-13

Family

ID=67809635

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE2019/050768 WO2020162802A1 (en) 2019-02-08 2019-08-21 Handling user equipment capability information by a core network node and an access network node of a wireless communication network

Country Status (1)

Country Link
WO (1) WO2020162802A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112822717A (en) * 2020-12-31 2021-05-18 联想未来通信科技(重庆)有限公司 Method, device and system for dynamically controlling message buffering

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100330959A1 (en) * 2007-12-06 2010-12-30 Telefonaktiebolaget L M Ericsson (Publ) Method for Updating UE Capability Information in a Mobile Telecommunications Network
WO2017078580A1 (en) * 2015-11-02 2017-05-11 Telefonaktiebolaget Lm Ericsson (Publ) Handling device capabilities

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100330959A1 (en) * 2007-12-06 2010-12-30 Telefonaktiebolaget L M Ericsson (Publ) Method for Updating UE Capability Information in a Mobile Telecommunications Network
WO2017078580A1 (en) * 2015-11-02 2017-05-11 Telefonaktiebolaget Lm Ericsson (Publ) Handling device capabilities

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on optimisations of UE radio capability signalling (Release 16)", 3GPP STANDARD; TECHNICAL REPORT; 3GPP TR 23.743, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, no. V1.1.0, 6 February 2019 (2019-02-06), pages 1 - 56, XP051591874 *
ERICSSON: "Aspects on filtered capability enquiries with SA2 Capability ID solutions", vol. RAN WG2, no. Athens, Greece; 20190225 - 20190301, 15 February 2019 (2019-02-15), XP051602023, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg%5Fran/WG2%5FRL2/TSGR2%5F105/Docs/R2%2D1900646%2Ezip> [retrieved on 20190215] *
SAMSUNG: "Use of identifier representing NR UE capabilities, baseline", vol. RAN WG2, no. Athens, Greece; 20180226 - 20180302, 15 February 2018 (2018-02-15), XP051399667, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg%5Fran/WG2%5FRL2/TSGR2%5F101/Docs/> [retrieved on 20180215] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112822717A (en) * 2020-12-31 2021-05-18 联想未来通信科技(重庆)有限公司 Method, device and system for dynamically controlling message buffering
CN112822717B (en) * 2020-12-31 2023-04-28 联想未来通信科技(重庆)有限公司 Method, device and system for dynamically controlling message buffering

Similar Documents

Publication Publication Date Title
US11528761B2 (en) Communication method and communications apparatus
KR102167933B1 (en) Method and apparatus for scanning access point in wileless system
US20220394607A1 (en) Network slice configuration update
CN113676896B (en) Communication method and related equipment
KR102514834B1 (en) A method for handling terminal capabilities in a wireless communication network
US20220256329A1 (en) Method for handling of terminal capabilities in a wireless network
WO2021030946A1 (en) A method of registration with access and mobility management function re-allocation
EP3834444B1 (en) Method for identifying terminal capabilities in a wireless communication system
WO2020162802A1 (en) Handling user equipment capability information by a core network node and an access network node of a wireless communication network
KR102256582B1 (en) Method for obtaining context configuration information, terminal equipment and access network equipment
WO2020034105A1 (en) Wireless communication method and terminal device
US20210385725A1 (en) Data transmission method, apparatus, and computer storage medium
US20220394683A1 (en) Method and apparatus for handling user equipment capabilities in a wireless network
US20220394566A1 (en) Registration with accessibility and mobility management function re-allocation
US20220360996A1 (en) Network slice redirection method and apparatus
WO2024082125A1 (en) Systems and methods for communications among network functions
WO2023185295A1 (en) Communication method, terminal device, and core network device

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19761978

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19761978

Country of ref document: EP

Kind code of ref document: A1