WO2021094187A1

WO2021094187A1 - Control module for a lifi network

Info

Publication number: WO2021094187A1
Application number: PCT/EP2020/081098
Authority: WO
Inventors: Mohammad Fal SADIKIN; Andries Van Wageningen; Piotr Polak; Muhammad Mohsin MUSIR; Sahil Sharma; Sandeep Shankaran KUMAR
Original assignee: Signify Holding B.V.
Priority date: 2019-11-12
Filing date: 2020-11-05
Publication date: 2021-05-20

Abstract

A LiFi network (100) comprises a plurality of LiFi access points (101). A control module (110) for the LiFi network (100) is configured to maintain a list (121) of current legitimate identifiers of the LiFi access points (101) in the LiFi network (100), and determine the presence of an additional LiFi access point (201) that is not an access point of the LiFi network (100) if either: (i) an identifier of a LiFi access point received at the control module (110) from an endpoint device (150) is not in the list (121) of current legitimate identifiers; or (ii) a plurality of identifiers of LiFi access points received at the control module (110) from an endpoint device (150) comprises more than one instance of the same identifier.

Description

Control module for a LiFi network

TECHNICAL FIELD

The present disclosure relates to a control module, method and endpoint device.

BACKGROUND

Light Fidelity (LiFi) refers to techniques whereby information is communicated in the form of a signal embedded in light (including for example visible light, infrared light or ultraviolet light) emitted by a light source. A signal is embedded by modulating a property of the light, which is typically the intensity of the light but may be the frequency.

US2017/0251365A1 discloses a light enabled security system for allowing a user device access to files or data on a network, each user device having a user ID and each file/data having a file/data ID. The system has a plurality of light enabled user access points for allowing access to the network via a light communication channel, each light enabled user access point is associated with a unique location ID which is used to localize file access. Additionally, geo-fencing is disclosed to only allow file access through user access points in vicinity of the user device.

SUMMARY

According to a first aspect disclosed herein, there is provided a control module for a LiFi network comprising a plurality of LiFi access points, the control module being configured to: maintain a list of current legitimate identifiers of the LiFi access points in the LiFi network, wherein each of the current legitimate identifiers in the list maintained by the control module comprises a respective value property; determine the presence of an additional LiFi access point that is not an access point of the LiFi network if either: i) an identifier of a LiFi access point received at the control module from an endpoint device is not in the list of current legitimate identifiers; update the value properties in accordance with a time property and provide the respective value properties to the LiFi access points in the LiFi network; and determine, after the updating, the presence of an additional LiFi access point if: ii) an identifier of a LiFi access point received at the control module from an endpoint device does not comprise the respective updated value property.

The additional LiFi access point may be a rogue, malicious, or unknown LiFi access point.

Preferably, the “value property” is one or more of: a random number, pseudo random number, a random string, a pseudo-random string, a nonce, and a timestamp.

Preferably, the “time property” is one or more of: a period of time, and a point in time (e.g. a time stamp). For example, a value property may be determined to be valid only during a time window (period of time) indicated by the time property.

In an example the control module is configured to determine the presence of an additional LiFi access point if: iii) a plurality of identifiers of LiFi access points received at the control module from an endpoint device comprises more than one instance of the same identifier. Advantageously, iii) comprises determining that a second instance of an identifier was received within a threshold period of time after a first instance of the same identifier.

An identifier may be determined to not comprise the respective value property if the identifier does not comprise a value property, or if the identifier comprises a value property which is not the same as the respective value property for that LiFi access point as specified in the list maintained by the control module.

In the embodiments wherein we update the value property over time, preferably the identifier comprises a time-invariant and a time-variant part. The time- invariant part is preferably a substantially time-invariant identifier part which uniquely identifies the access point in the network (and thus could be considered an identifier in its own right). This substantially time-invariant part is then accompanied by a time-variant part, which effectively functions as a proof of identity.

The time-invariant part in these embodiments is substantially time-invariant in that it could be assigned a fixed time-invariant identifier in the factory, or alternatively could be assigned a time-invariant identifier when joining the network, thereby effectively obtaining a time-invariant “session identifier” until the access point leaves the network.

It will be clear to those skilled in the art that the time-invariant part of the identifier and the time-variant part of the identifier may be embedded in data packets in a singular field, or alternatively the respective parts may be embedded in distinct fields.

A further preferred option may be to only include the time-variant part and time-invariant parts in select data packages or frames. The advantage of using distinct fields is that the time-invariant part of the identifier could be used as a commonly used identifier in a protocol stack, thereby limiting the impact of the claimed invention on bandwidth requirements. More optionally, the time-variant part is embedded in a vendors specific field allowing for further customization without affecting normal operation. Notably, including both parts in larger number of packet types will enable more elaborate verification at the cost of bandwidth.

On the other hand, if bandwidth is key, then the time-variant part could be included sparingly, preferably in those frames encountered by an endpoint when connecting to an access point, such as in beacon frames. In this manner an endpoint device can, early on report the detected identifier (both time-invariant and time-variant part) to other access points.

In an example, the control module is configured to determine the presence of an additional LiFi access point if: iv) a plurality of identifiers of LiFi access points received at the control module from an endpoint device comprises an identifier of a first LiFi access point in the LiFi network and an identifier of a second LiFi access point in the LiFi network and the first LiFi access point and second LiFi access point do not having any overlapping LiFi coverage area.

In an example, the identifiers are received by the control module from the endpoint device via one of the LiFi access points in the network.

In other examples, the identifiers are received by the control module from the endpoint device via a network other than the LiFi network.

In an example, the control module is configured to perform determining the presence of an additional LiFi access point in response to an interference level in the LiFi network surpassing a threshold interference level.

In an example, the control module is configured to output an indication of the presence of an additional LiFi access point in response to determining the presence of a rogue LiFi access point.

In an example, the control module is implemented in one or more of the LiFi access points.

In an example, the control module is implemented in a central management system of the LiFi network.

Once a rogue has been detected, the data collected in the process may be used to assist in tracking down the rogue AP. For example the detection by endpoint devices of a rogue AP in the coverage area of another legitimate AP already provides a pointer as to the possible area where the rogue AP is located. Based on this information an alert could be raised and/or service personnel could be dispatched to locate and remove the rogue AP from the facility. Here reports from the endpoint device of legitimate APs in proximity of the rogue AP may be used to localize the rogue AP. Alternatively or additionally adjacent legitimate APs may be instructed to send secured push notifications to endpoint device users regarding the presence of a rogue AP device.

According to a second aspect disclosed herein, there is provided a method of determining presence of an additional LiFi access point in an environment comprising a LiFi network having a plurality of LiFi access points, the method comprising: maintaining a list of current legitimate identifiers of the LiFi access points in the LiFi network, wherein each of the current legitimate identifiers in the list maintained by the control module comprises a respective value property; determining the presence of an additional LiFi access point that is not an access point of the LiFi network in response to: i) receiving, from an endpoint device, an identifier of a LiFi access that is not in the list of current legitimate identifiers; updating the value properties in accordance with a time property and providing the respective value properties to the LiFi access points in the LiFi network; and determining, after the updating, the presence of an additional LiFi access point (201) that is not an access point of the LiFi network in response to: ii) receiving, from an endpoint device (150), an identifier of a LiFi access point that does not comprise the respective updated value property.

In an example, the value properties may be periodically updated.

In an example, the method comprises determining the presence of an additional LiFi access point that is not an access point of the LiFi network in response to: iii) receiving, from an endpoint device, a plurality of identifiers of LiFi access points comprising more than one instance of the same identifier.

In an example, the method comprises determining the presence of an additional LiFi access point that is not an access point of the LiFi network in response to: iv) receiving, from an endpoint device, a plurality of identifiers of LiFi access points comprising an identifier of a first LiFi access point in the LiFi network and an identifier of a second LiFi access point in the LiFi network, the first LiFi access point and second LiFi access point not having any overlapping LiFi coverage area.

In an example, the method comprises determining the presence of an additional LiFi access point in response to an interference level in the LiFi network surpassing a threshold interference level. BRIEF DESCRIPTION OF THE DRAWINGS

To assist understanding of the present disclosure and to show how embodiments may be put into effect, reference is made by way of example to the accompanying drawings in which:

Fig. 1 shows schematically an example of a LiFi network;

Fig. 2 is a flow chart illustrating an example method performed by a control module of a the LiFi network; and

Fig. 3 is a flow chart illustrating another example method performed by the control module.

DETAILED DESCRIPTION

Examples described herein relate to Light Fidelity (LiFi) networks. LiFi refers to techniques whereby information is communicated in the form of signals embedded in light (including for example visible light, infrared light or ultraviolet light) emitted by a light source and received at a light detector. Depending for example on the particular wavelengths used, such techniques may also be referred to as coded light, visible light communication (VLC) or free-space optical communication (FSO).

In this context: visible light may be light that has a wavelength in the range 380nm to 740nm; infrared light may be light that has a wavelength in the range 740nm to lmm; and ultraviolet light may be light that has a wavelength in the range lOnm to 380nm. It is appreciated that there may be some overlap between these ranges. These wavelengths of light are typically blocked by physical obstructions, for example the walls of a room. Therefore, it is appreciated that the wavelengths of light used in LiFi systems are such that devices need to be in line-of-sight of each other.

In any case, a signal is embedded by modulating a property of the light, typically the intensity but optionally alternatively or additionally the frequency, according to any of a variety of suitable modulation techniques. In cases using visible light in particular, the modulation may be performed at a high enough frequency to be beyond human perception, or at least such that any visible temporal light artefacts (e.g. flicker and/or strobe artefacts) are weak enough and at sufficiently high frequencies not to be noticeable or at least to be tolerable to humans. Thus, the embedded signal does not affect the primary illumination function, i.e., so the user only perceives the overall illumination and not the effect of the data being modulated into that illumination. Hence, the light may comprise both a visible illumination contribution for illuminating a target environment (typically the primary purpose of the light), and an embedded signal for providing information into the environment (typically considered a secondary function of the light). A channel access scheme, such as for example time division multiple access (TDMA), frequency division multiple access (FDMA), code division multiple access (CDMA), etc., may be used to share the available channels between plural devices connected to the LiFi network.

Based on the modulation, the information in the LiFi coded light can be detected using any suitable light sensor. For example, the light sensor may be a photodiode. The light sensor may be a dedicated photocell (point detector), an array of photocells possibly with a lens, reflector, diffuser or phosphor converter (for lower speeds), or an array of photocells (pixels) and a lens for forming an image on the array. For example, the light sensor may be a dedicated photocell included in a dongle which plugs into a user device such as a smartphone, tablet or laptop, or the sensor may be integrated and or dual-purpose, such as an array of infrared detectors initially designed for 3D face recognition. Either way this may enable an application running on a device to receive data via the light.

A typical LiFi network comprises a plurality of LiFi access points (APs) which allow endpoint devices to connect to the LiFi network. Each AP comprises one or more light sources for outputting LiFi signals for reception by endpoint devices and one or more receivers for receiving LiFi signals from endpoint devices. For example, each light source may comprise light emitting diodes (LEDs) or laser diodes (e.g. VCSELs) for outputting modulated light (LiFi signals). The APs can be provided by purpose-built communication devices. Alternatively or additionally, and in particular in cases where visible wavelengths of light are used, the APs may be comprised in luminaries installed within an environment for the secondary purpose of providing illumination within the environment. That is, each luminaire comprises one or more light sources configured to emit a modulated visible light output providing the dual purposes of illumination and outputting LiFi signals. Each luminaire may also comprise one or more light receivers configured to demodulate received LiFi signals. Hence, a luminaire may act as a LiFi network AP.

One potential security issue for a LiFi network is that an attacker could install a “rogue” AP (i.e. an AP that is not part of the LiFi network itself) such that an endpoint device connects to the rogue AP instead of (or in addition to) a legitimate AP of the LiFi network. This may allow the attacker to hijack the communication, inject malware to the endpoint device, steal the user’s data, jam communication between the endpoint device and other (legitimate) APs, etc. Solving this problem comprises addressing some particular issues which are particular to LiFi networks. For example, the fact that LiFi signals operate on a line-of-sight basis combined with the fact that APs may commonly be installed in locations in which the APs cannot “see” one another (e.g. in the ceiling) means that it is not possible for the APs to communicate directly with one another by means of LiFi signals.

Figure 1 shows schematically a first example of a LiFi network 100 according to the present disclosure. The LiFi network 100 comprises a first AP 101a, a second AP 101b, a third LiFi access point 101c, a control module 110 and a data storage 120. The control module 110 is operatively coupled to each of the APs 101, as well as to the data storage 120. The APs 101 may have a wired “backbone” comprising a wired connection allowing each AP 101 to communicate directly with the other APs 101. As mentioned below, there is no line-of-sight LiFi link between APs 101. Also shown are an endpoint device 150, and a rogue AP 201. The rogue AP 201 in this example is connected to or part of an associated rogue network 200. Whilst only three legitimate APs 101 are shown, there may be further legitimate APs 101 in the LiFi network 100, and similarly there may be plural endpoint devices.

The control module 110 is illustrated schematically as a functional block for the purposes of explanation only. The control module 110 may be implemented in software, hardware or a combination of both software and hardware. For example, the control module 110 may be implemented as software running on a processor configured to perform the steps described herein. The control module 110 may be implemented separately from the APs 101, for example in some central controller as illustrated in Figure 1, or may be implemented in one of the APs 101. There may alternatively also be several control modules 110 implemented within the system, e.g. a control module could be provided in each room for verifying the access point integrity in that room. In this scenario a control module 110 could be a standalone device that receives information from respective access points, or could alternatively be integrated within an access point.

Each AP 101 is configured to output LiFi signals in the form of modulated light for the purposes of LiFi communication with the endpoint device 150. The endpoint device 150 may be, for example, a smart phone, a tablet computer, a laptop computer, etc. The endpoint device 150 comprises a LiFi receiver for receiving and demodulating LiFi signals from the APs. The endpoint device 150 is configured to connect to the LiFi network 100 via any available AP of the LiFi network 100 using the LiFi receiver. As mentioned above, the modulated light output by each AP 101 operates on a light-of-sight basis. This means that each AP 101 provides LiFi connectivity within a respective coverage area, which is the area covered by LiFi signals from that AP. The coverage area of each AP may be limited by the environment in which the AP is installed.

For example the coverage area may be limited by the environment itself (walls, floors, ceilings, etc.) and by objects within the environment (e.g. furniture etc.). In particular, the APs 101 do not “see” each other because they are not within line-of-sight of each other. That is, the APs 101 are not able to communicate with each other directly via LiFi. Instead, the wired backbone may be provided, as mentioned above. In the example shown in Figure 1, the endpoint device 150 is located within the coverage area of the first AP 101a, the second AP 101b, and the rogue AP 201 (discussed later below).

In the example shown in Figure 1, the environment comprises a plurality of rooms. The first AP 101a and the second AP 101b are installed in a first room 300 and the third AP 101c is installed in a second room 400 which is separated from the first room 300 by a wall which is not transparent to the light that is used in the LiFi network 100. In this example, it may be assumed that the coverage area of the first AP 101a and the second AP 101b both substantially cover the first room 300 and none of the second room 400, and that the coverage area of the third AP 101c substantially covers the second room 400 and none of the first room 300. That is, the coverage area of the first AP 101a and the second AP 101b do overlap each other, and the coverage area of the third AP 101c does not overlap with the coverage area of any other AP.

Note however that, in general, the coverage area of each AP 101 does not necessarily coincide with the entire spatial extent of the room in which it is installed. That is, the fact that the endpoint device 150 is in the same room as a particular AP 101 does not automatically or necessarily mean that the endpoint device 150 is in the coverage area of that AP 101.

Also shown in Figure 1 is a rogue AP 201. The rogue AP 201 may be part of a rogue network 200 or may be a standalone device. The rogue AP 201 is installed within the first room 300. Hence, it is assumed that the coverage area of the rogue AP 201 overlaps with the coverage area of both the first AP 101a and second AP 101b but not the third AP 101c. In this context, “rogue” means that the AP 201 is additional to the other “legitimate” APs 101 in the LiFi network 100 and is not a (legitimate) member of the LiFi network 100. The rogue AP 201 may be connected to and operated by a malicious or otherwise unknown party. In the example shown in Figure 1, the endpoint device 150 is located within the first room 300. Therefore, the endpoint device 150 is assumed to be within the coverage area of the first AP 101a, the second AP 101c, and the rogue AP 201, but not the third AP 101c.

Each legitimate access point 101 is associated with a respective identifier, ID. The identifier of each access point may be, for example, a MAC address of that access point, an identifier that is configured by a management function when starting the access point, etc. In the description below, the following notation will be used:

Access Point 101a is associated with identifier IDA;

Access Point 101b is associated with identifier IDB; and

Access Point 101c is associated with identifier IDC.

The identifiers of the APs 101 which are part of the LiFi network 100 itself may be called “legitimate” identifiers. That is, an identifier is legitimate if it is an identifier of an AP 101 which his part of the LiFi network 100 of the control module 110 (IDA, IDB and IDC in this example). Similarly, an AP 101 which is part of the LiFi network 100 of the control module 110 may be called a legitimate AP (first AP 101a, second AP 101b, and third AP 101c in this example). This terminology is used in order to distinguish the APs 101 of the LiFi network 100 from other, rogue APs 201 which are not connected to the LiFi network 100 of the control module 110.

The control module 110 is configured to maintain a list 121 of legitimate identifiers of the APs 101 of the LiFi network 100. For example, the control module 110 may store the list 121 in data storage 120, as shown in Figure 1. In this case, the list 121 comprises IDA, IDB, and IDC.

Each legitimate AP 101 is configured to emit its respective identifier via its LiFi signal, thereby to advertise its presence to endpoint devices. To do so, each legitimate AP 101 may store its identifier in a local memory (not shown). The endpoint device 150 can thereby receive the identifiers of any APs which are in range (in line-of sight). In the example of Figure 1, the endpoint device 150 will receive IDA from the first AP 101a and IDB from the second AP 101b.

The endpoint 150 in this example will also receive an identifier from the rogue AP 201. This identifier may be, for example, an identifier of the rogue AP 201 itself, or may be an identifier of one of the legitimate APs 101 which the rogue network 200 has managed to obtain.

The endpoint device 150 is configured to return any identifiers it receives to the LiFi network 100, specifically to a control module 110 of the LiFi network 100. For example, the endpoint device 150 may be configured to transmit the received identifiers via a connection separate from the LiFi network 100 (e.g. the Internet) or via the LiFi network 100 itself. In the latter case, the endpoint device 150 may broadcast the identifiers to all APs in range, or the endpoint device 150 may transmit the identifiers to a single AP. In any event, the control module 110 receives one or more identifiers from the endpoint device 150 representing the identifier(s) of any and all APs which are in range of the endpoint device 150.

The control module 110 is configured to determine the presence of a rogue AP 201 based on the identifiers received from the endpoint device 150. This may comprise the control module 110 comparing the received identifiers with the list 121 of “legitimate” identifiers of APs 101 in the LiFi network 100 which is maintained by the control module 110.

In some examples, the control module 110 may be configured to perform the step of determining presence of the rogue AP 201 in response to an interference level in the LiFi network 100 exceeding a threshold level. In normal operation, the interference within a LiFi network 100 is minimized by coordinating the APslOl. This may be performed by the control module 110 described herein, or may be performed by a management system or LiFi controller not shown in the figures. In addition, dedicated timeslots can be chosen (e.g. by the management system or by an AP) that are supposed to be interference-free. The presence of a rogue AP 201 can raise the interference level because the rogue AP 201 is likely not coordinated with the legitimate APs 101.

In the simplest example, the control module 110 is configured to determine presence of a rogue AP 201 if: a received identifier of an AP is not in the list 121 of legitimate identifiers; or if the control module 110 receives more than one instance of the same identifier from the endpoint device 150.

For example, if the control module 110 receives identifier IDX, it can determine that rogue AP 201 is present because IDX is not in the list 121. This may occur if, for example, the rogue AP 201 simply outputs its own identifier (IDX in this example).

A slightly more sophisticated rogue AP 201 may imitate the identifier of a legitimate AP 101. That is, the rogue AP 201 may output the identifier of a legitimate AP 101. For example, the rogue network 200 may have managed to obtain the identifier of one of the legitimate APs 101 either directly from the LiFi output of one of the legitimate APs 101 or from the list 121 maintained in data storage 120.

In such cases, however, the legitimate AP 101 with that identifier (which is being imitated) will continue outputting its identifier. Therefore, the control module 110 can determine presence of the rogue AP 201 in these cases if it receives more than one instance of the same identifier. For example, with reference to Figure 1, the rogue AP 201 may imitate the first legitimate AP 101a by outputting IDA. In this case, the endpoint device 150 will receive IDB and two instances of IDA. The endpoint device 150 will provide these three identifiers to the control module 110. The control module 110 can then identify that there are two instances of IDA in the received set and that therefore there is a rogue AP 201 imitating the first AP 101a.

Hence, in another example, if the control module 110 receives two (or more) instances of a legitimate identifier (e.g. IDA), then it can determine that rogue AP 201 is present because only one instance of each legitimate identifier should be expected. In this context, the control module 110 may be configured to determine presence of the rogue AP 201 only if more than one instance of the same identifier is received within a time threshold. To do so, each identifier reported by the endpoint device 150 may be associated with a timestamp. The timestamp for each identifier may be added by the APs 101, the endpoint device 150, or the control module 110. In examples, the timestamp may be: added by the APs 101 to indicate a point in time when that identifier was emitted; added by the endpoint device 150 to indicate a point in time when that identifier was received at the endpoint device 150; added by the endpoint device 150 to indicate a point in time when that identifier was emitted by the endpoint device 150; added by an AP 101 to indicate a point in time when that identifier was received by the AP 101; or added by the control module 110 to indicate when that identifier was received by the control module 110. In any case, the identifiers may comprise a respective timestamp (time-variant part). That is, each identifier has a “base” identifier (time-invariant part) and a timestamp (time-variant part).

The control module 110 may then determine that multiple instances of the same identifier have been received if a second instance of an identifier is received within a threshold period of time after a first instance of the same identifier, as indicated by the timestamps of the two instances of the identifier.

The threshold period of time (time threshold) may be explicit, e.g. one hour, one day, etc. Alternatively or additionally, the time threshold may be implicit, e.g. related to the communication from the user device 150. For example, the endpoint device 150 may provide the identifiers to the control module 110 in a single communication (e.g. as a set of identifiers), in which case the control module 110 may determine presence of the rogue AP 201 if more than one instance of the same identifier is received as part of the same communication from the endpoint device 150.

In yet further examples, the APs 101 do not advertise their identifiers all the time. Instead, the APs 101 may be configured to output their identifier only at certain points in time or during particular time windows. In such cases, the control module 110 may determine presence of a rogue AP 201 if the endpoint device 150 reports an identifier of a legitimate AP 101 which is not currently advertising (outputting) its identifier.

The period of time can be set based on a delay variation in the network 100 in order to allow for some delay which can be expected between an AP 101 advertising its identifier and final receipt by the control module 110. For example, a relatively long time window may be set which tolerates the expected delays over the backbone in which the control module 110 checks for copies of an AP identifier instance reported by an endpoint device 150.

On the other hand, a shorter time window may be used. However, this is more suitable in situations where the APs 101 are synchronized. The AP 101 outputting the identifier informs the control module 110 of the actual time of sending its identifier (output to the endpoint device 150 via LiFi) in addition to the timestamping by the receiving AP 101 (the AP 101 receiving the identifier from the endpoint device 150). Assuming that the endpoint device 150 reports the detection of an AP identifier with a relatively short delay, the sending time and the reception time should correspondingly fall within the small time window.

Note that the above assumes that the endpoint device 150 has the same notion of time as the originating AP 101. This may be achieved through synchronizing within the network 100.

Note that the above applies in cases where there is a single endpoint device 150. In cases where there are a plurality of endpoint devices, the control module 110 can identify the endpoint device 150 from which it receives the identifiers (e.g. via an identifier of the endpoint device 150 used in the communication, such as a MAC address). Hence, the control device may apply any of the above criteria on a per-device basis. That is, the control module 110 may, for example, determine presence of a rogue AP 201 if it receives multiple instances of the same identifier from the same endpoint device 150. In some examples, the control module 110 may additionally use commissioning data 122 in order to determine presence of the rogue AP 201. Commissioning data 122 is information which relates to the layout of the APs 101. Commissioning data 122 is usually obtained during installation or updating of the LiFi network 100, e.g. by a LiFi network engineer, or by the control module 110 itself. For example, the control module 110 or other control unit of a LiFi network can learn which access points have overlapping coverage area based on reports of identifiers from endpoint devices, e.g. when it is assured that there is no threat of a rogue AP.

For example, a particular endpoint device may be a “trusted” or “authorized” endpoint device, such as an endpoint device of a supervisor, IT manager, or an installer of the LiFi system 100. Such a device may have secured access to the LiFi network. In an example, the supervisor may physically check a room for the existence of any rogue APs 201. Once confirmed that there are no rogue APs 201 present, supervisor informs the control module 110 that subsequent reports of identifiers can be trusted to accurately portray the overlapping coverage of the APs 101. The supervisor may they move a trusted endpoint device around in that room to update the control module 110 on the actual situation (so that he control module 110 can then store the retrieved commissioning data).

Furthermore, such a trusted endpoint device may establish a secure connection with an access point, e.g. API, using a secure handshake based on information that only the trusted device and the (legitimate) access point know. The trusted endpoint device may also attempt to connect to a neighbor, e.g. AP2 or a rogue that mimics AP2, using the secure handshake. Only if the handshake is correct, may the control module 110 trust the neighbor relation between API and AP2, otherwise the control module 110 signals a warning that the detected neighbor AP (AP2) is rogue. Moreover, the trusted device may also report a failed handshake to the control module 110. The control module 110 may decide to trust the neighbor relation between API and AP2 only after multiple times a trusted device has reported AP2 as neighbor followed by a correct handshake with AP2, while in the meantime, the control module 110 has not received any warning.

In some examples, the coverage overlap relation between APs 101 can be determined by aggregating reports of identifiers from multiple endpoint devices 150. The Li Fi standard (ITU-T G.9991, G.vlc, hereby incorporated by reference), for example, defines a number of maximum endpoint device 150 that can connect to a single AP (e.g. 16 for each AP). Hence, there may be many endpoint device 150 reporting to a single AP 101 (either at one time, or over the course of time, e.g. days, weeks, etc.). The control module 110 may aggregate the reports in order to determine an “average” report. For example, if most of the endpoint devices 150 report the identifiers of AP 101a and AP 101b, then the control module 110 can determine that AP 101a and AP 101b share overlapping coverage, even if one or more (the minority) other endpoint device 150 do not report that this is the case. In another example, if most of the endpoint devices 150 report the existence of rogue AP 201, then the control module 110 signals a warning (determines presence of rogue AP 201).

The commissioning data 122 may be stored in the data storage 120, as shown in Figure 1, or may be stored in a separate storage device from that in which the list 121 is stored. A central control module 110 has all commissioning data available and therefore knows which APs 101 have overlapping coverage area with which other APs 101. In examples in which the control module 110 is implemented in a distributed manner, the commissioning data can be partitioned over the APs 101 for a distributed control function. For example, each AP 101 knows with which APs 101 it has overlapping coverage area. These may be called that AP’s “AP -neighbors”. An AP lOlcan also share the current value property and/or time property with its neighbor APs via the backbone.

When the control module 110 functionality is implemented at an AP 101, e.g. AP 101a, AP 101a can verify correctness of a received identifier in two ways: 1) if the identifier is a legitimate AP identifier, the AP 101a can judge whether the reported value is correct; 2) if the reported AP identifier is that of a neighbor, the AP 101a needs to be able to also know what the “state” of the neighbor AP should be. In this case, the new values or instances are shared with other neighboring APs locally via the backbone.

For example, if AP 101a receives a report from an endpoint device that detected a rogue AP 201 that mimics AP 101b, AP 101a can detect the rogue:

1) If AP 101b is not a neighbor of AP 101a;

2) If AP 101b is a neighbor of AP 101a and AP 101b has informed AP 101a of its currently-used value property and this does not match that which was reported to AP 101a.

Alternatively to 2), AP 101a may forward the reported identifier to AP 101b. AP 101b which can then perform this step.

In particular, the commissioning data 122 may comprise an indication of the overlaps (if any) between the coverage areas of legitimate APs 101. For example, the commissioning data 122 indicate that AP 101a and AP 101b have overlapping coverage area but that neither AP 101a nor API 01b shares overlapping coverage area with AP 101c. As mentioned above, the coverage area of an AP is restricted by the layout and structure of the environment. Hence, in some examples it may be assumed that each AP 101 provides coverage only within a particular room in which it is installed (i.e. not in any other rooms). Therefore, in some examples, the commissioning data 122 may indicate the room in which each of the legitimate APs 101 is installed. In the example shown in Figure 1, the commissioning data 122 would indicate that the first AP 101a and the second AP 101b are located in the first room 300 and the third AP 101c is located in the second room 400.

When the control module 110 has access to commissioning data 122 as described above, the control module 110 may additionally determine presence of a rogue AP 201 if it receives identifiers of two legitimate APs 101 that are out of range of one another, i.e. the coverage areas of the two APs 101 do not overlap, as indicated in the commissioning data 122. With reference to Figure 1, this may be the case, for example, if the rogue AP 201 is imitating the third AP 101c (by outputting IDC). The endpoint device 150 will receive IDA, IDB and IDC, and provide these identifiers to the control module 150. The control module 150 can then identify presence of rogue AP 201 based on the fact that the third AP 101c is not in range of the first AP 101a (or the second AP 101b). In other words, the control module 110 expects all the identifiers received from the endpoint device 150 to be identifiers of APs 101 located in the same room. If this is not the case, it suggests that a rogue AP 201 is present which is outputting one of the other legitimate identifiers (for an access point that is in another room or otherwise out of sight in this example).

In cases in which the control module 110 receives the identifiers from the endpoint device 150 via one of the APs 101 of the LiFi network 100, the control module 110 may additionally determine presence of a rogue AP 201 if one (or more) of the received identifiers is an identifier of a legitimate AP 101, but the coverage area of that legitimate AP 101 does not overlap with the coverage area of the AP 101 via which the identifier was received. For example, with reference to Figure 1, if the control module 110 receives IDC via the first AP 101a, it can determine presence of the rogue AP 201 because there should be no way for the endpoint device 150 to be in range of both the first AP 101a and the third AP 101c at the same time. In other words, because AP 101a and AP 101c do not have any overlapping coverage area, the endpoint device 150 should not simultaneously report detection of IDA and IDC. In this context, “simultaneously” means within a time frame which is shorter than the time required for the endpoint device 150 to move from the coverage area of AP 101a to the coverage area of AP 101c. This may be easier or more reliable than the example given above because it does not rely on the successful reception of IDA by the control module 110.

Figure 2 is a flow diagram illustrating an example method performed by the control module 110.

At S500, the control module 110 receives one or more identifiers from the endpoint device 150.

At S501, the control module 110 checks to see if all the received identifiers are legitimate. This is done by comparing the received identifiers with the list 121. If any of the received identifiers are not on the list 121, then the method proceeds to S510 and the control module 110 identifies that a rogue AP 201 is present. If all the received identifiers are on the list 121 (i.e. all the received identifiers are (apparently) legitimate identifiers), then the method proceeds to S 502.

At S502, the control module 110 checks to see if there are two or more instances of the same identifiers in the received identifiers reported by the endpoint device 150. If there are two or more instances of the same identifier, then the method proceeds to S510 and the control module 110 identifies that a rogue AP 201 is present. Otherwise (i.e. if there is only a single instance of each identifier) the method proceeds to S503. As mentioned above, the control module 110 may receive identifiers from more than one endpoint device 150. Hence, the control module 110 may be configured to identify the endpoint 150 from which it receives each identifier. In such cases, the control module 110 may check to see if there are multiple instances of the same identifier received from the same endpoint device 150 in order to determine presence of the rogue AP 201. That is, it can be expected that the control module 110 receive an instance of the same identifier from different endpoint device 150 each reporting identifiers, even when there is no rogue AP 201 present.

At S503, the control module checks to see if there are any inconsistent pairs of identifiers in the received identifiers. An inconsistent pair of identifiers is a pair of identifiers which are the identifiers for legitimate APs 101, but which do not share any overlapping coverage area (e.g. they are in different rooms). Hence, the control module 110 performs this step by accessing the commissioning data 122. For example, the control module 110 may determine, from the commissioning data 122, the room in which the AP 101 associated with each received identifier is installed. If these APs 101 are not all installed in the same room, the method proceeds to S510 and the control module 110 identifies that a rogue AP 201 is present. Otherwise (e.g. if the APs are all installed in the same room) the method proceeds to either S520 or S504 (shown in Figure 3 and described below in relation to Figure 3). Note that S503 described above is optional in that it requires the use of commissioning data 122. If no commissioning data 122 is available to the control module 110, then the method may proceed directly from S502 to S520 when the control module 110 does not identify two or more instances of the same identifier.

At S520, the control module 110 stops. In further examples, additional checks may optionally be carried out, as will now be discussed.

In some examples, the identifiers of the legitimate APs 101 each comprise a respective “value property”. That is, each identifier comprises a “base” identifier (as described above) and also a value property in addition to the base identifier. This allows the control module 110 to perform additional checks to determine presence of a rogue AP 201. The “value property” can be random number, pseudo random number, a random string, a pseudo-random string, a nonce, timestamp, etc.

The base identifiers of the APs 101 are static or semi-static. The base identifiers are therefore distinguished from the value properties in that the value properties can be easily updated on an ad-hoc basis.

The value property for each legitimate AP 101 may be stored along with the identifier for that legitimate AP 101 in the local memory (mentioned above). The control module 110 may communicate with each legitimate AP 101 in order to update the value property for that AP 110. In any case, each legitimate AP 101 in this example is configured to include the value property in its identifier which it outputs via its LiFi signal. The endpoint device 150 is configured to receive the identifiers with associated value properties from any APs in range (in a similar manner as described above) and to send those identifiers and associated value properties to the control module 110 (again, in a similar manner as described above).

The control module 110 is configured to keep track of the respective value property for each legitimate AP 101. For example, the control module 110 may associate each identifier in the list 121 it maintains with the (current) respective value property. If there is only a single value property (as described below), the control module 110 may maintain a list 121 of identifiers, but only a single instance of the (current) random number. In a similar manner to as mentioned above, the identifiers may be associated with a respective timestamp. Hence, in some examples, the identifiers comprise a “base” identifier, a value property, and a timestamp.

The control module 110 may assign a single value property to all the APs 101. The (single) value property may be updated according to a time property. The time property specifies, either explicitly or implicitly, when the value property is to be updated. That is, a value property may be determined by the control module 110 to be valid only during a time window (period of time) indicated by the time property.

In other words, a window of time can then be specified in which a reported value property is valid starting from the moment that an AP 101 advertises its identifier with that value property. After that window no report of that identifier and value property is valid until the time that an AP 101 advertises a new identifier (new value property). In short, the time threshold (or “time window”) specifies a period of time in which the identifier and value property combination is valid, and the control module 110 determines presence of rogue AP 201 if an identifier is reported from the endpoint device 150 after this period of time comprises a value property which has expired.

The time property may be a period of time. In these cases, the property value is updated after that period of time specified by the time property has elapsed. Alternatively or additionally, the time property may be a point in time (e.g. a timestamp). In these cases, the property value is updated when the current time is equal to the point in time specified by the time property. In either case, the control module 110 may update the value properties and provide the updated value properties to the APs 101. Alternatively or additionally, the control module 110 and APs 101 may be configured to autonomously update the value properties in a corresponding manner, e.g. according to a predefined rule known to both the control module 110 and the APs 101. Various examples are described below.

In a first example, the value property may be periodically updated, e.g., once a second, once a minute, once an hour, once a day, etc. In general, the more frequently the value property is updated, the harder it will be for a rogue AP 201 to spoof correctly. However, in cases where the updated value properties are transmitted to the APs 101, there is a data overhead incurred in doing so. Therefore, there is a trade-off between increased security and the limitations of the LiFi network this is therefore another advantage to: a) distributed implementation of the control module 110; and b) autonomous local updating of the value properties, as described herein.

In a first example, the control module 110 may update the value property by sending a new value property to each legitimate AP 101. The control module 110 then updates the value property for each legitimate AP 101 in the list 121 accordingly. In a second example, the value property may update according to a pre-defmed rule. In such cases, the legitimate APs 101 may be configured to autonomously update the value property as used by the legitimate APs 101. The control module 110 may be configured with the same pre defined rule and to update the value properties in the list 121 correspondingly.

In another example, the value property is a value from a predefined set. In these cases, the (current) value property is selected based on a random or pseudo-random time at which to change the value property. In this manner, the value property could be a simple sequence (0-255), but the time at which it changes is random (or pseudo-random).

An example of a pre-defmed rule is an incremental counter. Such a counter may increase by a fixed amount (e.g. one) every predefined period of time (e.g. every second, every minute, every hour, every day, etc.). A clock (e.g. UNIX time) is an example of an incremental counter. In general, the counter is a predefined series of values to use as value properties. After Nl, the next value N2=SUCC(N1) can be determine by both the control module 110 and the APs 101 according to the predefined series. For example, another way to detect an intrusion is to detect a report of ID + Nl at an AP 101, when a report of ID + N2, N2 being a SUCC(N1), was received within a certain time-window.

Another example of a pre-defmed rule is a hash of an incremental counter. For example, a secure hash algorithm (SHA) may be applied to the current time in order to generate a value property which updates every second.

Another example of a pre-defmed rule is a hash of an incremental counter which is “salted” with the identifier of the AP 101, thereby producing a different value property for each legitimate AP 101. The control module 110 is configured with the same predefined rule and is therefore able to calculate the same value property as the legitimate APs 101.

In yet another example, the time property may be dynamic. For example, the time property may be changed depending on one or more factors including, e.g. attack history, location of APs 101, etc. In a first example, when the APs 101 are located in a remote area where the “chances of attack” are higher, the time property may specify that the value properties are to update more frequently (than in another area in which the “chances of attached” are lower). The chance of attack may be determined based on previous instances in which the control module 110 has determine presence of a rogue AP 201.

In the examples given above, the value property is equal for all APs 101. One advantage of this is that it reduces the communication overhead from control module 110 to APs 101 may also reduce the time-window complexity. That is, updating of the (single) value property can be done in a single step. This means that there is a single valid time-window for the value property, irrespective of which AP 101 is considered. In other examples, the control module 110 may assign a different value property to each of the APs 101. One advantage of this is that each value property can have its own time property (i.e. update independently of the other value properties). This may be implemented, for example, in cases where the control module 110 functionality is distributed over the APs 101 and each AP 101 generates its own value property and keep track of the related time-window (via the time property) in which that value property is valid.

Hence, in such cases, the (plural) value properties may be updated according to a time property, in a similar manner to describe above. Also similarly to described above, the control module 110 may transmit a new value property to each legitimate AP 101, or each legitimate AP 101 may generate its own new value property according to a predefined schedule or rule. The control module 110 may similarly update the value property for each identifier in the list 121 when it changes (either when the control module 110 updates the value property, or the value property is changed according to the predefined schedule or rule).

Figure 3 is a flow chart illustrating additional method steps performed by the control module 110 in an example. These steps are additional to the method steps shown in Figure 2. As mentioned above, the method may proceed from S503 to S504.

At S504, the control module 110 checks whether each of the identifier(s) received from the endpoint device 150 comprises a value property. That is, the control module 110 determines whether each the identified s) received from the endpoint device 150 comprises both the “base” identifier of an AP and additional digits representing the value property. If not (if one or more of the identified s) comprises just the “base” identifier without any additional digits, the method proceeds to S510 and the control module 110 determines presence of a rogue AP 201. Otherwise (if all the received identifiers do comprise a value property) the method proceeds to S505.

At S505, the control module 110 checks whether each of the identifier(s) received from the endpoint device 150 comprises the correct value property, i.e. the expected value property for that identifier as defined in the list 121 maintained by the control module 110. If one or more of the identifiers comprises an incorrect value property, the method proceeds to S510 and the control module 110 determines presence of a rogue AP 201. This may be the case, for example, if the rogue AP 201 is attempting to imitate the identifier and value property of a legitimate AP 101 but is either behind or ahead of schedule. The more frequently the value property or value properties update, the harder it is for the rogue AP 201 to successfully output the currently-correct value property. Otherwise (if all the received identifiers have the correct value property), the method proceeds to S520.

Again, at S520, the control module 110 stops because it has determined, based on the information available to it, that the identifiers and value properties reported to it be the endpoint device 150 are at least consistent with there being no rogue AP 201.

The steps described above in Figures 2 and 3 relate to checks which can be performed by the control module 110 in order to determine presence of a rogue AP 201. The order of these steps in Figures 2 and 3 is merely an example. It is understood that the control module 110 may perform these checks in any order. For example, when value properties are used, it may be more efficient to perform S504 or S505 first.

Further, the minimum to be performed by the control module 110 is S501 and S502. The control module 110 may omit any of the other steps S503, S504, S05.

While the above has been discussed largely with reference to LiFi only, it is understood that the invention or any example therefore could also be implemented using Optical Wireless Communication, OWC, or Visible Light Communication, VLC, or similar.

It will be understood that the processor or processing system or circuitry referred to herein may in practice be provided by a single chip or integrated circuit or plural chips or integrated circuits, optionally provided as a chipset, an application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), digital signal processor (DSP), graphics processing units (GPUs), etc. The chip or chips may comprise circuitry (as well as possibly firmware) for embodying at least one or more of a data processor or processors, a digital signal processor or processors, baseband circuitry and radio frequency circuitry, which are configurable so as to operate in accordance with the exemplary embodiments. In this regard, the exemplary embodiments may be implemented at least in part by computer software stored in (non-transitory) memory and executable by the processor, or by hardware, or by a combination of tangibly stored software and hardware (and tangibly stored firmware).

Reference is made herein to data storage for storing data. This may be provided by a single device or by plural devices. Suitable devices include for example a hard disk and non-volatile semiconductor memory (including for example a solid-state drive or SSD).

Although at least some aspects of the embodiments described herein with reference to the drawings comprise computer processes performed in processing systems or processors, the invention also extends to computer programs, particularly computer programs on or in a carrier, adapted for putting the invention into practice. The program may be in the form of non-transitory source code, object code, a code intermediate source and object code such as in partially compiled form, or in any other non-transitory form suitable for use in the implementation of processes according to the invention. The carrier may be any entity or device capable of carrying the program. For example, the carrier may comprise a storage medium, such as a solid-state drive (SSD) or other semiconductor-based RAM; a ROM, for example a CD ROM or a semiconductor ROM; a magnetic recording medium, for example a floppy disk or hard disk; optical memory devices in general; etc.

The examples described herein are to be understood as illustrative examples of embodiments of the invention. Further embodiments and examples are envisaged. Any feature described in relation to any one example or embodiment may be used alone or in combination with other features. In addition, any feature described in relation to any one example or embodiment may also be used in combination with one or more features of any other of the examples or embodiments, or any combination of any other of the examples or embodiments. Furthermore, equivalents and modifications not described herein may also be employed within the scope of the invention, which is defined in the claims.

Claims

CLAIMS:

1. A control module (110) for a LiFi network comprising a plurality of LiFi access points (101a, 101b, 101c), the control module (110) being configured to: maintain a list of current legitimate identifiers of the LiFi access points in the LiFi network, wherein each of the current legitimate identifiers in the list maintained by the control module comprises a respective value property; the control module (110) configured to: determine the presence of an additional LiFi access point (201) that is not an access point of the LiFi network if: i) an identifier of a LiFi access point received at the control module from an endpoint device (150) is not in the list of current legitimate identifiers; update the value properties in accordance with a time property and provide the respective value properties to the LiFi access points in the LiFi network; and determine, after the updating, the presence of an additional LiFi access point

(201) if: ii) an identifier of a LiFi access point received at the control module from an endpoint device (150) does not comprise the respective updated value property.

2. A control module (110) according to claim 1, wherein the control module is configured to determine the presence of an additional LiFi access point (201) if: iii) a plurality of identifiers of LiFi access points received at the control module from an endpoint device (150) comprises more than one instance of the same identifier.

3. A control module (110) according to claim 1 or 2, wherein the control module is configured to determine the presence of an additional LiFi access point (201) if: iv) a plurality of identifiers of LiFi access points received at the control module from an endpoint device (150) comprises an identifier of a first LiFi access point (101a) in the LiFi network and an identifier of a second LiFi access point (101c) in the LiFi network and the first LiFi access point (101a) and second LiFi access point (101c) do not have any overlapping LiFi coverage area.

4. A control module (110) according to any of claims 1 to 3, wherein each identifier received at the control module from an endpoint device (150) is associated with a respective timestamp.

5. A control module (110) according to any of claims 1 to 4, wherein the control module is configured to perform determining the presence of an additional LiFi access point (201) in response to an interference level in the LiFi network surpassing a threshold interference level.

6. A control module (110) according to any of claims 1 to 5, wherein the control module is configured to output an indication of the presence of an additional LiFi access point (201) in response to determining the presence of a rogue LiFi access point.

7. A control module (110) according to any of claims 1 to 6, wherein the control module is implemented in one or more of the LiFi access points (101a, 101b, 101c).

8. A control module (110) according to any of claims 1 to 7, wherein the control module is implemented in a central management system of the LiFi network.

9. A method of determining presence of an additional LiFi access point (201) in an environment comprising a LiFi network having a plurality of LiFi access points (101a, 101b, 101c), the method comprising: maintaining a list of current legitimate identifiers of the LiFi access points (101a, 101b, 101c) in the LiFi network, wherein each of the current legitimate identifiers in the list maintained by the control module comprises a respective value property; and determining the presence of an additional LiFi access point (201) that is not an access point of the LiFi network in response to: i) receiving, from an endpoint device (150), an identifier of a LiFi access that is not in the list of current legitimate identifiers; updating the value properties in accordance with a time property and providing the respective value properties to the LiFi access points (101a, 101b, 101c) in the LiFi network; and determining, after the updating, the presence of an additional LiFi access point (201) that is not an access point of the LiFi network in response to: ii) receiving, from an endpoint device (150), an identifier of a LiFi access point that does not comprise the respective updated value property.

10. A method according to claim 9, comprising: determining the presence of an additional LiFi access point (201) that is not an access point of the LiFi network in response to: iii) receiving, from an endpoint device (150), a plurality of identifiers of LiFi access points comprising more than one instance of the same identifier.

11. A method according to any of claims 9 to 10, comprising determining the presence of an additional LiFi access point (201) that is not an access point of the LiFi network in response to: iv) receiving, from an endpoint device (150), a plurality of identifiers of LiFi access points comprising an identifier of a first LiFi access point (101a) in the LiFi network and an identifier of a second LiFi access point (101c) in the LiFi network, the first LiFi access point (101a) and second LiFi access point (101c) not having any overlapping LiFi coverage area.

12. A method according to any of claims 9 to 11, comprising determining the presence of an additional LiFi access point (201) in response to an interference level in the LiFi network surpassing a threshold interference level.