Network configuration adaptation based on contextual awareness

Abstract

This invention relates to a method and system for dynamical adaptation of a streetlight-based wireless network based on local contextual data to achieve context awareness and efficiently deal with transient demand. Lighting grid sensing data for controlling a set of streetlights is leveraged by a networking domain (e.g., mmWave radios) to be able to adapt to local contextual changes. A context engine acts as a broker for exchanging sensing data between lighting and networking and may gather data from external applications (e.g., weather stations, public event lists etc.), to provide contextual insights to a network management system. Based thereon, the network management system can augment its own self-organizing network capabilities without a need for additional sensors or equipment.

Description

[0001] Network configuration adaptation based on contextual awareness

[0002] FIELD OF THE INVENTION

[0003] The invention relates to the field of communication in wireless networks, such as - but not limited to - telecommunication networks, for use in various different applications.

[0004] BACKGROUND OF THE INVENTION

[0005] Outdoor lighting grids (e.g., street lighting) offer a near-ideal grid to deploy wireless communication infrastructure (such as Wi-Fi, telecommunications 4G / 5G, E-band and V-band backhaul) because they may offer proximity (to people and / or traffic), scale (ubiquitous presence), granularity (distance between light poles matches typical requirements of radio frequency (RF) network design) and elevation (height to mount equipment for signal coverage). On top of that, they may be used to provide electrical power. A challenge to get acceptance from cities (permits) and the public is to provide aesthetic solutions and minimized form factors, as there is a strong desire to hide technology in unseen places.

[0006] From a technology point of view, this may put pressure on the design of overall RF systems which may consist of a base band unit (BBU), a radio unit and an antenna (array), as key building blocks. For lower frequencies (e.g., below about 7 GHz), the BBU, the radio unit and the antenna (array) may be physically separated. However, for higher frequencies, physical separation between the radio unit and the antenna (array) needs to be minimized.

[0007] The ever-growing data consumption (data throughput) requires higher bandwidths, which in turn demands usage of higher frequencies. As an example, radio frequencies used for telecommunication’s 5G standard will increase to 3-6 GHz and later to 26 GHz and beyond. The frequencies of 26 GHz and higher frequencies are typically referred to as mmWave (millimeter wave) because the wave lengths are in the order of (several) millimeter. Moreover, frequencies of wireless backhaul networks (i.e., physical parts of communications networks between central backbones and individual local networks) are typically 60 GHz or 70 GHz and will grow beyond 100 GHz. Signals at these frequencies behave like optical waves in the sense that they do not penetrate walls and objects. Thus, a communication link between a transmitting point or node (transmitter) and a receiving point or node (receiver) requires clear line of sight (LOS), which means that the transmitter and receiver must “see” each other via an uninterrupted, unobstructed, straight line.

[0008] Designing an optimal city-wide wireless network is a very complex, timeconsuming activity that considers a multitude of multi-dimensional parameters. As an example, link budget parameters can be calculated by also incorporating statistical weather data such as annual rainfall & snow of the intended city or site. Further, future network demand projections, quality of service (QoS) requirements, commercial and operational considerations are some of the other parameters that may need to be considered. The network design is then translated to a network topology which is used to deduce geographical position and placement of broadband luminaires and fiber hubs. After physical installation, radio links between these broadband luminaires and fiber hubs are created.

[0009] However, basing network design largely on past statistical data to determine the number of nodes, geolocation of nodes, link paths etc. leads to a static network design that does not allow adaptation of the network to sudden or local contextual changes unless the network is largely over-dimensioned.

[0010] In general, if more bandwidth is required or needs to be prioritized in certain sections of the network, the network design may need to be expanded by installing more broadband luminaires and the network topology may need to be manually adjusted. Such an approach is however costly and impractical for short-term peaks and also leads to underutilization of capacity in non-peak times.

[0011] US2022110012A1 is related to a method that includes obtaining measurement data from at least part of a wireless communication network during a first interval of time, with the measurement data including measurements indicating whether there are potential disturbances to operation of the wireless communication network.

[0012] US2023216577A1 is related to a telecommunications (telecom) system that includes cellular transceivers, a core network, and at least one streetlight-mountable telecom support unit providing communications connectivity between the cellular transceivers and the core network., and the cellular transceivers may be mounted to other streetlights.

[0013] SUMMARY OF THE INVENTION

[0014] It is an object of the present invention to provide a fast and dynamic network control functionality that allows for efficient adaptation to changing bandwidth demand.

[0015] This object is achieved by a context engine as claimed in claim 1, by a method as claimed on claim 13, and by a computer program product as claimed in claim 14. According to a first aspect, an context engine comprising an apparatus and at least one interface is proposed for supporting configuration control of a wireless network by a network management system, the wireless network comprising a plurality of network nodes integrated in a lighting system, wherein the apparatus comprises a context builder for monitoring context-related information received from a lighting control and management system of the lighting system, the wireless network and one or more external applications, for deriving context information from the monitored context-related information, and for forwarding the derived context information to the network management system. The content engine also comprises at least one interface, in particular a plugin or application programming interface, for providing an adapted connection to the lighting control and management system, one or more sensors of the lighting control and management system, the one or more external applications, and a plurality of transceiver units, in particular mmWave radios, of the wireless network

[0016] As an example, a network management system comprising a content engine of the second aspect is provided.

[0017] As a further example, a streetlight-based wireless network is provided, which comprises a network management system of the third aspect, a lighting management and control system and a plurality of radio transceiver units, in particular, mmWave radios.

[0018] According to a second aspect, a method of a content engine for supporting configuration control of a wireless network by a network management system is provided, the wireless network comprising a plurality of network nodes integrated in a lighting system, wherein the method comprises: monitoring context-related information received from a lighting control and management system of the lighting system, the wireless network and one or more external applications; deriving context information from the monitored context-related information; forwarding the derived context information to the network management system; and providing an adapted connection to the lighting control and management system, one or more sensors of the lighting control and management system, the one or more external applications, and a plurality of transceiver units, in particular mmWave radios, of the wireless network. According to a further aspect, a computer program product is provided, which comprises program code for producing the steps of the above method when run on a computer device.

[0019] Accordingly, adaptive network configuration via monitoring of context-related (contextual) information can be achieved. A context engine can be deployed to act as a broker for receiving and / or exchanging sensing data between a lighting control system and a coexisting broadband communication network, collecting and analyzing the sensing data and provide contextual insights to the network management system for load balancing purposes. Thereby, sensing data from different sources can be combined to improve both lighting control and load balancing in the network management system. In an example, certain properties of radio / wireless links can be used to derive context-related information (e.g., weather conditions), such as LOS communication (e.g., mmWave communication). Other context- related information (e.g., traffic flow) may be derived from the presence of users and / or public traffic and / or the like. Thus, context information can cover various sources including the wireless network side, the lighting network side or other external sources.

[0020] According to a first option of the present invention, the context-related information may comprise sensing data of the lighting control and management system, wherein the apparatus may be adapted to act as broker for collecting and analyzing the sensing data and for providing contextual insights to the network management system for load balancing of the wireless network.

[0021] According to a second option of the present invention, measured properties of radio or wireless links may be used as virtual sensors for deriving weather conditions as the context information.

[0022] According to a third option of the present invention, the one or more sensors may comprise at least one of a light sensor, a humidity sensor, a rain sensor, a temperature sensor, and a presence and / or movement sensor.

[0023] According to a fourth option of the present invention, the content engine may be adapted to receive radio frequency parameters from the transceiver units (e.g., via a network management system of the wireless network).

[0024] According to a fifth option of the present invention, the radio frequency parameters may comprise one or more of antenna power, wireless link budget, number of wireless link paths, radio frequency link re-routing or topology change , re-routing of user data traffic (e.g., network L2 (switching) or L3 (routing ) connection change actions), user data traffic counters, received signal strength indicator, signal-to-noise ratio, packet drop ratio, transmitter / receiver buffer size, or a combination of these.

[0025] According to a sixth option of the present invention, at least one of weather information, event calendar information, social media information and public transport information may be received (e.g., by the content engine) from the one of more external applications.

[0026] According to a seventh option of the present invention, at least one of lighting schedules, light pole coordinates and light identities may be received (e.g., by the content engine) from the lighting management and control system.

[0027] According to an eighth option of the present invention, the wireless network may be controlled by the network management system based on the context information, to configure the wireless network by at least one of transmitting and / or loading control information to network nodes, setting a tunnel layout, setting new or alternate radio links, and setting a class of service.

[0028] According to a ninth option of the present invention, the plurality of LOS transceiver units may comprise a plurality of physically separated sectors configured to establish a plurality of LOS communication links to other network nodes.

[0029] It is noted that the above apparatus may be implemented based on discrete hardware circuitries with discrete hardware components, integrated chips, or arrangements of chip modules, or based on signal processing devices or chips controlled by software routines or programs stored in memories, written on a computer readable media, or downloaded from a network, such as the Internet. More specifically, the software may run on a virtual device such as a Docker Container, or virtual machine, which may be implemented on a physical server on a respective premise or as part of a cloud infrastructure.

[0030] It shall be understood that a preferred embodiment of the invention can also be any combination of the dependent claims or above embodiments with the respective independent claim.

[0031] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter.

[0032] BRIEF DESCRIPTION OF THE DRAWINGS

[0033] In the following drawings:

[0034] Fig. 1 shows schematically a block diagram of an outdoor luminaire with integrated mmWave radio; Fig. 2 shows schematically an architecture of a wireless network with a context engine according to various embodiments;

[0035] Fig. 3 shows a table with examples of sensors that may be used for deriving contextual information;

[0036] Fig. 4 shows schematically a block diagram of a context engine according to a first embodiment; and

[0037] Fig. 5 shows a flow diagram of context deriving process according to a second embodiment.

[0038] DETAILED DESCRIPTION OF EMBODIMENTS

[0039] Various embodiments of the present invention are now described based on an outdoor lighting network with integrated wireless network (e.g., with a mesh or linear or star or any other topology), such as a wireless network compliant with IEEE 802.11 ad, IEEE 802.11 ay or similar networks.

[0040] The wireless network can be defined as a network of N network nodes that can establish a connection to other nodes by establishing wireless RF links. The network operates best in line-of-sight (LOS) conditions to maximize connectivity. In its essence, the network may be “wireless fiber” with gigabit speeds, rapid deployment capability, and flexible use case support.

[0041] Furthermore, the network may be a distribution level network designed to augment and expand a fiber optic network. That is, the network may be a high-speed backbone network to which other networks are connected. When combined with fixed access connections or Wi-Fi access points, the network provides a low-cost solution to achieve street-level coverage with high speeds.

[0042] According to embodiments, the flow of data traffic in the network is continuously optimized by using an active network management system. Thereby, the fact that networks are dynamic systems where traffic per connected external device varies over time with different timescales and where these variations have very limited predictability can be addressed. Moreover, the wireless nature of such networks adds additional dynamics in that the capacity and number of links between network nodes may vary. In order to continually optimize traffic (minimize congestion) and respond to variations, a layered / nested / hierarchical network management system may be implemented.

[0043] Exemplary instances that could necessitate spatiotemporal changes in network demand or characteristics include: 1. local events such as fairs, demonstrations or sports in the city typically leads to more people density in a specific area demanding connectivity that leads to higher bandwidth in a certain section or segment than was originally designed.

[0044] 2. Weather conditions such as fog, rain & snow adversely influences the range & quality of wireless links, as described e.g. in W. Asen et al.: comparison of rain attenuation and drop size distributions measured in Chilbolton and Singapore” , Radio Science, Vol. 37, Issue 3, June 2002 (https: / / doi.org / 10.1029 / 2000RS0Q2613). or in D. Nandi and A. Maitra, "The Effects of Rain on Millimeter Wave Communication for Tropical Region", 2019 URSI Asia-Pacific Radio Science Conference (AP-RASC), New Delhi, India, 2019, pp. 1-3 (doi: 10.23919 / URSIAP-RASC.2019.8738591). Network performance of certainly links could be negatively impacted (degraded or total loss) while a few of the other links could be overloaded. This can eventually lead to degraded QoS for the end user.

[0045] 3. Emergency situations (car accidents, fire, flooding, etc.) which require emergency street lighting to be forced on but also needs a stable and very capable (bandwidth) backhaul network in the same region as the region for emergency services or the like.

[0046] It is noted that - throughout the present disclosure - the structure and / or function of blocks with identical reference numbers that have been described before are not described again, unless an additional specific functionality is involved. Moreover, only those structural elements and functions are shown, which are useful to understand the embodiments. Other structural elements and functions are omitted for brevity reasons.

[0047] Fig. 1 shows schematically a block diagram of an outdoor luminaire with integrated mmWave radio 26 or other wireless transceiver (transmitter / receiver), which may thus be understood as a “broadband” luminaire.

[0048] As can be gathered from Fig. 1, the luminaire supports a lighting system (using a lighting control node 10 and a lighting unit 24) and a backhaul broadband networking system (using the mmWave radio 26 or other wireless transceiver) as two separate systems.

[0049] The lighting control node 10 may comprise a controller (CTRL) 12 connected to a luminaire socket (SKT) 22 at a housing 20 of the luminaire, an RF link unit (RF-L) 14 (e.g., cellular or other established by an RF unit) and one or more sensors (S) 16 (e.g., sensors for sensing at least one of light, movement, temperature, humidity, etc.). The light source (e.g., LED) part of the luminaire may thus be controlled / dimmed by the lighting control node 10.

[0050] The mmWave radio 26 is composed of a modulation unit (MOD) 264 powered by a dedicated power supply unit (PSU) 28. The power supply unit 28 is powered by an external power supply or grid (P). Additionally, an LED power supply unit (LED-PSU) 244 is provided for supplying power to one or more light sources (LS) 242 of the lighting unit 24.

[0051] The modulation unit 264 is connected to one or multiple antennas 262 (e.g., four sector antennas Al to A4 in the example of Fig. 1) which may include respective transceivers, wherein data offload (DO) of information received via the sector antennas 262 can be achieved e.g. via a Power-over-Ethemet (PoE) adapter.

[0052] The mmWave radio 26 is configured to operate in a frequency band, also known as millimeter band, that creates wavelengths between 10mm (30 GHz) and 1mm (300 GHz). It is also known as the extremely high frequency (EHF) band by the International Telecommunication Union (ITU). “mmWave” is a band of electromagnetic spectrum that can be used in a broad range of products and services, such as high-speed, point-to-point wireless local area networks (WLANs) and broadband access. In telecommunications, millimeter wave is used for a variety of services on mobile and wireless networks, as it enables higher data rates. Antennas for millimeter wave devices are smaller than for other frequencies, making them more suitable for small devices.

[0053] Since commissioning and operationality of the two systems (i.e., lighting system and backhaul broadband networking system) of the luminaire of Fig. 1 are critical, they may be continuously monitored remotely by respective operators.

[0054] The mmWave unit 26 may use the sector (segmented) antennas 262 (e.g., a multi-element, phased array antenna) and advanced beamforming techniques to form high- quality communication links to other luminaires (or nodes) at distances up to e.g. 100 m, including primarily LOS paths, while also using reflection paths between the nodes. In an example, antennas 262 at transceiver sides of both connection ends may create a direct and LOS RF link between both, which may be degraded suddenly by objects, trees, or the like. Each node may select the strongest communication link from the many possible propagation paths between the nodes. Phased-array antennas may allow the luminaire to establish links to mitigate co-channel interference that often prevails in dense urban environments.

[0055] In an exemplary architecture of such networks, the luminaire or another type of network node (or “node” throughout the present disclosure) may have a central network processor that handles network traffic (or “traffic” throughout the present disclosure) from and to a plurality of sectors of the sector antennas 262 that together use beamforming to establish links with sectors of other nodes. As an example, the four sectors of the four sector antennas Al to A4262 may enable a 360-degree coverage horizontally (azimuthally). It is further assumed that each luminaire (node) can establish up to four network connections, paths or channels to other nodes, which may be accomplished by the four sector antennas Al to A4 262. It is however noted that this is not a necessary restriction. Each luminaire (node) may also have more (or fewer) than four network connections, paths or channels to other luminaires (nodes). Each sector may thus be used for no, a single or multiple connections to other luminaires (nodes) nodes.

[0056] In addition to establishing network connections (RF links) to other luminaires (nodes), luminaires (nodes) may also establish network connections to stand-alone (nonluminaire built-in) RF transceivers used as an access point (example for fixed wireless access).

[0057] Fig. 2 shows schematically an architecture of a wireless mesh network with a context engine (CE 204) according to various embodiments.

[0058] The wireless mesh network is built up by a plurality of streetlights (e.g., light poles) 30 each comprising the lighting control node 10 and the mmWave radio 26 (e.g., as described in connection with Fig. 1). Furthermore, at least some of the streetlights comprise one or more connected sensors 32 (which may comprise at least some of the sensors 16 of the lighting control node 10 of Fig. 1).

[0059] The mmWave radio 26 are configured to establish mmWave radio links (mmW- R) between the streetlights 30.

[0060] Furthermore, the lighting control nodes 10 are configured to establish respective RF and / or cellular links (RF / C) (e.g., by using the RF link unit 14 of Fig. 1) to a lighting control and management system (LC&M) 202, e.g., to exchange measurement and control data.

[0061] The lighting control and management system 202 may be a connected lighting management application and is to be understood as a system that enables remote management, monitoring and control of at least some of the streetlights 30 or other luminaires of (outdoor) lighting.

[0062] Additionally, the lighting control and management system 202 is configured to communicate with the content engine 204 and the content engine 204 may be configured to communicate with a (high-speed) network monitoring system (NMS) 206 and optionally with external applications (E-APP) 208 (such as weather stations, public event list, etc.).

[0063] The network management system 206 is to be understood as an application or set of applications that allows network administrators to manage a network’s independent components inside a bigger network management framework. It may be used to monitor both software and hardware components in a network. It usually records data from a network’s remote points to carry out central reporting to a system administrator. A network management system may thus be useful in one or more of network device discovery, network device monitoring, network performance analysis, network device management, intelligent notifications, or customizable alerts.

[0064] Moreover, the network monitoring system 206 may be connected to one or more of the mmWave radios 26 of the streetlights 30 (e.g., the rightmost one in Fig. 2).

[0065] Thereby, a smart and connected lighting grid is provided, that has a set of sensors 32, such as ambient light sensor, humidity sensor, rain sensor, temperature sensor, presence detection etc., to control an individual one or a set of the streetlights 30. The obtained sensing data can thus also be leveraged by the networking domain (e.g., the mmWave radios 26) to allow adaptation to local contextual changes.

[0066] Throughout the present disclosure, context-related or contextual information is understood to comprise one or more of time (e.g., urgency, time span etc.), importance and location aspects, such as emergency light activation (e.g., immediate action required), sensor data (e.g., a currently present sensor may prove or help other sensors), RF link data (e.g., current data on link degradation and quality, used bandwidth etc.), weather data (e.g., short- time future weather prediction), or event data (e.g., currently scheduled activities).

[0067] In embodiments, the context engine 204 may be adapted to act as a broker for exchanging relevant (sensor) data metrics between the lighting domain (e.g., lighting system with lighting control units 10) and the networking domain (e.g., sensors 32 and mmWave radios 26). Additionally, the context engine 204 may gather data from the external applications 208 (as indicated in the table of Fig. 3 below). The context engine 204 may then analyze the collected sensing and / or context data to provide contextual insights to the network management system 206.

[0068] By processing the collected and analyzed data, the network management system 206 can leverage on (enhance) the lighting domain’s existing data models and sensing capabilities to augment its own self-organizing network capabilities without a need for additional sensors or equipment.

[0069] In an example, the network management system 206 along with its meshing and resilience orchestrator functions (e.g., for simulating scenarios by varying priorities of tunnels (e.g., set of connected links between nodes) between network nodes of the wireless network and calculating effects on network metrics, and / or by adding and / or changing tunnels between network nodes of the wireless network, and / or by adding and / or removing links between network nodes of the wireless network, and / or by adding and / or moving and / or removing network nodes of the wireless network) can use this contextual information as an additional input e.g. to specifically address and adapt a certain sub-set of luminaires in a section of the city and optimize their radio parameters such as antenna power, wireless link budgets, number of wireless link paths, link re-routing, (throttling ol) user data traffic or a combination of these to achieve improved QoS from the wireless network.

[0070] In examples, another form of context management may be achieved by data bandwidth shaping (QoS shaping), where the bandwidth for certain mmWave RF links and / or connected devices (to the broadband luminaire) is lowered or limited using the data offload (DO) connection port (cf Fig. 1) of the broadband luminaire.

[0071] As an example, people presence data (e.g., from a presence sensor of the connected sensors 32) and public traffic information (e.g., form one of the external applications 208) can be combined to automatically detect that there is more activity than normal in a certain part of the city. Based on this information, the context engine 204 can anticipate that more bandwidth is required or that at least QoS will need to be higher in the concerned part of the city and can indicate to the network management system 206 to actively change or add RF links in that area to support these requirements.

[0072] As another example, if emergency lighting is used in a section of the city (e.g., a light override feature in a smart lighting system), this event can be used by the context-engine 204 to infer an occurrence of an incident / accident and the concerned location of the luminaires associated with it. The context engine 204 can then direct the network management system 206 to change the network configuration of the specific luminaires (e.g., streetlight 30) to support additional bandwidth requirement in this region. As a further option, user data traffic from other non-critical wireless paths or routes can be throttled temporarily to provide priority for wireless paths or routes that are part of the critical path where emergency services are needed. Augmenting precise location of streetlights and light override information from the lighting control and management system 202 in conjunction with the context engine 204 enables proper adaptation on part of the network management system 206.

[0073] Fig. 3 shows a table with examples of sensors (e.g., the sensors 32 in Fig. 2) and data sources that may be used for deriving contextual information gathered and / or exchanged by the context engine 204.

[0074] Light sensors (LS) 101, 201, presence / movement sensors (P / M-S) 102, 202, temperature and humidity sensors (T&H) 103, 203 may be part of a connected lighting systems (e.g., a smart lighting system). These sensors may be in-situ sensors (IS-S) connected locally (in-situ) or externally connected sensors (EC-S) connected remotely (externally) to the luminaires as sensor-bundles using wired or wireless interfaces. It is a known phenomenon that radio links undergo attenuation, distortion, diffraction due to rain, moisture and snow. The mmWave radio links (e.g., 60 GHz frequency) used between the (broadband) luminaires (e.g., streetlights 30) are susceptible to weather conditions as well resulting in variations in the received signal strength indicator (RSSI), signal-to-noise ratio (SNR) etc. Furthermore, certain patterns of these properties can be used to detect the presence of rain, moisture, snow in the environment, as described e.g. in C. Han et al.: ‘‘Rainfall Monitoring Based on Next-Generation Millimeter -Wave Backhaul Technologies in a Dense Urban Environment”, Remote Sens. 2020, 12(6), 1045 (https: / / doi.org / 10.3390 / rsl2061Q45).

[0075] The mmWave radio properties as measured (e.g., by the mmWave radios 26) of the streetlights 30 can be used as a virtual sensor (mmW-RF) 104, 204, e.g., to correlate and derive a rain-rate.

[0076] Similarly, external sources and / or applications (E-SRC / APP) such as weather stations (WS) 301, public event database (e.g., city event calendar) (CEC) 302, social media handles (SMH) 303 (and / or other social media information) and public transport information (PTI) 304 can be tracked to gather contextual data on weather, public gatherings and activities.

[0077] Additionally, data collected by the lighting management system (LMS), such as lighting schedules (LSC) 401, lamp pole locations / coordinates (LPC) 402, light identities (LI) 403, and light override information (LOI) 404 (e.g., if regular light schedules or light levels have been overridden or not) can be gathered from existing lighting management systems (e.g., application programming interfaces (APIs) of a smart lighting system).

[0078] Fig. 4 shows schematically a block diagram of the context engine 204 according to a first embodiment.

[0079] The context engine 204 may be implemented based on a software-controlled processor or an application-specific integrated circuit (ASIC) or a programmable logic array (PLA) or a gate array with data storage facilities (e.g., databases (DBs)).

[0080] A lighting management interface plugin (LMI-PI) 41 may be provided to receive / gather and collect data from the light management system (LMS), such as the lighting schedules 401, the lamp pole locations / coordinates 402, and the light identities 403 (e.g., via API(s)), to be stored in a first database (section) DB1.

[0081] Furthermore, one or more sensor plugins (S-PI) 42 may be provided to receive / gather and collect in-situ and / or external sensor data from one or more of the light sensor(s) 101, 201, the presence sensor(s) 102, 202, and the temperature and humidity sensor(s) 103, 203 to be stored in a second database (section) DB2. Additionally, an external-application plugin (E-APP-PI) 43 may be provided to receive / gather and collect data from external sources and / or applications, such as the weather stations 301, the public event database (e.g., city event calendar) 302, the social media handles 303 and the public transport information 304 to be stored in a third database (section) DB3.

[0082] Moreover, a mmWave RF sensing plugin (mmW-S-PI) 44 may be provided to receive / gather and collect data from a network management system plugin (NMS-PI) 46 that is adapted to receive RF data (RF-D), such as the mmWave radio properties measured (e.g., by the mmWave radios 26) of the streetlights 30 used as a virtual in-situ or external sensors 104, 204 (e.g. to correlate and derive a rain-rate), to be stored in a fourth database (section) DB4.

[0083] The collected data stored in the databases (sections) DB1 to DB4 may then be read and analyzed by a content builder (CB) 45 to derive context information (CON) which is supplied to the network management system 206 via the network management system plugin 46. The content builder 45 may be configured as cross-data content management tool that consolidates the different data content stored in the first to fourth database (sections) DB1 to DB4 to a single context information.

[0084] In embodiments, the content builder 45 adds additional input data (contextual data) to enhance network management and control actions of the network management system 206 to maintain or improve performance (e.g., quality of service).

[0085] In examples, input information of the content builder 45 may comprise one or more of time (e.g., urgency, time span etc.), importance and location aspects, such as emergency light activation (e.g., immediate action required), sensor data (e.g., a currently present sensor may prove or help other sensors), RF link data (e.g., current data on link degradation and quality, used bandwidth etc.), weather data (e.g., short-time future weather prediction), or event data (e.g., currently scheduled activities).

[0086] Each of the above or other input information may have a (static or dynamically adjustable) priority to indicate an issue and probability rating indicating an issue leading to a certain decision (action taken). Each issue may thus be combined from all available input parameters and their priority and / or probability rating with a mathematical decision block based on one or more of e.g. Bayesian mathematics, machine learning, artificial intelligence.

[0087] In an example, the context builder may comprise a mathematical decision block that is configured to combine all or some input data into certain actions according to an action table of a subsequent decision block (input —> output actions), that may be fixed, learned over time (e.g., based on feedback from historical data, orchestrators and / or the network management system 206). Such actions may comprise one or more of tunnel priority and / or backup switching, adding / changing tunnels, adding / removing RF links, adding / removing nodes, traffic shaping (e.g., QoS, bandwidth limits, etc.) on network nodes.

[0088] According to first example, a scenario is considered, where an emergency light is switched on in a certain area (e.g., a first input from lighting management interface plugin

[0089] 41) together with increased presence detection events (e.g., a second input from sensor plugins

[0090] 42) and a known public gathering in this same region (e.g., a third input from externalapplication plugin 43). When combined by the content builder 45, these three inputs increase reliability and likelihood (“probability”) of a real emergency happening at this same region. As a consequence, the decision or actuation could be to maximize network performance (connectivity) at this same location and a potential action could be one or more of creating a dedicated connectivity tunnel to this location, disabling connectivity (e.g., tunnel disabling) to other non-critical areas, maximizing bandwidth shaping to favor this emergency location, or other suitable actions.

[0091] According to a second example, readings of network key performance indicators (KPIs) (e.g., decreased signal-to-noise ratio) in a certain area (e.g., a first input from the mmWave RF sensing plugin 44) together with an estimated or received bad weather data (e.g., rain etc.) in this same region (e.g., a second input from the external-application plugin 43) may be combined into a more reliable and likely (“probable”) indication that a real network traffic affecting weather phenomenon is happening at this same region. The decision could then be to maximize network performance (connectivity) at this same location and a potential action could be to create an alternative connectivity tunnel to this location bypassing as most as possible of the affected areas placed broadband luminaires or any other suitable action.

[0092] According to a third example 3, network KPI readings (e.g., decreased signal- to-noise ratio) in a certain area (e.g., a first input from the mmWave RF sensing plugin 44) to an orchestrator of the network management system 206 may trigger the orchestrator to decide and act (opportunistically) to maximize network performance (connectivity) at a given location e.g. by creating an alternative connectivity tunnel to off-load traffic or start to throttle or shape traffic from certain paths and locations. However, if there are no such indications observed from the lighting management interface plugin 41, the sensor plugins 42 and / or the externalapplication plugin 43, the decision(s) by the orchestrator may be altered, deferred or even ignored by the context builder 44. The low network KPI readings may just have been a transient or temporary effect that may not need to be acted upon immediately as the rest of the (sensor) information from the lighting management interface plugin 41, the sensor plugins 42 and / or the external-application plugin 43 do not validate or confirm the reasoning for the decision by the orchestrator.

[0093] The above-mentioned plugins 41 to 44 and 46 may by software or hardware add-ons that enable customization and adaptation to the lighting control nodes 10 of the lighting management system, the connected sensors 32, the external applications 208, and (controllers of) the mmWave radios 26, respectively.

[0094] In an example, a host application of the content engine 204 may provide services which the plugins 41-44 and 46 can use, including a way for the plugins 41-44 and 46 to register themselves with the host application and a protocol for the exchange of data with the plugins 41-44 and 46. The plugins may depend on the services provided by the host application or the host application may operate independently of the plugins 41-44 and 46, making it possible for end-users to add and update plugins dynamically without needing to make changes to the host application. The plugins 41-44 and 46 may be configured as shared libraries which get dynamically loaded at run time. Programs may also implement the plugins 41-44 and 46 by loading a directory of simple script files written in a scripting language.

[0095] At least some of the above plugins 41-44 and 46 may include or may alternatively be replaced by an application programming interface (API) which refers to a set of routines, protocols and tools for building software and applications or by another type of interface. The API or other type of interface defines how the content engine 204 interacts with the lighting control and management system 202, the network management system 206 and / or the external applications 208, facilitating communication between them.

[0096] Fig. 5 shows a flow diagram of context deriving process (as performed e.g. by the content engine 204 of Fig. 4) according to a second embodiment.

[0097] In step S501 (D-EXC), the content engine receives sensing data and / or other data (e.g., via the plugins 41, 42 and / or 44) from at least one of the lighting management system, the connected sensors 32 and the mmWave radios 26.

[0098] In step S502 (EXT-D), the content engine may gather further context-relevant data from external applications such as weather stations, public event lists, etc. (cf. Fig. 3).

[0099] Then, in step S503 (ANA), the content engine analyses (e.g., by the content builder 45 of Fig. 4) the collected data and generates enhanced context information to provide enhanced contextual insights to the network management system 206.

[0100] By processing this enhanced context information, the network management system 206 can enhance existing data models and sensing capabilities to improve network management capabilities. The procedures may include a procedure to determine a momentary quality of wireless network links of the network 100. Quality of a link may be determined based on data extracted from the network nodes and possibly processed or derived data e.g. by calculating ratios. Quality parameters may include at least one of availability, (excess) capacity of the links, latency, packet delay, signal-to-noise ratio, modular coding scheme (MCS) levels and the like. Applicability and / or usefulness of various parameters may depend on preference and technical feasibility. Extracted information from the nodes may include buffer status in the network node, traffic per link, link budget, MCS level and the like. The link quality may be recorded periodically (e.g., node reports to a central network management software (NMS) of the network design system 10 or the NMS polls such data) or can be reported by network nodes whenever certain thresholds (set points) are exceeded. The reporting of data may be initiated by the nodes themselves (push model) or may be initiated by the network design system 10 (poll model).

[0101] The analysis of the collected data and the generation of the enhanced context information (e.g., by the context builder 45) may be implemented based on software routines and / or tools that can run automatically, on a scheduled basis, or through some level of user interaction. They may be based on artificial intelligence, deterministic algorithms or any other software-based routines.

[0102] To summarize, a method and system has been described for dynamical adaptation of a streetlight-based wireless network based on local contextual data to achieve context awareness and efficiently deal with transient demand. Lighting grid sensing data for controlling a set of streetlights is leveraged by a networking domain (e.g., mmWave radios) to be able to adapt to local contextual changes. A context engine acts as a broker for exchanging sensing data between lighting and networking and may gather data from external applications (e.g., weather stations, public event lists etc.), to provide contextual insights to a network management system. Based thereon, the network management system can augment its own self-organizing network capabilities without a need for additional sensors or equipment.

[0103] While the invention has been illustrated and described in detail in the drawings and foregoing description, such illustration and description are to be considered illustrative or exemplary and not restrictive. The invention is not limited to the disclosed mesh-type communication network with sectorized nodes. It may be applied to all kinds of wireless networks that make use of wireless mmWave connections between network nodes. The mmWave radios 26 may be replaced by other wireless transceiver units (e.g., optical transceiver units in the visible or non-visible wavelength range). Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure and the appended claims. In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. A single processor or other unit may fulfil the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. The foregoing description details certain embodiments of the invention. It will be appreciated, however, that no matter how detailed the foregoing appears in the text, the invention may be practiced in many ways, and is therefore not limited to the embodiments disclosed. It should be noted that the use of particular terminology when describing certain features or aspects of the invention should not be taken to imply that the terminology is being re-defined herein to be restricted to include any specific characteristics of the features or aspects of the invention with which that terminology is associated.

[0104] A single unit or device may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

[0105] The described operations like those indicated in Fig. 5 can be implemented as program code means of a computer program and / or as dedicated hardware of the transmitter devices, receiver devices or transceiver devices, respectively. The computer program may be stored and / or distributed on a suitable medium, such as an optical storage medium or a solid- state medium, supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.

Claims

CLAIMS1. A content engine comprising:- an apparatus for supporting configuration control of a wireless network by a network management system (206), the wireless network comprising a plurality of network nodes integrated in a lighting system, wherein the apparatus comprises a context builder (45) configured to monitor context-related information received from a lighting control and management system (202) of the lighting system, the wireless network and one or more external applications (208), for deriving context information from the monitored context- related information, and for forwarding the derived context information to the network management system (206), and- at least one interface (41-44), in particular a plugin or application programming interface, for providing an adapted connection to the lighting control and management system (202), one or more sensors (32) of the lighting control and management system (202), the one or more external applications (208), and a plurality of transceiver units (26), in particular mmWave radios, of the wireless network.

2. The content engine of claim 1, wherein the context-related information comprises sensing data of the lighting control and management system (202), and wherein the apparatus is adapted to act as broker for collecting and analyzing the sensing data and for providing contextual insights to the network management system (206) for load balancing of the wireless network.

3. The content engine of claim 1 or 2, wherein the content engine is configured to use measured properties of line-of-sight, LOS, links as virtual sensors for deriving weather conditions as the context information.

4. The content engine of any one of the previous claims, wherein the one or more sensors (32) comprise one or more of a light sensor, a humidity sensor, a rain sensor, a temperature sensor, and a presence and / or movement sensor.

5. The content engine of any one of the previous claims, wherein the content engine (204) is adapted to receive radio frequency parameters from the transceiver units (26).

6. The content engine of any one of the previous claims, wherein the radio frequency parameters comprise one or more of antenna power, wireless link budget, number of wireless link paths, radio frequency link re-routing or topology change, user data traffic counters, received signal strength indicator, signal-to-noise ratio, packet drop ratio, transmitter / receiver buffer sizes, or a combination of these.

7. The content engine of any one of the previous claims, wherein the content engine (204) is adapted to receive at least one of weather information, event calendar information, social media information and public transport information from die one or more external applications (208).

8. The content engine of any one of claims 4 to 7, wherein the content engine (204) is adapted to receive at least one of lighting schedules, light pole coordinates and light identities from the lighting management and control system (202).

9. A network management system (206) comprising a content engine (204) according to any one of claims 4 to 8.

10. The network management system (206) of claim 9, configured to control the wireless network based on the context information, to configure the wireless network by at least one of transmitting and / or loading control information to network nodes, setting a tunnel layout, and setting a class of service.

11. A streetlight-based wireless network comprising a network management system (206) according to claim 9 or 10, a lighting management and control system (202) and a plurality of transceiver units (26), in particular, mmWave radios.

12. The streetlight-based wireless network of claim 11, wherein the plurality of transceiver units (26) comprise a plurality of physically separated sectors configured to establish a plurality of communication links to other network nodes.

13. A method of a content engine for supporting configuration control of a wireless network by a network management system (206), the wireless network comprising a plurality of network nodes integrated in a lighting system, wherein the method comprises: monitoring context-related information received from a lighting control and management system (202) of the lighting system, the wireless network and one or more external applications (208); deriving context information from the monitored context-related information; forwarding the derived context information to the network management system(206); and providing an adapted connection to the lighting control and management system(202), one or more sensors (32) of the lighting control and management system (202), the one or more external applications (208), and a plurality of transceiver units (26), in particular mmWave radios, of the wireless network.

14. A computer program product comprising program code for producing the steps of claim 13 when run on a computer device.

Images