Patent Description:
Document <CIT> discloses several stream processing methods adapted to transform a data stream into a structured data stream and/or to compress the data stream.

The example embodiments and/or features, if any, described in this specification that do not fall under the scope of the independent claims are to be interpreted as examples useful for understanding various embodiments.

Example embodiments will become more fully understood from the detailed description given herein below and the accompanying drawings, wherein like elements are represented by like reference numerals, which are given by way of illustration only and thus are not limiting of this disclosure.

Detailed illustrative embodiments are disclosed herein. However, specific structural and functional details disclosed herein are merely representative for purposes of describing example embodiments.

Network logs are available at network nodes and may be sent to a network controller for processing and analysis. However, conventional network logs are relatively large in size, and conventional network log analysis techniques are not adapted for control plane operation in latency-sensitive <NUM>th Generation (<NUM>) edge-cloud technology. Additionally, network log analysis techniques may be relatively computation intensive.

One or more example embodiments provide a pattern-based mini-log creation method for distributed network log size reduction and/or distributed control plane architecture for using mini-logs to build an intelligent light-weight control plane.

One or more example embodiments may reduce network log size, which may reduce latency, storage and/or processing requirements of a network control plane.

One or more example embodiments may also enable the creation of scalable, intelligent and/or light-weight control plane, with applications in <NUM> telecommunications systems.

One or more example embodiments are based on the observation that textual network logs have different repetitive patterns, each of which is indicative of particular feedback information from a network node. According to one or more example embodiments, instances of patterns may be identified and substituted with one or more numerical values to generate mini-logs (also referred to herein as reduced size network logs or reduced size textual network logs). The mini-logs may be <NUM>-<NUM>% smaller than the larger, conventional network logs.

According to at least one example embodiment, a network node may transform a network log into a mini-log using a data series transformation. The most general data series example is "time-series" data. However, example embodiments may utilize what is referred to as "event-order series" because multiple events may occur concurrently or simultaneously. As a result, a network node may transform the lines of code (of an event record) having the pattern to one or more numerical values event-by-event according to the order of events in the network log.

Furthermore, network logs are initially available locally and not at the network controller. Thus, according to one or more example embodiments network logs are processed to generate mini-logs locally at the network node to enable the creation of a more efficient "light-weight" control plane and/or conserve bandwidth in the network.

As discussed in more detail later, according to at least one example embodiment, a network log may be transformed into a mini-log by pre-processing the network log (e.g., sampling, denoising, etc.) and then processing/transforming the network log according to one or more algorithms (algorithm can be single or mixed), such as a data series transformation.

One or more example embodiments discussed herein may be performed iteratively.

As discussed herein, a pattern refers to log entry or entries (lines of code) having an identifiable format and/or text. In one example, a pattern may refer to a sequence of integer character counts for a plurality of consecutive lines of code in a textual network log.

<FIG> illustrates an intelligent light-weight control plane architecture according to example embodiments.

Referring to <FIG>, the control plane architecture includes light-weight intelligent network controller (LINC) <NUM> and a plurality of network nodes <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>,.

The LINC <NUM> is a logically centralized network controller including functionality for machine learning processing of mini logs (MLML) <NUM> in addition to functionality of conventional network controllers. The LINC <NUM> also includes control functions <NUM>-<NUM>,.

The MLML <NUM> may be implemented in hardware and/or software at the LINC <NUM>. As discussed later, the MLML <NUM> may update parameters for one or more of one or more control functions <NUM>-<NUM>,. , <NUM>-n based on mini-logs <NUM> from network nodes <NUM>-<NUM>, <NUM>-<NUM>,. , <NUM>-m, which may improve the control functions <NUM>-<NUM>,. <NUM>-n present at the LINC <NUM>.

The MLML <NUM> receives the mini-logs <NUM> from one or more of the network nodes <NUM>-<NUM>, <NUM>-<NUM>,. , <NUM>-m and enables intelligent use of information provided by the mini-logs <NUM> to, for example, update parameters for the control functions <NUM>-<NUM>,.

Control functions <NUM>-<NUM>,. <NUM>-n may assist with, for example, traffic classification, routing optimization, Quality of Service (QoS)/Quality of Experience (QoE) prediction, resource management and security, or the like. The control functions <NUM>-<NUM>,. , <NUM>-n may send new or updated configuration parameters to a set of the network nodes <NUM>-<NUM>,. The set of network nodes may execute the actions requested by the LINC <NUM>, which may result in creation of new or updated network logs.

Each of the network nodes <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>,. , <NUM>-m includes a function for local processing of logs (FLPL) <NUM>.

The FLPL <NUM> may be implemented in hardware and/or software at a network node. The FLPL <NUM> processes network logs (e.g., by applying pattern-based reduction algorithms) to generate mini-logs, and sends the mini-logs to the MLML <NUM> at the LINC <NUM>. The FLPL <NUM> may also include a database of network logs generated at the network node, and a data structure (e.g., a look up table (LUT)) storing configuration parameters received from the LINC <NUM> (e.g., during one or more LINC cycles).

According to one or more example embodiments, the textual network logs are text files and may be archived by "zipping" old(er) logs. A database is not required for log processing, however, the log processing framework (e.g., ELK stack) may be an independent system, which may collect the network logs from different nodes and process the collected network logs them in a centralized way for more advanced log processing (e.g., indexing logs, map reducing, storing in databases, etc.).

A similar principle applies with regard to processing of mini-logs. The FLPL <NUM> may convert the textual network logs to numeric values, and then send the mini-logs to the control plane (e.g., LINC <NUM>). The control plane may provide the mini-log processing functions such as pattern searching, machine learning, storing in databases, etc. In this case, the FLPL <NUM> need not include a database.

The MLML <NUM> reads the mini-logs and applies machine learning techniques to the mini-logs to generate conclusions. The MLML <NUM> (or LINC <NUM>) informs the control functions <NUM>-<NUM>,. , <NUM>-n about the machine learning conclusions. The control functions <NUM>-<NUM>,. , <NUM>-n make further decisions regarding the network nodes based on the conclusions.

<FIG> illustrates a network log to assist in explaining example embodiments.

Referring to <FIG>, a network log may include millions of lines of code. As mentioned above, within the lines of code in the network log, different repetitive patterns are indicative of particular feedback information from the network node. This feedback information is also referred to as event records or events. The event records may include network functions such as an indication that a FPGA is successfully installed, a FPGA is out of memory, etc. As discussed in more detail below, the FLPL <NUM> may parse the network logs to identify identified patterns within the network log, and replace the identified patterns with one or more numerical values (e.g., on an event-by-event basis) to reduce the size of the network logs and generate the mini-logs.

Network log entries generally follow the format of Log Head + Log Body.

The Log Head has the format of timestamp, hostname, module name, line number and log level. An example of a portion of a Log Head in OpenStack is shown below. mai <NUM><NUM>:<NUM>:<NUM> nuc4 neutron-openvswitch-agent[<NUM>]: DEBUG.

In this example, mai <NUM> <NUM>:<NUM>:<NUM> is the timestamp, nuc4 is the hostname, neutron-openvswitch-agent is the module name, [<NUM>] is the line number of the network log, and DEBUG is the log level.

The Log Body includes message text with variable parameters. The variables identify the event (e.g., PID, uuid, amount, etc.). Despite the fact that variable length may change, the message text on a given line of the Log Body still falls within a threshold range. The difference in length caused by variables may be considered as "variance" according to one or more example embodiments. As discussed in more detail later, in the case of message text with variance for a given line, the length may be represented by a range of values.

An example of a uuid line of the Log Body is shown below. mai <NUM><NUM>:<NUM>:<NUM> nuc4 neutron-openvswitch-agent[<NUM>]: <uuid>6ece0ff6-33c3-43eO-8f93-bbf02740cOda </ uuid>.

In this example, uuid is a variable, but the length of this entry is the same in this OpenStack example regardless of the value of the individual characters.

An example of a line of the Log Body including instance name is shown below. In this example, the instance name is a variable with a length that may vary. Thus, this line may have "variance," and be represented by a range of values. mai <NUM><NUM>:<NUM>:<NUM> nuc4 neutron-openvswitch-agent[<NUM>]: <name>instance-0000006c</name>.

The above-noted example is provided for example purposes. The network log format implementation may differ for different network log framework and configuration. For example, the hostname, module name or line numbers may all be configurable. The control plane may be aware of the format of the network logs and may adapt the corresponding pattern to process the mini-logs.

<FIG> is a flow chart illustrating a method according to example embodiments. The method shown in <FIG> will be discussed with regard to the architecture shown in <FIG> for example purposes. In so doing, the example embodiment shown in <FIG> will be discussed with regard to the LINC <NUM> and the network node <NUM>-<NUM>. The method shown in <FIG> may be performed with regard to a set of network nodes, wherein the set of network nodes may include any number of network nodes.

The example embodiment shown in <FIG> will, in most cases, be described with regard to operations performed by the FLPL <NUM> and the MLML <NUM>. Example embodiments may also be described with regard to the functions performed by the LINC <NUM> and the network node <NUM>-<NUM>.

For simplicity, the example embodiment shown in <FIG> will be discussed with regard to a single network log and generating a mini-log based on the network log. The method shown in <FIG> may be applied to any number of network logs.

Referring to <FIG>, at the start of a LINC cycle of duration T (step S302), the LINC <NUM> sends new or updated configuration parameters to the network node <NUM>-<NUM> at step S304.

The LINC cycle duration T is the execution time for generating and analyzing one or more mini-logs. The duration T may be determined by the LINC <NUM> depending on requirements from subscribed (or deployed) control functions (e.g., control functions <NUM>-<NUM>,. , <NUM>-n) as well as the network nodes (e.g., in communication with the LINC <NUM>). In one example, for 5th Generation (<NUM>) Radio Access Networks (RANs), the duration T may be within the scheduling period (e.g., about <NUM>).

The configuration parameters are parameters for configuring the FLPL <NUM> to generate mini-logs. In one example, the configuration parameters configure the FLPL <NUM> with typical patterns within the network log and the corresponding numerical value(s) to be substituted (e.g., written or entered in place of) for the pattern in the network log. For example, the configuration parameters may include an identifiable format for a given event record in the form of an ordered pattern of one or more numerical values. The ordered pattern corresponds to ordered character counts of lines (e.g., consecutive lines) of code within the network log. In at least some example embodiments, the ordered pattern may correspond to ordered character counts of lines of code constituting an event record.

For example, a pattern Pattern_X for an event record Event_X may be associated with an ordered pattern [x<NUM>, x<NUM>, x<NUM>,. xN], wherein N is number of values in the pattern and corresponds to the number of (consecutive) lines of code in the pattern Pattern_X. Each value in the pattern (or data series) represents an integer character count of a respective line (e.g., first line, second line, third line,. , Nth line) of the pattern.

In a more specific example, a pattern for an event record having <NUM> lines without variance may be [<NUM>, <NUM>, <NUM>, <NUM>, <NUM>], wherein each number in the pattern represents a character count of a respective line of the event record.

As mentioned above, character counts for lines of an event record may be arranged as a pattern with or without variance. In an example with variance, a pattern for an event record having N lines of code may be [(y<NUM>, z<NUM>), [y<NUM>, z<NUM>), (y<NUM>, z<NUM>),. , (yN, zN)]. Each set of numbers in parentheses represents a range of integer or decimal values for the character count in the respective line.

In a more specific example with variance, a pattern for an event record having <NUM> lines of code with variance may be [(<NUM>, <NUM>), [<NUM>, <NUM>), (<NUM>, <NUM>), (<NUM>, <NUM>), (<NUM>, <NUM>)]. In this instance, the pattern indicates that the first line of code has a character count between <NUM> and <NUM>, the second line of code has a character count between <NUM> and <NUM>, and so on.

The configuration parameters may also instruct the FLPL <NUM> with regard to how to update the local database (e.g., frequency of updates, etc.) at the FLPL <NUM>. In one example, the configuration parameters may be provided in the form of, and stored at the network node <NUM>-<NUM> as, one or more LUTs. The configuration parameters may also be stored at the LINC <NUM> in one or more LUTs. The configuration parameters may include (i) patterns (or data series) or (ii) patterns and their associated event records, which may be stored at the FLPL <NUM>.

Still referring to <FIG>, in response to receiving the configuration parameters, at step S308 the network node <NUM>-<NUM> determines whether there are any new or updated network logs available. As discussed above, when the control functions <NUM>-<NUM>,. , <NUM>-n send new or updated configuration parameters to a set of the network nodes <NUM>-<NUM>,. , <NUM>-m, the set of network nodes may execute the requested actions, which may result in creation of new or updated network logs. Thus, the network node <NUM>-<NUM> may have new or updated network logs available after having received and executed actions requested by the control functions <NUM>-<NUM>,.

If there are no new or updated network logs available, then the process returns to step S302 and continues as discussed herein for the next LINC cycle.

Returning to step S308, if one or more new or updated network logs are available at the network node <NUM>-<NUM>, then at step S310 the network node <NUM>-<NUM> updates the FLPL database with the new network log information.

At step S312, the FLPL <NUM> at the network node <NUM>-<NUM> generates a mini-log based on the new or updated network log and the configuration parameters received from the MLML <NUM>. As discussed in more detail below, the FLPL <NUM> may generate the mini-log by identifying instances of one or more patterns within the network log and replacing the identified patterns with the one or more numerical values (e.g., in the ordered data series) included in the configuration parameters.

<FIG> is a flow chart illustrating a method for generating mini-logs according to example embodiments. The example embodiment shown in <FIG> will be described with regard to instances of a single pattern without variance for example purposes. The FLPL <NUM> may parse any number of network logs to identify instances of any number of patterns with or without variance concurrently or simultaneously.

Referring to <FIG>, at step S410, the FLPL <NUM> parses the network log to identify instances of the pattern in the network log based on the configuration parameters provided at step S304.

Referring back to the above-discussed example in which the pattern is [<NUM>, <NUM>, <NUM>, <NUM>, <NUM>], in this example the FLPL <NUM> parses the network log to identify instances of consecutive lines of code (e.g., constituting an event record) in the network log having the respective values in the order noted in the pattern.

Once the FLPL <NUM> identifies instances of the pattern, at step S412 the FLPL <NUM> replaces or substitutes the consecutive lines of code having the pattern of numerical values with the one or more numerical values in the pattern (as identified in the configuration parameters sent at step S304) in the network log.

In the example discussed above with regard to step S410, once the FLPL <NUM> identifies instances of the pattern, at step S412 the FLPL <NUM> replaces or substitutes the numerical values [<NUM>, <NUM>, <NUM>, <NUM>, <NUM>] for the corresponding lines of code constituting the instances of the pattern.

The steps shown in <FIG> may be performed iteratively, concurrently or simultaneously to replace each instance of each provided pattern in the network log to generate the mini-log.

At step S314, the network node <NUM>-<NUM> sends the generated mini-log to the LINC <NUM> (e.g., using control signaling).

At step S318, the MLML <NUM> generates conclusions based on the received mini-logs.

According to one or more example embodiments, the MLML <NUM> does not convert the mini-logs back to the original, textual network logs. Rather, the MLML <NUM> interprets or deciphers the mini-logs, and the substituted numerical values included therein, based on the configuration parameters, which are known at the MLML <NUM>, to identify the corresponding event record, which may be used to generate the conclusions. Thus, the MLML <NUM> may generate the conclusions directly from the mini-logs without conversion.

According to one or more example embodiments, the MLML <NUM> may generate the conclusions by applying machine learning techniques based on the content of the mini-logs.

According to one or more example embodiments, when the MLML <NUM> receives the mini-logs from the FLPL <NUM>, the MLML <NUM> begins a machine learning approach to log analytics, including supervised or unsupervised learning. For example, the MLML <NUM> may utilize the data series pattern to label the mini-logs. Once the mini-logs are labeled, the MLML <NUM> may construct a mini-log classifier. The MLML <NUM> may perform classification in any suitable manner (e.g., Support Vector Machines (SVM), Random Forests, etc.). Once the classifier is trained, the MLML <NUM> may predict one or more events and/or generate one or more conclusions based on the trained classifier and the most recent mini-logs sent by the FLPL <NUM>.

The conclusions may include new parameters used to improve and/or optimize the control functions at the LINC <NUM> (e.g., new flow rules for improving Quality of Service (QoS) and/or Quality of Experience (QoE) for users connected to the network. In another example, for mobile networks, the conclusions may include various radio configurations, resource allocation decisions, configuration related to network slicing, etc..

At step S320, the MLML <NUM> determines whether new or updated conclusions are available. In the case of new or updated parameters for the control functions <NUM>-<NUM>,. , <NUM>-n at the LINC <NUM>, for example, the MLML <NUM> may determine whether new or updated conclusions are available based on a comparison between current parameters and parameters generated at step S318.

If new or updated conclusions are not available, then the process returns to step S302 and continues as discussed herein.

Returning to step S320, if new or updated conclusions are available, then at step S322 the MLML <NUM> outputs the new or updated conclusions to the respective control functions <NUM>-<NUM>,. <NUM>-n and/or network nodes <NUM>-<NUM>,. , <NUM>-m as needed, for configuring or controlling the network. The control functions <NUM>-<NUM>,. , <NUM>-n and/or the network nodes, <NUM>-<NUM>,. , <NUM>-m may then configure and/or control the network accordingly in any suitable manner.

The process then returns to step S302 and continues as discussed herein.

<FIG> illustrates an example embodiment of a network node. The network node shown in <FIG> may serve as one or more of the network nodes <NUM>-<NUM>,. , <NUM>-m shown in <FIG>. The network node may also be referred to as a network apparatus or network device. Although discussed with regard to a network node, the structure shown in <FIG> may also serve as the LINC <NUM>.

As shown, the network node <NUM> includes: a memory <NUM>; a processor <NUM> connected to the memory <NUM>; various interfaces <NUM> connected to the processor <NUM>; and one or more antennas or antenna panels <NUM> connected to the various interfaces <NUM>. The various interfaces <NUM> and/or the antenna <NUM> may constitute a transceiver for transmitting/receiving data from/to other network nodes and/or LANs via a wired or wireless links. As will be appreciated, depending on the implementation of the network node <NUM>, the network node <NUM> may include many more components than those shown in <FIG>. However, it is not necessary that all of these generally conventional components be shown in order to disclose the illustrative example embodiment.

The memory <NUM> may be a computer readable storage medium that generally includes a random access memory (RAM), read only memory (ROM), and/or a permanent mass storage device, such as a disk drive. The memory <NUM> also stores an operating system and any other routines/modules/applications for providing the functionalities of the network node <NUM> (e.g., functionalities of a network node, such as a server, a router, a switch, component or element of a <NUM>th Generation telecommunications network, etc., methods according to the example embodiments, etc.) to be executed by the processor <NUM>. These software components may also be loaded from a separate computer readable storage medium into the memory <NUM> using a drive mechanism (not shown). Such separate computer readable storage medium may include a disc, tape, DVD/CD-ROM drive, memory card, or other like computer readable storage medium (not shown). In some example embodiments, software components may be loaded into the memory <NUM> via one of the various interfaces <NUM>, rather than via a computer readable storage medium.

The processor <NUM> may be configured to carry out instructions of a computer program by performing the arithmetical, logical, and input/output operations of the system. Instructions may be provided to the processor <NUM> by the memory <NUM>.

The various interfaces <NUM> may include components that interface the processor <NUM> with the antenna <NUM>, or other input/output components. As will be understood, the various interfaces <NUM> and programs stored in the memory <NUM> to set forth the special purpose functionalities of the network node <NUM> will vary depending on the implementation of the network node <NUM>.

The interfaces <NUM> may also include one or more user input devices (e.g., a keyboard, a keypad, a mouse, or the like) and user output devices (e.g., a display, a speaker, or the like).

As discussed herein, illustrative embodiments will be described with reference to acts and symbolic representations of operations (e.g., in the form of flow charts, flow diagrams, data flow diagrams, structure diagrams, block diagrams, etc.) that may be implemented as program modules or functional processes include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types and may be implemented using existing hardware at, for example, existing network nodes, network controllers, network apparatuses, elements or entities including routers, switches, components or elements of <NUM>th Generation telecommunications networks, cloud-based data centers, computers, cloud-based servers, or the like. Such existing hardware may be processing or control circuitry such as, but not limited to, one or more processors, one or more Central Processing Units (CPUs), one or more controllers, one or more arithmetic logic units (ALUs), one or more digital signal processors (DSPs), one or more microcomputers, one or more field programmable gate arrays (FPGAs), one or more System-on-Chips (SoCs), one or more programmable logic units (PLUs), one or more microprocessors, one or more Application Specific Integrated Circuits (ASICs), or any other device or devices capable of responding to and executing instructions in a defined manner.

As disclosed herein, the term "storage medium," "computer readable storage medium" or "non-transitory computer readable storage medium" may represent one or more devices for storing data, including read only memory (ROM), random access memory (RAM), magnetic RAM, core memory, magnetic disk storage mediums, optical storage mediums, flash memory devices and/or other tangible machine-readable mediums for storing information. The term "computer-readable medium" may include, but is not limited to, portable or fixed storage devices, optical storage devices, and various other mediums capable of storing, containing or carrying instruction(s) and/or data.

Furthermore, example embodiments may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine or computer readable medium such as a computer readable storage medium. When implemented in software, a processor or processors will perform the necessary tasks. For example, as mentioned above, according to one or more example embodiments, at least one memory may include or store computer program code, and the at least one memory and the computer program code may be configured to, with at least one processor, cause a network node, network controller, network apparatus, network element or network device to perform the necessary tasks. Additionally, the processor, memory and example algorithms, encoded as computer program code, serve as means for providing or causing performance of operations discussed herein.

A code segment of computer program code may represent a procedure, function, subprogram, program, routine, subroutine, module, software package, class, or any combination of instructions, data structures or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable technique including memory sharing, message passing, token passing, network transmission, etc..

The terms "including" and/or "having," as used herein, are defined as comprising (i.e., open language). The term "coupled," as used herein, is defined as connected, although not necessarily directly, and not necessarily mechanically. Terminology derived from the word "indicating" (e.g., "indicates" and "indication") is intended to encompass all the various techniques available for communicating or referencing the object/information being indicated. Some, but not all, examples of techniques available for communicating or referencing the object/information being indicated include the conveyance of the object/information being indicated, the conveyance of an identifier of the object/information being indicated, the conveyance of information used to generate the object/information being indicated, the conveyance of some part or portion of the object/information being indicated, the conveyance of some derivation of the object/information being indicated, and the conveyance of some symbol representing the object/information being indicated.

According to example embodiments, network nodes, network controllers, network apparatuses, elements or entities including routers, switches, components or elements of <NUM>th Generation telecommunications networks, cloud-based data centers, computers, cloud-based servers, or the like, may be (or include) hardware, firmware, hardware executing software or any combination thereof. Such hardware may include processing or control circuitry such as, but not limited to, one or more processors, one or more CPUs, one or more controllers, one or more ALUs, one or more DSPs, one or more microcomputers, one or more FPGAs, one or more SoCs, one or more PLUs, one or more microprocessors, one or more ASICs, or any other device or devices capable of responding to and executing instructions in a defined manner.

Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments of the invention. However, the benefits, advantages, solutions to problems, and any element(s) that may cause or result in such benefits, advantages, or solutions, or cause such benefits, advantages, or solutions to become more pronounced are not to be construed as a critical, required, or essential feature or element of any or all the claims.

Claim 1:
A method comprising:
generating a reduced size textual network log from a textual network log including event records by
parsing (S410), based on one or more configuration parameters from a network controller, the textual network log to identify instances of a pattern in the event records, wherein the configuration parameters include an identifiable format for an event record in the form of an ordered pattern of numerical values that defines the pattern to be identified;
substituting (S412) each of the identified instances of the pattern with the numerical values;
outputting the reduced size textual network log to a network controller.