WO2021197603A1

WO2021197603A1 - Collection of symptom data for disaggregated network elements

Info

Publication number: WO2021197603A1
Application number: PCT/EP2020/059340
Authority: WO
Inventors: Jürgen Goerge; Esko Perttu PÄTTIKANGAS; Sigmar Lust
Original assignee: Nokia Technologies Oy
Priority date: 2020-04-02
Filing date: 2020-04-02
Publication date: 2021-10-07

Abstract

The present document discloses a method of collecting symptom data for at least one elementary function in a disaggregated network element. In particular, the method may comprise monitoring the elementary function for faults. And if a fault is detected in an elementary function, the method may further comprise triggering the elementary function to collect symptom data related to the detected fault, generating a signature based on the detected fault and sending a trigger message including the generated signature to at least one related neighboring elementary function for triggering further collection of symptom data of the at least one related neighboring elementary function.

Description

COLLECTION OF SYMPTOM DATA FOR DISAGGREGATED NETWORK ELEMENTS

Technical Field

The present disclosure generally relates to collection of symptom data in a network system, and particularly, relates to collection of symptom data for elementary functions of disaggregated network elements deployed in the network system.

Background

Generally speaking, due to the possibilities of virtualization, communication service providers and/or vendors are currently targeting to move as many telecommunication network functions as possible from expensive and special-build hardware to commercial off the shelf (COTS) hardware. Basically, all network functions of the mobile core network can now in principle be running as virtualized network functions in a cloud (i.e., on COTS hardware). As for the radio access network (RAN) architecture, standardization (e.g., 3rd Generation Partnership Project or 3GPP for short, open-RAN or O-RAN for short, etc.) may allow for an even finer disaggregation of network functions into for example elementary functions (or sometimes also referred to as micro services) communicating over standardized interfaces. For example, a traditional base station may be split into several functional units as shown in Figure 1, which will be described in more detail below.

Typically, most of the RAN network functions can be hosted on the cloud as pure software services. In particular, this shall enable the service providers to replace (or swap) these functions much faster compared to functions that require special-built hardware and to select the different functions from different vendors. On the other hand, from operation and management point of view, these disaggregated functions may expose own management interfaces in order to allow for individual management of each entity.

All these efforts can lead to strongly disaggregated functions of the radio access network, where these functions would typically be independently developed by different vendors and might be managed by dedicated management tools. Nevertheless, the service provider (or operator) still has the challenge to manage the overall network. In particular, instead of managing (aggregated) network elements, each with a single management interface and each provided by one vendor, the operator will face disaggregated, smaller "elementary functions", potentially each provided by different vendors with different concepts for the management, yet all depending on each other.

Generally speaking, such disaggregation of the network elements/functions poses problems (e.g., for the service provider and/or operator) when to analyze critical problems and/or failures occurred in the network element(s) of the network system, since these network elements/function are disaggregated to run on multiple processing units and/or to be provided by different vendors.

Summary

In view of some or all of the above problems and/or use cases, the present disclosure generally proposes a simple and efficient mechanism allowing to record and/or collect symptom data in a synchronized manner from an elementary network function exhibiting a problem and all its related network functions (or micro services) so as to allow comprehensive analysis of the context in which the problem occurred.

As a broad aspect, there is provided a method of collecting symptom data for at least one elementary function in a disaggregated network element. In particular, the method may comprise monitoring the elementary function for faults. And if a fault is detected in an elementary function, the method may further comprise triggering the elementary function to collect symptom data related to the detected fault, generating a signature based on the detected fault and sending a trigger message including the generated signature to at least one related neighboring elementary function for triggering further collection of symptom data of the at least one related neighboring elementary function.

In particular, the network element being disaggregated may be a radio access network (RAN) node/element, such as a base station; or a core network node/element. By way of example but not limitation, in a 4G (Long Term Evolution or LTE for short) technology based network, the base station may also be referred to as an evolved NodeB (or eNB for short); while in a 5G (New Radio or NR for short) technology based network, the base station may also be referred to as a next generation NodeB (or gNB for short). However, any other suitable network node or element may be possible, as will be appreciated by the skilled person.

The network element/node may be disaggregated (or split) into a number of (e.g., one or more) elementary function(s). In some cases, an elementary function may also be referred to as a micro service. The disaggregation or split of the network element may be performed in any suitable manner depending on various implementations and/or requirements, as will be appreciated by the skilled person. For instance, the network element may be disaggregated in compliance with existing standard(s) (e.g., as defined by O-RAN consortium), or proprietarily (i.e., vendor-specific).

Depending on various situations (e.g., whether or how virtualization is deployed), the elementary functions and/or the network element may be implemented in a "pure" software form (e.g., deployed/hosted on cloud), in a hardware form (e.g., using special or dedicated hardware), or in a combination thereof. The monitoring of the elementary function may be achieved by any suitable means, such as an embedded or dedicated function (or functional block), depending on various implementations and/or requirements. The fault to be monitored may be an error in a function or a device, or a failure of the functional (or system) block, which may cause uncertain, undesired or erroneous behavior in execution of the elementary function; or render the elementary function (and eventually the entire network element) inoperable.

In some examples, the symptom data may comprise information for facilitating analysis of the fault. In particular, the symptom data may be or comprise: a core dump, a log file, low-level status information of applications related to the detected fault, data stored in one or more registers, a configuration (file), or a combination thereof. Of course, any other information or data that is suitable or helpful for analyzing and/or debugging the detected fault may be used and collected as symptom data, as will be clearly understood and appreciated by the skilled person.

In some examples, a related neighboring elementary function of the at least one related neighboring elementary function may be an elementary function that has an interface towards the elementary function having the fault. The interface may be a direct interface between the one or more related neighboring element functions and the elementary function where the fault is detected. The interface may be a physical interface or a virtual (e.g., software- implemented) interface. The interface may be an existing communications interface e.g. as defined in standards, or a newly defined dedicated interface for collecting symptom data.

Particularly, in some examples, a related neighboring elementary function of the at least one related neighboring elementary function may be located in the disaggregated network element. In other words, the interface towards the related neighboring elementary function may be within the same disaggregated network element. Thus, trigger messages are distributed within the disaggregated network element. In other examples, a related neighboring elementary function may be located across the boundary of the disaggregated network element in another disaggregated network element and the interface may be across the disaggregated network elements.

In some examples, the signature related to the detected fault may be a unique identification (or simply referred to as an ID) associated with the fault. For example, the signature may be generated in such a manner that the fault may be individually identifiable by the generated signature, as can be clearly understood and appreciated by the skilled person. That is to say, by analyzing (e.g., parsing or decoding) the generated signature, the analyzer (e.g., a software program/application or a human expert or system administrator) can easily identify and conclude on the fault occurred in the elementary function. In some case (but without any limitation), this may be achieved by creating a one-to-one or one-to-group relationship (mapping) between the (to-be-generated) signature and the (to-be-detected) fault, as will be appreciated by the skilled person. In particular, in some examples, the signature may comprise a unique identification (ID) that is generated or created in accordance with the fault. As illustrated above, the identification may be generated in such a manner that it can be used for facilitating the identification of the occurred fault.

In some examples, the signature (or the trigger message) may comprise further information, such as a timestamp associated with the fault. The timestamp collected may be used for facilitating debugging or analyzing, e.g., in cases where multiple faults are to be post-processed collectively, the timestamp may be used for indicating which of the collected symptom data belongs to which fault, etc. Of course, any other suitable information may be included in the unique signature/identifier, in order to further facilitating analyzing and resolving the problems and/or to make the signature unique. By way of example but not limitation, a network identifier (such as an IP address) of the elementary function where the fault is detected may be further comprised in the signature.

In general, there might be many different faults or reasons to start symptom data collection and it is at the discretion of every provider (vendor) of elementary functions to prepare a list of faults for the communication service provider for fault analysis. As will be appreciated by the skilled person, there exist many different kinds of data to collect as part of the symptom data collection. Thus, the present disclosure shall not be limited by defining specific faults or specific types of symptom data and the disclosed mechanism should be construed as general as possible. In a broad aspect, any fault may trigger the collection of symptom data and the kind of collected data is not specified or limited. Each elementary function may collect its own specific symptom data.

In some examples, the trigger message may further comprise information indicative of the symptom data to be collected. That is to say, the information, upon receipt (possibly being parsed/decoded from the trigger message), may be used to indicate an elementary function to collect which symptom data, e.g. which part of the (e.g. a subset instead of the complete) available symptom data. For instance, if a fault detected is related only to a particular function or feature (e.g., a specific procedure), then the trigger message may be generated to comprise information that may instruct the receiving elementary function to only collect symptom data that is related to the particular function or feature (e.g., involved in the specific procedure), as opposed to the collection of all available symptom data, such as a complete core dump (which may be relatively large in terms of memory consumption).

In some examples, the trigger message may yet further comprise information indicative of (a subset of) the at least one related neighboring elementary functions to collect the symptom data. That is to say, instead of all related neighboring elementary functions being instructed to collect the symptom data, the trigger message may be generated to comprise information that may instruct only part of (a subset of) the receiving elementary functions to collect symptom data. As will be appreciated by the skilled person, this may be achieved by any suitable manner, such as to include a predefined list, map, look-up table (LUT), or policy, etc.

Configured as such, particularly by the generation and inclusion of the (unique) signature, the symptom data collected by all relevant elementary functions related to individual fault can be distinguished and correlated if necessary, for example for further processing by an evaluating tool or expert.

In some examples, the signature may be generated by the elementary function itself where the fault is detected. On the other hand, in some cases, it is also possible that the signature may be predetermined or predefined (for example being implemented as a LUT in accordance with the to-be-detected faults), as can be clearly understood and appreciated by the skilled person.

In some examples, the elementary function to collect the symptom data may be triggered for one or more predefined fault conditions. In other words, the elementary function may be configured (e.g., predetermined) to collect the symptom data and send a trigger message only for one or more predefined faults (or in some cases, groups of faults), such as certain severe faults/errors, and to refrain (e.g., to ignore) from collecting symptom data for the other faults (or groups of faults), such as certain less severe faults/errors.

In some examples, the method may further comprise informing a management function about availability of the symptom data collected by the elementary function. As will be appreciated by the skilled person, the management function may be implemented as part of (e.g., as an embedded functional/feature block) the disaggregated network element, or as a dedicated or standalone function that may be external to the disaggregated network element.

In some examples, the method may further comprise providing the symptom data collected by the elementary function to: the management function, a location requested by the management function, a preconfigured location, or a combination thereof. As such, depending on where the symptom data is sent, the symptom data collected by one or more elementary functions may be gathered for processing (e.g., analyzing or debugging) in any suitable manner, as will be appreciated by the skilled person.

In some examples, the symptom data may be sent out, e.g., to the management function, as part of a (communication) message.

In some examples, the method may further comprise including the generated signature into the message comprising the symptom data. In other words, the symptom data and the generated signature may be multiplexed and sent out together, such that the recipient (e.g., the management function) can, e.g., by parsing the signature, identify and link the symptom data with the fault.

In some examples, the method may further comprise storing the symptom data collected by the elementary function. In particular, in some cases, the symptom data may be stored until the symptom data is sent out, e.g., to the management function or somewhere else. In some other cases, the symptom data may be stored for a predefined time limit (before the symptom data is deleted from the store memory).

In particular, in some cases, the message including the symptom data may be sent using an existing interface (e.g., as defined in standards) between the elementary function and the destination where the message is sent to. For this, the message including the symptom data may need to be processed before being able to re-use the existing interface, as will be understood and appreciated by the skilled person. By way of example but not limitation, the message including the symptom data may be required to be multiplexed with the other data payload that is to be sent using the existing interface; or the message including the symptom data may be required to be re-encoded using the data structure supported by the existing interface, as will be understood by the skilled person. In some other cases, the message including the symptom data may be sent using a new (e.g., specifically defined) interface between the elementary function and the destination where the message is sent to.

In some examples, the method may further comprise, for a second elementary function of (among) the at least one related neighboring elementary function at which the trigger message including the signature is received, triggering the second elementary function to collect symptom data in accordance with the detected fault. The method may further comprise sending a further trigger message (or forwarding the received trigger message) including the received signature to at least one further related neighboring elementary function, for triggering further collection of symptom data of the at least one further related neighboring elementary function.

In particular, the further trigger message may be sent or forwarded from the second elementary function to the at least one further related neighboring elementary function. The second elementary function may be configured to collect the symptom data in an analogous manner as illustrated above for the (first) elementary function. However, instead of generating a new signature as has been done by the (first) elementary function above, the second elementary function may be configured to pass through (or relay) the received signature (which was generated by the elementary function where the fault occurred) to the at least one further related neighboring elementary function, in order to trigger further collection of symptom data of the at least one further related neighboring elementary function. Similar as above, the further related neighboring elementary function may be an elementary function which has an (direct) interface towards the second elementary function; and the further related neighboring elementary function may belong to the same disaggregated network element where the second elementary function (and possibly also the first elementary function) resides. This process may repeat until all elementary functions in the disaggregated network element have collected symptom data.

In some examples, the method may further comprise, prior to triggering the second elementary function to collect the symptom data, determining whether the signature has been received before. And, the method may further comprise, if it is determined that the signature has been received before, ignoring the received trigger message by not triggering the second elementary function to collect the symptom data and not sending the further trigger message.

In particular, the determination of whether the signature has been received before or not may be achieved by any suitable means, as will be appreciated by the skilled person. For instance, the determination may involve appropriately decoding (or parsing) the receive signature to get the identification contained therein; and comparing the received identification with any previously received (and possibly stored somewhere in the memory) identification(s). If it is determined that the signature has been received before (e.g., by comparing the included identification), the second elementary function may be configured to ignore the received trigger message and refrain from collecting the symptom data and/or sending further trigger message(s) to any related neighboring elementary function.

Configured as such, the undesirable ping-pong of trigger messages exchanged amongst various elementary functions may be largely suppressed or avoided, thereby saving the whole network system from being flooded by potential avalanches of unnecessary trigger messages.

As another broad aspect, there is provided a method of collecting symptom data for at least one elementary function in a disaggregated network element. In particular, the method may comprise receiving, at an elementary function of the disaggregated network element, a trigger message including a signature from another elementary function. More particularly, the signature may be generated based on a fault detected by one elementary function (different from the present elementary function which receives the trigger message). In this sense, the signature may be generated by the elementary function which detects the fault. The method may further comprise, in response to receiving the trigger message, triggering the elementary function to collect symptom data in accordance with the fault. Finally, the method may further comprise sending a further trigger message including the received signature or forwarding the received trigger message to at least one related neighboring elementary function, for triggering further collection of symptom data of the at least one related neighboring elementary function. Thus, the method collects symptom data and forwards the trigger message in the network to other elementary functions.

In some examples, the method of the last-mentioned broad aspect may further comprise, prior to triggering the elementary function to collect the symptom data, determining whether the signature has been received before. And if it is determined that the signature has been received before, the method may further comprise ignoring the received trigger message by not triggering the elementary function to collect the symptom data and not sending the further trigger message. Configured as such, the undesirable ping-pong of trigger messages exchanged amongst various elementary functions may be largely suppressed or avoided, thereby saving the whole network system from being flooded by potential avalanches of unnecessary trigger messages.

As another broad aspect, there is provided an elementary function of a disaggregated network element. In particular, the elementary function may comprise means for monitoring for faults in the elementary function. And, the elementary function may further comprise, if a fault is detected by the elementary function, means for collecting symptom data related to the detected fault, means for generating a signature based on the detected fault, and means for sending a trigger message including the generated signature to at least one related neighboring elementary function for triggering further collection of symptom data of the at least one related neighboring elementary function. The various means of elementary function may be implemented using any suitable manner (e.g., software, hardware, a combination thereof, etc.) depending on different designs and/or requirements, as will be appreciated by the skilled person.

As another broad aspect, there is provided an elementary function of a disaggregated network element. In particular, the elementary function may comprise at least one processor and at least one memory including computer program code. More particularly, the at least one memory and the computer program code may be configured to, with the at least one processor, cause the elementary function at least to perform monitoring for faults in the elementary function, and if a fault is detected by the elementary function, collecting symptom data related to the detected fault, generating a signature based on the detected fault, and sending a trigger message including the generated signature to at least one related neighboring elementary function for triggering further collection of symptom data in the at least one related neighboring elementary function.

As another broad aspect, there is provided an elementary function of a disaggregated network element. In particular, the elementary function may comprise means for receiving a trigger message including a signature from another elementary function. More particularly, the signature may be generated based on a fault detected by one elementary function (different from the present elementary function which receives the trigger message). Further, the elementary function may comprise means for collecting symptom data in accordance with the fault and means for sending a further trigger message including the received signature to at least one related neighboring elementary function for triggering further collection of symptom data of the at least one related neighboring elementary function.

In some examples, the disaggregated network element may be or form part of a base station. Of course, the disaggregated network element may be implemented as any other used network node e.g., of the radio access network or of the core network. As another broad aspect, there is provided a disaggregated network element. In particular, the disaggregated network element may comprise at least one elementary function according to any one of the example embodiments as illustrated above.

As yet another broad aspect, there is provided a non-transitory computer readable medium.

The non-transitory computer readable medium may comprise program instructions for causing an elementary function of a disaggregated network element at least to perform monitoring for faults in the elementary function, and, if a fault is detected by the elementary function, collecting symptom data related to the detected fault, generating a signature based on the detected fault, and sending a trigger message including the generated signature to at least one related neighboring elementary function for triggering further collection of symptom data of the at least one related neighboring elementary function.

Notably, it is understood that methods according to the disclosure relate to methods of operating the elementary function(s) and/or disaggregated network element according to the above example embodiments and variations thereof, and that respective statements made with regard to the apparatuses (e.g., the elementary function and/or disaggregated network element) likewise apply to the corresponding methods, and vice versa, such that similar description may be omitted for the sake of conciseness. In addition, the above aspects may be combined in many ways, even if not explicitly disclosed. The skilled person will understand that these combinations of aspects and features/steps are possible unless it creates a contradiction which is explicitly excluded.

Implementations of the disclosed apparatuses may include using, but not limited to, one or more processor, one or more application specific integrated circuit (ASIC) and/or one or more field programmable gate array (FPGA). Implementations of the apparatus may also include using other conventional and/or customized hardware such as software programmable processors.

Other and further example embodiments of the present disclosure will become apparent during the course of the following discussion and by reference to the accompanying drawings.

Brief Description of the Figures

Embodiments of the disclosure are explained below in an exemplary manner with reference to the accompanying drawings, wherein

Figure 1 schematically illustrates an example of a high level block diagram of a disaggregated radio access node according to an embodiment of the present disclosure;

Figure 2 schematically illustrates an example of a flow chart of symptom data collection according to an embodiment of the present disclosure;

Figure 3 schematically illustrates an example of a flow chart of ping-pong of triggers; and Figure 4 schematically illustrates an example of a flow chart of avoiding ping-pong triggers according to an embodiment of the present disclosure.

Detailed Description

In the following, example embodiments of the present disclosure will be described with reference to the appended figures. In particular, identical elements in the figures may be indicated by identical (or similar) reference numbers, and thus repeated description thereof may be omitted for the sake of conciseness.

Figure 1 schematically illustrates an example of a high level block diagram of a disaggregated radio access node according to an embodiment of the present disclosure. In particular, the radio access node may be a traditional base station (sometimes also referred to as a Base Transceiver Station, or BTS for short). Figure 1 shows the architecture, the various types of elementary functions and their interfaces. It doesn't show how often each of those elementary functions can be instantiated.

Broadly speaking, due to the possibilities of virtualization, telecommunication network functions/elements are being considered to be moved as many as possible from expensive special-build hardware to commercial off the shelf (COTS) hardware.

Referring to the example as shown in Figure 1, a disaggregated base station 120 may be split into several functional units. In some cases, the functional units may also be referred to as elementary functions. For instance, the functional units may include a central unit (CU) 122, which is typically configured to host non-time critical processing for many hundred or thousand cells. Notably, this central unit 122 might run in a central cloud on COTS hardware, as will be appreciated by the skilled person.

Depending on various implementations and/or requirements, the CU 122 itself may be further separated into a CU control plane (CU-CP) unit 122-1 to handle the signaling and a CU user plane (CU-UP) unit 122-2 to handle the payload traffic of the user sessions. In this sense, the CU- CP unit 122-1 and the CU-UP unit 122-2 may comprise suitable protocol layers (e.g., Radio Resource Control or RRC for short, Service Data Adaptation Protocol or SDAP for short, etc.) for supporting respective functionality, as will be appreciated by the skilled person. Notably, the CU-CP 122-1 and CU-UP 122-2 may be connected by an interface 122-5, such as the El interface as standardized by 3GPP 38.463.

Further, the disaggregated base station 120 may also include multiple (sometimes even up to ~1000) distributed units (DUs). Notably, in the example of Figure 1 the DUs are collectively represented as 124. In particular, as opposed to the CU 122, the DUs 124 are typically configured to host real time (or close to real time) data processing. For this reason, the DUs 124 should be located close to the antennas, because otherwise the latency introduced by the travel time of the signals from/towards the antennas would be too high. The DUs 124 may be respectively connected via an interface 127 to one CU 122, such as the FI interface as standardized by 3GPP TS38.470 - TS38.473. Alternatively, the DUs 124 may be connected via a separate interface (e.g., Fl-C and Fl-U) to CU-CP 122-1 and CU-UP 122-2, respectively.

Moreover, the disaggregated base station 120 may further include multiple radio units (RUs), which are collectively show as 125 in the example of Figure 1. The RUs 125 are typically configured to be responsible to covert between digital signals from/towards the DU(s) 124 and the analog signal from/towards mobile stations via the air interface, and may be implemented as remote radio head (RRH). RUs 125 may be connected by an interface 128 to one DU 124. Different versions of this interface 128 have been standardized e.g. by enhanced common public radio interface (eCPRI) or xRAN low level split (LLS) interface. In some cases, a DU may be connected to around 10 RUs, for translating between the digital signals from the front haul interface and the analog RF signals of the air interface.

In some cases, e.g. the O-RAN consortium may further target to split the functions of the CU-CP 122-1 into a "CU-Low" and a "CU-High", which may result in a new network function called RAN intelligent controller (RIC) 121. Generally speaking, the RIC 121 may act as a standardized application server to host applications formerly part of the base station or extending the functionalities of a base station. The RIC 121 may be connected to the CU 122 and/or the DUs 124 via an interface 126, such as an E2 interface as defined in standards.

As will be clearly understood and appreciated by the skilled person, the disaggregated base station may comprise any other suitable functions if so required, such as a network function virtualization infrastructure (NFVI) platform 123.

Additionally, there may be provided an orchestration and automation function 110 implemented as an external node having an interface 115 (e.g., the A1 interface as defined in standards) towards the base station 120. However, in some cases, it is possible that the orchestration and automation function 110 may be implemented as a (internal/integral) part of the base station 120.

Notably, in the context of virtualization, most of the RAN network functions may be hosted on a cloud as 'pure' software services. This shall enable the service providers to replace (e.g., swap) these functions much faster compared to functions that require special-built hardware, and to select the different functions from different vendors.

From operations and management point of view, these disaggregated functions should expose own management interfaces, in order to allow for individual management of each entity.

However, all these efforts of splitting the network element/node would lead to strongly disaggregated functions of the radio access network, where these functions could be independently developed by different vendors and might be managed by dedicated management tools. Nevertheless, the service provider or operator may still have the challenge to manage the overall network. Instead of managing (aggregated) network elements, each with a single management interface and each provided by one vendor, the operator would face disaggregated, smaller elementary functions, potentially each provided by different vendors with different concepts for the management, yet all depending on each other.

Broadly speaking, in order to analyze critical problems and failures, the network elements are able to collect so called symptom data that may comprise (but is not limited to) log files, low- level status of the applications, configurations, core dump, etc. Typically, the network elements may collect symptom data autonomously in case of a critical fault. Then, the network elements may upload these data to the management systems, where experts or analytics applications can analyze the problems in detail. On one hand, the symptom data must mirror the system status (sometimes also referred to as a "snapshot") during the failure as close as possible. Therefore, the corresponding data must be collected before any corrective action like a (autonomous) restart may have changed the status. On the other hand, the resulting data files may typically be very big and cannot be stored for longer periods on the network elements. Therefore, collection and storage of this data must happen on demand after a failure. In other words, ahead collection on regular basis is generally not possible.

For this analysis, it is important to receive the symptom data of all entities that are involved, e.g., in the set of ongoing calls during the failure/problem to capture all dependencies. In classical deployment where all elementary functions are provided by one vendor as one (aggregated) network function on one piece of hardware, it is possible to collect these symptom data from all involved functions. However, once the functions of the RAN are disaggregated to run on multiple processing units and/or to be provided by different vendors, this may not be easily achievable. As a result, the service provider operator will not get the full context of a problem, but only the part of the symptom data in the elementary function that experienced the problem may be available.

Figure 2 schematically illustrates an example of a flow chart of symptom data collection according to an embodiment of the present disclosure.

Broadly speaking, the present disclosure presents a simple and efficient mechanism allowing recording and collecting symptom data in a synchronized manner from an elementary network function exhibiting a problem and all its related network functions, so as to allow comprehensive analysis of the context in which the problem occurred. In particular, the mechanism consists of a basic and efficient interface between the elementary functions of a disaggregated RAN or core network element. Notably, the basic and efficient mechanism enables the elementary functions to inform each other (e.g., by sending a message) that one of them has experienced a critical problem and that, as a consequence, the recipients of the message shall trigger collection of symptom data, too. In Figure 2, a trigger message 'CollectSymptoms(ID)' is sent to the DUs (DU1, DU2). No message is sent directly from CU-UP (where the fault occurs) to the RU, but rather does DU1 send a message to the RU (since DU1 and RU interface with each other, see Figure 1). In general, each elementary function that experiences a fault will trigger its direct 'neighbours', i.e. the network functions it interfaces with. Upon completion of symptom data collection, the elementary functions may inform a 'Collector' of the data (e.g. by sending a message 'LogsReady(ID)') that the symptom data is ready for retrieval.

In this example, the scope of 'propagation' of the symptom data collection trigger is limited to one network element or 'node' such as the disaggregated base station 120 shown in figure 1. In the case of 5G RAN this is a 5gNB. Such a 5gNB can be disaggregated into hundreds of elementary functions. There will be one RIC and one CU-CP per 5gNB but all other elementary functions can be instantiated many times. In this example, distribution of trigger messages is limited to one 5gNB. It is not proposed to 'spread' the collection triggers across the boundaries of a 5gNB. In other scenarios, it could make sense to distribute the triggers even broader to other network elements.

Particularly, for each triggering event (e.g., a specific fault), the concerned elementary function may generate a unique signature (or identifier) associated with the triggering event, and shall add this signature/identifier to the collected symptom data and possibly also to a trigger message that it sends to inform other related (neighboring) elementary functions. 'Related' means that the elementary functions interface with each other directly according to the functional architecture and its interfaces e.g. shown in Figure 1.

Subsequently, elementary functions that receive the trigger message should collect respective symptom data, add the received unique signature/identifier to the collected symptom data, prepare a trigger message that includes the received unique signature/identifier, and send this message to other related (neighboring) elementary function(s) to trigger it/them to further collect symptom data too. Configured as such, i.e., by using the same signature/identifier in all involved elementary functions, it may enable a correlation of the data collected by different network functions with the (same) initial trigger. Particularly, such unique signature/identifier might consist of e.g. a timestamp and some unique identification created by the elementary function exhibiting the problem. Of course, any other suitable information may be included in the unique signature/identifier, in order to further facilitating analyzing and resolving the problems. By way of example but not limitation, a network identifier (such as an IP address) of the elementary function where the fault is found may be further comprised in the signature. This may help to make the signature unique.

In general, if an elementary function receives a trigger message to collect symptom data, it shall collect the requested data and inform its management system about the availability of the data. Depending on the configuration (of the elementary function and/or the management system) and the content of the message, the elementary function may either store the symptom data until the management system uploads it, until the data expires, or until the entity has uploaded the data to the requested or configured location, as will be clearly understood and appreciated by the skilled person.

By using these trigger messages, all related elementary functions may inform each other to collect symptom data. Also, all elementary functions can add the same unique signature/identifier to the collected symptom data, in order to enable the evaluating tools to correlate all incoming symptom data to the triggering event/fault. Generally speaking, correlation of symptom data (e.g., log files) may require the network functions to be time synchronized. The reason is mainly that in the present disclosure the symptom data may be collected in all elementary functions under a single context (i.e., the signature).

Correspondingly, the evaluation of for example logged (and time stamped) events and their end to end re-constitution (temporal sequence of events across the functions) would then require timely synchronization.

Now referring back to Figure 2, in the shown example, there is provided a collector 201 acting as a kind of management system/functionality where all the symptom data collected by various elementary functions is uploaded (or sent). The collector may be implemented in any suitable manner, as will be appreciated by the skilled person. Further, there is provided a CU-CP 202, a CU-UP 203, a first DU1 204, a second DU2 205 and an RU 206. The CU-CP 202, the CU-UP 203, the first and second DUs 204, 205 and the RU 206 may be analogous or similar to the CU-CP 122-1, CU-UP unit 122-2, DU 124 and RU 125, respectively. Notably, only two DUs 204, 205 and one RU 206 are shown in the example of Figure 2, however, it should be apparent to the skilled person that other numbers of DUs and/or RUs may be present in the disaggregated network element, as illustrated above.

In block 210, it is determined that a fault has been detected in the CU-UP 203. The determination may be based on detection of an internal fault occurred in the CU-UP 203 itself, or alternatively, based on an external (or manual) trigger received from another elementary function (e.g., the CU-CP 202).

Upon detection of the fault (whether internal or external), the CU-UP 203 is configured to collect symptom data and to generate a unique signature (not shown in Figure 2) related to the detected fault. In particular, the signature may be generated in any suitable manner such that the fault may be individually identifiable by the generated signature. For instance, a signature may comprise a unique identification (ID) that has a one-to-one relationship with a respective fault (or, in some cases, a group of faults).

Once such signature is generated, the CU-UP 203 sends a respective trigger message to each one of the related neighboring elementary functions. Generally speaking, a related neighboring elementary function may be an elementary function that has a (direct) interface towards the elementary function where the fault is detected. Such interface may for example be any one of the interfaces 122-5, 126, 127, and 128 internal to the disaggregate network element as shown in Figure 1. In other words, the related neighboring elementary functions may be limited to those within the same disaggregate network element (e.g., the disaggregated base station 120 in Figure 1), without crossing the boundary of a single disaggregate network element. However, in some cases, crossing the boundary of a single disaggregate network element for collecting the symptom data may be possible (or may even be desirable).

Thus, in the present example of Figure 2, the CU-UP 203 may send a trigger message 220 to the CU-CP 202, a trigger message 230 to the first DU1 204, and a trigger message 240 to the second DU2 205. The first DU1 204 then sends a trigger message 250 to the RU 206 so that all elementary functions have received a trigger message. Alternatively, DU2 could have sent a trigger message 250 to the RU 206. As explained above, each of the trigger messages 220 - 250 comprises the same generated signature.

In some cases, the trigger messages 220, 230, 240 and 250 may be sent over existing interfaces (e.g., the interfaces 122-5, 126, 127, and 128 as shown in Figure 1). For this purpose, these interfaces may need to be enhanced, e.g., to support new data structure, etc., as will be appreciated by the skilled person. In some other cases, new (dedicated) interfaces may need to be defined to accommodate these trigger messages 220, 230, 240 and 250.

Once the symptom data has been collected, the respective elementary functions, i.e., the CU-CP 202, the CU-UP 203, the first DU 204, the second DU 205 and the RU 206 may, for example upon request by the collector 201, send the collected symptom data to the collector respectively in messages 260, 270, 280 and 290, for further processing. Alternatively, the collector may be informed of the collected symptom data and initiate an upload of the symptom data. In consequence, symptom data of all elementary functions of the network element are available at the collector for analysis and problem correction.

Notably, since the elementary functions of a disaggregated network node might span a network by their own, and because any of them might act as initial trigger to other elementary functions, the proposed mechanism should offer a possibility for the receiving elementary function to identify multiple triggers for the same incident and to ignore these duplicate triggers to avoid possible avalanches, e.g. to avoid the following scenario:

• CU-UP detects a severe problem and triggers collection of symptom data;

• CU-UP sends a trigger to DU=1 and to CU-CP to collect symptom data;

• DU=1 and CU-CP receive the trigger, start to collect symptom data, and send triggers to CU-UP and amongst each other to inform them about the problem;

• The above activities continue until the system gets saturated with messages. Figure 3 schematically illustrates an example of a flow chart of a ping-pong scenario of triggers. In particular, it is to be noted that identical or like reference numbers in Figure 3 indicate identical or like elements in the example as shown in Figure 2, such that repeated description thereof may be omitted for reasons of conciseness.

In the example of Figure 3, the CU-UP 303 detects a severe problem in block 310 and subsequently triggers collection of symptom data, by sending a trigger message 320 to the CU- CP 302 and a trigger message 330 to the first DU 304.

Upon reception of the respective trigger messages 320, the CU-CP 302 starts to collect its symptom data, and then sends a trigger 321 to the CU-UP 303 (and possibly also to other elementary functions, not shown in Figure 3) to inform it/them about the problem. Similar transmission/reception of trigger messages also happens between the CU-UP 303 and the first DU 304 (i.e., messages 323 and 324).

Such ping-pong of trigger messages may go on and on, until unfortunately the whole system may get saturated with messages and symptom data collection.

In order to suppress the endless ping-pongs of triggers, the elementary functions may be configured to e.g. ignore triggers with known unique signature/identifier that have been received and processed before. An example of a flow chart of avoiding ping-pong triggers according to an embodiment of the present disclosure is shown in Figure 4. It is to be noted that identical or like reference numbers in Figure 4 indicate identical or like elements in the example as shown in Figure 2 or Figure 3, such that repeated description thereof may be omitted for reasons of conciseness.

In particular, as shown in the example of Figure 4, the system still would send potentially unnecessary messages 421 and 431 amongst the elementary functions. But, since each elementary function/entity would be able to detect known signature or identification as duplicates, these unnecessary messages would be ignored in blocks 422 and 432 and thus would not cause an undesirable message avalanche (which may even render the whole system inoperable).

Notably, as can be clearly understood and appreciated by the skilled person, whether a message in a specific (fault) situation really is unnecessary might depend on the availability of links in this specific situation. That is to say, in some cases, a severe fault of an entity might already render some links unavailable. For example, an inoperable link may prevent transmission of a trigger message from a first elementary function experiencing a fault to a normally related neighboring second elementary function. A trigger message may however be received by another elementary function that has a functioning link to the second elementary function so that the another elementary function can send a trigger message to the second elementary function. In this case, this will be the first arriving trigger message for this particular fault as can be determined by the signature/identifier associated with the fault. The disclosed example embodiments can be implemented in many ways using hardware and/or software configurations. For example, the disclosed embodiments may be implemented using dedicated hardware and/or hardware in association with software executable thereon. The components and/or elements in the figures are examples only and do not limit the scope of use or functionality of any hardware, software in combination with hardware, firmware, embedded logic component, or a combination of two or more such components implementing particular embodiments of this disclosure.

It should further be noted that the description and drawings merely illustrate the principles of the present disclosure. Those skilled in the art will be able to implement various arrangements that, although not explicitly described or shown herein, embody the principles of the present disclosure and are included within its spirit and scope. Furthermore, all examples and embodiment outlined in the present disclosure are principally intended expressly to be only for explanatory purposes to help the reader in understanding the principles of the proposed method. Furthermore, all statements herein providing principles, aspects, and embodiments of the present disclosure, as well as specific examples thereof, are intended to encompass equivalents thereof.

List of abbreviations

BTS: Base Tranceiver Station

CU: Central Unit of a cloud BTS, responsible for not so latency critical functions.

CU-CP: Part of a Central Unit that is responsible for handling the Control Plane.

CU-UP:Part of a Central Unit that is responsible for handling the User Plane.

DU: Distributed Unit of a cloud BTS, responsible to handle latency-critical functions.

RU: Radio Unit of a BTS, responsible to convert between digital signals from/towards the DU and the analog signals from/towards the mobile stations via the air interface.

Claims

Claims:

1. A method of collecting symptom data for at least one elementary function in a disaggregated network element, the method comprising: monitoring the elementary function for faults; and if a fault is detected in an elementary function: triggering the elementary function to collect symptom data related to the detected fault; generating a signature based on the detected fault; and sending a trigger message including the generated signature to at least one related neighboring elementary function for triggering further collection of symptom data of the at least one related neighboring elementary function.

2. The method according to claim 1, wherein the symptom data comprises information for facilitating analysis of the fault.

3. The method according to claim 1 or 2, wherein the symptom data comprises at least one of: a core dump, a log file, low-level status information of applications related to the fault, data stored in one or more registers, or a configuration.

4. The method according to any one of the preceding claims, wherein a related neighboring elementary function is an elementary function that has an interface towards the elementary function having the fault.

5. The method according to any one of the preceding claims, wherein a related neighboring elementary function is located in the disaggregated network element.

6. The method according to any one of the preceding claims, wherein the signature is generated in such a manner that the fault is individually identifiable by the generated signature.

7. The method according to any one of the preceding claims, wherein the signature comprises a unique identification associated with the fault.

8. The method according to any one of the preceding claims, wherein the signature further comprises a timestamp associated with the fault.

9. The method according to any one of the preceding claims, wherein the trigger message further comprises information indicative of the symptom data to be collected.

10. The method according to any one of the preceding claims, wherein the trigger message further comprises information identifying the at least one related neighboring elementary function to collect the symptom data.

11. The method according to any one of the preceding claims, wherein the elementary function to collect the symptom data is triggered by one or more predefined fault conditions.

12. The method according to any one of the preceding claims, further comprising: informing a management function about availability of the symptom data collected by the elementary function.

13. The method according to any one of the preceding claims, further comprising: providing the symptom data collected by the elementary function to at least one of: a management function, a location requested by the management function, or a preconfigured location.

14. The method according to any one of the preceding claims, further comprising: for a second elementary function of the at least one related neighboring elementary function at which the trigger message including the signature is received: triggering the second elementary function to collect symptom data in accordance with the detected fault; and sending a further trigger message including the received signature to at least one further related neighboring elementary function for triggering further collection of symptom data of the at least one further related neighboring elementary function.

15. A method of collecting symptom data for at least one elementary function in a disaggregated network element, the method comprising: receiving, at an elementary function of the disaggregated network element, a trigger message including a signature from another elementary function, wherein the signature is generated based on a fault detected by one elementary function; in response to receiving the trigger message, triggering the elementary function to collect symptom data in accordance with the fault; and sending a further trigger message including the received signature to at least one related neighboring elementary function for triggering further collection of symptom data of the at least one related neighboring elementary function.

16. The method according to claim 15, further comprising: prior to triggering the elementary function to collect the symptom data, determining whether the signature has been received before; and if it is determined that the signature has been received before: ignoring the received trigger message by not triggering the elementary function to collect the symptom data and not sending the further trigger message.

17. An elementary function of a disaggregated network element, the elementary function comprising: means for monitoring for faults in the elementary function; and if a fault is detected by the elementary function: means for collecting symptom data related to the detected fault; means for generating a signature based on the detected fault; and means for sending a trigger message including the generated signature to at least one related neighboring elementary function for triggering further collection of symptom data of the at least one related neighboring elementary function.

18. An elementary function of a disaggregated network element, the elementary function comprising: means for receiving a trigger message including a signature from another elementary function, wherein the signature is generated based on a fault detected by one elementary function; means for collecting symptom data in accordance with the fault; and means for sending a further trigger message including the received signature to at least one related neighboring elementary function for triggering further collection of symptom data of the at least one related neighboring elementary function.

19. A disaggregated network element, comprising at least one elementary function according to any one of claims 16 to 18.

20. A non-transitory computer readable medium comprising program instructions for causing an elementary function of a disaggregated network element at least to perform: monitoring for faults in the elementary function; and if a fault is detected by the elementary function: collecting symptom data related to the detected fault; generating a signature based on the detected fault; and sending a trigger message including the generated signature to at least one related neighboring elementary function for triggering further collection of symptom data of the at least one related neighboring elementary function.