MODELING THE CONVEYOR-MODULAR TRANSFER OF MULTIMEDIA DATA IN A SENSOR NETWORK OF TRANSPORT SYSTEM

The paper studies the issues of distributed sensor networks interaction based on the Internet of Things architecture in the context of automated control systems design for dynamic objects of transport infrastructure. The properties of multimedia streams like digital telemetry exchange and packet data delivery between the sensor controllers of urban transport network are analyzed. A method of modifying the standard Ethernet network interface at the logical link control (LLC) sublayer on Raw Socket technology for joint transmission of multi-channel telemetry and packet data is proposed. A software simulator has been developed for conveyor-modular transfer in Python codes for Linux Ubuntu operating system based on the dynamic data structuring by the markup tags. The relevance of this work is due to the need to further improve the open system interoperability when building heterogeneous Internet of Things. As a result of the studies conducted, the use of conveyor-modular transfer (CMT) for telemetry data exchange with limited latency in urban control systems of transport safety is substantiated. The tests of the conveyor-modular simulator confirmed the relevance and logical consistency of the basic principles of encoding, transmitting and decoding multimedia data in the communication channel of the Internet of Things. The obtained results create scientific and methodological prerequisites for replenishing the existing TCP/IP stack with a new internetworking protocol with limiting delays, which can be used in conjunction with the IP protocol in real-time applications of the Internet of Things, and above all, in urban transport safety management systems

Any distributed ACS functions by exchanging telemetry data between the ACS-controller and sensor network objects in real-time mode. Such automated control systems are sensitive to data transmission delays in the control loop, [3,4]; these time delays can generate parasitic self-oscillations in the system, [5].
In the last decades, special hardware and software tools have been actively developed to build sensor networks [6,7]. Many developments of this type exhibited as proprietary commercial products; therefore, a large variety of methods, tools and protocols emerged, as well as difficulties in standardizing these products raised. In this regard, the current direction in the field of telecommunications is to further increase the interoperability of heterogeneous sensor networks while their aggregation into the infrastructure of the Internet of things.

Literature review and problem statement
In the architecture of the Internet of Things (IoT), by analogy with the TCP/IP stack for the Internet, we distinguish three main layers for the open systems interoperability.
1) The access layer of terminal sensor devices, which represent distinct segments of a sensor network (sensor access networks).
2) The aggregation layer of sensor access networks into IoT-domains.
3) The interconnection layer of geographically and/or functionally separated IoT-domains of the entire Internet of things, each of which combines several segments of sensor access networks.
Consider the main characteristics of each of these three layers of interoperability in the architecture of the Internet of Things (IoT).
The first IoT-layer (i.e. sensor access networks) is typically built on the equipment of a particular manufacturer. Thus, diverse sensor access networks often meet difficulties in coherent operation because of various technical solutions offered by competing companies. Known approach at this IoT-layer is utilization of different Ethernet modifications, aka "Real Time Ethernet" (RTE), [8]. The RTE-technologies are used for both wired and wireless communications.
The second IoT-layer (aggregation of sensor access networks into IoT-domains) is not always possible to build entirely on the equipment of one manufacturer. Therefore, at the second layer, the problem arises of joining disparate hardware/software technologies from competing manufacturers.
In the TCP/IP model of the contemporary Internet no particular layer had been designed for real-time open system interconnection. Therefore, the conjunction of heterogeneous sensor networks into a common domain acts as an intermediate sublayer in TCP/IP architecture, which is located between the access layer and the internetworking layer (denote it L1.5).
The third IoT-layer (integration of distributed sensor domains) coincides with the second layer of the TCP/IP stack (i.e. IP-layer). However, the IoT-domains interaction in real-time mode on IP-protocol does not always meet the QoS requirements in M2M systems or services (e.g. urban traffic safety management).
Known methods and protocols of telemetry data exchange in sensor networks and IoT-segments mainly support the multichannel real-time data transmission at the access layer, [9].
For the real-time Ethernet (RTE), particular mechanisms are used to synchronize individual processes of the sensor network in RTE compatible protocols. Examples of such mech-anisms are the open application protocol of the Industrial Ethernet family (EtherNet/IP, [10]), as well as the open industry standard based on the TCP/IP stack (PROFINET, [11]). One of the most popular IoT technologies is EtherCAT (industrial standard of the Industrial Ethernet family, [12]). Local sensor networks and control systems widely use the Ethernet Powerlink real-time data transfer protocol ([13]), as well as the third generation of the Serial Real time Communication System standard (SERCOS III, [14]).
The Ethernet Powerlink protocol provides for scheduling exchanges on the bus at the expense of the allocated time intervals in which access to the bus is allowed only to one of the devices. Also known is the IEEE 1588 standard, which allows synchronization of subscriber timers, [15]. A comparative analysis of the standards and protocols mentioned above is given in [16]. According to this analysis, the most widely used is the EtherCAT standard, developed by Beckhoff. The EtherCAT protocol specification is currently available only to members of the co-founders organization, which increases the cost of EtherCAT devices.
The EtherCAT protocol operates on packets transmitted within an IEEE 802. 3 Ethernet frame (with an Ethertype 88a4 field) or within a UDP/IP datagram. The EtherCAT network segment combines one master device with its MAC address and many slave devices (without their own MAC addresses). The EtherCAT segment has a logical ring topology (although the physical topology can be of any other type like bus, star, etc.).
The 802. 3 Ethernet frame payload field contains an embedded EtherCAT packet. The EtherCAT packet is indivisible and consists of a header (2 bytes) and one or more messages. The data sequence does not depend on the physical order of the nodes in the network, and the addressing can be serviced in any order. Each packet sent by the slave device sequentially traverses all the nodes of the segment with a specified time cycle.
Multicast and broadcast data transfer between final recipients is also possible, and should be implemented on the master device in the current network segment. If IP routing is not required, the EtherCAT protocol can be inserted into a UDP/IP datagram. This makes it possible to use the TCP/IP stack for addressing in EtherCAT segments.
Technological solutions offered in the telecommunications market in the field of compatibility of various IoT platforms rely primarily on the TCP/IP stack. At the same time, manufacturers provide for expansion of the address space and additional flow control capabilities in the IPv6 protocol [17]. The task of interconnection of individual segments and domains of sensor networks is partially solved by prioritizing real-time packet traffic in the known models of integrated services (IntServ) and differentiated services (DiffServ), [18]. Increasing the priority for telemetry streams reduces the overall average data latency, but variations of time delay may not be acceptable in specific M2M systems.
A wide range of IoT researches is focused on application-layer software interfaces, [19]. To increase the IoT scalability, researchers in academia and industry developed recommendations on heterogeneous IoT platforms, [20]. The problem of IoT standardization is dealt with by the Open Interconnect Consortium (OIC), AllSeen Alliance, oneM2M, OMALwM2M, ETSI M2M and other international organizations. A popular trend in IoT development is network function virtualization (NFV) on a software defined network (SDN), [21]. This approach implies an additional local controller embedded between the SDN control plane and application plane. Also, technological developments of W3C's SemanticWeb at IoT application layer, such as the Resource Description Framework (RDF) and SPARQL [22], as well as Web Ontology Language (OWL) are known, [23]. On the way of IoT globalization and transition to integrated regional networks, the interoperability provision becomes a key issue of the 21st century [24]. In [25], the authors note that solving the interoperability problem for segments and domains of the IoT network yields up to 40 % of additional economic gain.
As a part of NGN researches at the telecommunication networks department of A.S. Popov ONAT (Ukraine), the new concept of packet networks interoperability is developed, [26][27][28][29][30]. This concept provides for the adaptation of basic data link layer technologies (primarily Ethernet) and the TCP/IP stack expansion to design IoT sensor network segments. This concept relies on special protocol for conveyor-modular data transfer in real time mode with latency control (CMT) acting along with conventional IP. The CMT method targets both traditional multimedia applications (digital telephony, video conferencing, etc.) and the telemetry data exchange in IoT sensor networks. Time delays are limited in real-time applications by installing virtual connections between individual controllers of sensor networks. In particular, the adaptation of Ethernet LLC sublayer has been proposed. The CMT supports QoS provision for real-time applications at the second (internetworking) layer of the TCP/IP model. This is higher than the access layer of industry sensor networks standards (such as EtherCAT, Ethernet Powerlink and others). On the other hand, the CMT does not affect the application layer of open systems interconnection (as in the above-mentioned technologies and protocols such as NFV/SDN, RDF and OWL). The CMT based IoT interoperability provides a packet-overhead to latency-control compromise with respect to conventional real-time data encapsulation, along with the ease of inter-layer data processing. The price of such a solution is the need to further expand the standards for the most promising data link layer technologies (Ethernet, WiFi and LTE). Physical interfaces, as well as the MAC sublayer of the data link layer of the underlying technologies, do not require modification to implement the СMT protocol. To support the conveyor-modular transfer of real-time data through modified link-layer frames, several variants of the CMT protocol are described in [25][26][27][28][29][30], including, based on IEEE 802.3 wired Ethernet, IEEE 802.11 radio (WiFi), and mobile LTE communication. Analyzing related works [8-17, 19, 20, 24, 26-31] we conclude that promissing increase of IoT interoperability is available by the use of conveyor-modular transfer of multimedia data (CMT) developed in the Odessa National Academy of Telecommunications [26][27][28][29][30].
However, more researches are needed for CMT method verification and related protocol specification. An important step in network protocol enhancement is computer simulation of basic algorithms and processes of the open system interaction that underlie the proposed method.

The aim and objectives of the study
This work aims conveyor-modular transfer simulation for multimedia data processing in the IoT sensor network domain of urban transport management system. On this premise, the following tasks are considered: -Substantiation of an appropriate algorithm for multichannel telemetry transmission in urban transport management system; -Development of the data link layer interface for conveyor-modular transfer via the Ethernet frames; -The software simulation of multi-channel real-time data transfer combined with IP-packets delivery.

Substantiation of the algorithm for multichannel telemetry transmission
Consider the three-layered architecture of a distributed transport management system, Fig. 1. The first layer embraces four segments with local controllers (C1-C4) aggregated in two second layer domains. The number of segments in one domain depends on specific transport management system. For example, the first domain combines sensor networks for subordinated transport means control; the second one integrates air traffic and meteorology services, flight control, etc. The regional transport management system may also contain subsystems of road control, sea and river transport, each of which forms its own departmental domain of the sensor network on the Internet of things. The domain controller communicates with the segment controllers through some network environment. Ways to build this environment are of interest from the point of view of the interoperability problem, and are discussed further in this paper.
Any sensor network domain is a subnet on the second (aggregation) layer of IoT hierarchy. At the same time, sensor domains are entities of the 3-rd layer of IoT hierarchy incorporated through the IoT infrastructure by the central processor of sensor network, which interacts with domain controllers. Any sensor network under a common administration policy forms an IoT autonomous system (AS-IoT). Currently, the AS-IoT systems are mainly deployed on the access layer and are heterogeneous on object dynamics and QoS requirements. Today, the main protocol for interworking on the Internet is IP. However, consider the distributed objects management, IP acts as a sublayer of transport tunnel for telemetry data exchange. Other sublayers of this TCP/IP stack tunnel are UDP/TCP transport protocols along with the Real-Time Transport Protocol (RTP) and RTP control Protocol (RTCP). The distributed control system processes the upstream telemetry of sensor states and downstream telemetry of actuator commands. The IoT telemetry of sensor networks has the following properties.
1) The distinct object telemetry is mainly formed by short messages sequence.
2) The telemetry must be recurrent and low latent for sustained object control.
3) The telemetry QoS requirements widely differ depending on objects dynamics.
For instance, a modern urban traffic management system targets future unmanned vehicles control requiring millisecond or less telemetry latency. At the same time, the control subsystem of traffic lights is not so critical to the small time delays in data transmission. The telemetry time delay is formed by two main parts: 1) Unremovable latency caused by the finite time of electromagnetic wave propagation; 2) Operational delay in data processing nodes (mainly, the overall queuing time in switching/routing nodes).
An urban transport management network may include video monitoring subsystem with local data storage. However, the one-way video data transmission or streaming does not require high dynamics or strict time delay control, and therefore, can be carried out using UDP/TCP in batch mode, which is typical for IP networks. Thus, when building distributed AS-IoT, the coherence of many IoT-domains must be ensured in a wide range of QoS-requirements, along with the packet overhead minimization.
This problem solution involves integration of parallel data streams in a common physical communication channel which is divided into many heterogeneous logical subchannels (telemetry transmitted in circuit-switching mode, and data files delivered in packet-switching mode). Since different sensor networks are usually performed at the access layer on the equipment of one manufacturer, the local compatibility can be ensured within any segment. Therefore, the IoT access layer naturally allows for a large variety of competitive solutions, and objectively, it is difficult to unify. The interoperability and protocol compatibility issues mainly emerge on the second layer of IoT-hierarchy, Fig. 1. If sensor networks are compact and compatible (i. e. allocated on the common territory of one company), then a special backbone network can be created on the data link layer to aggregate these networks into domains.
The domain of a sensor network, whose entire infrastructure is subordinated to the common administration policy, is turned into an autonomous system of sensor network. So the AS-segments compatibility becomes an internal task of AS-administrator. In this case, achieving interoperability is less limited by the current standards. If the segments of a sensor network are located in different areas of the city or functionally divided, then a special network infrastructure for IoT-segments aggregation is neither technically nor economically expedient. In this case, the existing telecommunications infrastructure can be utilized based on the conventional TCP/IP protocols. Consider sensor networks interoperability. A relatively simple aggregation option is the use of IP-based Internet. To support this option, the sensor network controllers must operate on the TCP/IP platform. This approach prevails today in the IoT sensor networks.
When IP based aggregation of sensor networks, the IoT-domain loses the privilege of AS common administration policy; therefore, the sovereign admin policy is solely preserved at the access layer. Such a solution meets QoS issues in telemetry long distance delivery, because of IntServ/DiffServ models limitations. Besides, transmission the short real-time messages via the TCP/IP stack results in excessive overhead. The TCP/IP redundancy in sensor telemetry delivery is due to complicated multilayered RTP segments encapsulation (12-byte header). In turn, the RTP protocol segments are packed into UDP transport protocol segments (8-byte header). Next, UDP segments are embedded in IP packet (20byte header for IPv4). Again, IP packets are enclosed in L2 frames (i. e. Ethernet frames with 18-byte header). The total overhead of TCP/IP encapsulation is now 58 bytes. In case of 2-byte telemetry unit, the overall IoT-channel utilization yields inefficient figure of 2/(2+58)•100 %≈3.3 %.
The IP-aggregation of sensor networks turns the 3-layer IoT-architecture (Fig. 1) into a 2-layer framework, where the last two layers merged into one IP-based interworking layer. So, the sovereign admin policy drops to the layer of sensor network segments. Such a decision complicates the M2M systems design on the IoT platform. The integration of sensor network segments into IoT-domain via the public IP-network solely retains the AS-policy privilege when "transparent" telemetry traffic. This "transparency" implies telemetry latency control in a wide range of QoS requirements, as well as elimination of the conventional protocol overhead.
The sensor network domain formed by the sensor network integration through the transparent public network, can be considered as a virtual autonomous system (VAS). As noted above, the transparency of the IoT packet transporting system for telemetry traffic of sensor network segments can be achieved by conveyor-modular transfer of multimedia data (CMT, [26][27][28][29][30]). There are two principal CMT-algorithms.
The first algorithm for expanding the interoperability of the packet network provides for the introduction of one additional virtual circuit switching protocol VCP at the interworking layer (IP layer in the TCP/IP model), along with the current IP protocol (regardless of the specific IP protocol version) [26,27]. The idea of this approach is as follows. In the gateway, a simple local network with one communication channel and a pair of Ethernet network interfaces is formed. In this network, the MAC addresses of the sender and receiver are known in advance, and there is no need to switch frames to the MAC addresses of the receiver. Frames are generated by the sender and processed by the receiver using the Raw Socket Ethernet technology. The Raw Socket Ethernet enables a system programmer to independently form a frame structure, including header fields, payload, and checksum. Due to this, in a single Ethernet frame instead of the traditional IP packet and header fields, there are two blocks of data: 1) Block of real-time data of variable length (which contains a tuple of segments of real-time data from many objects, for example, telemetry from sensors of the state of control objects); 2) Packet data block (which contains one or more fragments of a common packet queue); the length of this block is dynamically calculated as the rest of the overall frame payload after the real-time telemetry block is allocated.
According to the CMT method, the Raw Socket Ethernet frames circulate in both directions of the gateway with a constant duty cycle, forming a modular transport conveyor. The maximum possible frame length (within the selected Ethernet standard) is limited by the frequency of circulation and the bandwidth of the communication channel. The specific length of each frame changes dynamically depending on its actual payload. In the absence of data on the next duty cycle, the frame is omitted. While conveyor-modular data transmission, the time delay is predetermined by frame duty cycle in a particular gateway. Real-time segments are transmitted via pre-established virtual connections based on channel resource reservation at each gateway hop. This eliminates sporadic telemetry queuing and latency deviation. The overall time delay yields the sum of all the intermediate gateway duty cycles. The considered above first algorithm of multimedia data integration with one additional virtual circuit switching protocol VCP has the following peculiarity. During each transmission cycle, a block of packet data is formed in accordance with dynamically shaped telemetry block which always occupies the first part of the frame payload. It means, that IP-packet queuing data is scheduled to the rest slot of the current frame. For this type of data scheduling, the necessary part of the queue of concatenated IP packets is truncated. Therefore, when there is a packet data queue, the frame is always full, which ensures high efficiency of communication channel utilization (more than 90 %).
The second algorithm of multimedia data integration developed in ONAT ( [29]), provides for the introduction of two additional channel switching protocols along with conventional IP protocol. The first of the two novel protocols of the second algorithm (designated as VCP) supports the above method of virtual circuits switching with time delay control. The second protocol in this algorithm (designated as LCP) is intended for fast label switching of logical connections without latency control and resource reservation (by analogy with MPLS, but implemented at the interworking layer). The LCP protocol data segments are served by known methods; however, additional gain is achieved by overhead and delays reducing.
At this stage of computer simulation of conveyor-modular transfer, we have chosen the first algorithm (with one additional protocol VCP), since its implementation is simpler and more accessible in the short term. The implementation of the second algorithm may be an actual task in the IoT sensor networks in a more distant future.

Interface development of the conveyormodular data transfer via Ethernet frames
We'll build an interface of the conveyor-modular data transfer by modified Ethernet frames on Raw Socket technology using Send and Receive function modules of Python programming environment in Linux Ubuntu operating system. The Send module runs on the sending workstation, and the Receive module -on the receiving workstation. Both modules run in admin mode. Fig. 2 shows the program code of the Send module, designed for constructing and transmission of modified Ethernet frames. The operator from socket import socket, AF_PACKET, SOCK_ RAW loads the standard socket module and defines the parameters AF_PACKET, SOCK_RAW. The last two parameters are used to build a "raw socket" at the data link layer of the TCP/IP stack, i. e. for non-standard frame formation. Fig. 3 shows the program code of the Receive module, designed to receive modified Ethernet frames generated and transmitted by the Send module described above. The import optparse, socket, time, binascii operator loads four standard modules from the Linux library. The optparse module is the parser of parameters contained in program code operators. In the BUF_SIZE=1,600 code line, the buffer size is set to 1600 bytes for receiving an Ethernet frame.   Fig. 4 shows a functional scheme of a software simulator for modeling the processes of conveyor-modular transfer of the telemetry data and packet data between sensor networks controllers in the Internet of things infrastructure. This scheme describes the simplex half of the duplex communication channel. The second simplex half of the channel is constructed similarly.
On the transmitting side of the channel, the MUX multiplexer receives a flow of segments from the Real Time Data Generator, as well as from the IP Packet Generator. From these two flows, the multiplexer forms Raw Socket Ethernet frames. Each successive frame is passed to the Send software module to be sent to the specified network interface (wired Ethernet or WiFi radio interface).
On the receiving side of the channel, the frame is received by the Receive program module and placed in the data processing buffer. Next, the DEMUX inverse multiplexing module parses the frame payload in the buffer. As a result, the buffer content is divided into a real-time data flow (Real Time Data Output) and an IP packet queue (IP-Packet Output). Real-time segments are transmitted over pre-established virtual connections (VC). Each virtual connection has a label, a fixed frequency and size of the segments. A modified Raw Socket Ethernet channel is formed by a pair of Send/Receive modules.
Consider a sensor network managing traffic safety at a complex intersection of the city's or megalopolis transport system. We'll assume that this sensor network contains three main segments according to departmental subordination: − First segment: municipal electric transport (trams, trolley buses); − Second segment: traffic police of the Ministry of Internal Affairs (manned and unmanned vehicles, motorcycles, bicycles and pedestrians with move control devices); − Third segment: traffic service (traffic lights, sound signaling devices, surveillance cameras, etc.).
Each of the three sensor network segments is an autonomous system of the access layer, and contains its own controller. The segments associate into a domain via a domain controller, which provides their interaction with the urban traffic management system. The number of sensors and controls in each segment of such an access network may be many dozens, which determines the number of parallel flows and virtual channels for telemetry data transfer. Each flow has its own characteristics in terms of possible rates and admissible delays in the control loop. For example, the speed of cars at the intersection can reach 50 km/h, cyclist'sabout 15 km/h, pedestrian's -5 km/h.
For the model description simplicity, we divide all real-time telemetry flows into three main categories.
The first group is the most dynamic flows (for example, car telemetry). We assume that each frame transmitted between the segment controllers and the domain controller contains telemetry data blocks from all sensors or actuators from the first group of streams for a particular segment of the sensor network. The delay in transmission over the physical link is approximately one duty cycle T of frame circulation. The metropolis scale delay of electromagnetic waves propagation can be neglected.
The second group consists of medium dynamic flows (for example, cyclists' telemetry). The data blocks of these streams will be placed in every even of two successively transmitted frames. The transmission delay will be 2T.
The third groupthe least dynamic flows (for example, telemetry of pedestrians and special vehicles); data blocks will be placed in every third of three successively transmitted frames. The transmission delay will be 3T.
For the convenience of visual control in the process of debugging a software simulator CMT, we will assume that all data blocks of the first category of telemetry streams are the same in size and value, and are equal to the character constant '11'. Blocks of the second category take constants '2222'; the third category '333333'. The operation of CMT multiplexer does not depend on the specific values of data blocks. The PAYLOAD size is 24 characters (maximum size is 1,506). In each frame, if there is free space, we will place a fragment of the packet queue (for example, information from surveillance cameras) in order to fully utilize the payload field. For ease of visualization, individual packages and their fragments carry the monotonous characters, for example: XXX, YYY, ZZZ, etc. The payload field formed in this way, containing telemetry data blocks and packet fragments, we designate as conveyor-transporting module (CTM). Multiplexing telemetry blocks and fragments of a packet queue in the PAYLOAD field will be performed using markup tags, each of which is formed by a combination of the reserved character "C" (command) and other symbols: C0 is the separator between the real-time data area (the initial part of the CTM module) and the packet data area (the remaining part of the CTM module); CN is the label of the telemetry data block for the Nth category of real-time streams (C1, C2, C3, etc.); CA is the beginning of the package; CC is a substitution command for transferring any tag as a data byte.
Suppose the packet queue is: Then the first six CTM modules will take the form shown in Fig. 5.
The program code of the simplified version of the MUX multiplexer is shown in Fig. 6. The MUX module is designed as a standalone program that can be used independently of the Send and Receive modules for verifying the principle of multiplexing based on the entered markup tags. The working version of the MUX module is implanted in the Send module as subroutine based on an extended list of markup tags. The first three operators in the MUX module determine the size of the CTM module, the frequency of telemetry data blocks appearance, as well as the number of characters in each data block. The operator fout = open ("/ home / user / Desktop / OutPack.txt", 'w') opens the OutPack.txt file for recording, which displays the results of the MUX module. Operator x = fin.read (1) sets the read pointer on the first character of the fin file. The DEMUX software module is in many respects similar to the MUX module and performs inverse multiplexing operation on the receiving side of the channel.

Discussion on computer simulation results
The sensor networks interoperability is a great challenge for different equipment manufacturers on the way to the Internet of Things. One of the possible approaches to sensor networks compatibility provision was proposed in the Odesa national academy of telecommunications (Ukraine) based on the conveyor-modular data transfer (CMT) at the OSI network layer. To verify the CMT method, three main tasks were set in this work.
As a result of solving the first task in Section 4 of this work, a compromise choice of the algorithm for multi-channel transmission of multimedia data and digital telemetry in sensor networks of the Internet of Things is justified. This compromise is achieved through a technically simple modification of the logical link control (LLC) sublayer in the network interfaces of one of the most popular local area network technologies Ethernet. Such a modification at the first stage of its implementation can be carried out consolidated within the framework of separate associations of autonomous systems, and does not require a complex procedure for the harmonization and adoption of international standards. The essence of the selected CMT algorithm (Odesa national academy of telecommunications) is the implementation of one additional interworking protocol (VLC virtual connection protocol) in addition to the conventional IPv4 and IPv6 protocols. The choice of such a solution allows combining two difficultly compatible methods of processing and transmitting data in one physical communication channelcircuit switching (with deterministic delay) and packet switching (with high channel resource efficiency).
The result of solving the second task (Section 5) is the development of a software interface for conveyor-modular transfer of multimedia data via the Ethernet link or WiFi radio channel. This result was achieved through the creation of two software modules in the Python language in the Linux operating system (modules Send and Receive), as well as through the use of a low-level Raw Socket Ethernet frame shaping mode.
The result of solving the third task (Section 6) is a software simulation of multimedia data transfer processes that combines the processing of real-time data (telemetry of sensor networks) and IP packets. This result was achieved by creating two software modules in the Python/Linux language (MUX and DEMUX). The MUX module multiplexes data on the transmit side of the channel, i.e. carries logical coding of telemetry blocks and fragments of IP packets in the form of formal grammar text using markup tags. The DEMUX module performs data demultiplexing, i.e. parsing of the formalized text on the receiving side of the channel. After demultiplexing, the input data stream is divided into an IP-packet queue and a multi-channel telemetry queue. The packet queue is processed by the router, and the telemetry queue is processed by the virtual connection switch.
The advantage of modeling the conveyor-modular transfer (CMT) compared to previously published results is the creation of the first working version of the software simulator, in which the processes of data multiplexing and demultiplexing at the logical link layer (LLC) are separated from the processes of cyclic data transfer via the Ethernet frames.
From the point of view of the problem formulated in Section 2, this work is the next stage in the complex of systemic research on verification of the theoretical method of conveyor-modular transfer (CMT). The results of the work confirm the logical correctness of the selected basic algorithm with one additional interworking protocol VCP (virtual connection protocol). The developed software simulator is a practical tool for a new spectrum of model experiments and specification of individual parameters of the VCP protocol.
The main limitations of the simulation of the interworking processes in the IoT networks described in the software simulator and based on it modeling results are as follows. The first limitation is a simplified visual user interface that does not allow for cognitive tracking of rather complex information processes in sensor networks. The second aspect is a small set of markup tags, which limits the number of possible channels for parallel transmission of telemetry data (up to 10 channels). The third limitation is the absence in the simulator of a built-in generator of random telemetry streams and IP packets with given statistical characteristics. In addition, the simulator described is intended only for network adapters and Ethernet interfaces.
The above limitations can be considered as shortcomings of this work from the point of view of further research. The most urgent tasks at the next stages are the improvement of the interactive graphical user interface, the extension of the logical coding language of the frame payload, the development of a methodology for modeling the information load of communication channels. Also of interest is the scaling of the principles of conveyor-modular transfer (CMT) to other local area network technologies.

Conclusions
1. In the work, the rationale and specification of the algorithm for multi-channel data transmission in a real-time transport management system at the aggregation layer of individual domains of sensor networks are carried out. The proposed algorithm is based on the sharing of packet data transmission based on the current IP protocol and the new method of conveyor-modular transfer (CMT), the protocols of which are under development.
2. To build a multiplex channel in the real-time systems of the Internet of Things, wired and wireless interfaces were developed using the Raw Socket Ethernet technology in the Python programming language in the Linux Ubuntu operating environment. The implementation of such a communication channel involves the modification of the logical link control (LLC) sublayer in Ethernet technology.
3. Software modules MUX and DEMUX in the Python/Linux environment for simulating multi-channel data transfer using the conveyor-modular transfer method were developed. Preliminary testing of these modules was carried out, which confirms the logical correctness of the proposed algorithm. Based on the simulation results, the directions for further research in the field of interconnection of sensor networks in the architecture of the Internet of Things are formulated.