Patent Application
20250193739
Embodiments herein relate to radio access nodes, core network nodes and methods therein. In some aspects, they relate to handling supported Information Elements (IEs) related to a procedure involving a number of network nodes in a wireless communications system.
In a typical wireless communication network, wireless devices, also known as wireless communication devices, mobile stations, stations (STA) and/or User Equipments (UE) s, communicate via a Wide Area Network or a Local Area Network such as a Wi-Fi network or a cellular network comprising a Radio Access Network (RAN) part and a Core Network (CN) part. The RAN covers a geographical area which is divided into service areas or cell areas, which may also be referred to as a beam or a beam group, with each service area or cell area being served by a radio network node such as a radio access node e.g., a Wi-Fi access point or a radio base station (RBS), which in some networks may also be denoted, for example, a NodeB, eNodeB (eNB), or gNB as denoted in Fifth Generation (5G) telecommunications. A service area or cell area is a geographical area where radio coverage is provided by the radio network node. The radio network node communicates over an air interface operating on radio frequencies with the wireless device within range of the radio network node.
3GPP is the standardization body for specify the standards for the cellular system evolution, e.g., including 3G, 4G, 5G and the future evolutions. Specifications for the Evolved Packet System (EPS), also called a Fourth Generation (4G) network, have been completed within the 3rd Generation Partnership Project (3GPP). As a continued network evolution, the new releases of 3GPP specifies a 5G network also referred to as 5G New Radio (NR).
Frequency bands for 5G NR are being separated into two different frequency ranges, Frequency Range 1 (FR1) and Frequency Range 2 (FR2). FR1 comprises sub-6 GHz frequency bands. Some of these bands are bands traditionally used by legacy standards but have been extended to cover potential new spectrum offerings from 410 MHz to 7125 MHz FR2 comprises frequency bands from 24.25 GHz to 52.6 GHZ. Bands in this millimeter wave range have shorter range but higher available bandwidth than bands in the FR1.
Multi-antenna techniques may significantly increase the data rates and reliability of a wireless communication system. For a wireless connection between a single user, such as UE, and a base station, the performance is in particular improved if both the transmitter and the receiver are equipped with multiple antennas, which results in a Multiple-Input Multiple-Output (MIMO) communication channel. This may be referred to as Single-User (SU)-MIMO. In the scenario where MIMO techniques is used for the wireless connection between multiple users and the base station, MIMO enables the users to communicate with the base station simultaneously using the same time-frequency resources by spatially separating the users, which increases further the cell capacity. This may be referred to as Multi-User (MU)-MIMO. Note that MU-MIMO may benefit when each UE only has one antenna. Such systems and/or related techniques are commonly referred to as MIMO.
3GPP has since Release 99 introduced in Application Protocols specifying open network interfaces, such as NG Application Protocol (NGAP), S1AP, XnAP, etc., a mechanism by which a sender may control a receiver's behavior in case comprehension is critical to control.
Each Elementary Procedure (EP) and each Information Element (IE) contained within a message of an elementary procedure is assigned with a “criticality”, and there are 3 criticalities defined: “reject”, “ignore” and “ignore and notify”, whereas only “reject” and “ignore” have been used throughout 3G, 4G and 5G.
If a logical node receives an information element (IE) assigned with criticality “reject”, and if the logical node does not support the functionality associated to that information, the logical node will terminate the procedure unsuccessfully and notify the sending node about its non-support of that protocol element/EP by means of signaling an error message, independently of whether the node does not support functionalities for the whole procedure or only the information element (IE) with criticality “reject”.
The sending node may deduce,—from either the procedure code or the IE identifier received within the error message,—the protocol element that is not supported by the peer node and adapt future communication, by typically not triggering the procedure any more or not including the IE not supported by its peer node.
A procedure or IE associated with the criticality “ignore” however allows the receiving node to leave the sending node unaware of its non-support for the IE and continue to process the content of the message and execute the respective functions. In this case the receiving node will discard the IE that is not supported and with criticality “ignore”. Namely the functionalities associated to such IE will not be carried out by the receiving node.
The above mechanism aims to ensure interworking between peer nodes with different levels of feature implementation, ensuring backwards compatibility, meaning that a node deployed according to a “higher” version of a certain Application Protocol is able to operate together with a node deployed according to a “lower” version” of the same Application Protocol. The same mechanism also ensures forwards compatibility. Namely, if a new version of an AP supports a new IE and if such IE is marked with criticality ignore, then the receiving node, supporting an older version of the AP is able to discard the non-supported IE and continue functioning according to its supported functionalities. However, if the node supporting an older version of the AP receives an IE from a newer version of the AP, with criticality “reject”, the node will have to terminate the procedure and send back an error message, as explained above.
In principle, even the concept of “versions” disappears, and deployment may choose from a set of functions, irrespective the “3GPP Release”.
As a part of developing embodiments herein the inventors identified a problem which first will be discussed.
While Operations Administration and Maintenance (OAM) configuration and a homogenous feature deployment, namely aligning all nodes to support the same functionalities, is capable of solving most issues, an existing “criticality mechanism” works only on a single interface instance, where one node is “sitting”, also referred to as located, at each end of the interface. A criticality mechanism when used herein e.g. a mechanism to handle criticality information as set for individual IEs and/or IE groups as specified in 3GPP TS 38.413 v17.0.0.
If e.g., handover or dual connectivity is executed on an X2/Xn interface, the “criticality mechanism” works in the sense that procedures and IEs which are so important, that a certain feature would not work w/o the peer node supporting the function behind it, are assigned with a criticality set to “reject”, by which a node is able to gradually learn its peer's level of support. The X2 interface is a point-to-point logical interface between two eNodeBs. The Xn interface is an interface between two NG-RAN nodes.
For mobility however, involving multiple interface instances, i.e. handover that has to be performed via the CN, more than one interface instance of the RAN-CN interface are involved. One at the source side and one at the target side, and between CN nodes, e.g., when the source RAN node and the target RAN node are NG-RAN nodes connected to different Access and Mobility Management Functions (AMFs), or in case of inter-system mobility, where the source RAN node is an Evolved-UMTS Terrestrial Radio Access Network E-UTRAN node connected to EPC, and the target RAN node is an NG-RAN node, and AMF. In other words, the criticality mechanism does not work in case the functionality, e.g., handover, and the signaling procedures associated to it, involve more than two network nodes. One example is NG-based handover, that involves 3 or more network nodes.
In total, as far as RAN3 defined Application Protocols are concerned, up to 4 nodes may be involved, source and target RAN node and source and target CN node; each of them with potentially different levels of support. It needs to be pointed out that each RAN node may be split into different nodes. For example, a gNB in a split RAN architecture may consist of, also referred to as comprise, a gNB-Central Unit (CU) User Plane (UP), a gNB-CU-Control Plane (CP) and a gNB-Distributed Unit (DU). In a procedure such as the handover, each of these split RAN nodes is in charge of a functionality, which if not supported may cause the failure of the handover procedure. An example of such an architecture is illustrated in
The problem is therefore how to enable that different nodes involved in supporting the functionalities and the signaling associated with a certain feature are aware that the functionality and signaling is supported in full by all nodes involved. If the functionalities and the signaling are not supported by at least one of the second RAN node or the first CN node serving the first RAN node or the second CN node serving the second RAN node, then performing (or executing) a procedure and/or a functionality, the procedure and/or functionality initiated by a first RAN node served by a first CN node, and involving a second RAN node served by a second CN node, would result in a failure and/or in an undefined outcome—for instance, whether it is appropriate/possible for the first RAN node to attempt in the future the same procedure and/or functionality towards the second RAN node. The first RAN node is left with no knowledge about the support of the procedure and/or functionality at any of the second RAN node and/or first CN node and/or second CN node. There is no mechanism to support the first RAN node in avoiding to reattempt executing the same procedure and/or functionality multiple times in the future, leading to more failures and/or undefined behavior. If the functionalities and the signaling are not supported, an effect is then also a waste of signaling, manifested in the path between the first RAN node and the second RAN node, and including the CN signaling between the first CN node serving the first RAN node and the second CN node serving the second RAN node.
In the specific example of handovers via the CN, it is not possible at the source RAN to understand if the full functionality associated with a CN based Handover (HO) procedure is supported by target RAN or target AMF.
Similarly, the source RAN node does not know about support at target CN node or at target RAN node for a function using certain IEs that would be signaled to modify a session context that has already been established between the source and the target.
An object of embodiments herein is to improve efficiency of a wireless communications network.
According to an aspect, the object is achieved by a method performed by a first Radio Access Network, RAN node. The method is for handling supported Information Elements, IEs, related to a procedure involving a number of network nodes, towards a second RAN node in a wireless communications system.
The first RAN node sends a first indication towards the second RAN node. The first indication indicates whether or not one or more first IEs, that are part of the procedure are supported by the first RAN node during the procedure.
The first RAN node receives a response comprising a second indication from the second RAN node. The second indication indicates whether or not one or more second IEs that are part of the procedure are supported by the second RAN node during the procedure.
According to an aspect, the object is achieved by a method performed by a second Radio Access Network, RAN node. The method is for handling supported Information Elements, IEs, related to a procedure involving a number of network nodes, from a first RAN node towards the second RAN node in a wireless communications system.
The second RAN node receives a first indication from the first RAN node. The first indication indicates whether or not one or more first IEs, that are part of the procedure are supported by the first RAN node during the procedure.
The second RAN node sends a response comprising a second indication towards the first RAN node. The second indication indicates whether or not one or more second IEs that are part of the procedure are supported by the second RAN node during the procedure.
According to an aspect, the object is achieved by a method performed by a first Core Network, CN, node. The method is for handling supported Information Elements, IEs, related to a procedure involving a number of network nodes, from a first Radio Access Network, RAN, node towards a second RAN node in a wireless communications system. The first CN node is serving the first RAN node.
The first CN node receives a first indication from the first RAN node, sent towards the second RAN node. The first indication indicates whether or not one or more first IEs, that are part of the procedure are supported by the first RAN node during the procedure.
The first CN node filters the one or more first IEs comprised in the first indication based on whether the one or more first IEs are supported by the first CN node.
The first CN node sends towards the second RAN node, the first indication as filtered. The first indication as filtered indicates whether or not one or more first IEs that are part of the procedure are supported by both the first RAN node and the first CN node during the procedure.
According to an aspect, the object is achieved by a method performed by a second Core Network, CN, node. The method is for handling supported Information Elements, IEs, related to a procedure involving a number of network nodes, from a first Radio Access Network, RAN, node towards a second RAN node in a wireless communications system. The second CN node is serving the second RAN node.
The second CN node receives from the first RAN node sent towards the second RAN node via a first CN node serving the first RAN node, a first indication as first filtered by the first CN node. The first indication as first filtered indicates whether or not one or more first IEs that are part of the procedure are supported by both the first RAN node and the first CN node during the procedure.
The second CN node further filters the one or more first IEs comprised in the received first indication as first filtered, based on whether the one or more first IEs are supported by the second CN node.
The second CN node sends towards the second RAN node, the first indication as further filtered by the second CN node, indicating whether or not the one or more first IEs are supported by the first RAN node, the first CN node and the second CN node, during the procedure.
According to another aspect, the object is achieved by a first Radio Access Network, RAN node. The first RAN node is configured to handle supported Information Elements, IEs, related to a procedure involving a number of network nodes, towards a second RAN node in a wireless communications system. The first RAN node is further configured to:
According to another aspect, the object is achieved by a second Radio Access Network, RAN node. The second RAN node is configured to handle supported Information Elements, IEs, related to a procedure involving a number of network nodes, from a first RAN node towards the second RAN node in a wireless communications system. The second RAN node is further configured to:
According to another aspect, the object is achieved by a first Core Network, CN, node. The first CN node is configured to handle supported Information Elements, IEs, related to a procedure involving a number of network nodes, from a first Radio Access Network, RAN, node towards a second RAN node in a wireless communications system. The first CN node is serving the first RAN node. The first CN node is further configured to:
According to another aspect, the object is achieved by a second Core Network, CN, node. The second CN node is configured to handling supported Information Elements, IEs, related to a procedure involving a number of network nodes, from a first Radio Access Network, RAN, node towards a second RAN node in a wireless communications system. The second CN node is serving the second RAN node. The second CN node is further configured to:
Receive from the first RAN node, sent towards the second RAN node via the first CN node serving the first RAN node, a first indication as first filtered by the first CN node, which first indication as first filtered is adapted to indicate whether or not one or more first IEs that are part of the procedure are supported by both the first RAN node and the first CN node during the procedure,
An advantage of embodiments herein is e.g., that they enable gaining knowledge of protocol support at all involved logical network nodes and network functions such as RAN nodes, functions of a RAN node deployed in split architecture such as e.g., gNB-CU-CPs, gNB-CU-UPs, gNB-DUs, and CN nodes, for any procedure and functionality that involves more than two logical network nodes and/or network functions.
A further advantage of embodiments herein is e.g., that introducing a per-feature basis “support” indicator over network interfaces is avoided, which would otherwise lead to explicitly revealing the status of supported functionalities for nodes involved in a procedure.
Embodiments herein provide a mechanism in the form of methods and nodes for exchanging indications indicating node's capabilities to support IEs and optionally functionalities associated with the respective supported IEs during a given procedure, also referred to as information of the supported IE-Id during a given procedure, for example during a HO Resource Allocation procedure, based on the peer nodes' understanding of IE-Ids from different systems. This mechanism according to embodiments herein may be generalized for NGAP and S1AP, and for inter-system mobility, including via F1AP. The mechanism according to embodiments herein, will not necessarily be dependent on the criticality assigned to a certain IE, but the peer-RAN node would have to take into account its serving CN node support which is typically dependent on the assigned criticality.
The indications may be referred to as data. The IEs, may e.g., be IE-IDs.
RAN nodes, such as a first RAN node 111 and a second RAN node 112 operate in the wireless communications network 100. The first RAN node 111 and/or the second RAN node 112, may respectively be an Access Point (AP) and e.g., provides a number of cells, and may use these cells for communicating with UEs, e.g., a UE 120. The first RAN node 111 and/or the second RAN node 112 may respectively be a transmission and reception point e.g., a radio access network node such as a base station, e.g., a radio base station such as a NodeB, an evolved Node B (eNB, eNodeB, eNode B), an NR Node B (gNB), a base transceiver station, a radio remote unit, an Access Point Base Station, a base station router, a transmission arrangement of a radio base station, a stand-alone access point, a Wireless Local Area Network (WLAN) access point, an Access Point Station (AP STA), an access controller, a UE acting as an access point or a peer in a Device to Device (D2D) communication, or any other suitable networking unit. The first RAN node 111 and/or the second RAN node 112, may respectively e.g., further be able to communicate with each other via one or more CN nodes in the wireless communications network 100.
It should be noted that the first RAN node 111 and/or the second RAN node 112, may e.g., be split into different nodes. For example, a RAN node 111, 112 such as a gNB in a split RAN architecture may comprise a gNB-CU-UP, a gNB-CU-CP and a gNB-DU.
User Equipments operate in the wireless communications network 100, such as a UE 120. The UE 120 may e.g., be an NR device, a mobile station, a wireless terminal, an NB-IoT device, an eMTC device, an NR RedCap device, a CAT-M device, a Wi-Fi device, an LTE device and a non-access point (non-AP) STA, a STA, that communicates via a base station such as e.g., the first RAN node 111 and/or the second RAN node 112. It should be understood by the skilled in the art that the UE relates to a non-limiting term which means any UE, terminal, wireless communication terminal, user equipment, (D2D) terminal, or node e.g., smart phone, laptop, mobile phone, sensor, relay, mobile tablets or even a small base station communicating within a cell.
CN nodes such as a first CN node 131 and/or a second CN node 132 operate in the wireless communications network 100. The CN node may e.g., be an AMF node, an MME node, or an SMF node. Each of the first CN node 131 and/or the second CN node 132 may be able to forwards messages and/or signals from/to any one or both of the first RAN node 111 and the second RAN node 112.
Methods herein may be performed by any one or more out of the first RAN node 111, the second RAN node 112, the first CN node 131, and the second CN node 132. As an alternative, a Distributed Node (DN) and functionality, e.g., comprised in a cloud 140 as shown in
Embodiments herein may relate to a RAN node 111, 112 capability exchange e.g., at a CN based handover.
The procedure involving a number of network nodes, towards the second RAN node 112 may e.g., be performed via the first CN node 131, and the second CN node 132. In some embodiments, e.g., relating to Solution 2, see also
The filtering e.g., means that IEs that are not supported by the respective filtering node are removed from the first indication before forwarding it to the next node.
Embodiments of methods will now be described from different views, one by one, of the different involved nodes, comprising the first RAN node 111 in relation to
The first RAN node 111 sends a first indication towards the second RAN node 112. The first indication may be sent from the first RAN node 111 via the first CN node 131, the second CN node 132 to the second RAN node 112.
The first indication indicates whether or not one or more first IEs, that are part of the procedure, are supported by the first RAN node 111 during the procedure. This is an advantage since, the first RAN node 111 is enabled to request whether any one of the second RAN node 112 or CN nodes along the signaling path between the first RAN node 111 and the second RAN node 112 supports or do not support one or more of the first IEs
In some embodiments, the first indication further indicates whether or not one or more first functionalities associated with the respective one or more first les that are part of the procedure, are supported by the first RAN node 111 during the procedure. This is an advantage since, the first RAN node 111 is enabled to request whether any one of the second RAN node 112 or CN nodes along the signaling path between the first RAN node 111 and the second RAN node 112 support or do not support one or more functionalities associated with the respective one or more first IEs
In some embodiments, the first indication sent to the second RAN node 112, will be received by the second RAN node 112 as filtered based on whether one or more out of:
The first RAN node 111 receives a response from the second RAN node 112. This is a response to the first indication sent towards the second RAN node 112. The response comprises a second indication. The second indication indicates whether or not one or more second IEs that are part of the procedure are supported by the second RAN node 112 during the procedure, and e.g., further supported by any one or more out of: the first CN node 131 serving the first RAN node 111, and the second CN node 132 serving the second RAN node 112 during the procedure. This is an advantage since, the first RAN node 111 obtains information on whether the second RAN node 112 and the CN nodes along the signaling path between the first RAN node 111 and the second RAN node 112 support or do not support one or more of the first IEs.
In some embodiments, the second indication further indicates whether or not one or more second functionalities associated with the respective one or more second IEs that are part of the procedure, are supported by the second RAN node 112 during the procedure, and e.g., further supported by any one or more out of: the first CN node 131 serving the first RAN node 111, and the second CN node 132 serving the second RAN node 112 during the procedure.
In some embodiments, the one or more second IEs are selected among the one or more first IEs.
In some embodiments, the one or more second functionalities are selected among the one or more first functionalities.
In this way, the first RAN node 111 obtains information on whether the second RAN node 112 and the CN nodes along the signaling path between the first RAN node 111 and the second RAN node 112 support or do not support one or more of the first IEs and/or whether the second RAN node 112 and the CN nodes along the signaling path between the first RAN node 111 and the second RAN node 112 support or do not support one or more first functionalities associated to the one or more first IEs.
The second RAN node 112 receives a first indication from the first RAN node 111. The first indication indicates whether or not one or more first IEs, that are part of the procedure are supported by the first RAN node 111 during the procedure.
In some embodiments, the first indication further indicates whether or not one or more first functionalities associated with the respective one or more first IEs that are part of the procedure, are supported by the first RAN node 111 during the procedure.
In some embodiments, the first indication received from the first RAN node 111, will be received as filtered based on whether one or more out of:
As mentioned above, in some embodiments, when the first indication is sent towards the second RAN node 112 it may first pass in the first CN node 131 and be filtered there such that the supported IEs comprises the IEs supported by both the first RAN node 111 and the first CN node 131. The filtered first indication may then be forwarded and passed to the second CN node 132 and be filtered there such that the supported IEs comprises the IEs supported by both the first RAN node 111, the first CN node 131 and the second CN node 132, before forwarding the further filtered first indication to the second RAN node 112.
The second RAN node 112 sends a response comprising a second indication towards the first RAN node 111. This is a response to the first indication received from the first RAN node 111. The second indication indicates whether or not one or more second IEs that are part of the procedure are supported by the second RAN node 112 during the procedure, and e.g., further supported by any one or more out of: the first CN node 131 serving the first RAN node 111, the second CN node 132 serving the second RAN node 112 during the procedure.
In some embodiments, the second indication further indicates whether or not one or more second functionalities associated with the respective one or more second IEs that are part of the procedure, are supported by the second RAN node 112 during the procedure, and e.g., further supported by any one or more out of: a first CN node 131 serving the first RAN node 111, a second CN node 132 serving the second RAN node 112 during the procedure.
In some embodiments, the one or more second IEs are selected among the one or more first IEs.
In some embodiments, the one or more second functionalities are selected among the one or more first functionalities.
In this way the second RAN node 112, informs the first RAN node 111 of which one of the one or more first IEs and/or which one of the one or more first functionalities associated to the one or more first IEs are supported by the second RAN node 112 and by the first CN node 131 serving the first RAN node 111, and be the second CN node 132 serving the second RAN node112.
As mentioned above, in some embodiments, when the first indication is sent towards the second RAN node 112 it may first pass in the first CN node 131 and be filtered there such that the supported IEs comprises the IEs supported by both the first RAN node 111and the first CN node 131. The filtered first indication may then be forwarded and pass in the second CN node 132 for further filtering before forwarding the further filtered first indication to the second RAN node 112.
The method comprises any one or more out of the actions listed below.
The first CN node 131 receives a first indication from the first RAN node 111 sent towards the second RAN node 112. The first indication indicates whether or not one or more first IEs, that are part of the procedure are supported by the first RAN node 111 during the procedure.
In some embodiments, the first indication further indicates whether or not one or more first functionalities associated with the respective one or more first IEs that are part of the procedure, are supported by the first RAN node 111 during the procedure.
The first CN node 131 filters the one or more first IEs comprised in the first indication based on whether the one or more first IEs are supported by the first CN node 131.
In some embodiments, the first CN node 131 further filters the one or more first functionalities comprised in the first indication based on whether the one or more first functionalities are supported by the first CN node 131.
The first CN node 131 sends the first indication as filtered towards the second RAN node 112. The first indication as filtered indicates whether or not one or more first IEs that are part of the procedure are supported by both the first RAN node 111 and the first CN node 131 during the procedure.
In some embodiments, the first indication as filtered indicates whether or not the one or more first functionalities associated with the respective one or more first IEs are supported by both the first RAN node 111 and the first CN node 131 during the procedure.
In this way, the first CN node 131 can provide information to the first RAN node-once the response arrives at the first RAN node—of whether the first CN node supports or does not support one or more first IEs and/or one or more of first functionalities associated with the respective one or more first IEs.
As mentioned above, in some embodiments, when the first indication is sent towards the second RAN node 112 it may first pass in the first CN node 131 and be filtered there such that the supported IEs comprises the IEs supported by both the first RAN node 111and the first CN node 131. The filtered first indication may then be forwarded and pass in the second CN node 132 for further filtering before forwarding the further filtered first indication to the second RAN node 112.
The method comprises any one or more out of the actions listed below.
The second CN node 132 receives a first indication as first filtered by the first CN node 131 from the first RAN node 111 sent towards the second RAN node 112 via the first CN node 131 serving the first RAN node 111. The first indication as first filtered indicates whether or not one or more first IEs that are part of the procedure are supported by both the first RAN node 111 and the first CN node 131 during the procedure.
In some embodiments, the first indication as first filtered further indicates whether or not one or more first functionalities associated with the respective one or more first IEs are supported by both the first RAN node 111 and the first CN node 131 during the procedure.
The second CN node 132 further filters the one or more first IEs comprised in the received first indication as first filtered based on whether the one or more first IEs are supported by the second CN node 132.
In some embodiments, the second CN node 132 further filters the one or more first IEs comprised in the received first indication as first filtered further based on whether the one or more first functionalities are supported by the second CN node 132.
The second CN node 132 sends the first indication as further filtered by the second CN node 132 towards the second RAN node 112. The first indication as further filtered by the second CN node 132 indicates whether or not the one or more first IEs are supported by the first RAN node 111, the first CN node 131 and the second CN node 132 during the procedure.
In some embodiments, the first indication as further filtered, as sent towards the second RAN node 112, indicates whether or not the one or more first functionalities associated with the respective one or more first IEs are supported by the first RAN node 112, the first CN node 131 and the second CN node 132, during the procedure.
In this way, the second CN node 132 may provide information to the first RAN node 111—once the response arrives at the first RAN node 111—of whether the second CN node 132 supports or does not support one or more first IEs and/or one or more of first functionalities associated with the respective one or more first IEs.
In this way the methods described above, as an entirely, allow gaining knowledge of protocol support at all involved logical network nodes and network functions, RAN nodes such as the first RAN node 111 and the second RAN node 112, functions of a RAN node deployed in split architecture, e.g., gNB-CU-CPs, gNB-CU-UPs, gNB-DUs, and CN nodes such as the first CN node 131 and the second CN node 132, for any procedure and functionality that involves more than two logical network nodes and/or network functions.
For example, a RAN node, such as the first RAN node 111 and/or the second RAN node 112, is enabled to derive whether a certain procedure or functionality involving more than two logical nodes and/or network functions can be used or not, or whether such procedure or functionality can be fully or partially exploited.
The methods described above also avoids introducing a per-feature basis “support” indicator over network interfaces, which would otherwise lead to explicitly revealing the status of supported functionalities for network nodes or network functions involved in a procedure.
The methods will now be further explained and exemplified in below embodiments. The embodiments may be combined in any suitable manner.
Examples of method embodiments described herein are based on the signaling of one or more, e.g., in a list, of supported IEs that are part of a procedure involving a number of network nodes. Each node involved in the procedure may signal, either before the procedure takes place or during the procedure, an indication, indicating e.g., in a list, of IEs that apply to the procedure and that are supported. It should be noted that the wordings “the one or more IEs” and “the list of IEs” are used interchangeably herein. In some embodiments, the indication, also referred to as information, about support of each IE may also be complemented with specifying whether the functionality associated with the IE is supported or not supported. In some other embodiments, an indication of support or not-support for one IE implies that the functionality for that IE is supported or not-supported. In some other embodiments, the indication of support or not-support for one IE implies that only the IE is supported and not necessarily the functionality associated to it.
The method as described above may be applied to multiple procedures involving more than one network nodes. However, independently of the procedure, the method e.g., provides enriched signaling between nodes involved, such as e.g., the first RAN node 111, the second RAN node 112, the first CN node 131 and the second CN node 132, in the procedure with information that could be expressed in this exemplary form. Underlined text in below tables relate to embodiments herein.
IE-Id Information
0 . . . 1
List of IE-Id
YES
ignore
List
supported by the
source NG-RAN
node
>IE-id Information
1 . . .
Item
<maxnoofIEIds>
>>IE-ID
M
INTEGER(0 . . . 500, . . . )
Or as an alternative in the following forms (these alternatives are shown in the examples below, but are reported here because they apply to any use case):
IE-Id Information List
0 . . . 1
List of IE-Id supported
YES
ignore
by the target NG-RAN
node
>IE-id Information Item
1 . . . <maxnoofIEIds>
>>IE-ID
M
INTEGER(0 . . . 500, . . . )
>>Supported Functionality
O
ENUMERATED(supported,
It indicates whether
not-supported)
the functionality
corresponding to the
IE is supported or not
supported
In some embodiments, the one or more supported IEs e.g., the list of supported IEs, described above may be complemented in the following way:
The addition of the “Supported Functionality” indication gives the possibility to express, e.g., whether an IE is supported but the functionality associated to it is not supported. This may be useful in cases where the functionality has not been developed or implemented in a given node, but where the Access Point (AP) message encoding has been updated to support the IE.
In some other embodiments, the IE support indication may be in the form of a bitmap, where the value “1” indicates “IE supported”, while the value “0” indicates “IE not supported”.
In some embodiments, the IE support indication for “all” IEs (e.g., all IEs for all features in a Release) are indicated. In other variants, the IE support indication refers to all IEs of certain features or certain IEs of certain features. In this case, a node may signal a structure made of a list, where each item in the list consists of a feature and an indication of supported IEs for such feature. Namely, the information shown above may be modified as follows:
IE-Id Information List
0 . . . 1
List of IE-Id supported by the target
YES
ignore
NG-RAN node
>IE-id Information Item
1 . . . <maxnoofIEIds>
>>Feature ID
M
INTEGER(0 . . . 500, . . . )
Each integer represents a specific
feature
>>IEs Support
M
ENUMERATED(Not-Supported,
Value “Not Supported” indicates that
Supported, Partially supported
none of the IEs for the feature is
supported. Value “Supported” indicates
that all the IEs for this feature are
supported. Value “Partially supported”
indicates that some of the IEs for this
feature are supported.
In some embodiments, absence of a response indication, e.g., no IE-Id list from the target node, may be interpreted by the source node, such as e.g., the first RAN node 111, that this node is a legacy node that does not support the corresponding features or functions.
Some examples of how the method applies to specific procedures are described below.
In some general embodiments, the indication of whether or not one or more IEs, that are part of the procedure are supported, such as e.g., a list of supported IE-Id information, is optionally included in a Source to Target Transparent Container transmitted from the first RAN node 111, in this example the source RAN node also referred to as source node, to the second RAN node 112, in this example the target RAN node, also referred to as target node, during an HO procedure performed via the CN, such as e.g., via the first CN node 131 and the second CN node 132. The target node replies with a list of its supported IE-Ids e.g., in the Target to Source Transparent Container, which is an IE signalled from the target RAN to the source RAN.
In one specific embodiment, a list of supported IE-Id as specified by the Application Protocol used on the source side RAN-CN interface, e.g., S1AP (TS 36.413) in case of EPS, NGAP (TS 38.413 v17.0.0) in case of 5GS, is included at the source RAN node in an initiating message of the Handover Preparation (HANDOVER REQUIRED), e.g., in the existing Source NG-RAN to Target NG-RAN transparent container IE of this message, and provided to the target RAN node by means of the initiating message of the Handover Resource Allocation procedure, e.g., in the existing Source NG-RAN to Target NG-RAN transparent container. The target RAN Node replies by sending a Target NG-RAN to Source NG-RAN transparent container that comprises a list of IE-ids related to the function that it supports.
See
Instead of discussion on a per-feature basis whether a support indicator needs to be introduced, embodiments herein are generalised by specifying the exchange of supported IE Id of the HO resource Allocation procedures.
Embodiments herein may be introduced for NGAP and S1AP, even inter-system
Embodiments herein may e.g., only be applicable for the Handover resource Allocation Procedure.
Embodiments herein may e.g., only be for a limited number of IEs, it may not be intended to exchange the full set of IEs.
Embodiments herein may not necessarily be dependent on the criticality assigned to a certain IE, but the peer-RAN node would have to take into account its service CN such as e.g., the first CN node 131 and the second CN node 132.
Embodiments herein may e.g., replace out remote criticality for approach, or rather define it.
In some embodiments, the first RAN node 111, in this example the source RAN Node, may only include an IE-Id if also the serving CN node(s) 131 support the IE-Id. Respective knowledge may be gained by the CN node including the respective IE in a message, by means of the criticality mechanism, OAM or an explicit indication that the IE (or the related feature) is supported.
The second RAN node 112, in this example the target Node may reply that the feature is supported, if it has gained knowledge that also the serving CN 132 nodes support the feature. Respective knowledge on the target side may be gained as described above on the source side. If the target Node has not yet gained knowledge about the CN side support it may provide this information explicitly, e.g., “support not yet known”. If the target RAN node does not support the IE-Id, it shall reply “not supported” in any case.
In case of inter-system handover, the source RAN node may provide in the list of supported IE-Id those IE-Ids specified by the RAN-CN interface on the source side and may indicate the protocol supported on the source side RAN-CN interface explicitly. Likewise, the target RAN node may provide in the list of supported IE-Id those IE-Ids specified by the RAN-CN interface on the target side and may indicate the protocol supported on the target side RAN-CN interface explicitly, if the functional correspondence between IEs defined in RAN-CN interfaces specified for different systems is obvious or may be derived.
The list of IE-Ids does not need to be a comprehensive list of all IE-Ids supported, most typically it is a selective list. The target RAN node may only reply for those IEs for which support information was requested by the source RAN node.
The support information, i.e., the list of IE-Ids may also be provided within a Handover Failure Container in case the target node cannot successfully terminate the Handover Resource Allocation procedure.
If the source and target RAN configuration involves multiple nodes (e.g., in case of Dual- or Multi-Connectivity) the scope of the exchanged information may span over all involved RAN nodes, even if the control interface of the RAN-CN interface is only defined towards a single RAN node (as currently the case in EPS and 5GS), but this may depend on the feature represented by the IE-Id(s). In some embodiments, each new IE support indication supersedes the previous one. In some other embodiments, related to the update of IE support, only the difference with respect to the previous indication is sent.
In some embodiments, a node such as the first RAN node 111 or the second RAN node 112, indicate IE support only when polled. In some other embodiments, the first RAN node 111 may proactively indicate to the second RAN node 112, in this example the its IE support, where, in the response, the second RAN node 112, also indicates its IE support to the first RAN node 111.
A non-limiting example with added specification impact in underlined text is provided below:
3GPP TS 38.413 clause 9.3.1.29 Source NG-RAN Node to Target NG-RAN Node Transparent Container:
This IE is produced by the source NG-RAN node (e.g., the first RAN node 111), and is transmitted to the target NG-RAN node (e.g., the second RAN node 112). For inter-system handovers to 5G, the IE is transmitted from the external handover source to the target NG-RAN node.
This IE is transparent to the 5GC.
IE-Id Information
0 . . . 1
List of IE-Id supported by the source NG-
YES
ignore
List
RAN node
>IE-Id
1 . . .
Information Item
<maxnoofIEIds>
>>IE-ID
M
INTEGER(0 . . .
3GPP TS 38.413 clause 9.3.1.30 Target NG-RAN Node to Source NG-RAN Node Transparent Container:
This IE is produced by the target NG-RAN node (e.g., the second RAN node 112) and is transmitted to the source NG-RAN node (e.g., the first RAN node 111). For inter-system handovers to 5G, the IE is transmitted from the target NG-RAN node to the external relocation source.
This IE is transparent to the 5GC.
IE-Id Information List
0 . . . 1
List of IE-Id supported
YES
ignore
by the target NG-RAN
node
>IE-id Information
1 . . . <maxnoofIEIds>
Item
>>IE-ID
M
INTEGER(0 . . . 500, . . . )
In one embodiment, the list of supported IE-Id information is optionally signalled in the RAN Status Transfer Transparent Container for intra 5GC NG handover.
In one dependent embodiment, the list of supported IEs described above may be complemented in the following way:
IE-Id Information List
0 . . . 1
List of IE-Id supported by the
YES
ignore
target NG-RAN node
>IE-id Information Item
1 . . . <maxnoofIEIds>
>>IE-ID
M
INTEGER(0 . . . 500, . . . )
>>Supported
O
ENUMERATED(supported,
It indicates whether the
Functionality
not-supported)
functionality corresponding to
the IE is supported or not
The addition of the “Supported Functionality” indication gives the possibility to express, e.g., whether an IE is supported but the functionality associated to it is not supported. This may be useful in cases where the functionality has not been developed or implemented in a given node, but where the AP message encoding has been updated to support the IE.
In some other embodiments, the IE support indication may be in the form of a bitmap, where the value “1” indicates “IE supported”, while the value “0” indicates “IE not supported”.
In some embodiments, the IE support indication for “all” IEs (e.g., all IEs for all features in a Release) are indicated. In another variant, the IE support indication refers to all IEs of certain features or certain IEs of certain features. In this case, a node such as e.g., the first RAN node 111, and the second RAN node 112, may signal a structure made of a list, where each item in the list comprises a feature and an indication of supported IEs for such feature. Namely, the information shown above may be modified as follows:
In these embodiments, a list of IE-Ids supported in each involved node, e.g., source/target RAN/CN node such as the first RAN node 111, the second RAN node 112, the first CN node 131 and the second CN node 132, is signalled irrespective of the assigned criticality, in a dedicated signalling procedure. Namely, to collect such information e.g., the RAN Configuration Transfer procedure(s) may be used-within one round-trip between source- and target RAN node, this info should be available at all involved RAN/CN nodes. The indication of supported/not-supported IEs may be achieved as in Solution 1, namely the different ways described above to represent support of IEs and their functionalities may be reused in these embodiments.
In one dependent embodiment, the IE support indication during a round trip traverses the involved RAN and CN nodes, such as e.g., the first RAN node 111, the second RAN node 112, the first CN node 131 and the second CN node 132, as shown in
In some other embodiments, the IE support indication may be in the form of a bitmap, where the value “1” indicates “IE supported”, while the value “0” indicates “IE not supported”. In the context of solution 2, during the round trip of the IE indication across RAN and CN nodes, such as e.g., the first RAN node 111, the second RAN node 112, the first CN node 131 and the second CN node 132, as shown in
A non-limiting example with added specification impact in underlined is provided below:
This message is sent by the NG-RAN node, (e.g., the first RAN node 111) in order to transfer RAN configuration information.
Direction: NG-RAN node→AMF (e.g., the first CN node 131),
IE-Id Information
0 . . . 1
List of IE-Id
YES
ignore
List
supported
>IE-id Information
1 . . .
Item
<maxnoofIEIds>
>>IE-ID
M
INTEGER(0 . . . 500, . . . )
This message is sent by the AMF (e.g., the first CN node 131) in order to transfer RAN configuration information.
Direction: AMF→NG-RAN node (e.g., the first RAN node 111),
IE-Id Information
0 . . . 1
List of IE-Id
YES
ignore
List
supported
>IE-id Information
1 . . .
Item
<maxnoofIEIds>
>>IE-ID
M
INTEGER(0 . . . 500, . . . )
In some embodiments, the IE support indication for “all” IEs (e.g., all IEs for all features in a Release) are indicated. In another variant, the IE support indication refers to all IEs of certain features or certain IEs of certain features.
For certain functionalities, e.g., related to Self-Organizing Networks (SON), two (or more) RAN nodes may be involved, with the first RAN node 111, in this example the a first (source) RAN node, being part of a first wireless communication system and/or a first RAT, and the second RAN node 112, in this example a second (target) RAN node pertaining to a second wireless communication system (and/or a second RAT). The functionality is fully (or partially) exploited when both the source RAN node and the target RAN node, and potentially the CN nodes in between, such as e.g., the first CN node 131 and the second CN node 132, fully (or partially) support the functionality in question. As part of the functionality operation, the source RAN node sends to the target RAN the first indication in this example a list of optionally supported IEs, conveyed transparently from the first RAN node to the second RAN node. The second RAN node replies with the second indication in this example a list of IE-Ids related to the functionality that it supports.
In another scenario, a certain functionality, e.g., related to Self-Organizing Networks (SON), two RAN nodes are involved, and they both belongs to the same wireless communication system or the same RAT, and the functionality uses an indirect signaling connection between the RAN nodes. The functionality is fully exploited (or partially exploited) when both the first RAN node 111, in this example a source RAN node and the second RAN node 112, in this example the target RAN node, and potentially the CN nodes, such as e.g., the first CN node 131 and the second CN node 132, in between fully support (or partially support) the functionality in question. As part of the functionality operation, the source RAN node sends to the target RAN the first indication, in this example a list of optionally supported IEs, conveyed transparently from the first RAN node to the second RAN node. The second RAN node replies with the second indication, in this example a list of IE-Ids related to the functionality that it supports.
In another example, the functionality may relate to Cell Resource Coordination between nodes, in this example the first RAN node 111 is an gNB, the second RAN node 112 is a ng-eNB (or vice versa), and the Xn link between the RAN nodes is not defined or is not available or is temporarily not available. In one embodiment, the IE support indication for “all” IEs (e.g., all IEs for all functionalities in a Release) are indicated. In another embodiment, the IE support indication refers to all IEs of certain functionalities or certain IEs of certain functionalities.
The methods of embodiments herein may apply to the following scenarios:
As mentioned above, the first RAN node 111, and the second RAN node 112, may be split RAN nodes. Previous embodiments focused on the indication of IE support for non-split RAN nodes (i.e., gNBs) or for CUs, by using the signalling for UE NG-based mobility. However, in Rel-18, the NG-based mobility of DUs, such as e.g., an IAB-DU, or any mobile DU, will likely be supported, whereas the indication of IE support between the mobile DU and the target CU becomes relevant.
In one embodiment, pertaining to the case of DU mobility (split RAN node assumed) and NG-based handover, the IE support indication refers to the IE support of the DU. In another embodiment, the IE support indication pertains to both the source CU and mobile DU.
In one dependent embodiment, pertaining to mobile Integrated Access and Backhauling (IAB) nodes, the DU's IE support is indicated as a part of handover signalling for the Integrated Access and Backhaul-Mobile Termination (IAB-MT) collocated with the DU. In another variant, a dedicated, enhanced existing or newly defined signalling is used, separately from the handover signalling for the IAB-MT.
In one dependent embodiment, the IE support pertaining to the IAB-DU, is indicated separately (e.g., using a separate dedicated message) separately for the IAB-DU of the first RAN node 111, in this example mobile IAB-node and the IAB-DUs of the descendants of the mobile IAB-node. In another sub-variant, the IE support is indicated together (e.g., using group signalling) for the IAB-DU of the mobile IAB-node and the IAB-DUs of its descendant IAB-DUs.
In one dependent embodiment pertaining to the above embodiments, the indication of IE support of the first RAN node 111, in this example the mobile DU uses source to target containers. In another variant, the indication of IE support of the first RAN node 111, in this example the mobile DU is sent explicitly over the interfaces, e.g., NG, S1, inter-AMF interface etc.
The embodiments presented in this chapter may use the encoding proposed by the previous chapters (i.e., the IE IDs), or they may use a different encoding.
The embodiments presented in this chapter may apply to mobile IAB-DUs or they may apply to mobile DUs (i.e., non-IAB DUs).
According to some embodiments herein a new approach is introduced to gain information on the level of support for a certain feature based on supported functionality at the target NG-RAN side associated with an NGAP IE based on the respective IE-Id. In the below example, the target NG-RAN, is represented by the second RAN node 112, the Source NG-RAN Node, is represented by the first RAN node 111.
These embodiments introduce the possibility to retrieve information, indicate such as the first indication and the second indication, on the level of support for a certain feature based on supported functionality at the target NG-RAN side, associated with an NGAP IE based on the respective IE-Id by means of information provided within the CN transparent handover containers.
In some embodiments, a new NGAP IE Support Information Request List IE is introduced in the Source NG-RAN Node, to Target NG-RAN Node, Transparent Container IE containing a list of NGAP Protocol IE-Ids, for which the target NG-RAN node shall provide support information e.g. according to the second indication, (“supported” or “not supported”) within either the Target NG-RAN Node, to Source NG-RAN Node Transparent Container IE or the Target NG-RAN Node, to Source NG-RAN Node Transparent Failure Transparent Container IE. In addition, information is provided whether the reported IE was actually received by the target NG-RAN node within an HANDOVER REQUEST message.
If the HANDOVER REQUEST message contains within the Source NG-RAN Node to Target NG-RAN Node Transparent Container IE the NGAP IE Support Information Request List IE, the target NG-RAN node shall, if supported and the target NG-RAN node accepts the request for handover, for each included NGAP Protocol IE-Id provide within in the Target NG-RAN Node to Source NG-RAN NodeTransparent Container IE in the HANDOVER REQUEST ACKNOWLEDGE message, e.g. according to the second indication,
If the HANDOVER REQUEST message contains within the Source NG-RAN Node to Target NG-RAN Node Transparent Container IE the NGAP IE Support Information Request List IE, the target NG-RAN node shall, if supported and the target NG-RAN node does not accept the request for handover, for each included NGAP Protocol IE-Id provide within in the Target NG-RAN Node to Source NG-RAN Node Transparent Failure Transparent Container IE in the HANDOVER FAILURE message, e.g. according to the second indication,
The first RAN node 111 may comprise an input and output interface configured to communicate with other networking entities in the wireless communications network 100, e.g., the second RAN node 112, the first CN node 131, and the second CN node 132. The input and output interface may comprise a receiver, e.g., wired and/or wireless, (not shown) and a transmitter, e.g., wired and/or wireless, (not shown).
The first RAN node 111 may comprise any one or more out of: An obtaining unit, a receiving unit to perform the method actions as described herein.
The embodiments herein may be implemented through a processor or one or more processors, such as at least one processor of a processing circuitry in the first RAN node 111 depicted in
The first RAN node 111 may further comprise respective a memory comprising one or more memory units. The memory comprises instructions executable by the processor in the first RAN node 111. The memory is arranged to be used to store instructions, data, configurations, and applications to perform the methods herein when being executed in the first RAN node 111.
In some embodiments, a computer program comprises instructions, which when executed by the at least one processor, cause the at least one processor of the first RAN node 111 to perform the actions above.
In some embodiments, a respective carrier comprises the respective computer program, wherein the carrier is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium.
Those skilled in the art will also appreciate that the functional modules in the first RAN node 111, described below may refer to a combination of analog and digital circuits, and/or one or more processors configured with software and/or firmware, e.g., stored in the first RAN node 111, that when executed by the respective one or more processors such as the at least one processor described above cause the respective at least one processor to perform actions according to any of the actions above. One or more of these processors, as well as the other digital hardware, may be included in a single Application-Specific Integrated Circuitry (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a system-on-a-chip (SoC).
The second RAN node 112 may comprise an input and output interface configured to communicate with other networking entities in the wireless communications network 100, e.g., the first RAN node 111, the first CN node 131, and the second CN node 132. The input and output interface may comprise a receiver, e.g., wired and/or wireless, (not shown) and a transmitter, e.g., wired and/or wireless, (not shown).
The second RAN node 112 may comprise any one or more out of: An obtaining unit, a receiving unit to perform the method actions as described herein.
The embodiments herein may be implemented through a processor or one or more processors, such as at least one processor of a processing circuitry in the second RAN node 112 depicted in
The second RAN node 112 may further comprise respective a memory comprising one or more memory units. The memory comprises instructions executable by the processor in the second RAN node 112. The memory is arranged to be used to store instructions, data, configurations, and applications to perform the methods herein when being executed in the second RAN node 112.
In some embodiments, a computer program comprises instructions, which when executed by the at least one processor, cause the at least one processor of the second RAN node 112 to perform the actions above.
In some embodiments, a respective carrier comprises the respective computer program, wherein the carrier is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium.
Those skilled in the art will also appreciate that the functional modules in the second RAN node 112, described below may refer to a combination of analog and digital circuits, and/or one or more processors configured with software and/or firmware, e.g., stored in the second RAN node 112, that when executed by the respective one or more processors such as the at least one processor described above cause the respective at least one processor to perform actions according to any of the actions above. One or more of these processors, as well as the other digital hardware, may be included in a single Application-Specific Integrated Circuitry (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a system-on-a-chip (SoC).
The first CN node 131 may comprise an input and output interface configured to communicate with other networking entities in the wireless communications network 100, e.g., the first RAN node 111, the second RAN node 112, and the second CN node 132. The input and output interface may comprise a receiver, e.g., wired and/or wireless, (not shown) and a transmitter, e.g., wired and/or wireless, (not shown).
The first CN node 131 may comprise any one or more out of: An obtaining unit, a receiving unit, a filtering unit to perform the method actions as described herein.
The embodiments herein may be implemented through a processor or one or more processors, such as at least one processor of a processing circuitry in the first CN node 131 depicted in
The first CN node 131 may further comprise respective a memory comprising one or more memory units. The memory comprises instructions executable by the processor in the first CN node 131. The memory is arranged to be used to store instructions, data, configurations, and applications to perform the methods herein when being executed in the first CN node 131.
In some embodiments, a computer program comprises instructions, which when executed by the at least one processor, cause the at least one processor of the first CN node 131 to perform the actions above.
In some embodiments, a respective carrier comprises the respective computer program, wherein the carrier is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium.
Those skilled in the art will also appreciate that the functional modules in the first CN node 131, described below may refer to a combination of analog and digital circuits, and/or one or more processors configured with software and/or firmware, e.g., stored in the first CN node 131, that when executed by the respective one or more processors such as the at least one processor described above cause the respective at least one processor to perform actions according to any of the actions above. One or more of these processors, as well as the other digital hardware, may be included in a single Application-Specific Integrated Circuitry (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a system-on-a-chip (SoC).
The second CN node 132 may comprise an input and output interface configured to communicate with other networking entities in the wireless communications network 100, e.g., the first RAN node 111, the second RAN node 112, and the first CN node 131. The input and output interface may comprise a receiver, e.g., wired and/or wireless, (not shown) and a transmitter, e.g., wired and/or wireless, (not shown).
The second CN node 132 may comprise any one or more out of: An obtaining unit, a receiving unit, a filtering unit to perform the method actions as described herein.
The embodiments herein may be implemented through a processor or one or more processors, such as at least one processor of a processing circuitry in the second CN node 132 depicted in
The second CN node 132 may further comprise respective a memory comprising one or more memory units. The memory comprises instructions executable by the processor in the second CN node 132. The memory is arranged to be used to store instructions, data, configurations, and applications to perform the methods herein when being executed in the second CN node 132.
In some embodiments, a computer program comprises instructions, which when executed by the at least one processor, cause the at least one processor of the second CN node 132 to perform the actions above.
In some embodiments, a respective carrier comprises the respective computer program, wherein the carrier is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium.
Those skilled in the art will also appreciate that the functional modules in the second CN node 132, described below may refer to a combination of analog and digital circuits, and/or one or more processors configured with software and/or firmware, e.g., stored in the second CN node 132, that when executed by the respective one or more processors such as the at least one processor described above cause the respective at least one processor to perform actions according to any of the actions above. One or more of these processors, as well as the other digital hardware, may be included in a single Application-Specific Integrated Circuitry (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a system-on-a-chip (SoC).
When using the word “comprise” or “comprising” it shall be interpreted as non-limiting, i.e. meaning “consist at least of”.
The embodiments herein are not limited to the above described preferred embodiments. Various alternatives, modifications and equivalents may be used.
Below, some example Embodiments 1-32 are shortly described. See e.g.,
Embodiment 1. A method performed by a first Radio Access Network, RAN node 111 for handling supported Information Elements, IEs, related to a procedure involving a number of network nodes, towards a second RAN node 112 in a wireless communications system 100, e.g., via a first Core Network, CN, node 131 serving the first RAN node 111 and a second CN node 132 serving the second RAN node 112, the method comprising any one or more out of:
Embodiment 2. The method according to Embodiment 1, wherein:
Embodiment 3. The method according to any of the Embodiments 1-2, wherein any one or more out of:
Embodiment 4. The method according to any of the Embodiments 1-3, wherein:
Embodiment 5. A computer program comprising instructions, which when executed by a processor, causes the processor to perform actions according to any of the Embodiments 1-4.
Embodiment 6. A carrier comprising the computer program of Embodiment 5, wherein the carrier is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium.
Embodiment 7. A method performed by a second Radio Access Network, RAN node 112 for handling supported Information Elements, IEs, related to a procedure involving a number of network nodes, from a first RAN node 111 towards the second RAN node 112 in a wireless communications system 100, e.g., via a first Core Network, CN, node 131 serving the first RAN node 111 and a second CN node 132 serving the second RAN node 112, the method comprising any one or more out of:
Embodiment 8. The method according to Embodiment 7, wherein:
Embodiment 9. The method according to any of the Embodiments 7-8, wherein any one or more out of:
Embodiment 10. The method according to any of the Embodiments 7-9, wherein:
Embodiment 11. A computer program comprising instructions, which when executed by a processor, causes the processor to perform actions according to any of the Embodiments 7-10.
Embodiment 12. A carrier comprising the computer program of Embodiment 11, wherein the carrier is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium.
Embodiment 13. A method performed by a first Core Network, CN, node 131 for handling supported Information Elements, IEs, related to a procedure involving a number of network nodes, from a first Radio Access Network, RAN, node 111 towards a second RAN node 112 in a wireless communications system 100, e.g., via the first CN node 131 serving the first RAN node 111 and a second CN node 132 serving the second RAN node 112, which first CN node 131 is serving the first RAN node 111, the method comprising any one or more out of:
Embodiment 14. The method according to Embodiment 13, wherein the first indication further indicates whether or not one or more first functionalities associated with the respective one or more first IEs that are part of the procedure, are supported by the first RAN node 111 during the procedure, the method further comprising any one or more out of:
Embodiment 15. A computer program comprising instructions, which when executed by a processor, causes the processor to perform actions according to any of the Embodiments 13-14.
Embodiment 16. A carrier comprising the computer program of Embodiment 55, wherein the carrier is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium.
Embodiment 17. A method performed by a second Core Network, CN, node 132 for handling supported Information Elements, IEs, related to a procedure involving a number of network nodes, from a first Radio Access Network, RAN, node 111 towards a second RAN node 112 in a wireless communications system 100, e.g., via a first CN node 131 serving the first RAN node 111 and the second CN node 132 serving the second RAN node 112, which second CN node 132 is serving the second RAN node 112, the method comprising any one or more out of:
Embodiment 18. The method according to Embodiment 17, wherein the first indication as first filtered further indicates whether or not one or more first functionalities associated with the respective one or more first IEs are supported by both the first RAN node 111 and the first CN node 131 during the procedure, the method further comprising any one or more out of:
Embodiment 19. A computer program comprising instructions, which when executed by a processor, causes the processor to perform actions according to any of the Embodiments 17-18.
Embodiment 20. A carrier comprising the computer program of Embodiment 19, wherein the carrier is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium.
Embodiment 21. A first Radio Access Network, RAN node 111 configured to handle supported Information Elements, IEs, related to a procedure involving a number of network nodes, towards a second RAN node 112 in a wireless communications system 100, e.g., via a first Core Network, CN, node 131 serving the first RAN node 111 and a second CN node 132 serving the second RAN node 112, the first RAN node 111 further being configured to e.g., any one or more out of:
Embodiment 22. The first RAN node 111 according to Embodiment 21, wherein:
Embodiment 23. The first RAN node 111 according to any of the Embodiments 21-22, wherein any one or more out of:
Embodiment 24. The first RAN node 111 according to any of the Embodiments 21-23, wherein:
Embodiment 25. A second Radio Access Network, RAN node 112 configured to handle supported Information Elements, IEs, related to a procedure involving a number of network nodes, from a first RAN node 111 towards the second RAN node 112 in a wireless communications system 100, e.g., via a first Core Network, CN, node 131 serving the first RAN node 111 and a second CN node 132 serving the second RAN node 112, the second RAN node 112 further being configured e.g., to any one or more out of:
Embodiment 26. The second RAN node 112 according to Embodiment 25, wherein:
Embodiment 27. The second RAN node 112 according to any of the Embodiments 25-26, wherein any one or more out of:
Embodiment 28. The second RAN node 112 according to any of the Embodiments 25-27, wherein:
Embodiment 29. A first Core Network, CN, node 131 for handling supported Information Elements, IEs, related to a procedure involving a number of network nodes, from a first Radio Access Network, RAN, node 111 towards a second RAN node 112 in a wireless communications system 100, e.g., via the first CN node 131 serving the first RAN node 111 and a second CN node 132 serving the second RAN node 112, which first CN node 131 is serving the first RAN node 111, the first CN node 131 further being configured e.g., to any one or more out of:
Embodiment 30. The first CN node 131 according to Embodiment 29, wherein the first indication further is adapted to indicate whether or not one or more first functionalities associated with the respective one or more first IEs that are part of the procedure, are supported by the first RAN node 111 during the procedure, the first CN node 131 further being configured to any one or more out of:
Embodiment 31. A second Core Network, CN, node 132 for handling supported Information Elements, IEs, related to a procedure involving a number of network nodes, from a first Radio Access Network, RAN, node 111 towards a second RAN node 112 in a wireless communications system 100, e.g., via a first CN node 131 serving the first RAN node 111 and the second CN node 132 serving the second RAN node 112, which second CN node 132 is serving the second RAN node 112, the second CN node 132 further being configured e.g., to any one or more out of:
Embodiment 32. The second CN node 132 according to Embodiment 31, wherein the first indication as first filtered further indicates whether or not one or more first functionalities associated with the respective one or more first IEs are supported by both the first RAN node 111 and the first CN node 131 during the procedure, the second CN node 132 further being configured to any one or more out of:
With reference to
The telecommunication network 3210 is itself connected to a host computer 3230, which may be embodied in the hardware and/or software of a standalone server, a cloud-implemented server, a distributed server or as processing resources in a server farm. The host computer 3230 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. The connections 3221, 3222 between the telecommunication network 3210 and the host computer 3230 may extend directly from the core network 3214 to the host computer 3230 or may go via an optional intermediate network 3220. The intermediate network 3220 may be one of, or a combination of more than one of, a public, private or hosted network; the intermediate network 3220, if any, may be a backbone network or the Internet; in particular, the intermediate network 3220 may comprise two or more sub-networks (not shown).
The communication system of
Example implementations, in accordance with an embodiment, of the UE, base station and host computer discussed in the preceding paragraphs will now be described with reference to
The communication system 3300 further includes a base station 3320 provided in a telecommunication system and comprising hardware 3325 enabling it to communicate with the host computer 3310 and with the UE 3330. The hardware 3325 may include a communication interface 3326 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system 3300, as well as a radio interface 3327 for setting up and maintaining at least a wireless connection 3370 with a UE 3330 located in a coverage area (not shown) served by the base station 3320. The communication interface 3326 may be configured to facilitate a connection 3360 to the host computer 3310. The connection 3360 may be direct or it may pass through a core network (not shown) in
The communication system 3300 further includes the UE 3330 already referred to. Its hardware 3335 may include a radio interface 3337 configured to set up and maintain a wireless connection 3370 with a base station serving a coverage area in which the UE 3330 is currently located. The hardware 3335 of the UE 3330 further includes processing circuitry 3338, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The UE 3330 further comprises software 3331, which is stored in or accessible by the UE 3330 and executable by the processing circuitry 3338. The software 3331 includes a client application 3332. The client application 3332 may be operable to provide a service to a human or non-human user via the UE 3330, with the support of the host computer 3310. In the host computer 3310, an executing host application 3312 may communicate with the executing client application 3332 via the OTT connection 3350 terminating at the UE 3330 and the host computer 3310. In providing the service to the user, the client application 3332 may receive request data from the host application 3312 and provide user data in response to the request data. The OTT connection 3350 may transfer both the request data and the user data. The client application 3332 may interact with the user to generate the user data that it provides.
It is noted that the host computer 3310, base station 3320 and UE 3330 illustrated in
In
The wireless connection 3370 between the UE 3330 and the base station 3320 is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE 3330 using the OTT connection 3350, in which the wireless connection 3370 forms the last segment. More precisely, the teachings of these embodiments may improve the applicable RAN effect: data rate, latency, power consumption, and thereby provide benefits such as corresponding effect on the OTT service: e.g., reduced user waiting time, relaxed restriction on file size, better responsiveness, extended battery lifetime.
A measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 3350 between the host computer 3310 and UE 3330, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection 3350 may be implemented in the software 3311 of the host computer 3310 or in the software 3331 of the UE 3330, or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection 3350 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software 3311, 3331 may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 3350 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect the base station 3320, and it may be unknown or imperceptible to the base station 3320. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling facilitating the host computer's 3310 measurements of throughput, propagation times, latency and the like. The measurements may be implemented in that the software 3311, 3331 causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 3350 while it monitors propagation times, errors etc.
Definitions of some abbreviations and acronyms used herein.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/SE2023/050341 | 4/13/2023 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 63362967 | Apr 2022 | US |
