SYSTEM FOR COMMUNICATING A STRESS SIGNAL BY USING MESSAGE QUEUING TELEMETRY TRANSPORT FOR SENSOR NETWORK AND METHOD THEREOF

Abstract

The present invention relates to a system for communicating a stress signal by using Message Queuing Telemetry Transport for Sensor Network on road transportation. Further, the method for communicating a stress signal by using Message Queuing Telemetry Transport for Sensor Network on road transportation is also disclosed. The use of advanced communication technologies in vehicles has significantly improved the safety and security of drivers and passengers. However, the effectiveness of these technologies in sending distress signals during emergencies is often limited by various factors. This paper provides a novel design prototype for sending distress signals from vehicles using the MQTT-SN protocol over ZigBee. To the best of our knowledge, the MQTT-SN protocol is not being used in vehicle communication.

Specification

Description:FIELD OF THE INVENTION
The present invention generally relates to the field of communication system and more particularly the present invention relates to a system for communicating a stress signal by using Message Queuing Telemetry Transport for Sensor Network on road transportation. Further, the method for communicating a stress signal by using Message Queuing Telemetry Transport for Sensor Network on road transportation is also disclosed.

BACKGROUND OF THE INVENTION
A distress signal, also known as a distress call, is an internationally recognized means for obtaining help. Distress signals are communicated by transmitting radio signals, displaying a visually observable item or illumination, or making a sound audible from a distance. A distress signal indicates that a person or group of people, watercraft, aircraft, or other vehicle is threatened by a serious or imminent danger and requires immediate assistance:?PCG D-3? Use of distress signals in other circumstances may be against local or international law. An urgency signal is available to request assistance in less critical situations. For distress signalling to be the most effective, two parameters must be communicated: Alert or notification of an emergency in progress; and Position or location (or localization or pinpointing) of the party in distress.
MQTT (originally an initialism of MQ Telemetry Transport[a]) is a lightweight, publish-subscribe, machine to machine network protocol for message queue/message queuing service. It is designed for connections with remote locations that have devices with resource constraints or limited network bandwidth, such as in the Internet of Things (IoT). It must run over a transport protocol that provides ordered, lossless, bi-directional connections-typically, TCP/IP. It is an open OASIS standard and an ISO recommendation (ISO/IEC 20922). The MQTT protocol defines two types of network entities: a message broker and a number of clients. An MQTT broker is a server that receives all messages from the clients and then routes the messages to the appropriate destination clients. An MQTT client is any device (from a micro controller up to a fully-fledged server) that runs an MQTT library and connects to an MQTT broker over a network. Information is organized in a hierarchy of topics. When a publisher has a new item of data to distribute, it sends a control message with the data to the connected broker. The broker then distributes the information to any clients that have subscribed to that topic. The publisher does not need to have any data on the number or locations of subscribers, and subscribers, in turn, do not have to be configured with any data about the publishers. If a broker receives a message on a topic for which there are no current subscribers, the broker discards the message unless the publisher of the message designated the message as a retained message. A retained message is a normal MQTT message with the retained flag set to true. The broker stores the last retained message and the corresponding quality of service (QoS) for the selected topic. Each client that subscribes to a topic pattern that matches the topic of the retained message receives the retained message immediately after they subscribe. The broker stores only one retained message per topic. This allows new subscribers to a topic to receive the most current value rather than waiting for the next update from a publisher. When a publishing client first connects to the broker, it can set up a default message to be sent to subscribers if the broker detects that the publishing client has unexpectedly disconnected from the broker. Clients only interact with a broker, but a system may contain several broker servers that exchange data based on their current subscribers' topics. A minimal MQTT control message can be as little as two bytes of data. A control message can carry nearly 256 megabytes of data if needed. There are fourteen defined message types used to connect and disconnect a client from a broker, to publish data, to acknowledge receipt of data, and to supervise the connection between client and server.
A number of different types of systems and method for communicating distress signals are available in the prior art. For example, the following patents are provided for their supportive teachings and are all incorporated by reference: CN211718937U discloses an on-vehicle monitoring device belongs to vehicle safety control field. The device comprises camera devices I-IV, behavior recognition camera devices, driving assistance camera devices, mobile communication antennas, mobile communication modules, memory modules, storage modules, audio decoding modules, speakers, satellite positioning modules, satellite positioning antennas, microcontrollers, CAN transceivers, data ports, a main processor and a power module. The utility model discloses comprehensive utilization techniques such as video image and sensor realize having multidimension degree driving record, supplementary safe driving, functions such as all kinds of monitoring data collection to the safety monitoring of realization comprehensiveness such as navigating mate, vehicle, car-mounted device or goods, and integrated multiple monitoring function is in an organic whole, each hardware module resource of make full use of, and reduce cost is convenient for install and maintain.
Another prior art document, US20190173951A1 discloses a system and method of communicating with a vehicle through use of a publish-subscribe messaging protocol, wherein the vehicle includes a wireless communications device that is capable of carrying out data communications with a remote server or system through use of a messaging broker according to the publish-subscribe messaging protocol, the method including: establishing at least one connection with a messaging broker using the wireless communications device, wherein the connection is established using the publish-subscribe messaging protocol, and wherein each of the at least one connection is established by sending a connection request message from the vehicle to the messaging broker; obtaining vehicle information from at least one vehicle system module (VSM) of the vehicle; generating a publish message at the vehicle, wherein the publish message includes the obtained vehicle information; and sending the publish message from the vehicle to the messaging broker using the publish-subscribe messaging protocol.
Yet another prior art document, JP3233061B2 discloses A vehicle stop information transmitting device for transmitting stop information of a vehicle, wherein the vehicle-side device includes a vehicle position detecting means for detecting a vehicle position, and a driving condition for detecting a driving condition of the vehicle. Detecting means; updating necessity judging means for judging the necessity of updating the stop information based on the driving situation detected by the driving situation detecting means; and necessity of updating by the renewal necessity judging means. And transmission means for transmitting stop information including the vehicle position detected by the vehicle position detection means when the determination is made.The device must be updated as a device mounted on the vehicle and capable of being taken out of the vehicle. When it is determined that the stop information is sent from the transmission means, the stop information is stored in the stop information storage means, and the stop information is read out and transmitted.
Still another prior art document, US10560529B2 discloses A vehicle information and environmental monitoring compound vehicle system is provided, including a sensor device used as a mobile sensor for collecting sensory data of roads, and the sensor device integrates various sensor modules and the second-generation on board computer diagnostic system serial port. The sensor device also integrates a long-distance low-power Internet of Things (LoRa) communication protocol, which can transmit data through the long-distance low-power Internet of Things gateway, and upload data to the cloud platform based on algorithm.
Yet another prior art document, WO2007024989A2 discloses a system for monitoring vehicle operating data and transmitting same to a central processing center. The central processing center analyzes the received data and transmits the analyzed data to other vehicles.
Still another prior art document, US7190260B2 discloses A vehicle anti-collision system and method for is disclosed which provides drivers with additional time in which to react to significant roadway events which often precede accidents. The simplest implementation of the system and method (Phase I) employs a brake pedal mounted sensor packet for determining how hard a driver is braking. Hard braking information is relayed to approaching drivers by means of the reverse lights of the vehicle. Additional implementation phases (II through IV) are described wherein event information is communicated between vehicles over a communications link. Furthermore, additional vehicle information, such as an impact, swerving, emergency light activation, and roadway hazards may be communicated to approaching drivers by the communications link whereby drivers need not see the vehicle that has slammed on its brakes, or otherwise has created or responded to an event, in order to avoid an accident.
However, above mentioned references and many other similar references have one or moreof the following shortcomings: (a) Not discloses MQTT-SN; (b) not disclosing zigbee modules; (c) complex system; (d) lack of faster and easy to transfer distress signals; and (d) reliability on communicating distress signals.
The present application addresses the above-mentioned concerns and shortcomings (another similar concerns/shortcomings) about providing a method for communicating a stress signal by using Message Queuing Telemetry Transport for Sensor Network on road transportation and system thereof.
SUMMARY OF THE INVENTION:
In the view of the foregoing disadvantages inherent in the known types of systems and methods for communicating distress signals present in the prior art, the present invention provides an improved system and method for communicating a stress signal by using Message Queuing Telemetry Transport for Sensor Network on road transportation. Moreover, the present system enables quick and easy designing and communicating distress signals. As such, the general purpose of the present invention, which will be described subsequently in greater detail, is to provide a new and improved system for communicating a stress signal by using Message Queuing Telemetry Transport for Sensor Network (MQTT-SN) on road transportation.
The main aspect of the present invention is to provide a system (100) for communicating a stress signal by using Message Queuing Telemetry Transport for Sensor Network on road transportation comprising: a person travelling in a client vehicle (101); a plurality of forwarder vehicles (102A, 102B, 102C) assisting in forwarding said stress signal; a plurality of emergency vehicles (103) which helps in providing services; a control center (104); a plurality of infrastructure poles (105) for helping communication; wherein said client vehicle (101) and said plurality of forwarder vehicles (102A, 102B, 102C) comprising Zigbee transceivers, wherein said ZigBee transceivers connected with a vehicle's on board system; and wherein said infrastructure poles (105) which receives a message from an MQTT-SN client vehicle or forwarder vehicles over said ZigBee transceivers and forwarding it to said control center.
Another aspect of the present invention is to provide the system (100) for communicating a stress signal by using Message Queuing Telemetry Transport for Sensor Network on road transportation, wherein said system generates a client ID which is a unique identifier used by clients.
Still another aspect of the present invention is to provide the system (100) for communicating a stress signal by using Message Queuing Telemetry Transport for Sensor Network on road transportation, wherein said client vehicle (101) and said plurality of forwarder vehicles (102A, 102B, 102C) comprises a object device, such as smart phone or vehicle's on board system.
Still another aspect of the present invention is to provide the system (100) for communicating a stress signal by using Message Queuing Telemetry Transport for Sensor Network on road transportation, wherein said object device of said client vehicle (101) is installed with a ClientApp.
Still another aspect of the present invention is to provide the system (100) for communicating a stress signal by using Message Queuing Telemetry Transport for Sensor Network on road transportation, wherein said object device of said forwarder vehicles (102A, 102B, 102C) is installed with a ForwardApp.
Still another aspect of the present invention is to provide a method for communicating a stress signal by using Message Queuing Telemetry Transport for Sensor Network on road transportation comprising the following steps: Downloading and installing a ClientApp by an user on an object device; Attaching ZigBee module transceivers; Pressing an emergency button by said user for generating distress signals, wherein said distress signal comprises a ClientID; Broadcasting said distress signals by said clientApp to a forwarder vehicle or to a infrastructure pole by said ZigBee Modules; Forwarding said distress signals by a ForwardApp of the forwarder vehicle to said infrastructure poles by said ZigBee Modules; Communicating said distress signals by said infrastructure poles to a control center over TLS; Communicating said distress signals with details to emergency vehicles over TLS; and Providing services by emergency vehicles to the user of the client vehicle.
In this respect, before explaining at least one embodiment of the invention in detail, it is to be understood that the invention is not limited in its application to the details of construction and the arrangements of the components outlined in the following description or illustrated in the drawings. The invention is capable of other embodiments and of being practiced and carried out in various ways. Also, it is to be understood that the phraseology and terminology employed herein are for the purpose of description and should not be regarded as limiting.

These together with other objects of the invention, along with the various features of novelty which characterize the invention, are pointed out with particularity in the disclosure. For a better understanding of the invention, its operating advantages and the specific objects attained by its uses, reference should be had to the accompanying drawings and descriptive matter in which there are illustrated preferred embodiments of the invention.

(1) BRIEF DESCRIPTION OF THE DRAWINGS
The invention will be better understood and objects other than those set forth above will become apparent when consideration is given to the following detailed description thereof. Such description makes reference to the annexed drawings wherein:
Fig. 1 depicts MQTT-SN architecture, according to one of the embodiments of the present invention.
Fig. 2 illustrates a system (100) for communicating a stress signal by using Message Queuing Telemetry Transport for Sensor Network on road transportation, according to one of the embodiments of the present invention.
Fig. 3 depicts a flow chart of Message structure and message flow of the system, according to one of the embodiments of the present invention.
DETAILED DESCRIPTION OF THE INVENTION
In the following detailed description, reference is made to the accompanying drawings which form a part hereof, and which is shown by way of illustration of specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that the embodiments may be combined, that other embodiments may be utilized, and that structural and logical changes may be made without departing from the spirit and scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined by the appended claims and their equivalents.
References will now be made in detail to the exemplary embodiment of the present disclosure. Before describing the detailed embodiments that are in accordance with the present disclosure, it should be observed that the embodiments reside primarily in combinations arrangement of the system according to an embodiment herein and as exemplified in FIGURES 1 - 3.
In the following description, for the purpose of explanation, numerous specific details are set forth in order to provide a thorough understanding of the arrangement of the system according to an embodiment herein. It will be apparent, however, to one skilled in the art, that the present embodiment can be practiced without these specific details. In other instances, structures are shown in block diagram form only in order to avoid obscuring the present invention.
Now a days, there are millions of vehicles on the road and vehicle-to-vehicle communication (V2V) is a rising research area. V2V communication is used for many reasons, such as informing about road congestion, traffic blockage, accident, and sending distress signals to ask for help in case potential and immediate danger exists.
A distress signal is essential to the safety of the people in the vehicle. Many companies are supporting these distress signals for their new vehicle models. However, the problem arises can one kind of solution be good enough for all over the world? How will these solutions support backward compatibility with the old configured vehicles? As now technology move towards autonomous cars, electric and hybrid vehicles have the latest technologies. Also remember that these only cover a small portion of four-wheelers.
MQTT-SN (Message Queuing Telemetry Transport for Sensor Network) ([2] A. Stanford-Clark and H. L. Truong, "MQTT for Sensor Networks(MQTT-SN) Protocol Specification Version 1.2," Nov 2013) was standardized in 2013 by OASIS (Or- ganization for the Advancement of Structured Information Standards). However, it was not accepted in the market for a long time. On the other hand, MQTT is used in many deployed products. Recently, a few companies like Hive- MQ, uBlox and others are providing MQTT-SN services. Furthermore, a few researchers and professionals started designing a new standard draft for MQTT-SN [[5] OASIS-OPEN, "MQTT SN Subcommittee PublicDocuments." https://www.oasis-open.org/committees/documents.php?wgabbrev=mqtt- snshowdescriptions=yes, 2021], which aligns with the MQTTv5 protocol specification. Thus, the current trend shows the rise of research interest in MQTT-SN. MQTT-SN is the only application-layer messaging protocol that supports communication over link-layer protocols suchas ZigBee or BLE (Bluetooth Low Energy). Here are some examples of usage of MQTT-SN:compared CoAP (Constrained Application Protocol) and MQTT-SN for robotics applications based on header size, reliability, duplication, resource locator and communication mode. The authors concluded that MQTT-SN has 30% better transmission time than CoAP. The current interest of academics and professionals in MQTT-SN seems to have peaked. Similarly, for cellular, thereis a cellular chip shortage, meaning that necessary equipment could become more costly and hard to come by, which may stall new cellular technology (i.e., 5G) implementation. There is concern that the 5G network is not yet prepared or capable of hosting many connected devices, especially when safety is such a strong focus for connected vehicles. These concerns show us an opening for a solution that is easy to deploy financially, can use already available infrastructure, and can also support the vehicles already on the road.
The present invention discloses an architecture involving the MQTT-SN communication model, which uses the publish-subscribe method to send a distress signal from a vehicle to emergency services. To the best of our knowledge, this is the first system using MQTT-SN for vehicle communication to send distress signals. Using this, we contribute the following:
• It is design and implements a prototype for sending distress signals from vehicles using the MQTT-SN protocol.
• It is addresses the limitations of other technologies (e.g., Dedicated Short Range Communications (DSRC), Cellular, Advanced Emergency Braking System (AEBS), and Satellite) with the help of the system of the present invention and compare it with the solution provided here.
Details of the Components and Terms:
MQTT for Sensor Network(MQTT-SN)
MQTT-SN was designed earlier specifically for WSN (Wireless Sensor Networks), which cannot communicate over TCP (Transmission Control Protocol). It communicates over UDP (User Datagram Protocol), ZigBee and BLE. MQTT-SN message consists of two parts: a 2- or 4- octet long headerand an optional variable part. There are four components of MQTT-SN architecture:
1) MQTT-SN Clients: These are any battery-operated con- strained devices. These can be a publisher or a subscriber that wants to send/receive a message to/from the broker. A publisher can publish (i.e., send a message) to the broker, and a subscriber can subscribe (i.e., request a message) from the broker in an IoT environment for a topic (label attached to an Application Message). The published information (i.e., message) can be a status message or a command.
2) MQTT-SN Gateway: It is a bridge between MQTT-SN clients and the MQTT broker. It might be integrated with the MQTT broker as well.
3) MQTT-SN Forwarder: An MQTT-SN client can also access the gateway through the forwarder if the gateway is not directly attached to the WSN. The forwarder encapsulates the MQTT-SN client message it receives from the wireless side and forwards it to the gateway without modification; similarly, it decapsulates the message received from the gateway and forwards it to MQTT- SN clients. In the process of encapsulation, the forwarder adds broadcast radius and wireless node ID (i.e., a node which has sent or should receive the encapsulated MQTT- SN message).
4) MQTT Broker: It is also known as "server". The role of a broker is to collect and distribute messages. It also accepts client network connections, subscribes and unsubscribes client requests, and closes the client's network connection.
The present invention discloses a system (100) for communicating a stress signal by using Message Queuing Telemetry Transport for Sensor Network on road transportation comprising: a person travelling in a client vehicle (101); a plurality of forwarder vehicles (102A, 102B, 102C) assisting in forwarding said stress signal; a plurality of emergency vehicles (103) which helps in providing services; a control center (104); a plurality of infrastructure poles (105) for helping communication; wherein said client vehicle (101) and said plurality of forwarder vehicles (102A, 102B, 102C) comprising Zigbee transceivers, wherein said ZigBee transceivers connected with a vehicle's on board system; and wherein said infrastructure poles (105) which receives a message from an MQTT-SN client vehicle or forwarder vehicles over said ZigBee transceivers and forwarding it to said control center. In the system of the present invention Client vehicle (where user is present and from where distress signal generates) is MQTT-SN Clients. The forwarder vehicle is MQTT-SN Forwarder and infrastructure poles are MQTT-SN Gateway. The control center is a MQTT Broker.
Fig. 1 depicts MQTT-SN architecture, according to one of the embodiments of the present invention. The important parameters in the CONNECT, PUBLISH and SUBSCRIBE control packets are:
1) ClientID: It is a unique identifier used by clients. The server uses it to identify the client and their state relating to an ongoing MQTT-SN session.
2) Clean Session: It is a flag in the CONNECT message. If set to false, it means the client wants to have a persistent session (keeps track of all the session's information asthe devices go offline or disconnect). If set to true, then the broker deletes all information about the session once the connection terminates.
3) Topics:In MQTT-SN "pre-defined" topicIDs (i.e.,Topic alias) and short topic names are introduced, for which no registration is needed. The topicIDs in MQTT-SN are the strings that the broker uses to filter messages for each connected client. Topics can be predefined by manufacturers and brokers and may also be defined by publishers. Two or more publishers can publish under the same topic. But it is highly discouraged to identify the source of the message uniquely. MQTT-SN Topics have one or more levels, separated by a forward-slash(/). A client can subscribe to an exact topic used by the publisher, or a client can use the wildcard. MQTT- SN is the only application-layer messaging protocol that supports communication over link-layer protocols such as ZigBee or BLE.
4) Quality of Service (QoS): MQTT-SN supports three level of quality of service as part of publish message.
a) QoS0: It is also referred to as fire and forget (i.e., at most once). It works as the fastest method but is unreliable.
b) QoS 1: It guarantees that message will be delivered at least once or more than once to the broker. It is also referred to as acknowledgement delivery.The publisher publishes the message and waits for acknowledgement from the broker.
c) QoS2: To avoid duplicate delivery of messages (which is the possibility with QoS 1), and packet loss (which is the possibility with QoS 0), we choose QoS 2. It is also known as assured delivery (i.e., exactly once).
5) Retain Flag: If a publisher publishes a message on a topic and there is no subscriber currently available for that topic, the broker usually discards that message. With the help of setting this flag bit in a PUBLISH message, it is informed the broker to keep the publisher's last message on a topic in memory.
The purpose of the distress signal in a vehicle is to provide immediate assistance in case of an emergency. When the button is pressed, it sends a distress signal to a response center or emergency services, indicating the vehicle's location and providing other critical information. This allows for a quick response in an accident, breakdown, or other emergency situation. Below are different methods of sending emergency distress signals from vehicle:
1) Save Our Souls (SOS): The purpose of the SOS button in a vehicle is to provide immediate assistance in case of an emergency.
2) Onboard Emergency Call System (eCall): An in-vehicle system that automatically sends an emergency distress signal in the event of a crash or collision.
3) Personal Emergency Response System (PERS): A wear- able device that can be triggered to send an emergency distress signal in case of a medical emergency.
4) Mobile Phone App: An app installed on a mobile phone that can be used to send an emergency distress signal in case of an accident or other emergency.
5) Satellite-based Tracking System: A system that uses satellite technology to send an emergency distress signal in case of an accident or breakdown.
6) Roadside Assistance System: A system that provides emergency assistance when a vehicle is involved in a breakdown, accident, or other emergency.
7) Integrated Telematics System: A system that integrates various communication and navigation technologies to provide real-time information and emergency assistance.
These methods use different technologies for communication which we will use for comparison with our work:
1) Cellular: A cellular communication technology that is widely used for sending distress signals from vehicles, using either voice or text messaging. There are different types of cellular technologies, like GSM (Global System for Mobile Communications), 3G, LTE(LongTermEvolution), SMS (Short Message Service).
2) Satellite: A satellite-based navigation system that can be used to determine the location of a vehicle and send an emergency distress signal. There are different types of satellite technologies, like two-directional (Orbcomm, Iridium, Euteltrack, etc.) and uplink one-directional (Argos).
3) Advanced Emergency Braking System(AEBS): A system that uses radar or other sensors to detect a potential collision and send an emergency distress signal to alert other vehicles and/or emergency services.
4) Dedicated Short Range Communications (DSRC): A wireless communication technology that enables direct communication between vehicles and roadside infrastructure.
A primary goal of the present invention is to send a distress signal using MQTT-SN over ZigBee. The solution provided here uses the publish-subscribe model and helps the end-user when no cellular and wireless network is available. For this, we use the MQTT-SN model with the MQTT-SN forwarder. This involves the transfer of distress signals with important information (relative location, vehicle data with problem code) from the vehicle to the particular response team. We use MQTT-SN here because:
1) MQTT-SN is designed to be lightweight and efficient, making it ideal for the use of V2V communication. It has the shortest header. Below Table shows the MQTT-SN message structure and its values.

2) MQTT-SN is designed to work with various communication protocols, including IEEE 802.11p.
3) MQTT-SN can operate in various network environments, including low-power and lossy networks.
4) MQTT-SN is an OASIS standard and can be enhanced based on the application to send a secure distress signal.
5) MQTT-SN is a publish-subscribe protocol. The benefit of using the publish-subscribe model is the end-user does not need the information about the end client, which maintains privacy.
6) Due to the publish-subscribe model here because we do not want any unauthorized entity to read the message. Therefore, each emergency service subscribes to its cor- responding topics.
In the end, we also compare the MQTT-SN over ZigBee to DSRC (which is currently accepted technology for V2V communication).
Fig. 2 illustrates a system (100) for communicating a stress signal by using Message Queuing Telemetry Transport for Sensor Network on road transportation, according to one of the embodiments of the present invention. The present invention discloses a system (100) for communicating a stress signal by using Message Queuing Telemetry Transport for Sensor Network on road transportation comprising: a person travelling in a client vehicle (101); a plurality of forwarder vehicles (102A, 102B, 102C) assisting in forwarding said stress signal; a plurality of emergency vehicles (103) which helps in providing services; a control center (104); a plurality of infrastructure poles (105) for helping communication; wherein said client vehicle (101) and said plurality of forwarder vehicles (102A, 102B, 102C) comprising Zigbee transceivers, wherein said ZigBee transceivers connected with a vehicle's on board system; and wherein said infrastructure poles (105) which receives a message from an MQTT-SN client vehicle or forwarder vehicles over said ZigBee transceivers and forwarding it to said control center. MQTT-SN Publisher (ClientApp): A MQTT-SN publisher is an application which is used to publish the distress signal for the subscriber with the help of a ZigBee transceiver module. This application may also be part of the onboard automotive system. The ZigBee module transmitter used by this application is in broadcast-sending mode. Each application has its own unique identifier (i.e., ClientID) based on the vehicle, we can use the VIN number of vehicles as that identifier. The ClientApp is programmed using the Reach platform running over Samsung Galaxy Note 2 with 2 GB RAM and 32 GB Memoryattached to a plug-and-play ZigBee module to broadcasts messages. The ClientApp is denoted by subscript 'P' in our notation.
MQTT-SN Forwarder (ForwardApp): A MQTT-SN for- warder is an application which is used to receive the MQTT- SN message from the client and forward it to the gateway with the help of a ZigBee transceiver rmodule.This application may also be part of the onboard Android automotive system as well. In normal circumstances, the ZigBee module used by this application is in listening mode, once it receives any message it will broadcast it to the nearest gateway or another MQTT-SN forwarder. The Forward App is programmed using the Reach platform running over Samsung Galaxy S21with 2 GB RAM and 64 GB Memory attached to a plug-and-play ZigBee module to broadcasts messages. The ForwardApp is denoted by subscript 'F' in our notation.
MQTT-SN Gateway (Roadside Infrastructure): A MQTT- SN gateway is a roadside infrastructure which receives a message from an MQTT-SN client or forwarder over ZigBee and forwards it to the MQTT broker. The gateway convertsthe MQTT-SN message to MQTT. The message is transferred over the MQTT over the TCP channel. The ZigBee module is in listening mode at roadside infrastructures to receive data from the MQTT-SN forwarder. The Roadside infrastructure is programmed with the destination address MQTT broker (i.e., control centre). It is implemented using a Rasberry Pi 3B+ module (Broadcom BCM2837B0 qual-core A53 (ARMv8)), a 32-bit board with ZigBee and Wi-Fi module. The Roadside infrastructure is denoted by subscript 'G' in our notation. There are already roadside infrastructures available in multiple countries. These can easily be programmed to support this architecture to make it less expensive.
MQTT Broker (Control Centre): The MQTT distress mes- sage received by the broker over the TCP channel from the MQTT-SN gateway. The control centre's task is to distribute messages based on the subscriptions. Control Centre runs on a laptop with specifications: M2ProProcessor, 16GB RAM and 512 GB hard disk. The Control Centre is denoted by subscript 'B' in our notation.
MQTT Subscriber (Emergency Services): The MQTT sub- scribers subscribe to the different topics of distress signals. The trained professionals can provide assistance or dispatch emergency services based on the need. These emergency services include police, hospitals, and towing services. The emergency services run on a laptop with specifications: i7-8thGenProcessor, 16GB RAM and512 GB hard disk. The Emergency services are denoted by subscript 'S' in our notation.
The implementation of the system and how a distress signal is sent using MQTT-SN over ZigBee. Figure 2 shows the system of the present invention for distress signals moving from a vehicle to emergency services. The distress signal data contains relative location information and vehicle information (model, type, and year). Here, we use VIN (Vehi- cle Identification Number) as ClientID. One can use topic aliases, which are predefined and programmed in the ClientApp or vehicle on-board unit. A method for communicating a stress signal by using Message Queuing Telemetry Transport for Sensor Network on road transportation comprising the following steps:
Downloading and installing a ClientApp by an user on an object device;
Attaching ZigBee module transceivers;
Pressing an emergency button by said user for generating distress signals, wherein said distress signal comprises a ClientID;
Broadcasting said distress signals by said clientApp to a forwarder vehicle or to a infrastructure pole by said ZigBee Modules;
Forwarding said distress signals by a ForwardApp of the forwarder vehicle to said infrastructure poles by said ZigBee Modules;
Communicating said distress signals by said infrastructure poles to a control center over TLS;
Communicating said distress signals with details to emergency vehicles over TLS; and
Providing services by emergency vehicles to the user of the client vehicle.
The user downloads and installs the ClientApp on their smart phone, or the ClientApp can also be installed on the vehicle's on board system and plugged in the ZigBee module in the USB socket of the smart phone or vehicle's on board system. In old vehicles, the ZigBee module can easily be attached as a plug-and-play device. Similarly, the ZigBee module can be attached to a phone to send a distress signal. All the different distress message types and their topic alias are pre-installed.
In case of an emergency, the user launches the app, selects the type of distress message, and presses the emergency button. The ClientApp (i.e., publisher) broadcasts the distress signal so that it can be received by another vehicle ForwardApp (i.e., MQTT-SN Forwarder) or roadside infrastructure pole (i.e.,MQTT- SN gateway) through the ZigBee module. The distress MQTT-SN message contains ClientID as the VIN,whichmakesit unique and can be known publicly. This VIN helps the emergency services to define the information about the vehicle type, model, and make. The ForwardApp also broadcasts the message for a certain time. Sometimes due to no cellular or wireless network zone, the distress message needs to forward from one ForwardApp of a vehicle to another to reach the roadside infrastructure. As mentioned earlier, roadside infrastructure poles (i.e., MQTT-SN gateway) is programmed with the network details of the MQTT Broker (i.e., control centre). On receiving the message from the gateway, the control centre opens it and forwards it to the emergency services, depending on the subscription topic. The message received by the broker contains a topic alias. The broker already has the proper mapping of the topic and topic alias (i.e., Topic ID). The corresponding emergency services receive the distress message and respond accordingly. The message contains the VIN and the user's last known location information, which helps the emergency services to dispatch the help. Figure 3 shows different message structures and the flow of messages from ClientApp to emergency services.
SYSTEM ANALYSIS
A. Timing Evaluation
We have confirmed the distress signal functionality of our design using the implementation of a prototype. We could send distress signals from a Smartphone ClientApp and to emergency services. First, we test the system with all the components in a room, and second, we move the control centre and emergency service components to different houses. Finally, we test the system on the highway with the vehicle moving at a speed of 100 Km/hr.
The main objective in designing this prototype is to show thatMQTT-SN over ZigBee can also send distress signals from vehicles without cellular and satellite coverage. We have also calculated the timings for a distress signal to reach from 'P' to 'S' in three different scenarios. Here, Below Table 2 shows the timing evaluation of distress signal travel.

Comparative Analysis of the present invention over the existing solution:
The effectiveness of the dedicated emergency button in sending emergency distress signals depends on various factors, such as the availability of the on board communication system, the reliability of the button, and the response time of the emergency contacts and/or emergency services. Technologies used to send distress signals have many limitations. In the present invention, it shows that the system designed has overcome those limitations. Another benefit of using our prototype is that it's easy to maintain, as the software application can be easily updated. MQTT-SN is a standard protocol that overcomes one issue of lack of standardization.
The following problems are solved by the present invention which were faced by vehicles in sending distress signals and how our approach has addressed them:
1) Bandwidth Limitation: In rural areas, the coverage of mo bile networks and GPS systems are often weak, making it difficult for vehicles to send out distress signals. However, even though ZigBee has a bandwidth limitation, by leveraging and adapting different optimizations of MQTT-SN features like message compression, topic-based filtering, QoS levels, sleep modes, and smaller packet overhead, it is possible to mitigate bandwidth limitations in V2V networks. These techniques enable efficient use of available bandwidth and ensure reliable communication while accommodating the constrained nature of ZigBee devices and networks. Alongside, DSRC is one of the widely accepted V2V communication protocols. DSRC (works on a bandwidth of 75 MHz in the 5.9 GHz band) and cellular communication share the same frequency bands used by mobile phones and other electronic devices. This can cause network congestion, dropouts, and other reliability issues. On the other hand, ZigBee (workson a bandwidth of 2 MHz in the 2.4 GHz band) uses its unique frequency band, meaning it can operate with less interference and congestion. Alongside ZigBee helps us reduce packet loss through mesh topology.
2) Power Consumption: MQTT-SN over ZigBee's low power consumption can significantly increase the lifespan of embedded devices, such as sensors and controllers. In the present invention it uses sleep modes to conserve power when the system is not actively transmitting or receiving data. MQTT-SN can be integrated with the power management mechanisms of ZigBee devices, allowing them to wake up efficiently and establish connections only when necessary. This helps to optimize energy usage. This feature is not supported by AEBS, DSRC, cellular and satellite.
3) Cost: The infrastructure needed for our design is already present in current vehicles and vehicles without that infrastructure can also use their smart phone for the same because the end-user (i.e., publisher) only needs to havea ClientApp, which can be installed on the vehicle during manufacturing or old vehicle owners can install them over their Smartphone. The end-user only needs to purchase ZigBee modules, which cost around $20-$30. Many countries already have built roadside infrastructures, and we need to modify them to support MQTT-SN over ZigBee.

4) Maintenance: Maintenance of the various systems and technologies used to send distress signals can be difficult, especially in areas with limited access to trained tech- nicians. Our design is easy to maintain as the software application can be easily updated. However, roadside infrastructure might need regular maintenance based on location and usage.
5) Interoperability Issues: Different technologies and proto- cols used by different systems may not be fully com- patible, making it difficult to send distress signals across different networks. All the technologies used for sending distress signals lack a standard standardization. However, our design uses the MQTT-SN protocol, an OASIS standard, and ZigBee's support for mesh network topologies provides a reliable and scalable communication infrastructure for MQTT-SN messages.
6) Range Limitation: Cellular and Satellite technologies have no range limitation. However, AEBS has a range of 152 meters.On the other hand, DSRC has a range of 1000 to 5000 meters. Similarly, MQTT-SN over ZigBee has a range of300 meters. So a car travelling 100 Kilometers per hour on a highway (i.e., ForwardApp) and a car not working in a remote are a (i.e.,ClientApp).Therefore with the delays involved in opening and closing a connection on the order of 0.02 seconds,in DSRC has 36 seconds to send the message, and AEBS has 5.2 seconds. While in the case of MQTT-SN over ZigBee, the ForwardApp has 10.8 seconds to receive broadcast messages from ClientApp. With 50 bytes of payload (withinonepacket), ZigBee maintains a latency below 140 milliseconds outto 6 hops. In addition, our design leverages the MQTT- SN protocol and the MQTT-SN forwarder, which acts as a repeater to forward messages from one vehicle to another when the network is unavailable. This approach can substantially improve communication reliability and extend the range of functionality for transportation sys- tems operating in remote and rural environments.
7) Security: Data privacy and security concerns can also limit the widespread adoption of these technologies and systems, as their data can be sensitive. In our current design, we have not addressed security concerns as it is out of the scope of this paper. However, academics and professionals have designed their security architecture for different MQTT-SN applications.
It is to be understood that the above description is intended to be illustrative, and not restrictive. For example, the above-discussed embodiments may be used in combination with each other. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description.

The benefits and advantages which may be provided by the present invention have been described above aboutthe specific embodiments. These benefits and advantages, and any elements or limitations that may cause them to occur or to become more pronounced are not to be construed as critical, required, or essential features of any or all of the embodiments.
While the present invention has been described concerning particular embodiments, it should be understood that the embodiments are illustrative and that the scope of the invention is not limited to these embodiments. Many variations, modifications, additions, and improvements to the embodiments described above are possible. It is contemplated that these variations, modifications, additions, and improvements fall within the scope of the invention.
, Claims:We Claim:
1. A system (100) for communicating a stress signal by using Message Queuing Telemetry Transport for Sensor Network on road transportation comprising:
A person travelling in a client vehicle (101);
A plurality of forwarder vehicles (102A, 102B, 102C) assisting in forwarding said stress signal;
A plurality of emergency vehicles (103) which helps in providing services;
A control center (104);
A plurality of infrastructure poles (105) for helping communication;
Wherein said client vehicle (101) and said plurality of forwarder vehicles (102A, 102B, 102C) comprising Zigbee transceivers, wherein said ZigBee transceivers connected with a vehicle's on board system; and
Wherein said infrastructure poles (105) which receives a message from an MQTT-SN client vehicle or forwarder vehicles over said ZigBee transceivers and forwarding it to said control center.
2. The system (100) for communicating a stress signal by using Message Queuing Telemetry Transport for Sensor Network on road transportation as claimed in claim 1, wherein said system generates a client ID which is a unique identifier used by clients.
3. The system (100) for communicating a stress signal by using Message Queuing Telemetry Transport for Sensor Network on road transportation as claimed in claim 1,
4. The system (100) for communicating a stress signal by using Message Queuing Telemetry Transport for Sensor Network on road transportation as claimed in claim 1, wherein said client vehicle (101) and said plurality of forwarder vehicles (102A, 102B, 102C) comprises a object device, such as smart phone or vehicle's on board system.
5. The system (100) for communicating a stress signal by using Message Queuing Telemetry Transport for Sensor Network on road transportation as claimed in claim 1, wherein said object device of said client vehicle (101) is installed with a ClientApp.
6. The system (100) for communicating a stress signal by using Message Queuing Telemetry Transport for Sensor Network on road transportation as claimed in claim 1, wherein said object device of said forwarder vehicles (102A, 102B, 102C) is installed with a ForwardApp.
7. A method for communicating a stress signal by using Message Queuing Telemetry Transport for Sensor Network on road transportation comprising the following steps:
Downloading and installing a ClientApp by an user on an object device;
Attaching ZigBee module transceivers;
Pressing an emergency button by said user for generating distress signals, wherein said distress signal comprises a ClientID;
Broadcasting said distress signals by said clientApp to a forwarder vehicle or to a infrastructure pole by said ZigBee Modules;
Forwarding said distress signals by a ForwardApp of the forwarder vehicle to said infrastructure poles by said ZigBee Modules;
Communicating said distress signals by said infrastructure poles to a control center over TLS;
Communicating said distress signals with details to emergency vehicles over TLS; and
Providing services by emergency vehicles to the user of the client vehicle.

Documents