Technical Field

[01] The present invention generally relates to Software Defined Network controllers that perform network control and management functions in communication networks. Such Software Defined Network controllers are also called SDN controllers. Examples of network control and management functions performed by such SDN controllers are network topology discovery, traffic engineering, network path computation, etc.

Background

[02] In the Internet of Things or loT, massive numbers of devices become connected to the Internet, like sensors, household appliances, etc. The large amount of devices introduces new challenges with respect to network control and management, and data processing.

[03] Existing cloud data storage and processing models are not designed for the volume and variety of data generated by the loT, neither are they adapted to the velocity at which these data are generated in the loT. Next generation cloud data storage and processing models therefore are expected to extend cloud systems to be closer to the loT devices, i.e. closer to the edge of communication networks. Preprocessing data at the edge of communication networks or taking control and management decisions at the edge of communication networks has several benefits such as reduced bandwidth consumption and reduced latency. [04] In general, however, the closer network management and control functions are brought to the edge of communication networks, the more the cloud nodes become resource constrained, for instance as a result of more stringent space, power and cooling limitations at the edge of communication networks. Foreseeing the amount of resources that applications processing loT data and functions controlling the local loT network need, is unfeasible.

Summary

[05] It is an objective to enable bringing SDN controllers closer to the edge of communication networks, for instance to the loT gateway at the edge, and to execute network management and control functions in the more heterogeneous, resource constrained environment that the loT represents.

[06] Embodiments of the invention thereto disclose a local Software Defined Network controller, abbreviated local SDN controller, adapted to perform local network control and management functions in a resource constrained execution environment, the local SDN controller comprising:

- a resource monitor adapted to permanently monitor an amount of available resources in the resource constrained execution environment and to establish a shortage of a given type of resources in the resource constrained execution environment; and

- a function manager adapted to identify a non-critical function out of the local network control and management functions that can be deactivated and/or offloaded to a central SDN controller to release resources of the given type in the resource constrained execution environment. [07] Thus, embodiments of the invention concern a local SDN controller that self- adapts to the resources exposed by the execution environment that is resource constrained. The self-adaptation of the local SDN controller results in certain network control and management functions being deactivated and/or offloaded to a central SDN controller. To select which network control and management functions will be offloaded to the central SDN controller, functions that consume resources of a given type that is missing are selected. The type of resource may for instance be memory, storage capacity, computational capacity, etc. Amongst those functions, the one(s) that can be deactivated and/or offloaded without criticalities is/are selected. To enable the self-adaptation of a local SDN controller in resource constrained environments, at least two components must be added to the traditional SDN controller architecture. Firstly, a resource monitor must constantly monitor the amount of available resources in the resource constrained environment, e.g. the edge cloud environment. The resource monitor establishes when resources of a given type are running short, i.e. it detects when there is a shortage of a certain type of resources. Secondly, a function manager verifies if there are non-critical functions, i.e. non-critical for the correct functioning of the SDN controller, such that these non-critical functions can be safely deactivated and/or offloaded to a central SDN controller to release the type of resources that is running short. The function manager thereto for instance may maintain a static list of functions ranked by criticality and select offload the least critical function according to that list to the central SDN controller in case of shortage of resources. As an example, the function manager may select the path computation engine that consumes too much CPU power and offload that function to a central SDN controller. [08] Embodiments of the invention hence bring the advantage that SDN controllers can be executed at the edge of the cloud where execution environments are highly heterogeneous with different degrees of resource availability. The local SDN controller is able to cooperate with a central SDN controller and automatically offloads functions that cannot be executed at the resource constrained execution environment during runtime based on criticality of the functions, to automatically self-adapt to the resource availability in the resource constrained execution environment.

[09] Embodiments of the local SDN controller according to the present invention, defined by claim 2, further comprise:

- a permission requestor adapted to request permission for deactivation of a non- critical function in the list to the central SDN controller before deactivating and/or offloading the non-critical function.

[10] Indeed, in case coordination between the local SDN controller and central SDN controller is desired, permission shall be requested to the central SDN controller before any function is deactivated. This way, the central SDN controller can take over the selected function and the offloading from local SDN controller to central SDN controller takes place without service interruption. Hence, a graceful deactivation of the function becomes possible. [11] Embodiments of the local SDN controller according to the present invention, defined by claim 3, further comprise:

- a state manager adapted to maintain a function state for stateful functions performed in the resource constrained execution environment, and to transfer a current function state of the non-critical function in the list to the central SDN controller before deactivating and offloading the non-critical function.

[12] Indeed, for stateful functions selected to be deactivated and offloaded to a central SDN controller in order to release resources of a certain type in the resource constrained environment, transfer of the function's current state from the local SDN controller to the central SDN controller may be needed. Embodiments of the local SDN controller according to the present invention therefore may comprise a state manager that maintains the current state of stateful functions, and transfers that current state to the central SDN controller when a non-critical stateful function is selected by the function manager for being deactivated and/or offloaded to the central SDN controller.

[13] In embodiments of the local SDN controller according to the present invention defined by claim 4, the function manager further comprises:

- an offline profiler adapted to offline determine resource requirements for the local network control and management functions.

[14] Thus, the function manager may incorporate a first component: an offline profiler that provides an offline estimation of the resource requirements for each function in the list of non-critical functions. The offline profiler contains static information on the resource requirements per function, i.e. a static list of functions ordered according to resource requirements based on the function specification. Thanks to the offline profiler, the function manager enables to offload functions according to two criteria: criticality of the function and consumption of the type of resource that is lacking as specified in the function specification.

[15] In embodiments of the local SDN controller according to the present invention defined by claim 5, the function manager further comprises: - a function monitor adapted to gather resource consumption information for each function; and

- an online profiler adapted to generate, in case the resource monitor establishes a shortage of the given type of resources in the resource constrained execution environment, a list of functions out of the local network control and management functions consuming most resources of the given type of resources.

[16] Thus, the function manager may incorporate a second component, a function monitor that gathers resource consumption information for each function running in the local SDN controller, and a third component, an online profiler that uses the resource consumption information online collected by the function monitor to generate a list of functions consuming most resources of a given type in case of lack or shortage of that given type of resources. The online profiles shall for instance generate a list of functions ordered by CPU consumption if processing capacity is missing or running short. The local SDN controller now becomes able to cooperate with a central SDN controller and automatically offload functions that cannot be executed at the resource constrained execution environment during runtime based on criticality of the functions and the consumption of particular type(s) of resources by the functions, to thereby automatically self-adapt to the resource availability in the resource constrained execution environment.

[17] In embodiments of the local SDN controller according to the present invention defined by claim 6, the function manager further comprises:

- an upload manager adapted to deactivate and upload the non-critical function at runtime from the local SDN controller to the central SDN controller.

[18] Thus, the function manager may incorporate a third component: an upload manager that performs graceful deactivation or activation of a given network control and management function.

[19] In embodiments of the local SDN controller according to the present invention defined by claim 7, the upload manager is further adapted to offload the non-critical function from the central SDN controller as soon as the resource monitor establishes sufficient resources of the given type in the resource constrained execution environment.

[20] This way, a previously offloaded function can be loaded back into the local SDN controller given that there are enough resources again in the resource constrained execution environment at some point in time. The central SDN controller may use a controller-to-controller interface to monitor the state of the local SDN controller and decide when a function that was previously offloaded, is reloaded again into the local SDN controller.

[21] In addition to a local SDN controller as defined by claim 1 , embodiments of the present invention also concern a corresponding method of performing local network control and management functions in a resource constrained execution environment as defined by claim 8, the method comprising:

- permanently monitoring an amount of available resources in the resource constrained execution environment and establishing a shortage of a given type of resources in the resource constrained execution environment; and

- identifying a non-critical function out of the local network control and management functions that can be deactivated and/or offloaded from a local SDN controller to a central SDN controller to release resources of the given type in the resource constrained execution environment.

Brief Description of the Drawings

[22] Fig. 1 illustrates the Internet of Things comprising an embodiment of the local SDN controller 101 according to the present invention;

[23] Fig. 2 is a functional block scheme of the embodiment of the local SDN controller 101 of Fig. 1 ;

[24] Fig. 3 is a flow diagram of an embodiment of the method for performing network control and management functions according to the present invention; and [25] Fig. 4 illustrates a computing system suitable for hosting the local SDN controller according to the present invention and suitable for implementing the method for performing network control and management functions according to the present invention.

Detailed Description of Embodiment(s)

[26] Fig. 1 shows the Internet of Things (loT) comprising a massive number of interconnected devices, six of which are drawn in Fig. 1 : D1 or 121 , D2 or 122, D3 or 123, D4 or 124, D5 or 125 and D6 or 126. Fig. 1 further shows a number of network elements that forward data: NE1 or 1 1 1 , NE2 or 1 12, NE3 or 1 14, NE4 or 1 14 and NE5 or 1 15. Network element 1 1 1 represents an Internet of Things gateway hosting a local SDN controller 101 operating in line with embodiments of the present invention. Network element 1 14 represents a gateway to a cloud storage or processing system 104 that further hosts a central SDN controller 102. The local SDN controller 101 and central SDN controller 102 are coupled through a controller-to-controller interface 103, represented by a dashed line in Fig. 1 . [27] Fig. 2 shows the embodiment of the local SDN controller 101 of Fig. 1 in more detail. The local SDN controller 101 comprises a number of network control and management functions, three of which are drawn in Fig. 2: F1 or 21 1 , F2 or 212 and F3 or 213. The local SDN controller 101 further comprises a resource monitor 201 and a function manager 202. The resource monitor 201 connects with a memory wherein the usage of certain types of resources by the network control and management functions F1 -F3 is maintained. In the example of Fig. 2, the types of resources comprise the CPU power 221 , memory occupancy 222 and storage capacity 223. Fig. 2 further shows that the function manager 202 comprises four components: an offline profiler 231 , a function monitor 232, an online profiler 233, and an upload manager 234. The operation of the different components of the local SDN controller 101 will be described in more detail in the following paragraphs.

[28] The local SDN controller 101 has an amount of functions F1 -F3 or services, depending on the tasks that the local SDN controller 101 is expected to fulfill, e.g., a topology discovery service 21 1 , a traffic engineering service 212, a path computation engine 213, etc. The amount of functions and the tasks fulfilled by these functions varies between SDN controllers. The local SDN controller 101 is deployed in a resource constrained execution environment 200 where some of the non-critical functions hosted by the local SDN controller 101 , i.e. functions or services that are non- critical for the correct functioning of the local SDN controller 101 , can be deactivated in order to save resources. An example of such non-critical function is the topology discovery service 21 1 in the local SDN controller 101 . [29] The local SDN controller 101 further has two new components added to the traditional SDN controller architecture to enable self-adaptation to available resources in its resource constrained execution environment 200: the resource monitor 201 and the function manager 202. The resource monitor 201 constantly monitors the amount of available resources in its execution environment, e.g. the CPU consumption 221 , the memory occupancy 222 and the used storage capacity 223. In case of lack of a given type of resources, e.g. computational power or CPU capacity, the function manager 202 lists the most resource consuming functions of that given type, either through offline or online estimation of the amount of resources of that given type by the different functions F1 -F3. In the example of CPU capacity, the functions F1 -F3 become ordered by CPU consumption. The function manager 202 thereupon checks if there is any non-critical function in the previous list of functions that can be safely deactivated to release the type of resources that is missing or running short. The offline profiler 231 provides an offline estimation of the resource requirements for each of the functions F1 -F3, i.e. an estimation of the resource requirements based on the function specifications. In the example of Fig. 2 for instance, the function manager 202 establishes through its offline profiler 231 that the path computation engine F3 or 213 consumes too much CPU power according to its specifications whereas this is a non- critical function. Consequently, this function F3 can be offloaded to a central SDN controller, for instance SDN controller 102 in the situation of Fig. 1 . The upload manager 234 performs a graceful deactivation of selected non-critical function(s) 213 at the local SDN controller 101 and activation of that same function 213 at the central SDN controller 102. The local SDN controller 101 will coordinate with the central SDN controller 102 and ask for permission before deactivating the path computation engine 213, such that the central SDN controller 102 can take over this function 213 without service disruption. A graceful shutdown of the function 213 is thus realized at the local SDN controller 101 thereby releasing CPU power in the resource constrained environment 200 of the local SDN controller 101 . It is noticed that transfer of the current function state from the local SDN controller 101 to the central SDN controller 102 may be needed in case the function 213 selected to be deactivated is a stateful function. The function monitor232 further gathers effective resource consumption information for each function F1 -F3 running in the local SDN controller 101 . This online collected resource consumption information, when available, is used by the online profiler 233 to establish a list of functions ordered according to online measured consumption of resources of the type that is missing. In the example of Fig. 2 for instance, the function manager 202 establishes through its function monitor 232 and online profiler 233 that the topology discovery service F1 or 21 1 consumes most CPU power at a point in time where CPU power is missing, whereas this is a non-critical function. Consequently, this function F1 can be offloaded to a central SDN controller, for instance SDN controller 102 in the situation of Fig. 1 . The upload manager 234 performs a graceful deactivation of the selected non-critical function 21 1 at the local SDN controller 101 and activation of that same function 21 1 at the central SDN controller 102. The local SDN controller 101 will coordinate with the central SDN controller 102 and ask for permission before deactivating the topology discovery service 21 1 , such that the central SDN controller 102 can take over this function 21 1 without service disruption. A graceful shutdown of the function 21 1 is thus realized at the local SDN controller 101 thereby releasing CPU power in the resource constrained environment 200 of the local SDN controller 101 . It is noticed that transfer of the current function state from the local SDN controller 101 to the central SDN controller 102 may be needed in case the function 21 1 selected to be deactivated is a stateful function.

[30] It is noticed that in alternative embodiments of the present invention, no function monitor and online profiler may be foreseen such that the function manager can only rely on static information obtained from the offline profiler to select non-critical function(s) that will be offloaded to a central SDN controller. In further alternative embodiments, the static information available from the offline profiler may be combined with the online information collected by the function monitor, and the static estimation of resource consumption and real-time measured estimation of resource consumption of a given type may be combined, e.g. in a weighted sum, to establish a list of functions ordered according to resource consumption. That list may then serve as starting point to select non-critical function(s) that will be offloaded to the central SDN controller.

[31] It is noticed that in an alternative embodiment, for very resource constrained devices where there is not enough place to store the proposed SDN controller functionality on chip (e.g. flash), it may even be possible to upload the functionality at runtime instead of activating/deactivating functions. The function could then be precompiled and run directly in RAM or through use of a generic lightweight virtual machine or some scripting language.

[32] Fig. 3 illustrates the steps executed in an embodiment of the method to perform network control and management functions in a resource constrained execution environment according to the present invention. In step 301 , a resource monitor 201 in a local SDN controller 101 probes certain resources in the resource constrained execution environment. In step 302, a function manager 202 in the local SDN controller 101 verifies if the consumption of resources of a certain type exceeds a certain limit. As long as this is not the case, the resource monitor 201 keeps probing the resources. As soon as the consumption of resources of a certain type exceeds a certain limit, the method moves to step 303 wherein the function manager 202 determines which type of resources is overloaded, e.g. computation power. Thereupon, the function manager 202 of the local SDN controller 101 checks in step 304 which non-critical functions are consuming most resources of the type that is overloaded. In step 305, the local SDN controller 101 requests permission to the central SDN controller 102 to deactivate a selected non-critical function and specifies that the reason for the request is a resource overloaded in the execution environment. The request is sent from the local SDN controller 101 to the central SDN controller 102 over the controller-to-controller interface 103. In step 306, the function manager 202 verifies if the request is granted by the central SDN controller 102. If this is not the case, the process returns to step 304 to select a different non-critical function that is consuming substantial resources of the type of resources that is overloaded. If on the contrary the request is granted by the central SDN controller 102, the local SDN controller 101 optionally transfers the latest function state to the central SDN controller 102 in step 307. This step is optional as it applies only to stateful functions or services, i.e. functions or services for which a state is maintained. Thereafter, in step 308, the function manager 202 offloads the function from the local SDN controller 101 to the central SDN controller 102, the central SDN controller 102 uploads the function and activates the function for execution. At the local SDN controller 101 , the function is deactivated, and the method returns to step 302 to verify if there are still resources of a particular type that are overloaded in the resource constrained execution environment 200.

[33] The above described invention is particularly advantageous when used in the Internet of Things (loT), where control and data aggregation from a high number of loT devices is likely to be done at the edge of the network. As loT networks become more popular, there will be a big variety of loT gateways in the market. SDN controllers, which may be commercialized as a Virtual Network Function (VNF), will need to adapt to different types of resource constrained execution environments in order to operate at the edge of the network. The present invention allows for executing an SDN controller at the very edge of the network, where execution environments are highly heterogeneus with different degrees of resource availability. The invention enables cooperation between a local SDN controller and a central SDN controller to offload the functions that cannot be executed at the resource constrained execution environment during runtime based on the resource availability considered per type of resource. [34] Fig. 4 shows a suitable computing system 400 for hosting the local SDN controller 101 according to the present invention and suitable for implementing the method for performing network control and management functions according to the present invention, embodiments of which are drawn in Fig. 2 and Fig. 3 respectively. Computing system 400 may in general be formed as a suitable general purpose computer and comprise a bus 410, a processor 402, a local memory 404, one or more optional input interfaces 414, one or more optional output interfaces 416, a communication interface 412, a storage element interface 406 and one or more storage elements 408. Bus 410 may comprise one or more conductors that permit communication among the components of the computing system. Processor 402 may include any type of conventional processor or microprocessor that interprets and executes programming instructions. Local memory 404 may include a random access memory (RAM) or another type of dynamic storage device that stores information and instructions for execution by processor 402 and/or a read only memory (ROM) or another type of static storage device that stores static information and instructions for use by processor 404. Input interface 414 may comprise one or more conventional mechanisms that permit an operator to input information to the computing device 400, such as a keyboard 420, a mouse 430, a pen, voice recognition and/or biometric mechanisms, etc. Output interface 416 may comprise one or more conventional mechanisms that output information to the operator, such as a display 440, a printer 450, a speaker, etc. Communication interface 412 may comprise any transceiver-like mechanism such as for example two 1 Gb Ethernet interfaces that enables computing system 400 to communicate with other devices and/or systems, for example mechanisms for communicating with one or more other computing systems. The communication interface 412 of computing system 400 may be connected to such another computing system 460 by means of a local area network (LAN) or a wide area network (WAN), such as for example the internet, in which case the other computing system may for example comprise a suitable web server. Storage element interface 406 may comprise a storage interface such as for example a Serial Advanced Technology Attachment (SATA) interface or a Small Computer System Interface (SCSI) for connecting bus 410 to one or more storage elements 408, such as one or more local disks, for example 1 TB SATA disk drives, and control the reading and writing of data to and/or from these storage elements 408. Although the storage elements 408 above is described as a local disk, in general any other suitable computer-readable media such as a removable magnetic disk, optical storage media such as a CD or DVD, -ROM disk, solid state drives, flash memory cards, ... could be used.

[35] The steps executed in the method of performing network control and management functions according to the present invention, illustrated by the above embodiments, may be implemented as programming instructions stored in local memory 404 of the computing system 400 for execution by its processor 402. Alternatively the instructions may be stored on the storage element 408 or be accessible from another computing system through the communication interface 412.

[36] Although the present invention has been illustrated by reference to specific embodiments, it will be apparent to those skilled in the art that the invention is not limited to the details of the foregoing illustrative embodiments, and that the present invention may be embodied with various changes and modifications without departing from the scope thereof. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive, the scope of the invention being indicated by the appended claims rather than by the foregoing description, and all changes which come within the scope of the claims are therefore intended to be embraced therein.

[37] It will furthermore be understood by the reader of this patent application that the words "comprising" or "comprise" do not exclude other elements or steps, that the words "a" or "an" do not exclude a plurality, and that a single element, such as a computer system, a processor, or another integrated unit may fulfil the functions of several means recited in the claims. Any reference signs in the claims shall not be construed as limiting the respective claims concerned. The terms "first", "second", third", "a", "b", "c", and the like, when used in the description or in the claims are introduced to distinguish between similar elements or steps and are not necessarily describing a sequential or chronological order. Similarly, the terms "top", "bottom", "over", "under", and the like are introduced for descriptive purposes and not necessarily to denote relative positions. It is to be understood that the terms so used are interchangeable under appropriate circumstances and embodiments of the invention are capable of operating according to the present invention in other sequences, or in orientations different from the one(s) described or illustrated above.