How to lay out the 4g industrial routers in the project

Existing industrial routers are generally used in relatively harsh environments. Due to work needs, most of the time the router needs to run all day or for several months. In order to make the industrial router have a longer service life, the existing router. Features natural ventilation holes. However, when a router that has been running for a long time becomes hot, timely and natural heat dissipation will not play a particularly big role. Moreover, the outlet connection port of industrial routers has a fixed direction and cannot adapt to different environments at the same time. At the same time, it is difficult to repair existing industrial routers.

In the Internet of Things project, how can 4G industrial routers be deployed to achieve the dual goals of network stability and high cost performance? This problem can be solved by understanding the communication data principles of the Internet of Things network and the overall network IP communication layout.

Data routing from source to sink is an integral part of any large-scale wireless sensing and Internet of Things (IoT) solution. Unplugged and/or mobile embedded devices used in such low-power lossy network (LLN) applications are always severely limited in terms of available power. Efficient data routing is therefore critical to any long-term sustainable solution.

Many large-scale wireless data acquisition and driver-related applications use low-power embedded devices. These applications include precision agriculture, building management/industrial automation, vehicle ad hoc networks (VANETs), and urban networks/energy and water grids to build smarter cities. In these wireless sensor networks, embedded devices operate under strict energy constraints, resulting in computational, storage, and radio transmission-related constraints. They also communicate through lossy channels.

Low-power embedded devices in such applications do not operate in isolation, but are often part of a larger wireless network, often involving hundreds or thousands of other similar devices (or nodes in the field). These live nodes can enter or leave the network at any time. Therefore, wireless routing solutions should be energy efficient, scalable and autonomous.

Low-power lossy networks (LLNs) typically consist of sensors, actuators, and routers that communicate wirelessly with each other. However, unlike sensors and actuators, routers are generally not (long-term) resource constrained. The routers that connect the LLN to the broader Internet infrastructure are called LLN border routers (LBRs).

Traffic patterns and data flows within LLN are highly directional. The mode can be defined as multipoint-to-point traffic (MP2P), point-to-multipoint traffic (P2MP) or point-to-point traffic (P2P). For example, in MP2P traffic, sensing information from multiple sensing nodes is routed to Internet applications through LBR. P2MP traffic is observed when query requests are made from the Internet (outside the LLN) and routed to multiple on-site nodes through the LBR and LLN routers. P2P communication occurs when control information needs to be sent to a specific actuator or alarm information is received from a specific sensor.

The Internet Engineering Task Force (IETF) formed a Working Group (WG) to better understand energy-efficient routing protocol requirements for application scenarios such as city/city-wide networks, building automation/management systems, industrial automation systems, and home automation.

Urban Wireless Sensor Network

Many projects related to urban sensing hope to monitor and track the conditions of many of our urban resources and environments. The MIT Sensory Cities Lab is running several projects to understand “real-time cities” to monitor “removal chains,” as opposed to product supply chains, such as “Trash Speech” and “Real-time Rome.” 1 IBM has been implementing its smart city technology in more than 100 cities around the world.

Urban networking applications like this represent a special kind of LLN with a unique set of wireless routing requirements. The Rome Real Time project uses aggregated people density data from mobile telecommunications operators and GPS location data from public buses communicating via cell tower connections.

However, building a sustainable solution that allows data collection, aggregation and display requires the implementation of a low-power mesh network that can route data between devices that are wirelessly connected and powered with low-energy power supplies. The RFC document describes the key functionality and routing requirements for urban LLNs:

• Node deployment: In a typical urban network deployment, hundreds or thousands of nodes with pre-programmed functionality are deployed. Before or after rollout, the network initialization phase can include allocation of addresses, (hierarchical) roles in the network, synchronization, and determination of schedules. After rollout, in the final topology, there may be some nodes that can be connected via multiple (redundant) paths, while other nodes may rely on critical links to achieve connectivity. Routing protocols should consider these factors and support self- organization and self-configuration at the lowest possible energy cost.

• Node association and disassociation: After the initialization phase, nodes can join or leave the network at any time. Routing protocols should also be able to handle situations where a failed node may affect or jeopardize overall routing efficiency.

• Periodic measurement reporting: Most field nodes are configured to report their readings at regular intervals (hourly, daily, etc.). The calculation and selection of data routing can depend on the sensed data, the frequency of reporting, the amount of energy remaining in the node, the charging pattern of the energy scavenging node, or other factors.

• Queries for measurement reporting: External applications can initiate queries on the city network. For example, one might need to know the pollution levels at a specific point or along a given road. Round trip time is important, ie the time from initiating the query from the node to delivering the measurement data to the node. (The delay is not critical, but should be less than the reporting interval.)

• Alarm reporting: Typically, sensing nodes may measure events that are classified as alarms, typically when sensed data exceeds a threshold. The route reporting alerts must be unicast (to an LBR) or multicast (to multiple LBRs).

• Scalability: Routing protocols must be able to support field deployments of hundreds to tens of thousands of sensor nodes without deteriorating selected performance parameters below configurable thresholds.

• Parameter-constrained routing: The protocol must be able to advertise node capabilities (CPU, memory size, available battery power) that can be used for routing decisions. Live nodes are required to dynamically calculate, select and install different paths to the same destination , depending on the nature of the traffic.

• Supports autonomous and alien configuration: Given the large number of nodes, manually configuring each node is not feasible. The scale and number of possible topologies require that the network self-organizes and self-configures according to some previously defined rules and protocols, and allows for externally triggered configurations.

• Support highly directed information flow: Urban networks typically route detected data from field nodes to Internet-based applications via LBR. As nodes become spatially dispersed and data gets closer to the LBR, the traffic concentration in the nodes closest to the LBR increases, resulting in load imbalance among these nodes. Routing protocols must be able to accommodate traffic bursts by dynamically calculating and selecting multiple paths to the same destination.

• Support for multicast and anycast: Routing protocols must have an addressing scheme that can support routing to a single field device (unicast), to a collection of nodes subscribing to the same group (multicast), and to multiple all of which are addressable by the same Internet Protocol (IP) address (anycast).

• Network dynamics: Field nodes can dynamically associate, detach or disappear from the urban network. Live node dynamics should not affect routing throughout the network, so routing protocols should have appropriate update mechanisms to notify live node status changes. The protocol should use this information to perform the required routing level reorganization and reconfiguration to maintain overall routing efficiency.

• Latency: Routing protocols should support the ability to route based on different delay/delay requirements. Urban networks can tolerate delays as long as information arrival times are proportional to reporting times. (If the time is every few hours, the delay may be several seconds.)

The basic building blocks of RPL

The core of RPL is to organize its topology as a directed acyclic graph (DAG), which is divided into one or more destination-oriented DAGs (DODAG), one DODAG per receiver (see figure). Each node in a DODAG (similar to a routing device in an IoT solution) has a node rank that defines its position relative to other nodes relative to the DODAG root.

The exact method of calculating the RPL node level depends on the objective function (OF) of the DAG. OF defines how routing metrics, optimization goals and related functions are used to calculate rankings. In essence, OF determines the formation of DODAG. The RPL topology is built using control messages transmitted as ICMPv6 messages. The three key RPL control messages are:

•DODAG Information Request (DIS): DIS requests a DODAG Information Object (DIO) from the RPL node.

• DODAG Information Object (DIO): DIO contains information that allows nodes to discover RPL instances, learn about their configuration parameters, select DODAG parent sets, and maintain DODAGs.

• Targeted Advertising Object (DAO): DAO is used to propagate targeted information upward along DODAG.

To build a DODAG topology, nodes can request DIO using DIS messages, or nodes can periodically send link-local multicast DIO messages. The node then listens to the DIO and uses its information to join a new DODAG or maintain an existing DODAG. Based on the information in DIO, the node selects a parent node to minimize the path cost to the DODAG root.

in conclusion

The successful implementation of RPL can enable the IoT solution to achieve its stated target functions and goals. Within the scope of RPL, a typical goal is to construct a DODAG based on a specific OF and maintain connections to a set of hosts. RPL is specifically optimized for MP2P and P2MP traffic patterns. Nodes are stateless and minimal routing state information is stored in each node. RPL also takes into account link and node attributes when selecting paths. Furthermore, link failures do not trigger global network re-optimization.

For large-scale IoT deployments (involving thousands of nodes and distributed over a large geographical area), when routing design and implementation take into account the various functions, functions and properties available in RPL, the battery life of the IoT solution is Year.

The possibility of using IP-based networks can significantly reduce the energy and costs associated with wireless IoT communications, which would otherwise require expensive mobile tower connections and GSM/EDGE-based communications. This RPL implementation could significantly change the deployment of IoT solutions in applications such as urban sensor networks.

RPL topologies include DAGs and DODAGs with multiple roots and no loops, or DAGs rooted at a single target (no output edges).

The industrial router control system includes a circuit unit, a power circuit unit, an ARM control unit, a network unit, a Switch unit and a high-speed RS485 unit. It is characterized in that the power module unit uses ST’s special power supply U1 : PM6641. PM6641 can generate three The power supplies are 3.3V, 1.8V and 1.2V respectively. The ARM control unit uses STSPEAr320S and is divided into two channels, one RGMII is used to connect to the PHY, the other RGMII is connected to the RTL Switch; one USB is used to connect the 3G module , In addition, USB is used to convert UART; the network unit selects the PHY of U17:KSZ8081, and the high-speed RS485 unit includes a transceiver, and the baud rate of the transceiver exceeds 1Mpbs.