Description:Fleet Tracking Device

TECHNICAL FIELD

[001] The present disclosure relates to tracking of vehicles, fleet management, anti-theft devices for vehicles, using wireless Machine-to-Machine communication and a gateway device such as On-Board Diagnostics (OBD) scanners, vehicle tracking devices.
BACKGROUND
[002] In logistics, it is a necessity to be able to track a vehicle’s location and monitor key parameters. Vehicle theft remains a significant concern, necessitating effective security measures to prevent unauthorized access and theft.
[003] Traditional anti-theft systems may lack real-time monitoring capabilities or fail to provide timely alerts in case of theft attempts. There is a need for a robust anti-theft device that can detect unauthorized access to the vehicle and take immediate action to prevent theft.
SUMMARY

[004] The present invention provides a vehicle tracking system using an on board diagnostics port scanner and related fleet management including theft prevention. The disclosed device provides for key parameter tracking and theft prevention device that utilizes Wireless Machine-to-Machine (M2M) communication and OBD interfaces for real-time connectivity and intervention.
[005] The device is connected to the vehicle's OBD port and communicates with an external gateway device via Wireless Machine-to-Machine communication scheme. In one embodiment, upon detecting unauthorized access or tampering, the device triggers an alarm and immobilizes the vehicle to prevent theft. In another embodiment, the device monitors parameters such as fuel consumption, vehicle tire pressure, variation in route alerts, based on data sent by the device.
[006] The device sends device specific data termed as ‘Heartbeat’, Encoded data (for every command/actions) and other relevant data to gateway OBD device which uses GPRS to send data to the server. The device can be configured with an OBD splitter in case only a single port is available, or if an existing OBD port is used by another device. Thus, the device can be used independently and in conjunction with other devices using the vehicle OBD port.
BRIEF DESCRIPTION OF THE DRAWINGS
[007] In the following, embodiments of the present invention including the figures will be described as non-limiting examples with reference to the accompanying drawings in which:
[008] FIG. 1 illustrates the components of the vehicle theft prevention device and its connection to the vehicle's OBD port using one particular method;
[009] FIG. 2 depicts an example of Wireless Machine-to-Machine (M2M) communication between the device and an external gateway device(OBD tracker, vehicle tracker);
[0010] FIG. 3A is description of the M2M communication of FIG. 2 / FIG. 7 and describes the signaling from a sensor node to a Gateway online cloud/Server;
[0011] FIG. 3B and FIG. 3C (continuation of FIG. 3B) is the packet configuration of the packet of FIG. 3A;
[0012] FIG. 4A is description of the M2M communication of FIG. 2 and describes packet configuration from a Gateway online cloud/Server to a Sensor Node (AG) Command Packet;
[0013] FIG. 4B is packet configuration of the packet of FIG 4A;
[0014] FIG. 5A is description of the M2M communication of FIG. 2 / FIG. 7 and describes a Gateway to Sensor Node (AG) Packet Heartbeat Packet;
[0015] FIG. 5B is packet configuration of the packet of FIG. 5A;
[0016] FIG. 6A is an example embodiment of communication of FIG. 2 / FIG. 7 and describes a Gateway to Sensor Node (AG) Packet Heartbeat / Payload Packet;
[0017] FIG. 6B and FIG. 6C are packet configuration of the packet of FIG. 6A;
[0018] FIG. 7A is a diagram of an example communications system 700 in which one or more disclosed embodiments may be implemented;
[0019] FIG. 7B is a system diagram of an example device that implements the wireless machine-to-machine signaling of as described in FIG. 3/ FIG. 4 at a OBD device in car 702;
[0020] FIG. 7C is a system diagram of the RAN 703 and the core network 706 according to an embodiment as described in the present invention; and
[0021] FIG. 7D is a system diagram of signaling between a M2M Gateway, a M2M Server, a M2M Application Server, and the other network elements of FIG. 7C.

DETAILED DESCRIPTION
[0022] The present disclosure provides a detailed description of the vehicle theft prevention device and its operation. The device comprises five wires: one for power supply, one for ground, one for the siren, and two for the ignition circuit. A relay is integrated into the device, which is initially shorted to complete the ignition circuit and enable vehicle operation.
[0023] Dynamic Ignition Control: The relay is controlled dynamically to intermittently open and close the ignition circuit, preventing thieves from easily bypassing the immobilization mechanism.
[0024] Tamper Detection: The device incorporates advanced tamper detection mechanisms, including accelerometer sensors, to detect unauthorized access attempts or tampering with the device itself.
[0025] Multi-Layered Communication: To ensure reliable communication and prevent signal interference, the device utilizes multi-layered communication protocols, including error-checking mechanisms and encryption techniques, to securely transmit data between the device, OBD device, and mobile application.
[0026] Emergency Override: In situations where authorized access is required, such as emergencies or vehicle servicing, the device includes an emergency override feature accessible through a secure authentication process.
[0027] Machine type communication (MTC), or alternately machine to machine (M2M) communication, is a form of data communication which may involve one or more devices or entities that may communicate without human interaction. Respective communication networks may include any number of MTC capable devices. Metering devices or tracking devices may be examples of MTC devices. As used herein, the term On Board Diagnostics (OBDs) may include MTC devices. Machine type communications may use an MTC Server, which may alternately be referred to as an M2M Server. A M2M server may collect data or control information from MTC devices. A M2M server may also send data and other information to M2M devices. MTC devices may communicate via 3GPP networks such as Long Term Evolution (LTE) networks, Universal Mobile Telecommunication System (UMTS) networks, etc. and over WiFi / Bluetooth / Zigbee networks and the like. A cellular network node, for example a Serving General Packet Radio Service (GPRS) Support. Node (SGSN), may communicate with an M2M server. The cellular network node may receive OBD device data and control data. The control data may facilitate a network control procedure and the OBD data may identify a device involved in the network control procedure. Example network control procedures may include network attach procedures, network detach procedures, authentication procedures, security mode procedures, Packet Data Protocol (PDP) context procedures, location area update procedures, routing area update procedures, tracking area update procedures, or the like.
[0028] The cellular network node may determine that the OBD involved in the network control procedure is a machine to machine device based on a data packet received. For example, the data may include an Access Point Name (APN), and the cellular network node may determine that a device is an M2M device based on the APN. Alternatively, the data may include a header identifying that it originates from a machine / is Machine data. The cellular network node may also send the control data to a machine to machine server using a message sent via a dedicated interface with the machine to machine server. The dedicated interface may be called a GM2M interface. The dedicated interface may be a logical interface internal to the network node.
[0029] The M2M server may request control data such as the current status of a M2M device. For example, the M2M server may request control data such as an attach status, a routing area status, security mode status, authentication status, PDP context status, and/or the like. The control data may be based on mobility control information or connection control information. The request for control data may be sent to a cellular network node via the GM2M interface. The cellular network node may initiate a network control procedure based on the request from the M2M server. The cellular network node may send control information from the network control procedure to the M2M device via the GM2M interface.
[0030] A detailed description of illustrative embodiments will now be described with reference to the various Figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be exemplary and in no way limit the scope of the application.
[0031] As depicted in FIG. 1, the vehicle protection device, in one embodiment is directly inserted into the ON-Board Diagnostics (OBD) Port available. From there, once the device is powered on, it uses Wireless Machine-to-Machine communication or any other wireless Machine-to-Machine (M2M) technology to transmit and receive signals. The OBD port is shown as OBD port in FIG. 1, but it would be clear to a practitioner that OBD 1 technology could also be used. The Auto Guard Device has a built-in relay to transmit / receive vehicle ignition signals. There is a built-in fuse that prevents vehicles from starting once an appropriate command is triggered.
[0032] In a different embodiment, the guard device is connected to the OBD 2 port using Wireless Machine-to-Machine communication or the like technologies (low power requirement) and not mounted into the OBD 2 port.
[0033] FIG. 2 describes the various signals that can be generated using the auto-guard device. These include (but are not limited to): Acknowledgement Packet (ACK / NACK); IGN-Out and IGN-In Status; Maintenance Status; Battery Status; Siren Status; OBD Device Charge Status; ALS Value; RSSI Value (Real Signal Strength Indicator); Accelerometer Data; OBD Connection / Disconnection Count; Reset Count; Reset, Relay, etc.
[0034] FIG. 3A is description of the M2M communication of FIG. 2 and describes the signaling from a sensor node to a Gateway online cloud/Server. FIG. 3B and FIG. 3C (continuation of FIG. 3B) is the packet configuration of the packet of FIG. 3A. The Packet as configured in FIG. 3B/3C is an acknowledgement packet and hence designated as an ACK packet.
[0035] FIG. 4A is description of the M2M communication of FIG. 2 and describes packet configuration from a Gateway online cloud/Server to a Sensor Node (AG) Command Packet, and FIG. 4B is packet configuration of the packet of FIG 4A. This is a command issuing packet and hence designated as a CMD packet.
[0036] FIG. 5A is description of the M2M communication of FIG. 2 and describes a Gateway online cloud/Server to Sensor Node (AG) Packet Heartbeat Packet and FIG. 5B is packet configuration of the packet of FIG. 5A: This is payload packet and hence designated as an Heartbeat packet.
[0037] Each of these parameters can be multiplexed together and transmitted using an appropriate coding scheme for the receiver / server. The choice of coding scheme is dependent on the capability of the wireless signal. There is no specific order in which each of the signals is transmitted in the multiplexed signal block and is dependent upon encoding scheme available. The server / recipient decodes the multiplexed signal depending on the encoding scheme used. Even though FIG. 2 shows transmission using Wireless M2M communication, other methods of transmission are also available.
[0038] FIG. 6 depicts an embodiment of remotely controlling the auto-guard device. Once the connectivity between the OBD device and auto-guard is established using Wireless M2M communication or any other protocol, the gateway device i.e OBD Device has features that allow it to connect to both a TCP / IP Server (for fleet management), and to a User Device. When connected to the TCP / IP Server, the data may be exchanged in a predefined protocol for decoding device specific data.
[0039] In one embodiment, the device once connected to a specific User Device, identified through its IMEI, provides specific information about vehicle theft using one bit of the possible bits available.
[0040] In another embodiment, information regarding pre-programmed values for fuel consumption, tire pressure, location, etc. are provided and deviation from those pre-programmed values is sent to the server using the number of bits available. In this embodiment, more number of bits are available as no IMEI information is required and additional parameters can be transmitted to a M2M server through a gateway.
[0041] FIG. 7A is a diagram of an example communications system 700 in which one or more disclosed embodiments may be implemented. The communications system 700 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 700 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 700 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single­ carrier FDMA (SC-FDMA), and the like.
[0042] As shown in FIG. 7A, the communications system 700 may include On Board Devices (OBDs) 702a, 702b, 702c, and/or 702d (which generally or collectively may be referred to as OBD 702), a radio access network (RAN) 703 / 704 / 705, a core network 706 / 707 / 709, a public switched telephone network (PSTN) 708, the Internet 710, and other networks 712, though it will be appreciated that the disclosed embodiments contemplate any number of OBDs, base stations, networks, and/or network elements. Each of the OBDs 702a, 702b, 702c, 702d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the OBDs 702a, 702b, 702c, 702d may be configured to transmit and/or receive wireless signals and may include on board device (OBD), a wireless sensor, consumer electronics, and the like.
[0043] The communications systems 700 may also include a base station 714a and a base station 714b. Each of the base stations 714a, 714b may be any type of device configured to wirelessly interface with at least one of the OBDs 702a, 702b, 702c, 702d to facilitate access to one or more communication networks, such as the core network 706/707/709, the Internet 710, and/or the networks 712. By way of example, the base stations 714a, 714b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 714a, 714b are each depicted as a single element, it will be appreciated that the base stations 714a, 714b may include any number of interconnected base stations and/or network elements.
[0044] The base station 714a may be part of the RAN 703 / 704 / 705, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 714a and/or the base station 714b may be configured to transmit and / or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 714a may be divided into three or more sectors. Thus, in one embodiment, the base station 714a may include three or more transceivers, i.e., one for each sector of the cell. In another embodiment, the base station 714a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.
[0045] The base stations 714a, 714b may communicate with one or more of the OBDs 702a, 702b, 702c, 702d over an air interface 715 / 716 / 717, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 715 / 716 / 717 may be established using any suitable radio access technology (RAT).
[0046] More specifically, as noted above, the communications system 700 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDIVIA, SC-FDIVIA, and the like. For example, the base station 714a in the RAN 703 / 704 / 705 and the OBDs 702a, 702b, 702c, 702d may implement a radio technology such as Universal Mobile Telecom Communications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 715 / 716 / 717 using wideband CDMA (W-CDMA).WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved I-ISPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).
[0047] In another embodiment, the base station 714a and the OBDs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115 / 116 / 117 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).
[0048] In other embodiments, the base station 114a and the OBDs 702a, 702b, 702c, may implement radio technologies such as IEEE 802.l6 (i.e., World-wide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (C3SM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.
[0049] The base station 714b in FIG. 7A may be a wireless router, Home Node B, Home eNodeB, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the base station 714b and the OBDs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). ln another embodiment, the base station 714b and the OBDs 702c, 702d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 714b and the OBDs 702c, 702d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. IA, the base station 714b may have a direct connection to the Internet 710. Thus, the base station 714b may not be required to access the Internet 710 via the core network 706/707/709.
[0050] The RAN 703 / 704 / 705 may be in communication with the core network 106/107/109, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the OBDs 702a, 702b, 702c, 702d. For example, the core network 706 / 707 / 709 may provide call control, billing services, mobile location·- based services, pre- paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication.
[0051] Although not shown in FIG. 7A, it will be appreciated that the RAN 703 / 704 / 705 and / or the core network 706 / 707 / 709 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 703 / 704 / 705 or a different RAT. For example, in addition to being connected to the RAN 703 / 704 / 705, which may be utilizing an E-UTRA radio technology, the core network 706 / 707 / 709 may also be in communication with another RAN (not shown) employing a GSM radio technology. The core network 706 / 707 / 709 may also serve as a gateway for the OBDs 702a, 702b, 702c, 702d to access the PSTN 708, the Internet 710, and/or other networks 712.
[0052] The PSTN 708 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 710 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (TP) in the TCP/IP internet protocol suite. The networks 712 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 712 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 703 / 704 / 705 or a different RAT.
[0053] Some or all of the OBDs 702a, 702b, 702c, 702d in the communications system 700 may include multi-mode capabilities, i.e., the OBDs 702a, 702b, 702c, 702d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the OBD 702c shown in FIG. 7A may be configured to communicate with the base station 714a, which may employ a cellular-based radio technology, and with the base station 714b, which may employ an IEEE 802 radio technology.
[0054] FIG. 7B is a system diagram of an example device that implements the wireless machine-to-machine signaling of as described in FIG. 3/ FIG. 4 at a OBD device in car 702. This device may be mounted on to the OBD port directly or have a wireless connection with a component mounted on the OBD port. For simplicity, the device is called as OBD Device in FIG. 7B and as an Auto Guard device in FIG. 1. As shown in FIG. 7B, the OBD 702 may include a processor 718, a transceiver 720, a transmit/receive element 722, an input slot 738 for connecting external peripherals, such as a keypad, a display/touchpad etc., a non-removable memory 730, removable memory 732, a power source 734, a global positioning system (GPS) chipset 736, and other peripherals 738. It will be appreciated that the OBD 702 may include any sub­ combination of the foregoing elements while remaining consistent with an embodiment. Also, embodiments contemplate that the base stations 714a and 714b, and/or the nodes that base stations 714a and 714b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (H-eNB), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in FIG. 7B and described herein.
[0055] The processor 718 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 718 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the OBD 702 to operate in a wireless environment. The processor 718 may be coupled to the transceiver 720, which may be coupled to the transmit/receive element 722. While FIG. 7B depicts the processor 718 and the transceiver 720 as separate components, it will be appreciated that the processor 718 and the transceiver 720 may be integrated together in an electronic package or chip.
[0056] The transmit / receive element 722 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 714a) over the air interface 715 / 716 / 717. For example, in one embodiment, the transmit/receive element 722 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 722 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 722 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 722 may be configured to transmit and/or receive any combination of wireless signals.
[0057] In addition, although the transmit/receive element 722 is depicted in FIG. 7B as a single element, the OBD 702 may include any number of transmit/receive elements 722. More specifically, the OBD 702 may employ MIMO technology. Thus, in one embodiment, the OBD 702 may include two or more transmit/receive elements 722 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 715 / 716 / 717.
[0058] The transceiver 720 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 722 and to demodulate the signals that are received by the transmit/receive element 722. As noted above, the OBD 702 may have multi-mode capabilities. Thus, the transceiver 720 may include multiple transceivers for enabling the OBD 702 to communicate via multiple RATs, such as UTRA and IEEE 802.11, Bluetooth or Zigbee or any specific M2M communication protocol, for example.
[0059] The processor 718 of the OBD 702 may be coupled to, and may receive user input data from, the input slot 738. In addition, the processor 718 may access information from, and store data in, any type of suitable memory, such as the non-removable 730 and/or the removable memory 732. The non-removable memory 730 may include random­ access memory (RAM), read--only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 732 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 718 may access information from, and store data in, memory that is not physically located on the OBD 702, such as on a server or a home computer (not shown).
[0060] The processor 718 may receive power from the power source 734, and may be configured to distribute and/or control the power to the other components in the OBD 702. The power source 734 may be any suitable device for powering the OBD 702. For example, the power source 734 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.
[0061] The processor 718 may also be coupled to the GPS chipset 736, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the OBD 702. In addition to, or in lieu of, the information from the GPS chipset 736, the OBD 702 may receive location information over the air interface 715 / 716 / 717 from a base station (e.g., base stations 7l4a, 714b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations, or by Assisted GPS, a combination of GPS and base stations. It will be appreciated that the OBD 702 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.
[0062] The processor 718 may further be coupled to other peripherals 738, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 738 may include an accelerometer, an e-compass, a satellite transceiver, a universal serial bus (USB), etc. and the like.
[0063] FIG. 7C is a system diagram of the RAN 703 and the core network 706 according to an embodiment. As noted above, the RAN 703 may employ a UTRA radio technology to communicate with the OBDs 702a, 702b, 702c over the air interface 715. The RAN 703 may also be in communication with the core network 706. As shown in FIG. 7C, the RAN 703 may include Node-Bs 740a, 740b, 740c, which may each include one or more transceivers for communicating with the OBDs 702a, 702b, 702c over the air interface 715. The Node-Bs 740a, 740b, 740c may each be associated with a particular cell (not shown) within the RAN 703. The RAN 703 may also include RNCs 742a, 742b. It will be appreciated that the RAN 703 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.
[0064] As shown in FIG. 7C, the Node-Bs 740a, 740b may be in communication with the RNC 742a. Additionally, the Node-B 740c may be in communication with the RNC 742b. The Node--Bs 740a, 740b, 740c may communicate with the respective RNCs 742a, 742b via an Iub interface. The RNCs 142a, 142b may be in communication with one another via an air interface. Each of the RNCs 742a, 742b may be configured to control the respective Node-Bs 740a, 740b, 740c to which it is connected. In addition, each of the RNCs 742a, 742b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro-diversity, security functions, data encryption, and the like.
[0065] The core network 706 shown in FIG. 7C may include a media gateway (MGW) 744, a mobile switching center (MSC) 746, a serving GPRS support node (SGSN) 748, and/or a gateway GPRS support node (GGSN) 750. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.
[0066] The RNC 742a in the RAN 703 may be connected to the MSC 746 in the core network 706 via an IuCS interface. The MSC 746 may be connected to the MGW 744. The MSC 746 and the MGW 744 may provide the OBDs 702a, 702b, 702c with access to circuit switched networks, such as the PSTN 708, to facilitate communications between the OBDs 702a, 702b, 702c and traditional land-line communications devices.
[0067] The RNC 742a in the RAN 703 may also be connected to the SGSN 748 in the core network 706 via an IuPS interface. The SGSN 748 may be connected to the GGSN 750. The SGSN 748 and the GGSN 750 may provide the OBDs 702a, 702b, 702c with access to packet-switched networks, such as the Internet 710, to facilitate communications between and the OBDs 702a, 702b, 702c and IP-enabled devices.
[0068] As noted above, the core network 706 may also be connected to the networks 712, which may include other wired or wireless networks that are owned and/or operated by other service providers.
[0069] The core network may include a mobile IP home agent (MIP-HA), an authentication, authorization, accounting (AAA) server 786, and a gateway 788. While each of the foregoing elements are depicted as part of the core network 709, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator. The MIP-HA may be responsible for IP address management, and may enable the OBDs 702a, 702b, 702c to roam between different ASNs and/or different core networks.
[0070] M2M Servers may provide M2M services for M2M devices. For example, an M2M server may send data to and receive data from an M2M device. For M2M device communicating with the M2M server via a 3GPP network (e.g., a cellular network), the M2M server may collect control information or data regarding the M2M device that is generated or maintained by the 3GPP Core Network. Example control data may include, but is not limited to, mobility information (e.g., routing area information, location area information, tracking area information, etc.), connection information (e.g., PDP context information, IP address, other addressing information, network attach/detach data, etc.), security information (e.g., authentication information, cyphering information, security mode info1mation, etc.), or any other information maintained or generated by a 3GPP core network.
[0071] To send and receive data between a M2M server and a cellular network node of a 3GPP network, a connection may be established between an M2M server and the cellular network node. For example, the cellular network node may be a SGSN. The connection between the cellular network node and the M2M server may be a dedicated interface. The dedicated interface may be referred to herein as a GM2M interface. The GM2M interface may include a defined communications protocol stack. Control and/or data signals from an M2M device and an M2M server may be communicated via the dedicated interface.
[0072] The cellular network node may determine that a device is a M2M device based on subscriber data. For example, the subscriber data may include an Access Point Name (APN), and the cellular network node may determine that a device is an M2M device based on the APN. The APN may be received from another cellular network node, for example a HLR. Subscriber data may be other data which may be used to identify a machine-to-machine device. For example, if the cellular network node has communicated with the M2M device in the past, it may store an indication that identifies the device as an M2M device. When the cellular network node receives subscriber data for the M2M device, such as a device identification or address, the indication may be used to determine that the device is an M2M device.
[0073] The M2M server may request control data such as the current status of a M2M device. For example, the M2M server may request control data such as an attach status, a routing area status, security mode status, authentication status, PDP context status, and/or the like. The control data may be based on mobility control information or connection control information. The request for control data may be sent to a cellular network node via the GM2M interface. The cellular network node may initiate a network control procedure based on the request from the M2M server. The cellular network node may send control information from the network control procedure to the M2M device via the GM2M interface.
[0074] The systems and methods disclosed herein may be described in relation to connecting an M2M Server to the SGSN of the 3GPP Core Network. However, the systems and methods disclosed herein may be applicable to other connection implementations. As such, use of the concepts described herein may not be limited to connections relating to the SGSN of the 3GPP Core Network. For example, the interface may be between the M2M server and a GGSN. In another example the dedicated interface may be between the M2M server and a MME in an LTE network. FIG. 7D is a system diagram of signaling between a M2M Gateway, a M2M Server, a M2M Application Server, and the other network elements of FIG. 7C.
[0075] FIG. 4 describes the packet configuration that is sent from any of the gateways using desired wireless communication technologies, for example, LTE / LTE-A. These packets are command packets and include header information about the payload. The payload is described in FIG. 4B and FIG. 4C. FIG. 4C is a continuation of the Packet of FIG. 4B. This embodiment describes in detail how the data sent by the device can prevent theft.
[0076] In another embodiment, the packet includes data such as fuel consumption, tire pressure, positioning using the onboard positioning devices, planned route, deviation, run time, etc. for fleet management. The packet can be configured accordingly to include that data. At the server, the server is analyzed and information useful for fleet management is observed. For example, if the packet contains data that fuel consumption is high, along with low tire pressure, an alert can be sent to the vehicle driver to correct the tire pressure at the next available point accordingly.
[0077] In another embodiment, laden weight of the vehicle is monitored and in the event of an alert in reduction of weight, an appropriate message is sent to fleet manager / user.
[0078] Thus, the packet itself can be configured to take data from the OBD port given that the port itself is a diagnostics port. In vehicles, the OBD2 port provides for specific instructions, say for reduction in engine temperature. Once the data is sent to the M2M server and processed at the server, a corresponding command can be issued, for example, to inject water into the engine to cool it down. For other engines, such as gas based engines, appropriate liquid may be inserted.
[0079] Several other types of signaling may be provided in additional or alternative embodiments of the present invention in the auto-guard / OBD2 device. Accordingly, one skilled in the art will recognize that an embodiment of the present invention may provide functionality based on either segment or a User Defined Protocol. The Payload is designed in such a way that it complements the existing TCP server thus makes it easy to parse, and link with the relevant vehicle ID on the basis of the IMEI of the gateway updated by the installer which makes it very scalable.
[0080] The device may be latched with the dashboard that has been provided to the client via Android App and it will provide him notification if there will be any tampering with the OBD Device(i.e., if it’s been plugged out), and it will also play the siren in that case, he can turn it off. The device allows him to play and stop the siren remotely, turn the vehicle on or off by toggling the Ignition Relay through the Android App.
[0081] In the above-description of various embodiments of this disclosure, it is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and may not be interpreted in an idealized or overly formal sense expressly so defined herein.
[0082] At least some example embodiments are described herein with reference to block diagrams and/or flowchart illustrations of computer implemented methods, apparatus (systems and/or devices) and/or computer program products. It is understood that a block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by computer program instructions that are performed by one or more computer circuits. Such computer program instructions may be provided to a processor circuit of a general purpose computer circuit, special purpose computer circuit, and/or other programmable data processing circuit to produce a machine, so that the instructions, which execute via the processor of the computer and/or other programmable data processing apparatus, transform and control transistors, values stored in memory locations, and other hardware components within such circuitry to implement the functions/acts specified in the block diagrams and/or flowchart block or blocks, and thereby create means (functionality) and/or structure for implementing the functions/acts specified in the block diagrams and/or flowchart block(s). Additionally, the computer program instructions may also be stored in a tangible computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instructions which implement the functions/acts specified in the block diagrams and/or flowchart block or blocks.
[0083] It should therefore be clearly understood that the order or sequence of the acts, steps, functions, components or blocks illustrated in any of the flowcharts depicted in the drawing Figures of the present disclosure may be modified, altered, replaced, customized or otherwise rearranged within a particular flowchart, including deletion or omission of a particular act, step, function, component or block. Moreover, the acts, steps, functions, components or blocks illustrated in a particular flowchart may be inter-mixed or otherwise inter-arranged or rearranged with the acts, steps, functions, components or blocks ill1ustrated in another flowchart in order to effectuate additional variations, modifications and configurations with respect to one or more processes for purposes of practicing the teachings of the present patent disclosure.
* * *

, Claims:CLAIMS
We Claim:
1. A method for managing machine-to-machine (M2M) communication for vehicle fleet management, wherein a device connected to On Board Diagnostics (OBD) port of a vehicle, comprising:
establishing a connection between the device connected to the OBD port and a M2M server using either of low powered connection or high powered connection when enabled in the device;
transmitting an acknowledgement packet including, header information, size, a MAC ID, a sensor status, device charging status, connect / disconnect count, reserved bytes, checksum, wherein the transmission is done depending on the time frame available for the transmission technology and is different for low power transmission and those of high powered connections;
receiving at the M2M server, the acknowledgement packet and transmitting to the device connected to the OBD port a command packet including header information, size, MAC ID, a sensor status, device charging status, connect / disconnect count, reserved bytes, checksum to establish the connection between the device and the M2M server;
receiving at the device connected to the OBD port from the M2M server a payload packet comprising header, size, reserved bytes, checksum, an IMEI Status when provided, and any of speed parameter, tire pressure parameters, last known assisted-GPS position, fuel consumption rate, laden weight, and refuelling status; and
executing the instructions in the payload packet for the vehicle.

2. The method of claim 1, wherein in the case of deviation from measured values stored at the M2M server of speed parameter, tire pressure parameters, last known assisted-GPS position, fuel consumption rate, laden weight and refuelling status for the vehicle, the device connected to the OBD port, takes actions as preset in a status parameter of the payload package.
3. The method of claim 2, wherein the M2M Server indicates vehicle engine immobilize to the device connected to the OBD port in the Status parameter.
4. The method of claim 2, wherein the M2M Server indicates to cut off fuel supply to vehicle engine to the device connected to the OBD port in the Status parameter.
5. The method of claim 1, wherein the M2M Server is a hand-held user device.
6. The method of claim 1, wherein the packet length are variable depending on the channel conditions and transmitted / received in parts using appropriate coding technology / channel condition.
7. The method of claim 1, wherein a dedicated interface of the M2M Server is provided to a User for fleet management.
8. The method of claim 1, wherein the packets are transmitted / received for a timeout period depending on the transmission technology used.
9. The method of claim 1, wherein the payload packet is a trigger for altering vehicle driver to either refuel, drive below a designated speed threshold, correct tire pressure, change course / update destination, and the like.

10. A device for machine-to-machine (M2M) communication in vehicle fleet management, wherein the device is connected to On Board Diagnostics (OBD) port of a vehicle, comprising:
a transceiver configured to establish a connection between the device connected to the OBD port and a M2M server using either of low powered connection or high powered connection when enabled in the device;
transmitting an acknowledgement packet including, header information, size, a MAC ID, a sensor status, device charging status, connect / disconnect count, reserved bytes, checksum, wherein the transmission is done depending on the time frame available for the transmission technology and is different for low power transmission and those of high powered connections;
receiving at the M2M server, the acknowledgement packet and transmitting to the device connected to the OBD port a command packet including header information, size, MAC ID, a sensor status, device charging status, connect / disconnect count, reserved bytes, checksum to establish the connection between the device and the M2M server;
receiving at the device connected to the OBD port from the M2M server a payload packet comprising header, size, reserved bytes, checksum, an IMEI Status when provided, and any of speed parameter, tire pressure parameters, last known assisted-GPS position, fuel consumption rate, laden weight, and refuelling status; and
a processor coupled to the memory for executing the instructions in the payload packet for the vehicle.
* * *