WO2024175176A1

WO2024175176A1 - Resource status reporting technique

Info

Publication number: WO2024175176A1
Application number: PCT/EP2023/054214
Authority: WO
Inventors: Daniel Henriksson; Tobias AHLSTRÖM; Henrik STRIDELL
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2023-02-20
Filing date: 2023-02-20
Publication date: 2024-08-29

Abstract

A technique for sending a status update message to a first network node (200) from a second network node (100) is described. As to a method (300) aspect of the technique, a request message is received (302) from the first network node (200). The request message is indicative of a request for reporting at least one status parameter from the second network node (100). A response message indicative of a successful initiation of the reporting of the at least one status parameter is sent (304) to the first network node (200). A status update message indicative of at least one event related to the at least one status parameter is sent (308) to the first network node (200).

Description

Resource Status Reporting Technique

Technical Field

The present disclosure relates to a technique for load sharing and load balancing in a radio access network (RAN). More specifically, and without limitation, methods and devices are provided for a status update message exchanged between RAN nodes for indicating results of measurements performed by a second RAN node following a successful Resource Status Reporting Initiation procedure requested by a first RAN node.

Background

The Third Generation Partnership Project (3GPP) specified the current fifth generation (5G) New Radio Access Network (NG RAN) architecture, which is partially depicted and described in the 3GPP documents TS 38.401, version 17.3.0, and TS 38.423, version 17.3.0. These documents specify the radio network layer signaling procedures of the control plane (CP) between NG RAN nodes in the NG RAN, which are also referred to as gNodeB (gNB). The NG RAN architecture comprises an interface Xn, which is connecting two NG RAN nodes. Functions related to the Xn interface are realized by signaling procedures defined in these 3GPP documents. The signaling procedures comprise a first NG RAN node sending a request for the reporting of load measurements to a second NG RAN node, which signaling is not related to a specific radio device (i.e., a User Equipment or UE) served by the NG RAN. For initiating such reporting, the inter-node interfaces Xn - and optionally midhaul interfaces Fl of a split gNodeB architecture - transport the Resource Status Request message and the Resource Status Response message. Successful operation of this Resource Status Request Initiation (e.g., according to clause 8.4.10 of the 3GPP document TS 38.423, version 17.3.0) means that a first gNB can set up "subscriptions" from a neighboring second gNB to get periodic reporting of some selected parameters. The subsequent Resource Status Reporting (e.g., according to clause 8.4.11 of the 3GPP document TS 38.423, version 17.3.0) may comprise the second gNB sending Resource Status Update messages to the first gNB. Herein, "subscription" may colloquially refer to the state of the first and second gNBs resulting from the successful operation of the Resource Status Request Initiation (which is not to be confused the subscription of a UE for being served by the RAN).

However, if events at the second gNB such as a change of a status of the second gNB affect the reporting, the second gNB has no opportunity to inform the first gNB about these issues or other actions. The second gNB can only send a Resource Status Update messages as requested in a Resource Status Request message and acknowledged in a Resource Status Response message.

Summary

Accordingly, there is a need for a resource status reporting technique that takes events at a reporting RAN node after a successful reporting subscription into account. Alternatively or more specifically, there is a need for enriching or expanding a Resource Status Update message with an opportunity for the reporting RAN node to inform the receiving RAN node about events relevant for the reporting such as issues, node status or other actions.

As to a first method aspect, a method of sending a status update message to a first network node from a second network node is provided. The first method aspect may be performed or initiated by the second network node. The method comprises receiving a request message from the first network node. The request message is indicative of a request for reporting at least one status parameter from the second network node. Furthermore, based in the request message, the second network node sends a response message indicative of a successful initiation of the reporting of the at least one status parameter to the first network node. Moreover, the second network node sends a status update message indicative of at least one event related to the at least one status parameter to the first network node.

Embodiments can enable the first and second network nodes to send and receive, respectively, an enriched or expanded Resource Status Update message that is indicative of the at least one event related to the at least one status parameter to the first network node. Same or further embodiments can enable the first network node, responsive to and/or depending on the received information in status update message indicative of the event, to act (e.g., counteract or prepare) or understand (e.g., by changing parameter processing) any consequence or impact on the ongoing status reporting in a better way. This can lead to a better network reaction to the event and a more robust handling of resource status reporting procedure.

As to a second method aspect, a method of receiving a status update message at a first network node from a second network node is provided. The second method aspect may be performed or initiated by the first network node. The method comprises sending a request message to the second network node. The request message is indicative of a request for reporting at least one status parameter from the second network node. The method further comprises receiving, from the second network node, a response message indicative of a successful initiation of the reporting of the at least one status parameter. Moreover, the method comprises receiving, from the second network node, a status update message indicative of at least one event related to the at least one status parameter.

The second method aspect may further comprise any feature or step disclosed in the context of the first method aspect, or features and steps corresponding thereto (e.g., according to the one-to-one correspondence between a transmitting node and a receiving node).

As to another aspect, a computer program product is provided. The computer program product comprises program code portions for performing any one of the steps of the first method aspect and the related embodiments and of the second method aspect and the related embodiment disclosed herein when the computer program product is executed by one or more computing devices. The computer program product may be stored on a computer-readable recording medium. The computer program product may also be provided for download, e.g., via the radio network, the RAN, the Internet and/or the host computer. Alternatively, or in addition, the first and/or second method aspects may be encoded in a Field- Programmable Gate Array (FPGA) and/or an Application-Specific Integrated Circuit (ASIC), or the functionality may be provided for download by means of a hardware description language.

As to a first device aspect, a second network node for sending a status update message to a first network node is provided. The second network node comprises memory operable to store instructions and processing circuitry operable to execute the instructions. The second network node is operable to receive a request message from the first network node. The request message is indicative of a request for reporting at least one status parameter from the second network node. The second network node sends, to the first network node, a response message indicative of a successful initiation of the reporting of the at least one status parameter. The second network node further sends, to the first network node, a status update message indicative of at least one event related to the at least one status parameter.

An embodiment of the second network node may be further operable to perform the steps of any one of the first method aspect, including its dependent method embodiments.

As to a variant of the first device aspect, a device for sending status update message to a first network node from a second network node is provided. The device may be configured to perform any one of the steps of the first method aspect. As an example of the variant of the first device aspect, a second network node for sending a status update message to a first network node is configured to receive a request message from a first network node. The request message is indicative of a request for reporting at least one status parameter from the second network node. The first network node is further configured to send, to the first network node, a response message indicative of a successful initiation of the reporting of the at least one status parameter. The first network node is further configured to send, to the first network node, a status update message indicative of at least one event related to the at least one status parameter.

An embodiment of the second network node may further be configured to perform the steps of any one embodiment of the first method aspect or a step corresponding thereto.

In a further embodiment, the second network node (of any one of first device aspects and related embodiments) is an NG RAN node.

As to a second device aspect, a first network node for receiving a status update message from a second network node is provided. The first network node comprises memory operable to store instructions and processing circuitry operable to execute the instructions. Accordingly, the first network node is operable to send a request message to the second network node. The request message is indicative of a request for reporting at least one status parameter from the second network node. The first network node is further operable to receive, from the second network node, a response message indicative of a successful initiation of the reporting of the at least one status parameter. The first network node is further operable to receive, from the second network node, a status update message indicative of at least one event related to the at least one status parameter.

An embodiment of the first network node further comprising the features or steps of any method embodiment of the second method aspect and the related embodiments.

As to a variant of the second device aspect, a first network node for receiving a status update message from a second network node is configured to send a request message to the second network node. The request message is indicative of a request for reporting at least one status parameter from the second network node. The first network node is further configured to receive, from the second network node, a response message indicative of a successful initiation of the reporting of the at least one status parameter. The first network node is further configured to receive, from the second network node, a status update message indicative of at least one event related to the at least one status parameter.

In an embodiment, the first network node further comprising the features or steps of any one of the second method aspect and the related embodiments.

In a further embodiment of the first network node (of any of any one of the second device aspects and the related embodiments) is an NG RAN node.

The RAN may be implemented according to the Global System for Mobile Communications (GSM), the Universal Mobile Telecommunications System (UMTS), 3GPP Long Term Evolution (LTE) and/or 3GPP New Radio (NR).

Any aspect of the technique may be implemented on a Physical Layer (PHY), a Medium Access Control (MAC) layer, a Radio Link Control (RLC) layer, a packet data convergence protocol (PDCP) layer, and/or a Radio Resource Control (RRC) layer of a protocol stack for the radio communication.

Herein, referring to a protocol of a layer may also refer to the corresponding layer in the protocol stack. Vice versa, referring to a layer of the protocol stack may also refer to the corresponding protocol of the layer. Any protocol may be implemented by a corresponding method.

Brief Description of the Drawings

Further details of embodiments of the technique are described with reference to the enclosed drawings, wherein:

Fig. 1 shows a schematic block diagram of an overall NG RAN architecture,

Fig. 2 shows a schematic block diagram of a selection of events,

Fig. 3 shows a flowchart for a method according to the first method aspect,

Fig. 4 shows a flowchart for a method according to the second method aspect,

Fig. 5 shows a schematic block diagram of a Status Update Message,

Fig. 6 shows a possible format of a Status Update Message,

Fig. 7 shows a schematic block diagram of a Resource Status Procedure,

Fig. 8 shows a schematic block diagram of a split NG RAN architecture, Fig. 9 shows a schematic block diagram of an embodiment of a second network node,

Fig. 10 shows a schematic block diagram of an embodiment of a first network node,

Fig. 11 shows a schematic block diagram of a second NG RAN architecture, and

Fig. 12 shows a schematic block diagram of a first NG RAN architecture.

Herein, the first network node may be referred to as requesting or receiving RAN node or first RAN node or RAN node 1. The first network node may be a node of a NR RAN, i.e., a first NR RAN node or NR RAN node 1, e.g. a first gNB or a corresponding first distributed unit (DU). Alternatively or in addition, the second network node may be referred to as reporting RAN node or second RAN node or RAN node 2. The second network node may be a node of the NR RAN, i.e., a second NR RAN node or NR RAN node 2, e.g., a second gNB or a corresponding second DU.

As to the first method aspect, by sending the status update message indicative of the at least one event, feedback options may be enhanced, e.g. beyond a set of the at least one status parameter agreed upon between the first network node and the second network node during successful resource status request initiation. Advantageously, the event indication can contain information, e.g. in the form feedback, about other procedures or functions that might have impact on status parameter, or the feedback could be caused by issues or problems local to the first network node.

The method may further comprise initiating, at the second node, measuring or monitoring of the status parameter based on (e.g., according to or in response to) the request message. The status parameter may be a measurement parameter.

The status update message (e.g., a Resource Status Update message) may be issued or initiated by the second network node (e.g., NG RAN node 2) to report the result of measurements requested by the first network node (e.g., NG RAN node 1) and/or admitted by the second network node according to or following a successful Resource Status Reporting Initiation procedure. Especially, if the NG RAN node 1 requested a periodic reporting, the NG RAN node 2 will send periodic updates to the NG RAN node 1. This will go on until NG RAN node 1 sends a request to stop the subscription to NG RAN node 2.

Herein, any (e.g., NG) RAN node may be a next generation node B (i.e., gNodeB or gNB). The request message (e.g., a Resource Status Request message) may be specified on interfaces between NG RAN nodes, e.g. the Xn and/or Fl interfaces (e.g., as logical NG RAN interfaces), as a Resource Status Request initiation, to be answered by the response message and to be fulfilled by one or more status update messages in a Resource Status Reporting process. In other words, an NG RAN node 1 can setup subscriptions from a neighbor NG RAN node 2 and get periodic reporting of some selected parameters.

The at least one status parameter (or briefly: parameter) may be a measurement parameter comprising an indication of a measurement value to be reported and/or comprising the requested measurement result.

The response message (e.g., a Resource Status Response message) may relate to the request message detailed above.

The at least one event may occur at (or to) the second network node. Alternatively or in addition, the event may impact (or may have the potential to impact) the update message as such or the parameter transmitted in the update messages. Accordingly, the given parameter of the update message may change, or the measurement values of the given parameter may change. Alternatively or in addition, the event may result in a (e.g., temporary) interruption of the reporting. In other words, the status update message may be indicative of a change in the reporting. Respective event related information elements (lEs) may be included (e.g., added or appended) to existing parameter lEs of the update message. The added lEs comprise additional information indicative to the event. They may provide a further feedback for the deeper/broader understanding of the event. NG RAN node 1 may thereby be enabled to understand the event. The NG RAN node 1 can then mitigate the problem or act to avoid larger impacts.

In an embodiment one or more further update messages indicative of an update of the at least one status parameter to the first network node may be send. The further update messages being responsive to the response message and may be submitted prior to indicating the event.

The one or more further status update messages may be different from the status update message indicative of the event. Alternatively or in addition, each of the one or more further status update messages is not indicative of the event. For example, each of the one or more further status update messages is a resource status update according to the 3GPP document TS 38.423 (e.g. version 17.3.0), clause 8.4.11.2. Hence, the further update messages may report the result of measurements of the parameter admitted by the NG RAN node 2 following a successful Resource Status Reporting Initiation procedure.

Advantageously, the status update message may be inserted in a stream of further update messages, related to the occurrence to an ongoing issue, which may be an NG RAN node 2 issue.

In another embodiment the status update message indicative of the at least one event further comprises an update of the at least one status parameter.

Advantageously, the status update message reduces the number of status update messages by combining both, the status parameter submission and the event submission.

In a further embodiment the status parameter comprising a load measurement of the second network node.

A load measurement may indicate specific load situations or circumstances of the NG RAN node 2, which may influence the status parameter presence or reported measurement values of the status parameter. As an example, NG RAN node 2 may temporarily pause the subscription in a critical load situation.

Advantageously, the reporting of the load measurement of the second network node, NG RAN node 2, assist the first network node, NG RAN node 1, to balance the load between the two NG RAN nodes.

In an embodiment the event comprises procedures and/or functions that have an impact on a presence and/or accuracy of the reported at least one status parameter.

The presence and/or accuracy of the reported at least one status parameter may depend on the load of the NG RAN node 2, which in turn may diminish the measurement value of the status parameter or even prohibit the submission of the status parameter, e.g. in a case where the NG RAN node 2 may temporarily pause the subscription in a critical load situation, as indicated above.

Advantageously, the NG RAN node 1 may be informed about said critical load situation or the like and may be in a position to react according to the respective circumstances. In a further embodiment the at least one status parameter comprises at least one measurement parameter of at least one cell of the second node. Optionally, the status update message comprises a cell identity, CID, of the at least one cell.

The at least one cell of the second node may be owned by the NG RAN node 2 and may be lend out to the NG RAN node 1 for load balancing between the nodes. The NG RAN node 2 may be a neighbor node (with an interface between the nodes to be EN-DC X2 and Xn) or a central node CU-CP (with an interface between the nodes to be Fl-C) to the NG RAN node 1.

The cell identity, CID, allows identifying a dedicated cell of the NG RAN node 2, which in turn allows cell individual reporting of the cell parameter.

Advantageously, the load balancing may be detailed down to a single cell of the NG RAN node 2, thereby allowing precise load balancing.

In another embodiment the request is a request for periodically reporting the at least one status parameter of at least one cell of the second node. As an example, the repetition rate of the reporting may be given by in the NG RAN node 1, for example in the status request message. Said repetition rate, however, might be changed by the event of the NG RAN node 2. Accordingly, the event may have an impact on the periodically reporting of the at least one status parameter of the at least one cell of the second network node.

The periodically reporting may give a repetition rate of the at least one status parameter. The periodically reporting of the at least one status parameter may be referred to as a subscription of the at least one status parameter of the at least one cell.

Advantageously, updates of the at least one status parameter measurement result appear automatically at the NG RAN node 1 after the initial request message and the related request response message.

In an embodiment the event is related to at least one of the following aspects. The second network node is highly loaded. In more detail, the NG RAN node 1 can remove (e.g., terminate) the subscription to reduce the load on NG RAN node 2 or change the subscription periodicity to a larger report interval. A further aspect may be that the second network node is restarted. In more detail, the NG RAN node 1 gets information that NG RAN node 2 is re-starting. NG RAN node 1 now knows that NG RAN node 2 is about to re-start. It can then remove the subscription before the re-start or just realize that since it does not receive any reports the subscription is lost in NG RAN node 2. Node 1 can later re-add the subscription. A further aspect may be that the second network node is in or about to enter a sleep mode. In more detail, if NG RAN node 2 is performing sleep mode it can inform NG RAN node 1 that for example some parts and/or cells or the NG RAN node 2 as such will be set to sleep mode state. NG RAN node 1 then knows the reason for not receiving any load reports. A further aspect may be that the second network node is in or about to enter an energy savings mode. In more detail, if NG RAN node 2 is performing energy savings it can inform NG RAN node 1 that for example some parts and/or cells or the NG RAN node 2 as such will be set to energy savings state. NG RAN node 1 then knows the reason for not receiving any load reports. A further aspect may be that the second network node pauses the periodically reporting of the at least one status parameter. In more detail, if status reporting is an operator-controlled feature it would be beneficial for NG RAN node 1 to understand that support for status reporting is removed on NG RAN node 2. Optionally, pausing the periodically reporting may also be referred to as pausing the subscription. A further aspect may be that the second network node deactivates the reporting of the at least one status parameter. In more detail, NG RAN node 2 can inform NG RAN node 1 about a pause in subscription. Information about the expected pause can be implicitly decided by configuration on both sides or added to the message explicitly. This is also a way to inform NG RAN node 1 of a pause due to high load, adding on a further duration of time.

As an example of the event, the second network node may temporarily suspend the periodically reporting of at least one status parameter. Optionally, the status update message indicative of the event may be indicative of a start time, end time and/or a time duration during which the reporting is suspended.

The subscription may be an agreement as to the reporting successfully established by the Request message and Response message. The subscription of the NG RAN node 2 by the NG RAN node 1 may be achieved by inter-RAN node (e.g., inter-NG RAN node) communication. As an example, it may be achieved by exchanging between NG RAN node 1 and NG RAN node 2 messages, optionally these may be the messages Resource Status Request and Resource Status Response according to the 3GPP TS 38.423, version 17.3.0 (2022-12).

Advantageously, an improved subscription handling for initiating NG RAN node is provided. The information can be used to modify subscriptions or increase robustness for subscriptions. In a further embodiment the event is outside of a reporting scope of the at least one status parameter initiated by the request message and the response message. Optionally, the event outside of a reporting scope of the at least one status parameter comprises an event related to further cell of the second network node, wherein the further cell is not reported in the status update message. In other words, the event is not limited to the at least one status parameter initiated by the request message and the response message. Hence, it could be related to a cell of the NG RAN node 2 which is not reported in the Resource Status Update Message.

Advantageously, an improved subscription handling for initiating NG RAN node is provided.

In another embodiment the receiving, at the second network node, a second request message related to the event responsive to the sending of the update status message indicative of the event. This second request message may be received from the first network node.

Advantageously, the first network node may change the reporting scope of the second network node based in the reported events, which in turn increases the reporting efficiency. As an example, reporting, optionally in the form of the Resource Status Update message, could pause for the pause duration indicated in the respective time IE.

In jet another embodiment the at least one of the Status Update Message and the one or more further status update messages is a radio resource control (RRC) message.

RRC manages in general that both parties, e.g. first network node and the second network node in a communication, reach agreement on a common configuration. To do this, a special control mechanism to exchange information on those configurations between communicating parties is needed. The resulting implementation of this control mechanism may be (or may be embodied by) Radio Resource Control (RRC).

Advantageously, the status update message is embedded in the respective control mechanism which in turn provides efficient communication.

In a further embodiment, the status update message comprises the event indication coded as a cellular network information element, IE, among other cellular network information elements, lEs, of the second network node. Optionally, the information element (IE) has a type-length-value (TLV) structure. The cellular network information element (IE) may be an information which may be included within a signaling message or data flow which is sent across an interface, for example in the status update message. As an example, one or more lEs of the status update message that are indicative of the at least one event (also referred to as added lEs) may be at least one of: a subscription IE (e.g., indicative of an ID of the subscription affected by the event or a status of the subscription as a result of the event), an information and/or cause IE (e.g., indicative of the event or its cause) and/or a time IE (also: time information IE, e.g. indicative of a start, duration and/or end of the event or its impact on the reporting of the at least one parameter). Any of the added lEs may be structures similarly to the other IE of the status update message.

The type-length-value structure is an encoding scheme used for optional informational elements in a certain protocol, e.g. in the RRC protocol.

Advantageously, an existing coding scheme or concept of the existing status update message can be maintained in the status update message indicative of the at least one event, e.g. for backward compatibility if the first network node does not support the first method aspect.

In an embodiment, the status update message indicative of the event comprises at least one of: a subscription IE indicative of a subscription of the reporting, a cause IE indicative of a cause for a change in the reporting; and a timing IE indicative of a timing for the reporting.

The timing IE may also be referred to as time information IE. The cause IE may also be referred to as information IE. The subscription IE may comprise an indicator or identifier of a subscription for the reporting established by the request message and the response message.

A valid subscription information IE, for example with the value 1, indicates that the following details belonging to subscription information. An invalid subscription information IE, for example with the value 0, indicates that no details belonging to the subscription information follows.

The cause IE comprises information about the subscription, which is passed from NG RAN node 2 to NG RAN node 1. It can comprise several different indications or causes for change of the subscription. Typical examples are mentioned above (second network node is highly loaded, second network node is restarted, the second network node is in a sleep mode, the second network node is in an energy savings mode, etc.). With respect to the Time Information IE the NG RAN node 2 can inform NG RAN node 1 about the estimated duration of the reported issue. If for example the subscriptions are paused for a specific interval, the time information can contain the intendent length of the pause or in the case of energy savings the probable sleep time can be reported.

Advantageously, NG RAN node 1 can provide measures for the given time only and can fall back to the previous configuration after this time is elapsed.

In jet a further embodiment the indicated timing of the reporting is related to an estimated duration of the event, optionally wherein after the estimated duration an alteration related to the event disappears.

Advantageously, and similar to the previous feature NG RAN node 1 can provide measures for the given time only and can fall back to the previous configuration after this time is elapsed.

In another embodiment the cause IE is mandatory in case the subscription IE is provided (e.g. with the value 1). Further the timing IE is optional in case the subscription IE is provided (e.g. with the value 1).

Advantageously, the additional lEs are limited to the necessary ones thereby saving communication resources, e.g. air time.

In jet another embodiment the request message is a cellular network Resource Status Request signal and/or the response message is a cellular network Resource Status Response signal and/or the status update message indicative of the event is a cellular network Resource Status Update signal.

At least one of or each of the first network node and the second network node may be a cellular network node, e.g., a next generation radio access network, NG RAN, node.

The request message may be a Resource Status Request and the response message may be a Resource Status Response message of a successful operation (e.g., according to 3GPP document TS 38.423, version 17.3.0, clause 8.4.10.2) of a resource status reporting initiation (e.g., according to 3GPP document TS 38.423, version 17.3.0, clause 8.4.10).

At least one of or each of the first network node and the second network node may be a cellular network node, e.g., a next generation radio access network, NG RAN, node. Advantageously, the next generation radio access network is enhanced by this feature.

In a further embodiment the first network node and the second network node comprise a central unit, CU, implementing an RRC layer and a distributed unit, DU, implementing at least one of a radio link control, RLC, layer, a medium access control, MAC, layer, and a physical, PHY, layer. Optionally, the first network node may be a NG RAN node and/or the second network node may be a NG RAN node.

At least one of the first network node and the second network node may be responsible for at least one of managing radio resources, controlling radio bearer establishment of a user plane and managing mobility during a communication session.

The NG RAN (next-generation radio access network) node, also named gNB (Next Generation NodeB), allows 5G UE to connect with 5G NG core using 5G NR air interface.

Advantageously, the various functions may be located in different units thereby enabling non-runtime critical parts to be located remotely, optionally centrally, for example in a cloud like environment. On the other hand, runtime critical parts may be spread out across the physical network location in or close to radio parts of the network, for example in small radio nodes.

The RAN (Radio Access Network) part in an NG RAN may typically be located in the radio control function (RCF) in a gNB (Next Generation NodeB) or ng-eNB (Next Generation Evolved NodeB). The RCF may be located physically in a distributed entity close to the radio nodes (RN) or in a data center in a central location or on suitable hardware somewhere in between.

In jet another embodiment the at least one status parameter agreed upon in the request message and the response message relates to an ongoing status reporting. Optionally, this may be a periodic status reporting. The request message and the response message may be part of a 3GPP procedure for resource status reporting initiation.

The request message and the response message may be part of a resource status reporting initiation according to 3GPP document TS 38.423 (e.g. version 17.3.0), clause 8.4.10. The update message may be different from a resource status failure message (e.g., as specified in 3GPP document TS 38.423, version 17.3.0, clause 8.4.10.3). Alternatively or in addition, the event may be different from an abnormal condition according to 3GPP document TS 38.423 (e.g. version 17.3.0), clause 8.4.10.4. Alternatively or in addition, the update message may be an extension of the resource status update according to 3GPP document TS 38.423 (e.g. version 17.3.0), clause 8.4.11.2.

As to the second method aspect, the event indication can advantageously contain information, e.g. in the form feedback, about other procedures or functions that might have impact on status parameter. Alternatively or in addition, the event indication may be indicative of a cause of issues or problems such as (e.g., temporary) capacity limitations at the second network node.

Any embodiment of the second method aspect may further comprise the features or steps of any one of method embodiments mentioned above or any feature or step corresponding thereto.

As to the first device aspect, the memory may be encoded with one or more programs that may perform the functions and steps or implement the units and modules disclosed herein, e.g. according to the first method aspect. Advantageously, the event indication can contain information, e.g. in the form feedback, about other procedures or functions that might have impact on status parameter, or it could be caused by issues or problems.

Fig. 1 shows a schematic block diagram of an overall NG RAN architecture 10, within which embodiments 100 (or 100' or 100") of the first device aspect may perform the first method aspect and/or embodiments 200 (or 200' or 200") of the second device aspect may perform the second method aspect.

This architecture 10 provides an example environment for the implementing the subject technique. For example, the corresponding first and second method aspects may be performed by a second gNB 100 and a first gNB 200, respectively.

Alternatively or in addition, the corresponding first and second method aspects may be performed by a second gNB-DU 100' (or 100") and a first gNB-DU 200' (or 200"), respectively.

The NG architecture 100 may further comprise at least one of the following features:

• The NG RAN comprises of a set of gNBs connected to the 5GC through the NG.

• Any gNB can support a frequency-division duplexing (FDD) mode, a timedivision duplexing (TDD) mode or dual mode operation.

The gNBs can be interconnected through the Xn interface. • A gNB may comprise a centralized unit (gNB-CU) and one or more distributed units (gNB-DUs.) A gNB-CU and one or more gNB-DUs may be connected via an Fl (e.g., logical) interface.

• One gNB-DU is connected to only one gNB-CU. Alternatively, e.g. for resiliency, a gNB-DU may be connected to multiple gNB-CU by appropriate implementation.

Fig. 2 shows a schematic block diagram of a Status Update Message 602. The status parameter comprised therein comprising in turn a load measurement of the second network node 100 (not shown). An example of the load measurement in the form of a measurement parameter is at least one of a TNL Capacity Indicator, a Composite Available Capacity Group, a Slice Available Capacity, a Number of Active UEs, a RRC Connections or the like. Further parameter are disclosed in 3GPP TS 38.423 V17.3.0, 9.1.3.21, which are incorporated herein by reference.

The event comprises procedures and/or functions that have an impact on a presence and/or accuracy of the reported at least one status parameter will be detailed below.

Fig. 3 shows a flowchart for a method according to the first method aspect.

This comprises a method 300 of sending a status update message to a first network node 200 from a second network node 100. The method 300 comprising receiving 302 a request message, from the first network node 200, the request message being indicative of a request for reporting at least one status parameter from the second network node 100. The method 300 further comprising sending 304, to the first network node 200, a response message indicative of a successful initiation of the reporting of the at least one status parameter. The method 300 further comprising sending 308, to the first network node 200, a status update message indicative of at least one event related to the at least one status parameter.

Optionally, the method 300 further comprising sending 306, responsive to the response message and prior to indicating the event, one or more further status update messages indicative of an update of the at least one status parameter to the first network node 200.

Optionally, the status update message indicative of the at least one event further comprises an update of the at least one status parameter.

Further optionally, receiving 310, from the first network node 200, a second request message related to the event responsive to the sending 308 of the update status message indicative of the event occurs. This second request message may be based on the received status update message indicative of at least one event related to the at least one status parameter. It may change, add or delete certain parameter in view of said received status update message.

Furthermore, at least one of the status update message and the one or more further status update messages is a radio resource control (RRC) message. The respective layer, the RRC layer, is handled by a control plane of the CU (CU-CP). The use of the RRC layer may be also indicated in the status update Message.

Fig. 4 shows a flowchart for a method according to the second method aspect, the method 400 of receiving a status update message at a first network node 200 from a second network node 10. The method 400 comprising sending 402 a request message, to the second network node 100, the request message being indicative of a request for reporting at least one status parameter from the second network node 100. The method 400 further comprising receiving 404, from the second network node 100, a response message indicative of a successful initiation of the reporting of the at least one status parameter. The method 400 furthermore comprising receiving 408, from the second network node 100, a status update message indicative of at least one event related to the at least one status parameter.

The method 400 further comprising the features or steps of any one of the method 300 or any feature or step corresponding thereto.

Further, according to another aspect, a computer program product (not shown) comprising program code portions for performing steps of any one of the method 300 or the method 400, when the computer program product is executed on one or more computing devices 1104; 1204. Optionally, the computer program product stored on a computer-readable recording medium 1106; 1206.

Fig. 5 shows an example format of a Status Update Message 600. The Status Update Message 600 comprising at least one status parameter 604, which in turn comprises at least one measurement parameter of at least one cell of the second node 100, see above. Further, Fig. 5 discloses the Cell ID 606 of a reported cell as a mandatory parameter with an IE type of a Global NG-RAN Cell Identity. The Status Update Message comprising lE/Group Name parameter like Message Type, NG-RAN node 1 Measurement ID, NG-RAN node 2 Measurement ID, Cell Measurement Result, >Cell Measurement Result Item, »Cell ID (mentioned already). Further, the Status Update Message 602 comprises Subscription information 608, >lnformation/cause 610 and >Time information 612. The lE/Group Name may further provide a selection of the indications 602 on Presence, Range, IE type, Semantics description, Criticality and Assigned Criticality for each item.

The request for reporting at least one status parameter from the second network node 100 is a request for periodically reporting the at least one status parameter of at least one cell of the second node 100. The period length may be given by the first network node or may be negotiated between the network nodes. The event, e.g. as detailed below, may be related to the at least one status parameter and/or may have an impact on the periodically reporting of the at least one status parameter (e.g., of the at least one cell) of the second network node 100. As an example, the event may extend (i.e., prolong) the period duration of the periodically reporting. Alternatively, the event may interrupt the periodically reporting for a given time.

The status update message comprises the event indication coded as a cellular network information element, IE, among other cellular network information elements, lEs, of the second network node 100. Optionally, the IE has a type-length- value structure.

The status update message indicative of the event comprises at least one of a subscription 608 IE indicative of a subscription of the reporting, a cause 610 IE indicative of a cause for a change in the reporting; and a timing 612 IE indicative of a timing for the reporting. The subscription 608 may have a first status and a second status and is binary coded. The first status indicates that no further information is provided.

The second status, however, indicates that further information is provided. This is preferably the case when an event impacts the measurement results of the parameter reported. Said impacted measurement results may be incomplete or they may inaccurate or they may be delivered outside the agreed upon interval, for example later. Further information is provided in additional fields. This may comprise the cause 610 IE and the timing 612 IE, e.g. as specified above.

The indicated timing in the timing 612 IE of the reporting is related to an estimated duration of the event. Accordingly, a time interval may be indicated in this field. Alternatively or in addition, a given time may be indicated. Furthermore, a pointer to a time information of another entity may be indicated. After time expiration alteration triggered by the event may disappear and the at least one status parameter measurement value will be reported in a regular fashion.

Further, the cause 610 IE is mandatory in case the subscription 608 IE is provided. Alternatively or in addition the timing 612 IE is optional in case the subscription 608 IE is provided. Consequently, a first combination of the event related information comprises the subscription 608 IE and the cause 610 IE. A second combination of the event related information additionally comprises the timing 612 IE.

The at least one status parameter agreed upon in the request message and in the response message relates to an ongoing status reporting, optional a periodic status reporting. Alternatively or in addition, the request message and the response message are part of a 3GPP procedure for resource status reporting initiation.

Fig. 6 shows a schematic block diagram of a selection of events. The event is related to at least one of the second network node 100 is highly loaded, the second network node 100 is restarted, the second network node 100 is in or about to enter a sleep mode, the second network node 100 is in or about to enter an energy savings mode, the second network node 100 deactivates the reporting of the at least one status parameter, and the second network node 100 pauses the periodically reporting of the at least one status parameter. Respective details are given in the summary above.

Further, the event is outside of a reporting scope of the at least one status parameter initiated by the request message and the response message. Optionally, the event outside of a reporting scope of the at least one status parameter comprises an event related to further cell of the second network node 100, wherein the further cell is not reported in the status update message.

As an example, the event relates to another cell, not dedicated to the first network node, but may even impact cells dedicated to the first network node.

Furthermore, the event comprises procedures and/or functions that have an impact on a presence and/or accuracy of the reported at least one status parameter. As an example, the event may impact the measurement accuracy or even limit the parameter reporting in time and/or quantity.

Fig. 7 shows a schematic block diagram of a Resource Status Procedure. Messages are exchanged between the first network node, named NG-RAN node 1, and the second network node, named NG-RAN node 2. The request message is a cellular network resource status request signal submitted from NG-RAN node 1 to NG-RAN node 2. Alternatively or in addition the response message is a cellular network resource status response signal submitted from NG-RAN node 2 to NG-RAN node 1.

Alternatively or in addition the status update message indicative of the event is a cellular network resource status update signal submitted from NG-RAN node 2 to NG- RAN node 1. The signals may be the messages disclosed in 3GPP TS 38.423 (e.g. version 17.3.0), clauses 8.4.10.2 and 8.4.11.2.

Fig. 8 shows a schematic block diagram of a split NG RAN architecture. The first network node 200 and the second network node 100 comprise a central unit, CU, implementing an RRC layer and a distributed unit, DU, implementing at least one of a radio link control, RLC, layer, a medium access control, MAC, layer, and a physical, PHY, layer. In addition, a further central unit, CU, implementing the packet data convergence protocol, PDCP, layer. The interface Fl-C connects the CU (RRC) and the DUs. The interface Fl-U connects the CU (PDCP) and the DUs. CUs are connected by the El interface.

Optionally, the first network node 200 is a NG RAN node. Alternatively or in addition the second network node 100 is a NG RAN node.

Fig. 9 shows a schematic block diagram of an embodiment of a second network node according to a first device aspect. The second network node 100; 1100 for sending a status update message to a first network node 200, comprising memory 1106 operable to store instructions and processing circuitry 1104 operable to execute the instructions. Accordingly, the second network node 100; 1100 is operable to receive a request message, by a Request Receiving Module 102, from the first network node 200, the request message being indicative of a request for reporting at least one status parameter from the second network node 100. The second network node 100; 1100 is further operable to send, by a Response Sending Module 104, to the first network node 200, a response message indicative of a successful initiation of the reporting of the at least one status parameter. The second network node 100; 1100 is furthermore operable to send, by an Update Sending Module 108, to the first network node 200, a status update message indicative of at least one event related to the at least one status parameter. The second network node 100; 1100 is the reporting NG-RAN node.

The second network node 100; 1100 is further operable to perform the steps of the method 300, detailed above. This optionally comprises sending, by the Further Update Sending Module 106, a further status update message indicative of at least one status parameter. It further optionally comprises to receive, by a Second Request Receiving Module 110, from the first network node 200, the second request message being indicative of the second request for reporting at least one status parameter from the second network node 100 in view of the status update message indicative of at least one event. As to a variant of the first device aspect, the second network node 100; 1100 for sending a status update message to a first network node 200, is configured to receive a request message, by a Request Receiving Module 102, from the first network node 200. The request message being indicative of a request for reporting at least one status parameter from the second network node 10. The second network node 100; 1100 is further configured to send, by a Response Sending Module 104, to the first network node 200, a response message indicative of a successful initiation of the reporting of the at least one status parameter. The second network node 100; 1100 is furthermore configured to send, by an Update Sending Module 108, to the first network node 200, a status update message indicative of at least one event related to the at least one status parameter.

The second network node 100 or 1100 is further configured to perform the steps of the method 300, detailed above.

The second network node 100 or 1100 is an NG RAN node.

Fig. 10 shows a schematic block diagram of an embodiment of a first network node. As to the second device aspect, the first network node 200; 1200 for receiving a status update message from a second network node 100, comprising memory operable to store instructions and processing circuitry operable to execute the instructions. The first network node 200; 1200 is operable to send, by a Request Sending Module 202, a request message, to the second network node 100, the request message being indicative of a request for reporting at least one status parameter from the second network node 100. The first network node 200; 1200 is further operable to receive, by a Response Receiving Module 204, from the second network node 100, a response message indicative of a successful initiation of the reporting of the at least one status parameter. The first network node 200; 1200 is furthermore operable to receive, by a Update Receiving Module 208, from the second network node 100, a status update message indicative of at least one event related to the at least one status parameter.

The first network node 200; 1200 is further operable to perform the steps of the method 400, detailed above. This optionally comprises receiving, by a Further Update Receiving Module 206, a further update message from the second network node 100, a further status update message indicative of at least one status parameter. It further optionally comprises to send, by a Second Request Sending Module 210, to the second network node 100, the second request message being indicative of the second request for reporting at least one status parameter from the second network node 100 in view of the status update message indicative of at least one event. As to a variant of the second device aspect, the first network node 200; 1200 for receiving a status update message from a second network node 100 is configured to send a request message, to the second network node 100. The request message being indicative of a request for reporting at least one status parameter from the second network node 100. The first network node 200; 1200 is further configured to receive, from the second network node 100, a response message indicative of a successful initiation of the reporting of the at least one status parameter. The first network node 200; 1200 is furthermore configured to receive, from the second network node 100, a status update message indicative of at least one event related to the at least one status parameter.

The first network node 200; 1200 is further configured to perform the steps of the method 400, detailed above.

The first network node 200; 1200 is an NG RAN node.

Fig. 11 shows a schematic block diagram of a second NG RAN architecture. This is the architecture of the reporting NG-RAN node. It comprises an interface 1102 and the second network node 100 which in turn comprises processing circuitry 1104 and memory 1106. The interface 1102 is communicatively coupled to the second network node 100. The processing circuitry 1104 is communicatively coupled to the memory 1106.

Fig. 12 shows a schematic block diagram of a first NG RAN architecture. This is the architecture of the Requesting NG-RAN node. It comprises an interface 1202 and the first network node 200 which in turn comprises processing circuitry 1204 and memory 1206. The interface 1202 is communicatively coupled to the first network node 200. The processing circuitry 1204 is communicatively coupled to the memory 1206.

In other words, the technique may be described or embodied as follows:

The technique is related to a NG RAN architecture, an example of which is illustrated in Fig. 1. The NG architecture 10 can be described as follows:

• The NG-RAN consists of a set of gNBs (network nodes 100, 200, 1100, 1200) connected to the 5GC through the NG.

• An gNB (network nodes 100, 200, 1100, 1200) can support FDD mode, TDD mode or dual mode operation. • gNBs (network nodes 100, 200, 1100, 1200) can be interconnected through the Xn interface.

• A gNB (network node 100, 200, 1100, 1200) may consist of a gNB-CU and gNB- DUs. A gNB-CU and a gNB-DU is connected via Fl logical interface.

• One gNB-DU is connected to only one gNB-CU.

For resiliency, a gNB-DU may be connected to multiple gNB-CU by appropriate implementation.

NG, Xn and Fl are logical interfaces. The NG-RAN is layered into a Radio Network Layer, RNL, and a Transport Network Layer, TNL. The NG-RAN architecture, i.e. the NG-RAN logical nodes (network node 100, 200, 1100, 1200) and interfaces between them, is defined as part of the RNL. For each NG-RAN interface NG, Xn and Fl the related TNL protocol and the functionality are specified. The TNL provides services for user plane transport and signaling transport. If security protection for control plane and user plane data on TNL of NG-RAN interfaces has to be supported, NDS/IP, see 3GPP TS 33.401, shall be applied.

A gNB (network node 100, 200, 1100, 1200) may also be connected to an LTE eNB via the EN-DC X2 interface. Another architectural option is that where an LTE eNB connected to the Evolved Packet Core network is connected over the EN-DC X2 interface with a so called en-gNB. The latter is a gNB not connected directly to a CN but connected via EN-DC X2 to an eNB for the sole purpose of performing dual connectivity (DC).

The architecture in Fig. 1 can be expanded by spitting the gNB-CU into two entities, optionally according to Fig. 8. Accordingly, in the split architecture option, the RAN protocol stack functionality is separated in different parts. The CU-CP is expected to handle the RRC layer, the CU-UP will handle the PDCP layer and the DU will handle the RLC, MAC and PHY layer of the protocol stack. In some further split the DU can have separated unit that handles the PHY parts separately compared to RLC and MAC layers that are handled in a DU.

As different units handle different protocol stack functionalities, there will be a need for inter-node communication between the DU, the CU-UP and the CU-CP. This is achieved via Fl-C interface related to control plane signaling, via Fl-U interface related to user plane signaling for communication between CU and DU and via El interface for communication between CU-UP and CU-CP. The El interface is a logical interface. It supports the exchange of signaling information between the endpoints. From a logical standpoint, the El is a point-to- point interface between a gNB-CU-CP and a gNB-CU-UP. The El interface enables exchange of UE associated information and non-UE associated information. The El interface is a control interface and is not used for user data forwarding.

All the interfaces Fl-C, EN-DC X2 and Xn are used to communicate information about for example served cells to a neighbor node (EN-DC X2 and Xn) or to a central node CU-CP (Fl-C).

Another procedure that is specified on the Xn/Fl interfaces are Resource Status Request initiation and Resource Status Reporting where one gNB (network node 100, 1100) can setup subscriptions from a neighbor gNB (network node 200, 1200) and get periodic reporting of some selected parameter, see Fig. 7.

The procedure initiated by one gNB (gNBl) (network node 100, 1100) that sends a Resource Status Request to a neighbor gNB (gNB2) (network node 200, 1200). If the neighbor accepts the request, it will send a Resource Status Response back to gNBl (network node 100, 1100). If gNBl requested a periodic reporting, gNB2 (network node 200, 1200) will send periodic updates to gNBl. This will go on until gNBl sends a request to stop the subscription to gNB2 (network node 200, 1200).

However, for NG-RAN node 2 (network node 200, 1200) there is no way to inform NR-RAN node 1 (network node 100, 1100) about any issues with an ongoing status reporting configured via 3GPP procedure Resource Status Request Initiation. NG-RAN node 2 (network node 200, 1200) can only send the requested Resource Status Updates.

The inventive solution solves this problem as follows. Expand the Resource Status Update message with an opportunity for NG-RAN node 2 (network node 200, 1200) to inform NG-RAN node 1 (network node 100, 1100) about issues, node status or other actions, see Fig. 6. NG-RAN node 1 (network node 100, 1100) can, depending on the received information, act or understand any consequence/impact on the ongoing Status reporting in a better way. This will lead to a better solution and a more robust handling of resource status reporting procedure.

Any aspect of the technique may comprise exclusively or in combination with the method 300 or 400, the following features and steps. The possibilities for NG-RAN node 2 (i.e., network node 200 or 1200) to send feedback to NG-RAN node 1 (i.e., the network node 100 or 1100) in a Report Status Update message (e.g., according to Fig. 5) is extend. Thereby, embodiments of the technique can enable NG-RAN node 1 (network node 100, 1100) to understand an ongoing issue. NG-RAN node 1 (network node 100, 1100) can then mitigate the problem or take action to avoid larger impacts.

The feedback (subscription 608 IE indicative of a subscription of the reporting, a cause 610 IE indicative of a cause for a change in the reporting and a timing 612 IE indicative of a timing for the reporting) can contain information about other procedures or functions that might have impact on status reporting, or it could be caused by issues or problems. The below list contains some examples and potential actions from NG-RAN node 1 (network node 100, 1100).

• gNB high loaded - NG RAN node 1 can remove subscription to reduce the load on NG-RAN node 2 or change the subscription periodicity to a larger report interval.

• Node re-starting - NG-RAN node 1 gets information that NG-RAN node 2 is restarting. NG-RAN node 1 now knows that NG-RAN node 2 is about to re-start. It can then remove the subscription before the re-start or just realize that since it does not receive any reports the subscription is lost in NG-RAN node 2. Node 1 can later re-add the subscription.

• Resources will go to sleep or energy savings mode - If NG-RAN node 2 is performing energy savings it can inform NG-RAN node 1 that for example some will be set to energy savings state. NG-RAN node 1 then knows the reason for not receiving any load reports.

• Status reporting deactivated - If status reporting is an operator-controlled feature it would be beneficial for NG-RAN node 1 to understand that support for status reporting is removed on NG-RAN node 2.

• Pause Subscription - NG RAN node 2 can inform NG-RAN node 1 about a pause in subscription. Information about the expected pause can be implicitly decided by configuration on both sides or added to the message explicitly. This is also a way to inform NG-RAN node 1 of a pause due to high load, adding on a pack of time.

The advantages of the solution are improved subscription handling for initiating NG- RAN node (network node 100, 1100). The information can be used to modify subscriptions or increase robustness for subscriptions.

It can also be used to enable control from NG-RAN node 2 (network node 200, 1200). For example, NG-RAN node 2 can temporarily pause the subscription in a critical load situation. A core embodiment of the invention is to enrich the Resource Status Update message (e.g. according to Fig. 2 or Fig. 5) to enable the NG-RAN node 2 to pass information back to NG-RAN node 1 about any ongoing subscription. One example on how this can be done is to expand the Resource Status Update message by adding additional lEs into the message. Fig. 5 show one example of message content where the added lEs compared to the original message are marked in dotted fields.

The subscription information indicates whether or not further information in this respect follows.

A first aspect is the Information and/or Cause IE. Here information about the subscription is passed from NG-RAN Node 2 (network node 200, 1200) to Node 1 (network node 100, 1100). It can be several different indications or causes for change of the subscription, typical examples are mentioned above.

A second aspect is the Time information IE. Here NG-RAN node 2 (network node 200, 1200) can inform NG-RAN node 1 (network node 100, 1100) about the estimated duration of the reported issue. If, for example, the subscriptions are paused for a specific interval, the time information can contain the intendent length of the pause or in the case of energy savings the probable sleep time duration can be reported.

With respect to a cloud implementation the RAN part of the proposed solution is in an NG-RAN typically located in the radio control function (RCF) in a gNB or ng-eNB. The RCF may be located physically in a distributed entity close to the radio nodes (RN) or in a data center in a central location or on suitable hardware somewhere in between.

Features referred to herein by reference signs have the technical meaning specified in above embodiments or indicated below.

List of Reference Signs

10 Overall NG RAN (Next Generation Radio Access Networks) architecture

100 Second network node

102 Request Receiving Module

104 Response Sending Module

106 Further Update Sending Module

108 Update Sending Module

110 Second Request Receiving Module

200 First network node

202 Request Sending Module

204 Response Receiving Module

206 Further Update Receiving Module

208 Update Receiving Module

210 Second Request Sending Module

300 Method of sending status update message

302 Receive a request message

304 Send a response message

306 Send one or more further update messages

308 Send a status update message

310 Receive a second request message

400 Method of receiving status update message

402 Send a request message

404 Receive a response message

406 Receive one or more further update messages

408 Receive a status update message

410 Send a second request message

600 Resource Status Update Message

602 Resource Status Update Header

604 Status Parameter

606 Cell ID

608 Subscription IE

610 Cause IE

612 Timing IE

700 Selected events possible

1100 Second network node 1102 Interface

1104 Processing circuitry

1106 Memory

1104 Computing devices 1106 Computer-readable recording medium

1200 First network node

1204 Computing devices

1206 Computer-readable recording medium

Abbreviation used herein have the meaning defined in context and at first appearance. Otherwise, appreciations are defined below.

List of Abbreviations

5GC 5G Core Network

CU-CP Central Unit Control Plane

CU-UP central unit user plane

DC Dual Connectivity

El El interface en-gNB gNB not connected directly to a Core Network

EN-DC X2 E-UTRAN New Radio - Dual Connectivity X2 interface

Fl Fl Interface (Location: Between gNB-CU and gNB-DU)

FDD mode Frequency-Division Duplexing mode gNB next Generation Neighbor Node gNB-CU gNB Centralized Unit gNB-DU gNB Distributed Unit

IE Information Element

LTE Long Term Evolution

MAC Medium Access Control

NDS/IP Network Domain Security for IP based protocols

NG RAN, NG-RAN Next Generation Radio Access Networks

NG Next Generation interface ng-eNB Next Generation e-NodeB

PDCP Packet Data Convergence Protocol

PHY Physical

RCF Radio Control Function

RLC Radio Link Control

RN Radio node

RNL Radio Network Layer

RRC Radio Resource Control

TDD mode Time Division Duplex mode

TNL Capacity Indicator Transport Network Layer Capacity Indicator Xn Xn interface

Claims

1. A method (300) of sending a status update message to a first network node (200) from a second network node (100)₇ the method (300) comprising: receiving (302) a request message, from the first network node (200), the request message being indicative of a request for reporting at least one status parameter from the second network node (100); sending (304), to the first network node (200), a response message indicative of a successful initiation of the reporting of the at least one status parameter; and sending (308), to the first network node (200), a status update message indicative of at least one event related to the at least one status parameter.

2. The method (300) of claim 1, further comprising: sending (306), responsive to the response message and prior to indicating the event, one or more further status update messages indicative of an update of the at least one status parameter to the first network node (200).

3. The method (300) of claim 1 or 2, wherein the status update message indicative of the at least one event further comprises an update of the at least one status parameter (604).

4. The method (300) of any one of claims 1 to 3, wherein the status parameter (604) comprising a load measurement (606) of the second network node (100).

5. The method (300) of any one of claims 1 to 4, wherein the event comprises procedures and/or functions that have an impact on a presence and/or accuracy of the reported at least one status parameter.

6. The method (300) of any one of claims 1 to 5, wherein the at least one status parameter comprises at least one measurement parameter of at least one cell of the second node (100)₇ optionally wherein the status update message comprises a cell identity, CID, of the at least one cell.

7. The method (300) of any one of claims 1 to 6, wherein the request for reporting at least one status parameter from the second network node (100) is a request for periodically reporting the at least one status parameter of at least one cell of the second node (100), and wherein the event has an impact on the periodically reporting of the at least one status parameter of the at least one cell of the second network node (100).

8. The method (300) of any one of claims 1 to 7, wherein the event is related to at least one of: the second network node (100) is highly loaded, the second network node (100) is restarted, the second network node (100) is in or about to enter a sleep mode, the second network node (100) is in or about to enter an energy savings mode, the second network node (100) deactivates the reporting of the at least one status parameter, and the second network node (100) pauses the periodically reporting of the at least one status parameter.

9. The method (300) of any one of claims 1 to 8, wherein the event is outside of a reporting scope of the at least one status parameter defined or initiated by the request message and the response message, and/or wherein the event comprises an event related to a further cell or a further beam of the second network node (100), wherein the further cell or the further beam is not reported in the status update message.

10. The method (300) of any one of claims 1 to 9, further comprising: receiving (310), optionally from the first network node (200), a second request message related to the event responsive to the sending (308) of the update status message indicative of the event.

11. The method (300) of any one of claims 1 to 10, wherein at least one of the status update message and the one or more further status update messages is a radio resource control, RRC, message.

12. The method (300) of any one of claims 1 to 11, wherein status update message comprises the event indication coded as a cellular network information element, IE, among other cellular network information elements, lEs, of the second network node (100), optionally wherein the IE has a type- length-value structure.

13. The method (300) of any one of claims 1 to 12, wherein the status update message indicative of the event comprises at least one of: a subscription (608) IE indicative of a subscription of the reporting, a cause (610) IE indicative of a cause for a change in the reporting; and a timing (612) IE indicative of a timing for the reporting.

14. The method (300) of claim 13, wherein the indicated timing of the reporting is related to an estimated duration of the event, optionally wherein after the estimated duration an alteration related to the event disappears.

15. The method (300) of claim 13 or 14, wherein the cause (610) IE is mandatory in case the subscription (608) IE is provided, and/or wherein the timing (612) IE is optional in case the subscription (608) IE is provided.

16. The method (300) of any one of claims 1 to 15, wherein the request message is a cellular network resource status request signal and/or the response message is a cellular network resource status response signal and/or the status update message indicative of the event is a cellular network resource status update signal.

17. The method (300) of any one of claims 1 to 16, wherein the first network node (200) and the second network node (100) comprise a central unit, CU, implementing an RRC layer and a distributed unit, DU, implementing at least one of a radio link control, RLC, layer, a medium access control, MAC, layer, and a physical, PHY, layer, and/or wherein the first network node (200) is a NG RAN node and/or wherein the second network node (200) is a NG RAN node.

18. The method (300) of any one of claims 1 to 17, wherein the at least one status parameter agreed upon in the request message and the response message relates to an ongoing status reporting, optional a periodic status reporting, and/or wherein the request message and the response message are part of a 3GPP procedure for resource status reporting initiation.

19. A method (400) of receiving a status update message at a first network node (200) from a second network node (100), the method (400) comprising: sending (402) a request message, to the second network node (100), the request message being indicative of a request for reporting at least one status parameter from the second network node (100); receiving (404), from the second network node (100), a response message indicative of a successful initiation of the reporting of the at least one status parameter; and receiving (408), from the second network node (100), a status update message indicative of at least one event related to the at least one status parameter.

20. The method (400) of claim 19, further comprising the features or steps of any one of claims 2 to 18 or any feature or step corresponding thereto.

21. A computer program product comprising program code portions for performing the steps of any one of the claims 1 to 18 or 19 to 20 when the computer program product is executed on one or more computing devices (1104; 1204), optionally stored on a computer-readable recording medium (1106; 1206).

22. A second network node (100; 1100) for sending a status update message to a first network node (200), comprising memory operable to store instructions and processing circuitry operable to execute the instructions, such that the second network node (100; 1100) is operable to: receive a request message, from the first network node (200), the request message being indicative of a request for reporting at least one status parameter from the second network node (100); send, to the first network node (200), a response message indicative of a successful initiation of the reporting of the at least one status parameter; and send, to the first network node (200), a status update message indicative of at least one event related to the at least one status parameter.

23. The second network node (100; 1100) of claim 22, further operable to perform the steps of any one of claims 2 to 18.

24. A second network node (100; 1100) for sending a status update message to a first network node (200), configured to: receive a request message, from the first network node (200), the request message being indicative of a request for reporting at least one status parameter from the second network node (100); send, to the first network node (200), a response message indicative of a successful initiation of the reporting of the at least one status parameter; and send, to the first network node (200), a status update message indicative of at least one event related to the at least one status parameter.

25. The second network node (100; 1100) of claim 24, further configured to perform the steps of any one of claims 2 to 18.

26. The second network node (100; 1100) of any one of claims 22 to 25, wherein second network node (100; 1100) is an NG RAN node.

27. A first network node (200; 1200) for receiving a status update message from a second network node (100), comprising memory operable to store instructions and processing circuitry operable to execute the instructions, such that the first network node (200) is operable to: send a request message, to the second network node (100), the request message being indicative of a request for reporting at least one status parameter from the second network node (100); receive, from the second network node (100), a response message indicative of a successful initiation of the reporting of the at least one status parameter; and receive, from the second network node (100), a status update message indicative of at least one event related to the at least one status parameter.

28. The first network node (200; 1200) of claim 27 , further operable to perform the steps of claim 20.

29. A first network node (200; 1200) for receiving a status update message from a second network node (100), configured to: send a request message, to the second network node (100), the request message being indicative of a request for reporting at least one status parameter from the second network node (100); receive, from the second network node (100), a response message indicative of a successful initiation of the reporting of the at least one status parameter; and receive, from the second network node (100), a status update message indicative of at least one event related to the at least one status parameter.

30. The first network node (200; 1200) of claim 29, further configured to perform the steps of claim 20.

31. The first network node (200; 1200) of any one of claims 26 to 29, wherein first network node (200; 1200) is an NG RAN node.