AU2019206135A1

AU2019206135A1 - Organic radio network for internet of things (iot) applications

Info

Publication number: AU2019206135A1
Application number: AU2019206135A
Authority: AU
Inventors: Damian Miller
Original assignee: Julius Industrial & Scient Pty Ltd
Current assignee: Julius Industrial & Scientific Pty Ltd
Priority date: 2018-07-23
Filing date: 2019-07-21
Publication date: 2020-02-13

Abstract

The invention defined herein is a method to provide remote control and monitoring functionality using a Radio-based Local Area Network (RF-LAN) in a Hybrid Model of loT (Internet of Things) where there is a distributed network of devices interconnected using low-power radio transceivers that may all be accessible through only a limited number of connections through to the Internet. It uses the principals of orthogonal transmission and self-organization in such a way as to assist in ease of deployment, improve transmission efficiency, extend the range of the network beyond what is otherwise possible, as well as to enhance overall system robustness through the exploitation of natural redundancies. The invention is intended for applications where the cost of single Internet subscriptions may be shared among many devices, and/or for deployments where there are many devices in a particular area that require control channeled through one or more point(s). Figure 1. (above) General System Overview. Here, the Central Node may be connected through to a Cloud Based Network Application using either fixed TCP/IP link and/or through licensed 3GPP-based interfaces. Network Application ntemet Central Node (LAN Gateway) socket t~t aU Remote Node X CetrNode RF Remote Node Y Remote NodeZ E Figure 2. Example Logical Diagram of the Hybrid Model of Interconnection (HMI). In this example there are three devices actingasRemote Nodes,eachwiththeirownCommunications Objects, andadevicesupporting the Central Node containing the Virtual Objects that are images of the Objects within the Remote devices as well as its own Objects. The Objects within the Central Node are accessible through the Central Node Device Manager that is connected through the Internet to a higher-level Network Application.

Description

Background

The background of this invention is in solving the problem of distributing control and data collection when applied to applications that involve large arrays of devices that may require connection to an Internet-Based server to fulfil their primary Application needs. In such applications, limitations often exist with respect to cost of operation through subscription-based networks as well as in the cost of production, configuration and installation of the devices themselves.

In order to reduce the number of costly subscriptions to internet service providers through mobile networks or otherwise as well as to reduce the overall product cost for loT applications, a Hybrid Model of Interconnection (HMI) can be employed where a single internet connection is shared among many devices using a Local Area Network (LAN). To further reduce the cost of installation as well as to improve flexibility of deployment, the LAN solution may use Radio technology (RF-LAN) to achieve the desired interconnection.

As such applications are often battery powered; it may also be necessary for the HMI network to use only very small amounts of power to operate. To maximize the cost benefits of such an HMI network it is also preferable to maximize the transport efficiency as well as network coverage of the RF-LAN to include as many devices (or logical Nodes) as possible over as great an area as possible.

To maximize power efficiency of such a network it is necessary to first examine the main contributors to power consumption in such applications. For low power radio-based loT applications, the primary power consumer is most often the radio transmission itself. Here, the key to reduce consumption and prolong battery life is to optimize for spectral and transport efficiency relative to the needs of the system application. This includes keeping the radio transmissions as short as possible through eliminating unnecessary packet data overhead or through the use of data compression techniques, transmitting with lowest possible RF power for the distance required and to use the transmission link for as short a time as possible. In doing so, there is a need to keep the communications protocol concise but simple to reduce the number of transmissions overall, maximize the bandwidth (BW) usage to increase the speed as much as possible (hence reducing the overall time needed for transmission), eliminate any unnecessary wait times and reduce link losses using principals of orthogonal transmission.

By enabling each Node in the RF-LAN to act as an intermediary repeater of transmissions between distant Nodes that otherwise would be out of range, it can then be possible to extend the range of such a network without reducing the effective data throughput or increasing the overall power consumption too much, therefore increasing the number of devices supported. To do this in such a way that does not cause interference between Nodes whilst meeting the low power needs as described earlier requires some form of orthogonal transmission, which may be granted by one or more of the following techniques:

• Spatial diversification, i.e. when sets of Nodes are out of range from each other.

• Transmitting at different times (TDMA).

• Transmitting on different frequencies (FDMA).

• Advanced transmission contention techniques, such as Listen-Before-Talk (LBT) and transmission scheduling.

The goal of the RF-LAN is to use the above-mentioned methods of orthogonal transmission to enable a selforganizing, or Organic, Network that does not require cell planning or configuration, is extensible in the functionality it may support, is secure and robust, can be used with many devices over a large area, may be ultra-low power, and fits with the Hybrid Model of Interconnection for loT applications with an optimal lifecycle cost efficiency.

2019206135 20 Aug 2019

This network need not be intended to be used with Nodes that are mobile; however, it shall support changes in Node positioning with respect to the impact to link budgets towards other Nodes in the Network caused by momentary interference or obstructions, as well as the dynamic addition and removal of Nodes.

Summary

The invention described herein is of a self-organizing (Organic) Radio-based Local Area Network (RF-LAN) networking solution that may or may not be connected through a limited number of points to a higher-level Internet based application intended to support Internet of Things (loT) based applications.

The RF-LAN described herein is designed in such a way as to extend the natural range of the network beyond the ordinary transmission range of the Radios employed using a method of message forwarding between intermediary devices where required. To do this, it also employs the principals of orthogonal transmission and frequency hopping to increase network performance and throughput through the provision of simultaneous transmissions between network devices and automatic adjustment mechanisms to reduce inter-network interference.

Externally, this invention provides an abstracted object-orientated interface towards distributed functional objects, or device capabilities, that reside in devices throughout its network. The mechanisms used within the network include a method of automatic device and device-object discovery where distributed device functions are automatically added upon connection. This allows Internet based applications access to distributed functionality in an easy way without the need of complex configuration, as well as it provides a mechanism of functional abstraction, localized control and buffering even when remote devices are in a low power mode unable to transmit.

Benefits of the Invention

The benefits of this invention are that it:

1. uses a Hybrid model of Internet of Things (loT) where multiple Devices may be tied together using a Radio-based Local Area Network (RF-LAN) through a central device supporting an Internet connection, therefore reducing Internet subscription costs.

2. provides a means of fully automatic network configuration, supporting the principals of the organic network, therefore reducing the complexity of installation and improving ease of deployment, as well as providing a means of transport redundancy when one or more devices within the network fail.

3. It can provide external access to uniquely addressable object-orientated device functions through buffered means to support localized control autonomy, low-power operations, as well as transparent data connectivity.

4. provides a means where devices may be interconnected using low-power radio technology transmitting within an unlicensed band. This eliminates the need for cabling and for licensing fees.

5. extends the range of its RF-LAN through using techniques of message forwarding where data messages may be passed through devices that are closer to a central device with/without the Internet connection to more distant devices that would otherwise be out of range.

6. significantly reduces interference between simultaneous network transmissions by using orthogonality thus allows for numerous local network transactions to be ongoing at the same time increasing throughput efficiency.

7. allows multiple networks connected to a Network Application through different central devices to operate in the same area with limited interference. In addition, it provides automatic redundancy in this configuration where devices attached through one central device may re-attach to another in the case where a central device fails.

2019206135 20 Aug 2019

8. employs frequency hopping operation to reduce interference towards and from adjacent networks using the same frequency band, including adjacent networks employing the same or different communications protocols.

9. automatically learns and adjusts its network routing to find the most optimal solution.

10. provides a means of enabling Low Power operation as well as automatic adjustment of transmission power and receiver sensitivity to improve power consumption by devices while transmitting.

2019206135 20 Aug 2019

Detailed Description

5.1 System Overview

The invention described herein uses a Hybrid Model of Interconnection (HMI) where there is at least one logical Central Node residing on a centralized device, which may have an Internet connection towards a Network Application possibly residing in a Cloud-based server, and that also provides abstracted connection to functions within Remote Nodes that are logical representations of distributed devices through a radio-based Local Area Network (RF-LAN). This is illustrated in Figure 1.

5.1.1 Object Orientated Connection

In one embodiment of the invention, each function residing on Nodes within the RF-LAN, with the exception of the interface functionality itself, may be treated as a logical Communications Object, each individually addressable with set capabilities, and are each represented within the RF-LAN's Central Node as an independent Virtual Object to run autonomously within the Node or be readily accessible through an Internet connection by a Network Application. Virtual Objects residing in the Central Node may be responsible for monitoring the status of and performing control actions on Objects residing on Remote Nodes, for keeping an image of the last measurements reported by these Objects and/or buffering scheduled commands ready to be forwarded to the Objects at the next possible opportunity, for example when the network is at sleep to save power.

Along with other native Objects residing in the Central Node, Objects may be accessed by a higher-level network application or by other higher-level objects within the Node providing hierarchical abstraction of functional groups.

In the illustration shown in Figure 2, each Object is referenced within each device (represented as a Node) using its Object type and type-specific reference number along with the Device ID unique to each device. This is illustrated using an Object index, for example X.1.1. This allows Objects to be addressable by a higher-level network application or by other higher-level objects within the Central Node providing hierarchical abstraction of functional groups.

It is the job of the Device Controller Object (DC Obj) in each distributed Remote Node to keep track of and report upon request the capabilities that are supported by the Node through the provision of details of the Communications Objects its device contains. To enable automatic discovery of Objects within the network, a LAN Manager Object using a fixed Object ID is employed within the Central Node that can receive messages from Remote Nodes advertising their existence. Once an advertisement message is received, the LAN Manager Object may then extract the full list of Objects contained within the Remote Node and instantiate them as Virtual Objects within the Central Node.

The Device Controller Object may also contain additional functionality to record and report any Events and Alarms that may have occurred within the Node, as well as to report and set the general status and configuration of the device for which it resides.

Transfers between the Virtual Objects and the Objects distributed in Remote Nodes should occur at regular intervals (Network Activation Cycle), depending on the needs of each Object. For low power implementation, this should only need to occur very seldom, and all Objects in that case should be updated using the same interval and at approximately the same time to allow the Network to power down for the remaining time.

5.1.2 Simplified Connection of Device Applications

In a simplified embodiment of this invention, software applications residing in remote devices may be connected to higher-level software systems applications, residing in a central device or in higher-level system

2019206135 20 Aug 2019 entities accessible through a central device, through the provision of Communications Objects acting as Ports. Each Port represents a conduit where data may be transported to/from a Remote Device to/from a Central Device using the RF-LAN.

Figure 3 shows the logical view of a typical implementation of the RF-LAN comprised of a series of Nodes that allow communication either directly with a Central Node or through (an) intermediary Node(s) to/from the Central Node. Along with connection and message forwarding functionality, each Remote Node provides at least one point of communication towards the Central Node within the Device it resides in, realized as a Communications Object or Port, where each is individually reflected within the Central Device as an independent virtual instance representing its corresponding Port within the Remote Device. The purpose of the Port Mirroring within the Central Device is to help in providing functionality to manage independent Port states and to Remote Device-specific message buffering.

In this embodiment, any single Remote Node may only have one Communications Object, or Port, with respect to the RF-LAN. Addressing of the Object residing within the Remote Device's may be achieved simply through using only Device ID information, see 5.1.4.1.

5.1.3 Local Area Network Typology

The invention described herein employs an Organic routing typology. This is realized by the systematic organization of Remote Nodes as they are progressively attached to the Network according to their distance to a Central Node. This distance, referred to here as the Node's Level, is not measured in the form of physical distance, but instead by the number of re-transmissions by intermediary Nodes (or hops) required for data from an outer Node to reach the Central Node and/or vice versa. Optimally the number of re-transmissions should be kept to a minimum since it not only incurs a longer time of transaction for any single transmission, but also can limit the number of transactions overall within the network due to congestion.

Figure 4 shows a simplified example of typical deployment of Nodes within the Network.

As explained in greater detail in Section 5.2.1 below, each Node will act as both a Slave and a Master (multiplexed in the time domain) using a combination of TDMA and FDMA techniques to ensure separation between Nodes of different levels when in these different Modes, as well as Nodes on the same level when in range of each other.

Each Node will determine its own Master within the network, therefore deriving its own Level, during the Network Discovery Process before acting as a Master itself, see Section 5.2.2.1 below.

5.1.4 Identification Data

The following sub-sections detail the identification data used to address elements of the network, including the network itself.

5.1.4.1 Device ID

The Device ID information is used to address individual Nodes during network handshaking as well as it forms a basis for the Object ID. Each device produced represented as a Node shall possess a unique Device ID installed during the production process.

In one embodiment, a 48-bit Device ID is employed as follows:

Byte 0-3 (MSB)	32-bit Serial Number of Device
Byte 4-5	16-bit Device Type

2019206135 20 Aug 2019

Here, the Device Type is needed in collaboration with the Serial Number as the same Serial Number may be assigned to different device types. Device types should not be allocated to more than one type of device.

If there is no Device ID data present, or it has been deemed as corrupt through verification of internal checksums by the device itself, the Node will not attempt to connect to the Network.

5.1.4.2 OBJECT ID

For Object Orientated embodiments, see Section 5.1.1, each Function residing within a Node may be identified through a unique Object ID comprised of the Device ID, Object Type and Instance Index for when there are more than one of the same types in a single Node. This ID is primarily used to address the Communications Object for which a network transaction is intended but may also be used to establish the type of Object and for which Node the Object resides. This ID may be used within the RF-LAN, internally between hierarchical Objects within the Central Node and as a method of addressing toward a possible internet connection, if present.

Virtual Objects, contained within the Central Node, will contain the same Object ID as the Objects they mirror within Remote Nodes in the RF-LAN. It will be contained as a reference in all packets traversing the network either destined to the remote Object from the Virtual Object held within the Central Node, or vice-versa.

In one embodiment, this ID is contained within a 64-bit structure with the following parameters:

Byte 0-5 (MSB)	48-bit Device ID
Byte 6	Object Type
Byte 7 (LSB)	Object Index relative to Device.

5.1.4.3 Network ID

In order to support many different LANs, a Network ID parameter is used to identify which network the Nodes may synchronize to. In one embodiment, this ID is defined as a 32-bit network application type and may be assigned to the Node during production along with the Device ID data. The Node shall only synchronize to a network with the same Network ID.

All Central Nodes that share the same Network ID may be connected to the same higher-level Network Application where suitable controls are in place to ensure that the same Object is not addressed through more than one Central Node from the higher-level application. This is to support the concept of RF-LAN redundancy where there may be multiple Central Nodes supporting RF-LANs with the same Network ID operating within an area such that if any single Central Node fails, transactions to Objects residing in the Remote Nodes attached to it may be routed through the remaining Central Nodes where possible.

5.2 Communications Flow

5.2.1 Framing Structure

All data transmitted over the RF-LAN is done so broken up and encapsulated in the form of packets. These packets are of a finite length and will contain not only a data payload but also other information including that relating to their source and in many cases their destination, depending on the type of packet. Once packets

2019206135 20 Aug 2019 have been formulated, they will be transmitted only at set times or using Listen-Before-Talk (LBT) techniques in order to prevent unnecessary collisions.

Communications through the RF-LAN is performed using two alternating time-domain Frames that each contain a transmit window (TX), a receive window (RX) and a Frame Synchronization information window (Sync). Here, the transmit window is used by a Node to transmit packet data, if available, whereas the receive window is set aside for receiving packet data and will be aligned with the respective transmit window of the Node on the other side of the current link. The Frame Synchronization information window is used by Nodes in Master mode to send a synchronization packet and by Nodes in Slave mode to adjust their frame timing to ensure synchronization with their Master Node, as well as to collect other important data relating to the link. The order of transmit and receive windows will be different depending on whether a Node is operating in Master Mode or Slave Mode.

For Central Nodes both Frames are used in Master mode, albeit to different sub-nets of Remote Nodes. This is done to optimize the available transmission capabilities, to increase transport efficiency and to reduce network collisions.

For Remote Nodes, one Frame is used when the Node acts as a sub-net Master and the other for when it is a Slave with respect to its Master that is either the Central Node or closer in the path toward the Central Node.

The switching between Slave and Master modes upon each consecutive frame allows for downstream and upstream communications flows within the Orthogonal Domains between Nodes at the different levels, therefore with limited interference from the transmission links between adjacent nodes or nodes on lower and higher levels that are not intended to be involved in the ongoing transmissions. Here, any transmissions of data travelling from a Central Node toward an outer Remote Node is said to be travelling downstream, whereas data from Remote Nodes to the Central Node is said to be travelling upstream.

Orthogonal domains are distinguished by the frequency channel, timing and/or limitations in transmission range creating spatial barriers. The reduction of interference as a result of the orthogonal transmissions allows simultaneous transmission between different Nodes within the same network, or with Nodes on adjacent networks of the same type, including with the same Network ID, therefore improving transmission autonomy thus enhancing the overall network performance and throughput.

The example shown in Figure 5 is of a single network transaction, also illustrated in Figure 7, using different frequency channels for each hop and the two-frame timing structure to help perform the traversal through the network without interference to other levels uninvolved in the transmission. These channels must always be kept different to each other in order to achieve said transmission autonomy.

5.2.1.1 Frametiming

The frame timing is illustrated as shown in Figure 6.

The length of each frame (Tf_rame) is fixed, however will be determined by the following parameters:

• Length of the Frame Synchronization Packet including preamble and synchronization data¹ (L_sync) in bytes. From this, the Sync Packet transmission time (T_sync) may be calculated using:

Drate ¹ Preamble and synchronization data are used for transmission detection and receiver synchronization and is included in all packets transmitted over a Radio interface.

2019206135 20 Aug 2019 • Maximum time allocated to the downstream transmit window (T_dl) in seconds. This should be at least long enough to transmit the largest possible data packet used within the network and to allow for a clear channel assessment contention window, see Section 5.2.1.3.

• Maximum time allocated to the upstream transmit window (T_ui) in seconds. This should be at least long enough to transmit the largest possible data packet used within the network and to allow for a clear channel assessment contention window, see Section 5.2.1.3. In addition, to account for uplink contention, that may be caused by multiple Slave Nodes attempting to transmit at the same time, this time should be somewhat larger than that for the downstream transmit window for optimal operation.

• Guard period between windows and channel changes to allow for processing (T_gd).

• Special guard period to apply after changing channels (T_gch). This time helps to ensure that small timing inaccuracies with respect to channel change will not cause a loss of synchronization.

• Data rate of the transmission (D_rate) in bits per second.

Using the above, the total frame time (lf_rame) may be calculated as:

Tframe = Tgch + T_sync + T_dl + T_ul + T_gd X 3

Note: The three guard periods each referred to as T_gd do not necessarily need to be the same length.

5.2.1.2 Frame Synchronization

When any Node is acting in Master Mode, the Node will transmit a Frame Synchronization Packet (Frame Sync) at the beginning of the frame. When received by a Node in Slave Mode, the Slave Node uses the information contained to synchronize to the frame timing as well as obtain information relating to frequency hopping, thus helping to ensure correct time alignment of the slots in the frame and a reliable lock onto the node's Master even when changing channels as a result of the frequency hopping functionality.

To ensure correct synchronization to a Master, Frame timing accuracy is maintained and updated by Nodes in Slave Mode at regular intervals after receiving Frame Sync from the Node's Master. To assist with the Network Discovery mechanism, if the current Master is not a Central Node, then the Node will only begin transmission of its Frame Sync in Master Mode after successful registration with a node acting as Master, see Section 5.2.3. This allows the discovery process to establish and connect Nodes closest to the Central Node before Nodes further away therefore providing more remote Nodes with the most relevant choices when selecting a suitable Master.

In one embodiment, the adjustment of the Frame Timing is done by Nodes in Slave Mode using the averaged received time of the Frame Sync from their respective Masters, as calculated over more than two Frames with respect to the current Frame Timing of the Slave. This is done in order to reduce the effects of timing jitter that may be a result of varying processing delays that exist in either the transmit or receive Nodes due to higher priority processor interrupts.

5.2.1.3 Dynamic transmissions with Clear Channel Assessment

Transmission of data, either upstream or downstream, is performed asynchronously within the constraints of the transmission window for which it is intended. That is, for in a single windowed timespan, one or more packet transmission(s) may be made consecutively one after another, provided the time it takes to transmit the packet(s) fit(s) within the bounds of the respective transmission window.

In one embodiment, a process of Listen-Before-Talk is employed, where before each packet is transmitted a Clear Channel Assessment (CCA) is performed for a random duration in time, referred to as the contention

2019206135 20 Aug 2019 period, to determine whether or not another Node in range has begun transmitting. It is only when the current transmission channel is deemed unoccupied for the contention period that the transmission may be initiated. If the channel is deemed occupied, the Clear Channel Assessment is restarted at the end of the contention period using a different randomly selected contention period. This process may be repeated while there is still sufficient time left within the transmit window to transmit the packet.

This process of Listen-Before-Talk reduces the risk of transmission clashes between multiple Slaves connected to a single Master, as well as when there is interference from other links within the same network using overlapping adjacent channels or from other unrelated networks.

In order to reduce the timing overhead when using Listen-Before-Talk, when a Node is in Master Mode the Clear Channel Assessment is only required to be performed for the first packet. This may be done since when in Master Mode it should be the only Node transmitting at that time and on that frequency due to the fixed frame structure and network structure, except for other Master Nodes transmitting on possibly overlapping adjacent channels or transmissions made in other unrelated networks.

Even when using Listen-Before-Talk clashes may still occur due to, among other reasons, Nodes performing Clear Channel Assessment being out of range or each other while both being in range of the intended receiver Node. To reduce the impact of this, collision handling must still be employed through the Link Layer handling, see Section 5.2.2.1.

5.2.1.4 Frequency Band and Hopping

The network uses a technique of Frequency Hopping to help avoid continuous interference with adjacent networks and sub-nets (adjacent sets of Master and Slaves) within the same network, either of the same type or of different types. Here each Node shall send the next hop channel and a frame count per hop as data contained in each Frame Sync when the Node is in Master Mode. This data is used to ensure that its Slave Nodes know when to hop even in the event that the last Frame Sync before the hop is not received. The next hop channel shall be derived from a fixed table of possible channels and hops shall occur at regular intervals, taking into consideration the Frame Time (7}_riIme) as detailed above in Section 5.2.1.1.

In one embodiment, in order to maximize the number of possible transmission links between sub-nets as well as to maximize the potential utilization of the band in any geographical location, the number of channels may greatly exceed the maximum number of carriers that would otherwise be possible before inter-channel interference would be experienced. In other words, the band would be broken up into a high number of overlapping channels considering the bandwidth of the carrier signals containing data and the separation of the carrier center frequencies.

To assist with this by providing orthogonal separation in the time domain, the channel sequence used for frequency hopping should possess poor characteristics of self-correlation such that if the channels of two adjacent sub-nets interfere in one frame, they will unlikely interfere in the next. The tolerance for missing Frame Synchronization Packets for Slaves should also be set very high as these packets are most likely to be corrupted when multiple Master Nodes transmit at the same time when in range. In addition, all packets should contain either data concerning their destination and/or origin such that Nodes may ignore packets intended to be processed or forwarded by other Nodes. These techniques also greatly improve the network robustness.

One embodiment may also use a method of adaption that uses statistical information regarding lost packets and interference on each channel to avoid transmission conflicts with adjacent networks and improve performance. Here, when a high number of data errors are recorded on any particular channel, the Node

2019206135 20 Aug 2019 recording them will report this upwards through the network towards the Central Node such that the channel may be disabled and other channels are used instead.

2019206135 20 Aug 2019

5.2.1.5 Channel Offset Allocation

Each Slave Node will be allocated a Channel Offset by its Master that is used to set the frequency channel with respect to its Master for when it itself is in Master Mode. When the channels are changed as a result of frequency hopping, the offsets are used such that all channels are changed at the same time as when changed by the Central Node in the network.

Each Node acting as a Master will randomly select the Channel Offset for its Slaves from a list of available offsets to aid in reducing conflicts to adjacent networks and separate branches of the same network (connected through a different Master). To enable orthogonal transmissions by the Slave Nodes connected to the same Master when they are in Master Mode, the allocated Channel must be unique for each Slave tied to a single Master as well as it shall not use the same channel as the Master when it is in Slave Mode to prevent unintentional clashes of transmissions from Nodes at different levels.

On some occasions, conflicts between Nodes on different branches may still occur. These cases are described along with their case handling mechanisms in Section 5.2.4.2.

5.2.2 Transactions

Except for a select group of messages, all other messages sent within the network are performed as transactions, where each transaction shall be comprised of a command and a response. There are two subtypes of transactions corresponding to two network layers of abstraction:

• Link Layer Transactions, e.g. handshaking and Object data packet acknowledgment for transmission between two Nodes.

• Object Transactions in the form of command/response between an Object residing in a Remote Node and its Virtual Object Instance residing in the Central Node.

A typical network transaction is illustrated in Figure 7 where an Object-based transaction is propagated through several Nodes from the Virtual Object Instance to its corresponding Object residing in a Remote Node.

Each of the transaction sub-types are explained in more detail in the sub-sections below.

5.2.2.1 Link Layer Transactions

Link Layer Transactions are in place to ensure that Data is correctly sent between the Nodes at different levels within the Network. This is particularly important when there are many Nodes acting as Slaves to a single Master Node and are likely to transmit upstream data at the same time. Here, to handle collisions and interference with adjacent systems, each packet containing Object Data, as well as certain handshaking messages, transmitted between two Nodes shall be acknowledged by the receiving Node. Similarly, most handshaking packets used in the Network Discovery process will also be acknowledged.

In one embodiment to allow for this, the transmitting node will include its Device ID in the packet along with a Link-Layer Transmission Reference that is specific to the node itself. A receiving node shall then return a Transmission Acknowledgement packet using the originating Node's Device ID along with the original packet reference. Once this is received, the originating node shall remove the packet from its packet buffer and assume the transmission was a success. If the originating node does not receive an acknowledgment within a number of Frames it will retransmit the Data Packet with a random delay to reduce the possibility of reoccurring transmission clashes between Slaves when transmitting to the same Master.

To prevent multiple acknowledgments in the case of Downstream Data transmissions, each Node shall keep a database of all the child Nodes that are linked through it. When a Downstream Data transmission is received by a Node it shall first check through its database of child Nodes and only respond when the Device ID

2019206135 20 Aug 2019 contained within the Object ID of the Data matches one of its entries. In the case that no match is found it shall remain silent.

5.2.2.2 Object Transactions

On the higher layer, an Object Command may be sent from a Virtual Object instance at the Central Node towards its physical Object instance attached to a Remote Node. Once received, the Object attached to the Remote Node will perform the requested function then return back a response to its Virtual Object instance. Alternatively, the Object within the Remote Node may initiate the transaction and it will then be the Virtual Object Instance that shall reply. This will be the case when there is a data reporting subscription in place or in the case of the simplified Object model where the Objects act simply as ports.

In one embodiment, Object Transactions will comply with the following rules to assist network performance:

• All transactions are comprised of a Command and a Response, with or without additional data, where the Response shall be in the form of a positive or negative acknowledgement of the received Command. When no response is received within a set time, this will indicate that the transaction has failed.

• To reduce congestion, although many transactions may be active within the network at the same time, only a limited number of transactions per single Remote Object-Virtual Object pair should be active at any one time.

• A mechanism is in place such that when transactions are considered as failed, due to that they do not respond within the set time, but that are later returned after said time, they will not cause incorrect function.

• For any single Object to distinguish between individual transactions, taking into consideration that multiple instances of the same transaction may be received due to re-transmission on the Link Layer, Transactions include a Transaction ID. If a transaction has been received with the same transaction ID as previous transactions, the transaction may be ignored to prevent consecutive processing of the same transaction. Conversely, if a transaction response has been received that does not correspond to the current ongoing transaction(s), it may be discarded.

5.2.3 Network Discovery

The Network Discovery Procedure for each Remote Node is illustrated in Figure 8.

Each of these steps are described in the following sub-sections.

5.2.3.1 Masters Node Scan

In this step, the Node will cycle backwards through the channels using the reverse order of hops as defined by the frequency hopping table and listen for Master Frame Sync packets. It will do this for a period long enough to detect at least four Frame Sync packets from any given Master and listen on each channel for a period of time somewhat greater than the frame time (Tf_rame) to ensure that at least one Frame Sync packet will be received within the time at each frequency. In addition to ensure that transmissions are not lost when changing channels, it should only change channel when there is no incoming data detected while in this mode.

During this process, the data contained in each Frame Sync packet received correctly shall be used to build a list of potential Masters. Only Masters using the allocated Network ID shall be added to the list, as will be indicated within the Network ID Field of the data. Included in this list should be the respective Master Node's Device ID, their Network Level, the number of Slaves currently attached and their Receiver Signal Strength Indicator (RSSI) value relating to the received Frame Sync packet.

2019206135 20 Aug 2019

5.2.3.2 Selection of a Suitable Master

Once the Master Scan has completed, the list of the potential Master Nodes is evaluated. Here, a Master Node may be selected based on a score calculated using such criteria as its Network Level, number of already attached Slave Nodes to the Master, connection history and Receive Signal Strength. The Master with the highest score will be chosen.

The Network Level criteria is considered in order to reduce the number of transmission hops to/from the Central Node through intermediary Nodes. The number of already attached Slave Nodes is considered to minimize potential congestion through any one sub-net. The connection history is used in cases where ongoing problems of connection exist towards any single Node that ordinarily would be the best option. These may be caused by multi-path reflections and/or interference from adjacent systems in the region. The Receiver Signal Strength is considered as the least important criteria, however does play a role in reducing the needed transmission power to support the link.

In the event there are no Master Nodes contained in the list, a new Master Node Scan shall be performed.

5.2.3.3 Synchronization To The Master

After a Master Node has been selected, the Synchronization process shall begin. Here the Node will continue to cycle through the frequency channels in the same way as for the Master Node Scan. Once a Frame Sync packet has been received with the correct Master Device ID the Node will use the Packet's receive time² and hop counter to set its frame timing and frequency hopping control to be synchronized to the Master Node.

In the event that the Node has not received the selected Master Node's Frame Sync within a reasonable time it will restart the Master Node Scan step.

5.2.3.4 Connection Handshaking

Once synchronization with the Master Node has been established, the Node shall initiate the Connection Handshaking process. This is described below in Section 5.2.4.1.1.

5.2.3.5 Enabling of Master Transmission

Once the connection handshaking is complete and the Slave Attach command has been successfully received, the Node may then begin transmitting its Frame Sync packet, thus allowing more distant Nodes to connect to it. It shall also begin the Object Discovery process.

5.2.3.6 Object Discovery

In one embodiment, even with the physical network established, Objects contained within Remote Nodes will not be known to the Central Node unless the Remote Nodes first advertise themselves to initiate the Object Discovery process. This is the job of the Device Controller Object residing in each Remote Node.

Once the LAN Manager Object receives an advertisement from a Device Controller Object residing in a Remote Node it will instantiate a Virtual Object for that Controller, which shall then proceed to query the Remote Node's Device Controller to gather the full list of Objects contained within. The Virtual Device Controller Object will then instantiate and register each of the discovered Objects with the LAN Manager Object as well as the ² The Packet Receive time may be acquired from either the time that the Packet has started to be received or from the time the complete packet is received adding time for the transmission time of the Packet.

2019206135 20 Aug 2019

Central Node Device Controller as new Virtual Objects representing each of the remote Objects addressable by the upper system.

Only Nodes not already represented within the Central Node should be added. In the case of receiving an Advertisement from an already known Device Controller Object, the Virtual Instance of the Object may be restarted. This is to ensure process synchronization between the two objects.

For purposes of higher-level routing by a possible Network Application connected to multiple devices acting as Central Nodes, each newly instantiated Virtual Object shall also be reported through the connection to the Network Application, if present. If the Object is already registered within the Network Application however it is connected through an alternative Central Node, the Network Application will update its routing information and send a message to the alternative Central Node to remove the Object's Virtual instance. This enables the Network Application and the entire network to adapt in cases such as where new Nodes are added or they have transferred over from other Central Nodes.

5.2.3.7 Simplified Object Discovery

In the simplified embodiment described in Section 5.1.2, once a Remote Node has registered with the Network, the Port Manager and Router block illustrated in Figure 3 will create a new Communications Object representing a Port through to the Remote Node. No further actions will need to be taken.

5.2.4 Network Optimization and Conflict Resolution

In general, Nodes will continuously listen through their radios unless transmitting a packet or while in Sleep Mode. This is such that they can detect transmissions from adjacent Nodes and/or networks. Nodes shall not process packets that do not originate from their Master or from their registered Slaves, however they may perform actions after receiving them that activate mechanisms to help avoid future network transmission clashes, see Section 5.2.4.2.

In addition, in order to reduce the number of corrupted transmissions from Nodes attempting to transmit on the same frequency at the same time, transmissions should use the Listen-Before-Talk functionality describe in Section 5.2.1.3.

5.2.4.1 Organic Network Adjustment

Mechanisms to support Organic Network Adjustment are in place to ensure that the most optimal paths are established between Remote Nodes and the Central Node. There are two main scenarios that need to be handled by these mechanisms as described in the following subsections.

5.2.4.1.1 Addition of a New Node

When a new Node is added to the network, the attachment process is followed as illustrated in Figure 9Error! Reference source not found..

Once Frame Synchronization has been established, the Node will send a Node Attach Request to its Master. This will include the Node's Device ID in its Data Segment and may also contain the RSSI of packets received from the Master. In one embodiment, the RSSI information may be used by the Master to reduce transmit power along with receiver sensitivity to reduce the overall power consumption and limit unintentional interference with adjacent-channel transmissions.

Once the Master Node has received the request it may then add the Node's Device ID into a Slave Node List that can then be used evaluate which channel offset (relative to its current channel when acting as Master), see Section 0, is best for the Node to transmit on when it is in Master Mode such that the risk conflicts with

2019206135 20 Aug 2019 other Nodes in the area and that are attached to the same Master is reduced. Once selected, the Node's Master will then send the offset data to the Node using an Offset Assignment message.

Alternatively, in the case of a new Node attaching to a Central Node, the Central Node will first evaluate how many Nodes are synchronized as Slaves through each of its two Master Mode Frames. For the purpose of minimizing congestion at the Central Node, if less Nodes are attached to the alternate Frame than the current Frame that the Node is attempting to connect through, the Central Node may issue a Switch Sync Frame Order. Once received by a Node in Slave mode, the Node will immediately switch to the other Frame using a Channel Offset parameter provided in the message to set the frequency to that of the other Frame and restart the attachment process.

In addition to sending an Offset Assignment after receiving an Attach Request, the Master will also send a Restart Slaves Order to its Slaves. This is to enable organic network organization and improve routing. Here, it could be that there are more distant nodes that may make use of the Node to shorten the number of hops required to transmit Object messages between them and the Central Node, therefore improving overall network performance.

The Restart Slaves Order will cause all of the Node's Master's Slaves to issue a further order to their Slaves to restart the Network Discovery Process, which will allow them to select the most optimal Master thus ensuring the most optimal routing. This process is illustrated in Figure 10.

Each time a Slave Node is registered to a Node's Slave List, the Node where it is modified will send a Slave List Update message to its Master Node which is then used to update its own list and forward the message upwards and so on. Using this information, it is then possible for each Node toward the Central Node to know which downstream Object packets to acknowledge. It is also possible for the Central Node to evaluate the number of Nodes attached and which Nodes are to be addressed through each Frame (since the Central Node uses both Slots in Master Mode) such that it may assign any downstream messages to be transmitted in the correct Frame.

For each Node that receives a Slave Update, it will also send a Remove Redundant Slave order to each of its slaves, thus allowing any residual records of the newly attached Node to be removed from alternative transmission paths in the network.

5.2.4.1.2 Removal of a Node

When a Node is removed, more distant nodes that previously used that Node to forward their transmissions will need to route their data through another path. Here, if a Slave Node has not received the Frame Sync packet from its Master for a set period of time, it shall restart its Network Discovery Process and cease sending out Frame Sync packets of its own to its Slave Nodes. This will in turn cause those Nodes to re-enter into the Network Discovery Process.

Once a new Master has been established and the Slave Node has been registered with it, the Master shall then send a Slave Update signal as described in Section 5.2.4.1.1. This will then ensure correct routing of packets intended for the Node. This process is illustrated in Figure 11.

5.2.4.2 Automatic Frequency and Time Adjustment

Automatic Frequency and Time adjustment is sometimes necessary to avoid persistent transmission conflicts between Nodes within the same network and with transmitting devices belonging to adjacent networks. The following sub-sections detail three such scenarios in which this may occur as well as the mechanisms in place to handle them.

2019206135 20 Aug 2019

Note: only in cases where conflicts are persistent, i.e. that transmissions are consistently detected after multiple consecutive channel changes, should any of the following mechanisms be employed. Nodes attached through the RF-LAN should have a high tolerance to temporary transmission conflicts and therefore should not apply these mechanisms otherwise.

5.2.4.2.1 Conflicts Between Two Central Nodes

If two or more Central Nodes are within range of each other and transmitting on the same frequencies at the same time a conflict could occur. To prevent this, if a Central Node detects Frame Sync packets from another Device acting as a Central Node (determined through its Level information) it will synchronize its timing to the Node's Frame Sync packet and choose another frequency, therefore helping to prevent any further collisions from occurring with that Node and its Slaves. This will then force its attached Slaves to restart their Network Discovery Process and reconnect. This process is illustrated in Figure 12.

5.2.4.2.2 Conflicts Between Nodes on the Same Level

For Remote Nodes, if they detect Frame Sync packets with a Level the same as theirs while acting as a Master, or if they receive a packet while in their transmit window, they will first disable Master-mode transmissions (including Frame Sync), which will also force their Slaves to restart the Network Discovery process, then they will send a request for a new Channel to be assigned to them by their Master. The Master of the Node will then assign a new channel to the Slave and send a new Offset Assignment, but it may leave the old channel offset marked for some period as being occupied to prevent further contention if a new Slave attempts to connect. This is illustrated in Figure 13.

5.2.4.2.3 Conflicts between Nodes on Different Levels

If a Remote Node receives Sync Packets from a Node at a level higher than theirs but does not belong to their Master this could indicate that there is an adjacent Network is present or that there are two higher level Nodes in the same proximity that are in conflict. In this scenario, the Remote Node that detected the packet will report the clash to its Master.

Once received, the Master will then request a new channel from its Master. Once its Master has received this it shall assign a new channel and subsequent synchronization and connection may be restored by the Child Nodes.

This process is illustrated in Figure 14.

5.2.5 Object Handling

5.2.5.1 Polling

Each Virtual Object instance contained in the Central Node is responsible for its own polling. To ensure device status, each Virtual Device Controller Object instance may poll its counterpart at regular intervals, or when Low Power operation is enabled, upon each Network Activation Cycle. In cases where the Device Controller Object residing in the Remote Node does not receive its poll, it may assume that its virtual counterpart is no longer active or present and may reinitialize the Object Discovery Process described in Section 5.2.3.6, that is if the entire Network Discovery Process has not already restarted due to loss of synchronization.

Conversely, if a Node's Device Controller Object no longer responds for any reason, the Virtual Object representing the Object may set its status to reflect that the Objects contained within the Node are nonresponsive. This status may be reported to the higher-level Network Application, if present, to allow reconnection through an alternative Central Node. The Central Node may only remove non-responsive Objects from its registry upon initiation of a new Network Discovery Process, causing all Virtual Objects to be removed, or after receiving a removal request from the Network Application layer.

2019206135 20 Aug 2019

5.2.6 Transmission Power Handling

In one embodiment of the invention, Transmission Power and Receiver Sensitivity is regulated to reduce overall power consumption in Low Power applications.

5.2.6.1 Calculation and Adjustment of Transmission Power

The Transmission power and Receiver sensitivity play a large part in the overall power consumption of each link; therefore, it is important to optimize each transmission in such a way that there is sufficient signal yet reduce output power and receiver sensitivity as much as possible.

The needed output power for a single transmission is dependent on several factors that contribute to the overall link-budget. These include the path losses, minimum receiver sensitivity, antenna gains (both transmit and receive) among others. Using the Receiver Signal Strength Indicator (RSSI) combined with a known output power of the transmitter we can approximate the sum of all losses and therefore calculate out a suitable output power for each transmission. Here, the sum of losses (L_ALL(dB)) is simply calculated as the transmitter output power minus the RSSI (dBm). The minimum required output power to ensure correct transmission may therefore be calculated as:

^Pout = ^PRX + ^L ALL ^{+ T}

Where P_RX is the minimum receiver sensitivity and T is a tolerance factor, which may be included to ensure correct function given minor deviations.

The rules for adjusting the transmission power are as follows:

• Frame Sync packets shall always be transmitted at maximum power - to allow for new distant Nodes to connect.

• In Slave Mode, transmissions should occur using an output power that is relative only to the Master's transmission Power using the fixed-power Frame Sync packet as a reference.

• In Master Mode, transmissions should occur using an output power that is sufficient to meet the link budget for the most distant Slave Node that has registered with the Master.

• Minimum Power Levels for both Master and Slave should be re-calculated and adjusted for every 100^th frame or directly after the Network has woken from sleep.

While in performing the Network Discovery procedure, see Section 5.2.2.1, all transmissions shall be made at maximum power.

5.2.6.2 Adjustments to Receiver Sensitivity

While the Node is in Slave Mode, the Receiver Sensitivity may be reduced when the RSSI of received Frame Sync packets from the Master is at a level sufficiently higher than the minimum receiver sensitivity specified to ensure correct reception, or when it is detected that the receiver is saturating.

When the Node is in Master Mode or during the Network Discovery Process, receiver sensitivity is set to maximum at all times. This is to allow reception of distant Slave Nodes that may start up at a later time after the Network Discovery has been completed.

With the exception of the Central Node, in the event that a Remote Node has not received the Frame Sync packet for a series of consecutive Frames, it shall increase its receiver sensitivity to maximum.

5.2.7 Other Network Functions

2019206135 20 Aug 2019

At various times it is essential to perform maintenance functions within the network. These are to ensure proper synchronization as well as to automatically optimize the network as may be required when devices cease in operation.

5.2.7.1 Global Network Restart

At various times the Network may require a restart. This can be for numerous reasons such as to optimize the transmission links in case of newly introduced obstructions, device failures or otherwise.

The standard method for Global Restart is to restart the Central Node such that it is no longer sending Sync on the frequencies as expected by its Slaves. This will then in turn force each Slave to restart its Network Discovery process. Alternatively, the Central Node can issue a Slave Restart handshaking command that will be broadcast to all attached Slaves. This will achieve the much the same effect.

5.2.7.2 Network Sleep

For the purposes of Power Save in low-power devices, each Node on the network may support Network sleep. To enter into Network Sleep, a broadcast command will be issued by the Central Node and forwarded by all nodes in the Network through each of the levels, after which they should disable their communications interfaces. Depending on the needs of Functions running within each Node they may also enter into a deep sleep state for the duration.

Timing of the Network Sleep functionality is critical to prevent Nodes from losing sync when waking up. Therefore, the Sleep functionality shall be entered just before the Nodes are due to hop to the next frequency and shall take into consideration the time to receive a new Frame after the given period has elapsed.

5.2.7.3 Networktime

Since the RF-LAN uses a synchronous frame structure, a network time parameter may be added to the Frame Sync packet that provides all devices in the network with a fixed time reference relative to the Central Node and the Level of the Node receiving the sync.

Claims

6 Claims

1. The invention comprises a synchronous self-organizing network that is used as a means of access to functionality distributed in one or more remote devices, where each remote device is logically represented as a conceptual Remote Node, attached either directly or indirectly, through to one or more central device(s) that are logically represented as conceptual Central Nodes, using a RadioBased Local Area Network, referred to as RF-LAN.
2. Devices represented as Central Nodes referenced by (1) may or may not be connected to a serverbased Network Application through an Internet connection that may allow more than one connection to Central Nodes of the same or different network type.
3. When Remote Nodes are out of range of Central Nodes, the RF-LAN referenced in (1) is designed in such a way that it provides a means where it is possible for Remote Nodes to connect through intermediary Nodes that are in range of a Central Node or are in range of other Nodes in a path towards a Central Node, and automatically route messages through them by means of retransmission.
4. All messages passed in the network as defined in (1) are transmitted in the form of Packets that contain information regarding its destination, its path to allow for message forwarding by intermediary Nodes as described in (3), the direction of network traversal (upstream or downstream), as well as the message payload data. Additional data may also be included such as that required for Packet Validation in the form of a checksum and for radio receiver lock.
5. To allow traversal of messages between Remote Nodes in the arrangement described by (3) to or from a Central Node, transmission over the RF-LAN is done within the constructs of a continuous repetition, or multiplexing, of two consecutive time-based frames where one frame is used for upstream transmission, that is to and from Nodes closer to the Central Node if not the Central Node itself, and the other for downstream transmissions to and from more remote Nodes further away from the Central Node relative to the current Node.
6. Each of the two Frames described in (5) may use a different transmission frequency offset, or channel offset, and will contain time-based windows relative to the start of each Frame for transmission and reception of Packets described in (4). These windows will include an allotted time for the transmission or reception of Frame Synchronization information, a separate allotted time for Packet transmission and a separate allotted time for Packet receive. The time-based windows allow numerous consecutive packets to be transmitted within the bounds of the window timing while also making it possible to reduce transmission clashes. The use of the two different channel offsets provides a means of reducing unintentional inter-level transmission interference, when multiple Nodes are in range and therefore unable to rely on spatial diversity.
7. When in the upstream transmission Frame as described in (5), the Node is in what is defined as Slave Mode. When in the downstream transmission Frame, the Node is in what is defined as Master Mode.
8. When acting as a Central Node as defined in (1), the Node will act in Master Mode, as described in (7), for both Frames as described in (5).
9. When a Node is in Master Mode as described in (7), it will transmit a Frame Synchronization packet at the start of each Frame. This packet will be used by Remote Nodes in Slave Mode to gather data for network establishment and as a time reference for frame synchronization.
10. Remote Nodes that attach themselves to the Central Node, as described in (8), will only synchronize to one of the two Frames. A mechanism is in place that will keep the number of Remote Nodes attached through each Frame equal where possible. This mechanism is used to reduce congestion in the Network by sharing the transmission load as evenly as possible between the two Frames. Using registration information provided through the Network Discovery Process, the Central Node will know in which of the two Master Mode Frames it needs to use when transmitting messages intended for Objects within Remote Nodes.

2019206135 20 Aug 2019
11. To reduce radio interference both from and toward adjacent networks, the network described in (1) uses a frequency hopping mechanism where the transmission frequency is pseudo-randomly changed at regular intervals among a set of pre-defined frequencies, denoted as channels. Here, the Frame Synchronization Packet transmitted in each Frame, as described in (9), will contain information regarding the number of Frames before the next frequency change as well as what frequency the Node in Master Mode will change to. All Nodes within the Network referenced in (1) will use this information, as well as the synchronization using the Frame Synchronization Packet time, to attempt to change the channels they use while in Slave and Master Modes at the same time.
12. To improve network transport efficiency, to increase the number of possible attached Nodes in any single sub-net and to maximize the frequency band usage, the frequency hopping scheme as described in (11) uses a large number of frequency channels where the bandwidth of the modulated carrier for any single channel exceeds the separation of the center frequencies to its adjacent channels and the pseudo-random hopping sequence is poorly self-correlated.
13. The network defined in (1) will be established, both physically and logically, during the Network Discovery Process.
14. As part of the Network Discovery Process defined in (13), all Nodes in the network are organized according to a Level that refers to the number of (re)transmissions necessary in order for a message from a Remote Node to reach its destination in the Central Node. The Central Node always has a Level of 0. This is achieved by scanning for surrounding Nodes, placing priority to attach to Nodes with the lowest Levels (closest to the Central Node) and assigning themselves as having a Level that is always greater than the Node they attach to.
15. To ensure that intermediary Nodes within the network defined in (1) know which messages to forward on, as part of the Network Discovery Process defined in (13), each Remote Node will, after synchronization of Frames with its selected Master as described in (5), registered itself with a Central Node and/or Remote Node with a lower Level in the path towards the Central Node.
16. Multiple transmissions may occur within the network defined in (1) at the same time with limited interference between Nodes on different Levels, defined in (14), and adjacent Nodes at the same Level when they are all in Master Mode as defined in (7). This is supported during the Network Discovery Process, defined in (13), by having each Node allocated a channel offset parameter by its Master Node (the Node it is connected through towards the Central Node) that tells the Node which frequency to use based on the current frequency when using frequency hopping as described in (11) of the Master Node, when it is in Master Mode. This channel offset will be different for each Node that is attached to any single Master Node as well as different to the channel the Master Node uses when it is in Slave Mode, therefore allowing for simultaneous orthogonal transmissions using different frequency channels within the transmission area.
17. Along with employing such mechanisms as Listen Before Talk to help prevent transmission clashes, to prevent a loss or corruption of messages due to interference or otherwise, a mechanism is in place where all transmissions within the network, defined in (1), containing messages intended between Nodes within the network are acknowledged by receiving Nodes for each link of the transmission after the integrity of the transmission is verified. In the case that a single transmission is not acknowledged within a given period of time the message is retransmitted.
18. To assist in keeping transmissions orthogonal within the network defined in (1), mechanisms are in place that detect the presence of transmission links between adjacent Nodes that may cause unintentional yet persistent interference and that automatically adjust the channel or time offset, as described in (16), or the network routing, described in (14), when detected.
19. As a compliment to (18), signaling mechanisms are in place to provide a means of automatic selfreorganization for when new Nodes attach to or existing Nodes are removed from networks that have already been established. These mechanisms also allow for the Nodes in the network to adjust their

2019206135 20 Aug 2019 registration such that messages can be rerouted through new paths, when necessary or deemed more optimal.
20. To allow for network redundancy on a higher layer and to support a wider coverage area, the invention allows more than one Central Node, referenced in (1), to exist in a given area using the same Network Identity connected through the same higher layer Network Application. This provides a means of RF-LAN redundancy in the event one or more Central Nodes fail.
21. The network referenced in (1) employs mechanisms that help synchronize and separate multiple Central Nodes described in (20) to operate individual RF-LANs without conflict.
22. Functionality residing within all devices interconnected by the RF-LAN referenced by (1) is categorized and accessible by the network through the concept of individually addressable Communications Objects, or Objects, where each Object represents a logical point of communications within the network to a specific device function.
23. Objects, as defined in (22), may be of different types where each Object type contains its own unique set of operational capabilities that may be accessed through network transactions that involve predefined commands and responses specific to that Object type. Functional capabilities may include such actions as sensor measurement, data storage and control actions related to a specific functional domain.
24. Objects, as described in (22), may be individually addressed over the RF-LAN defined in (1) using a unique Object ID that is made up of a Device ID, unique for each device, an Object Type and an Object Index. The Object Index is used to individually address Objects of the same type in the case there is more than one Object of the same type existing on a single Device.
25. Objects, as defined in (22), belonging to a Remote Node will be mirrored as Virtual Objects within the device acting as the Central Node and will use the same Object ID as their counterpart Objects within the Remote Node. Virtual Objects may be addressed using this ID on a higher level within a Central Node's functional hierarchy or externally through an Internet connection by an Internet-based Network Application.
26. Virtual Object instances, as defined in (25), may perform additional processing or control operations including autonomous data acquisition through the initiation of data transfers over the RF-LAN to/from their remote counterparts.
27. Virtual Objects defined in (25) will be instantiated within the Central Node during the process of Object Discovery, which is part of the Network Discovery Process defined in (13).
28. Instantiation of Virtual Objects, as described in (25), may be done through the use of Device Controller Objects that are Communications Objects that may reside within each Remote Node in the network. Here, after the physical network is established, this Object will advertise itself to a dedicated Object residing within the Central Node known as a LAN Manager Object. Once received, the LAN Manager Object will create a Virtual instance of the Device Controller Object, which shall then proceed to extract the full list of all other Communications Objects residing in the Remote Node. Each new Communications Object found will then be instantiated in the device containing the Central Node as a Virtual Object.
29. For simpler embodiments of the RF-LAN defined in (1), each Remote Node may contain only a single Communications Object, as defined in (22), operating as a Port that transparently provides data access between the Virtual Object instances, as described in (25), of the Ports accessible through the Central Node and the Object instances of the Ports at each of the Remote Nodes in the network.
30. The RF-LAN, referenced in (1), is designed in such a way that it may be placed into a temporary Sleep State for a set period of time. This is to reduce overall power consumption as a result of network activity. Additionally, the transmissions made over the network may be done in such a way as to minimize the transmission power, hence reduce overall power consumption of devices.

2019206135 20 Aug 2019
31. The network defined in (1) can provide a Network Time parameter, which is synchronized with the Frames as described in (5). This parameter can be used for operational synchronization of distributed functionality over the network.