Device to Backend Communication
Fig 1: Architectural Diagram
The VLT device would transmit data to the backend control centre using GPRS wireless connectivity
(with SMS fall back). The data from the device would travel over the wireless telecom service
provider network and finally get delivered to backend control centre. Since the permit holder’s /
Device suppliers would require to have a valid communication plan on SIM cards on the devices and
would avail services from multiple telecom service providers, the data would be transmitted to the
backend control centre using networks of multiple telecom service providers.
A suitable control mechanism would be established for the data transfer from VLT to Backend
Control Centre, as only the authorized devices should be able to transfer data to the Backend control
centre and a mechanism for authenticating the devices / SIMs shall be out in place.
The following Provision will be made at backend control Centre:
1. Registration and activation of the device(s) fitted on the vehicle, including the details of
vehicle registration number and engine number, chassis number, vehicle make and model,
and telecom service provider’s name.
2. Re-registration and activation of device(s) fitted on the vehicle in case of any change in
device or telecom service provider, etc.
3. Regular health check of the device(s) fitted on the vehicle.
4. Administration/configuration of devices for any changes in the parameters as decided by the
respective state from time to time.
5. Notification of alerts in case of press of an Alert Button fitted on the vehicle, in the protocol
defined in Section 4.
6. Notification of alerts in case of defined deviations by vehicle such as over-speeding,
deviation from defined route/geographic area, time of operation, etc.
7. Location tracking of the vehicle including real-time as well as history tracking for up to last
90 days.
8. Notification to the permit-holder through SMS in case any device(s) stops
functioning/sending data to the Backend Control Centre.
8. Reports of the vehicles with devices not working/sending data beyond defined number of
days (1 day, 3 days, 7 days and 30 days).
10. Ensure that the security and privacy of the data is maintained in accordance with applicable
laws/guidelines of various government authorities.
Tracking Device Health Monitoring Parameters The device shall send status of health parameters
at configurable interval and this threshold value shall also be configurable over the air. It shall be
possible for health parameters to be fetched on demand via command as set out below in Table
3B.
Table 3B:
Health Monitoring Parameter
Sl. No. Field Description
1 Start Character $
2 Header The header of the packet/ identifier
3 Vendor ID Vendor identification header
4 Firmware Version Version details of the Firmware
used in EX.1.0.0
5 IMEI Identified of the sending unit. 15
digit standard unique IMEI no.
6 Battery percentage Indicates the internal battery
charge percentage
7 Low battery threshold value Indicates value on which low
battery alert generated in
percentage
8 Memory percentage Indicates flash memory percentage
used
9 Data update rate when Indicates Packet frequency on
ignition ON ignition ON
10 Data update rate when OFF Indicates Packet frequency on
ignition ignition OFF
11 Digital I/o status Inputs connected to the device
12 Analog I/o status Analog input status
13 End character
ITS FUNCTIONS AND REQUIREMENTS
The list of ITS functions envisaged from this device type is set out below
in Table 3A –
Table 3A: List of ITS Functions and Sub Functions
Function Sub Functions
Emergency Buttons
Safety and Security
Vehicle Location Tracking (VLT)
The above functions and their requirements shall be met by only single
device that can be interfaced by external emergency buttons. The
communications to Backend Control Server (Government authorized
server) shall be done by device as per the protocol and functionalities
defined below.
Vehicle Location Tracking (VLT) With Emergency Button
Functional Requirements for VLT
3.1.1.1 Device shall be capable of obtaining position information using Global
Navigation Satellite System (GNSS). GNSS receiver specifications are as
follows:
a. Device shall be capable for operating in L and/or S band and include
support for NAVIC/IRNSS (Indian Regional Navigation Satellite
System) for devices installed on or after 1st April, 2018.
b. The Device shall support GAGAN, the Indian SBAS (Satellite Based
Augmentation System)
c. Device shall have a position accuracy of minimum 2.5 m CEP or 6 m
2DRMS
d. Device shall have an acquisition sensitivity of minimum (-) 148 dBm
e. Device shall have an tracking sensitivity of minimum (-) 165 dBm
f. Device shall have an internal antenna; however if in case of Integrated
systems with vehicle / aftermarket OEM approved kits if the fitment
location prevents the internal antenna from functioning, then external
antenna shall be provided.
3.1.1.2 Device shall support standard minimum I/Os as mentioned: 4 Digital, 2
Analogue and 1 Serial Communication (e.g. RS232) for interfacing
external systems (E.g. Digital input for Emergency request button
interfacing).
3.1.1.3 Device shall be capable of transmitting data to Backend Control Server
(Government authorized server) via Wide Area (Mobile) Communications
network (GSM/GPRS) as per Communication Protocol in Section 4.
3.1.1.4 Device shall be capable of transmitting Position, Velocity and Time (PVT
data) along with heading (direction of travel) to a Backend Control Server
(Government authorized server) at configurable frequency as per
Communication Protocol of Section 4.
The fixed frequency shall be user configurable, minimum frequency shall
be 5 sec during vehicle operation and not less than 10 minutes in sleep/IGN
OFF) as per the protocol defined in Communication Protocol of Section 4.
3.1.1.5 Device shall be capable of transmitting data to minimum 2 different IP
addresses (1 IP address for regulatory purpose (PVT data) and 1 IP address
for Emergency response system other than the IP’s required for
Operational purpose.
3.1.1.6 On pressing of Emergency button, the system implementing VLT function
shall send emergency Alert (Alert ID 10 as mentioned in Sub- section 4.2.1
of Communication Protocol Section 4) to the configured IP address(s) as
per the Communication Protocol mentioned in Section 4. In the absence
of GPRS network, the emergency alert shall be sent as SMS message along
with vehicle location data to configured control center number(s). The
SMS shall consist parameters as given in Sub-section
4.2.2.
3.1.1.7 Device shall have an internal back-up battery to support 4 hours of normal
operations (to be tested for positional record transmission at a frequency
of 60 sec)
3.1.1.8 Device shall be capable of transmitting alerts to the Backend Control
Server (Government authorized server) directly. The applicable list of
alerts is given in Section 4.2 (Alert ID 3 to 12) of Section 4.
3.1.1.9 Device shall support over the air software and configuration update.
3.1.1.1 Device shall support basic standard configuration (Mobile
0 communications network settings, Backend Control Server (Government
authorized server) details, data frequencies, alert thresholds etc.) as per
configuration specification defined in Section 4.
3.1.1.1 Device shall support store and forward mechanism for all type of data
1 (periodic data and alerts) meant for backend transmission. The system
shall store data in internal memory during communication network un-
availability and transmit the data when the connection resumes in last in
first out (LIFO) manner. The live data shall be given higher priority for
transmission than back log (stored data) at any point in time.
3.1.1.1 The Device shall have a unique identifier for identifying the VLT device
2 and data. The unique ID shall be stored in a read only memory area so that
it cannot be altered or overwritten by any person. The unique identifier
may be Vehicle Identification number or IMEI (International Mobile
Station Equipment Identity) Number.
3.1.1.1 Device shall store/write the registration number of the vehicle in the
3 internal nonvolatile memory.
3.1.1.1 Device shall have an Embedded SIM.
4
3.1.1.1 Device shall be designed to operate between 8VDC and 32VDC using
5 vehicle battery input voltage range 12 /24Volts.
3.1.1.1 Device shall have a sleep mode current ≤ 20 mA (If the function is
6 implemented in a dedicated system/device).
3.1.1.1 Device shall support any operational GNSS system with 12 (minimum)
7 acquisition channels.
3.1.1.1 The Device shall support:
8
• Location on GPRS/SMS
• Non-volatile memory to store min 40,000 positional log
• Configurable backup SMS facility in case of GPRS failure
• Capability to send serving and adjacent cell ID as well as network
measurement report (NMR)
3.1.1.1 The Device GNSS module shall have:
9
• The capability of Hot start <5s
• The capability of Warm start : < 30s
• The capability of Cold start < 40 s
3.1.1.2 Device shall support Outputs as per NMEA 0183
0
3.1.1.2 The Device GPRS module shall have:
1
• Multi slot GPRS with In - built Quad-band GPRS module/Modem
• GPRS class 10 or above
• Support Embedded SIM to cater to the automotive operational
requirement such as vibration, temperature and humidity and provide
long life span with at least 10 years life and more than 1 million
read/write cycles
• GPRS module & SIM shall support
o SMS, Data (GPRS, TCP/IP) and
o Support multiple network OTA switching (on-demand/automatic)
capabilities.
3.1.1.2 Device shall be dust, temperature, vibration, water splash resistant, IP 65
2 rated or better, tamper proof as per Section 6.
3.1.1.2 Device shall be manufactured using processes as per quality management
3 standard for automotive industries i.e. ISO/TS 16949 updated from time
to time
3.1.1.2 Device shall support A-GPS (Assisted GPS)
4
3.1.1.2 Device shall have provision of secured data transmission to the Backend
5 Control Centre from the devices through secured channel (e.g. secured
dedicated APN).
3.1.1.2 Device shall have 3 axis accelerometer and 3 axis gyroscope for getting
6 the alerts on harsh breaking harsh acceleration, and rash turning.
3.1.2 Functional Requirement for Emergency System
3.1.2.1 Passengers or in-vehicle crew present in the vehicle shall be able to make
an emergency request by pressing the emergency button provided
3.1.2.2 The emergency request function shall not exist as standalone. The function
shall be part of Vehicle Location Tracking (VLT) system. An alert shall
be sent to the Backend Control Server (Government authorized server)
when emergency request is raised. De-activation shall always be from
authorized government server who receives alert message i.e.
NERS system as mentioned in Sub-section 4.2.2.
3.1.2.3 The Emergency Buttons will be 'Normally Closed' (NC) type. The form
factor of Emergency Buttons will be such that the button is easy to press
in the case of an emergency, and simultaneously also minimizes the
possibility of accidental or unintended press thereby causing a false alert.
3.1.2.4 On pressing of Emergency button, the system implementing VLT function
shall send emergency Alert (Alert ID 10 as mentioned in Sub- section 4.2.1
of Communication Protocol Section 4) to the Backend Control Server
(Government authorized server) as per the Communication Protocol
mentioned in Section 4. In the absence of GPRS network, the alert shall be
sent as SMS message along with vehicle location data to configured
control center number. The SMS shall consist of parameters as given in
Sub-section 4.2.2.
3.1.2.5 In absence of both GPRS and GSM networks and on pressing of
Emergency Button, the system implementing VLT function shall store the
emergency Alert (Alert ID 10 as mentioned in Sub-section 4.2.1 of
Communication Protocol Section 4). Once the GPRS or GSM is available,
this alert information shall be sent on high priority to the configured IP
addresses as per the communication protocol mentioned in Section 4 or as
SMS message along with vehicle location data to configured control center
number. The SMS shall consist of parameters as given in Sub-section
4.2.2.
3.1.3 Configuration of Device Parameters Over the Air (OTA)
The device shall support at least the below parameters to be configurable
over the air (through SMS and GPRS). The updation shall be allowed only
over an ‘authenticated’ channel:
1. Setting/ Change of the Primary or Secondary IP and port number
2. Setting/ Change of the APN
3. Set configuration parameter like sleep time, overspeed limit, harsh
braking, harsh acceleration, rash turning threshold limits etc.
4. Emergency control SMS Centre Number(s)
5. Configuring the vehicle registration number
6. Configuring the frequency of data transmission in normal / Ignition
state / OFF state sleep mode/ Emergency state, etc.
7. Configuring the time duration for Emergency state
8. Capability to reset the device
9. Command to get the IMEI of the device
Configurable commands must involve the following features:
SET: For setting the parameters.
GET: For enquiring regarding the parameters such as mobile number,
GSM strength, vehicle number and other important parameters.
CLR: For clearing certain commands, alarms, alerts etc.
After each SET, GET, CLR command the device should send alert to
