Vehicle telematics unit communication authorization and authentication and communication service provisioning

A computer system comprising a processor, a non-transitory memory, and an application stored in the non-transitory memory. When executed by the processor, the application determines that a telematics unit (TU) has connected to a messaging gateway, determines communication services to which the TU is entitled, generates metadata based on the communication services to which the TU is entitled, where the metadata comprises instructions to the TU to subscribe to topics supported by a publish-subscribe messaging gateway, and transmits the metadata to the TU.

CROSS-REFERENCE TO RELATED APPLICATIONS

Not applicable.

REFERENCE TO A MICROFICHE APPENDIX

Not applicable.

BACKGROUND

Some motor vehicles may comprise an embedded computer system referred to as a head unit or telematics unit (TU). The TU may provide a variety of operational features including providing centralized access to vehicle sensors and electro-mechanical devices via a controller area network (CAN) communication bus. The TUs may be communicatively coupled to a wireless network, and information available to the TU may be accessed remotely via wireless communication link. This capability may be useful in transportation industries for fleet management and maintenance. This capability may make automobile maintenance and troubleshooting easier for car dealerships and/or independent auto repair shops.

Some TUs may provide wireless communication services for drivers and/or passengers of the vehicle, for example data communication links to the Internet to enable access to web applications and/or to surf the web while riding in the vehicle. The TUs may also provide the ability for authorized individuals (e.g., an owner of the vehicle or proxy of the owner of the vehicle) to employ an application executing on a user equipment (UE) or mobile phone to initiate remote vehicle operations via the TU data communication link. For example, an authenticated user may initiate a remote door unlock from a UE that propagates over a communication path from the UE to the TU, and the TU may command a door lock of the vehicle to unlock over a CAN bus of the vehicle.

SUMMARY

In an embodiment, a vehicle telematics unit (TU) is disclosed. The TU comprises a processor, a non-transitory memory, a cellular radio transceiver, and an application stored in the non-transitory memory. When executed by the processor, the application reads a vehicle identification number (VIN) from a controller area network (CAN) bus of a vehicle in which the TU is installed, generates a random number, transmits a first communication authorization request via the cellular radio transceiver, where the first request comprises the VIN read from the CAN bus and the random number, and receives a short message service (SMS) message via the cellular radio transceiver, where the SMS message comprises a number. Based on determining that the number equals the random number, the application further generates a temporary communication session key, transmits a second communication authorization request via the cellular radio transceiver, where the second request comprises the VIN and the temporary communication session key, and receives a message via the cellular radio transceiver, where the message comprises a permanent session key. The application further transmits a communication authentication request via the cellular radio transceiver, where the authentication request comprises the permanent session key, receives an authentication token via the cellular radio transceiver, and connects to a messaging gateway by sending a connection request via the cellular radio transceiver, where the connection request comprises the authentication token where the messaging gateway provides remote vehicle command communication service to a vehicle in which the TU is installed.

In an embodiment, a vehicle telematics unit (TU) is disclosed. The TU comprises a processor, a non-transitory memory, a cellular radio transceiver, and an application stored in the non-transitory memory. When executed by the processor, the application reads a vehicle identification number (VIN) from a controller area network (CAN) bus of a vehicle in which the TU is installed, obtains an authentication token based on the VIN, connects to a messaging gateway by sending a connection request via the cellular radio transceiver, where the connection request comprises the authentication token. The application further receives a message comprising metadata via the cellular radio transceiver, wherein the metadata identifies at least one topic supported by the messaging gateway the TU is to subscribe to, and transmits a subscription request via the cellular radio transceiver to the messaging gateway to subscribe to the at least one topic identified in the metadata. The application further receives information via the cellular radio transceiver from the messaging gateway published to the at least one topic, and configures the TU to provide communication services in accordance with the information published to the at least one topic.

In an embodiment, a computer system is disclosed. The computer system comprises a processor, a non-transitory memory, and an application stored in the non-transitory memory. When executed by the processor, the application determines that a telematics unit (TU) has connected to a messaging gateway, determines communication services to which the TU is entitled, generates metadata based on the communication services to which the TU is entitled, where the metadata comprises instructions to the TU to subscribe to topics supported by the messaging gateway, whereby subscribing to the topics causes information to be published to the TU that the TU uses to configure itself to provide the communication services to which it is entitled, and transmits the metadata to the TU.

DETAILED DESCRIPTION

Motor vehicles may have a telematics unit (TU) or head unit installed. TUs are computers that may execute specialized automotive applications like navigation applications, backup camera imaging applications, entertainment system applications, remote vehicle operation applications, maintenance support applications, and other vehicle applications. The TUs may communicate with sensors and electromechanical items in the vehicle via a controller area network (CAN) bus of the vehicle. TUs may provide access to a variety of wireless communication services. Some of the wireless communication services may be leased or subscription services. For example, the TU may be provisioned to execute ten remote vehicle operation commands over a predefined duration of time, in exchange for a payment from the subscriber and/or vehicle owner.

The disclosure teaches an authentication and authorization process that deters and/or reduces susceptibility to fraud and spoofing by bogus telematics units (e.g., a TU that poses as a different TU to obtain desirable communication services without paying a subscription fee for the services). The disclosure further teaches a system for configuring and updating TU communication services and/or functionality based on “pushing” a metadata file to the TU that identifies topics the TU is to subscribe to via a messaging gateway. The messaging gateway publishes information to those topics to the TU, and the TU uses the information to configure itself to deliver the communication services associated with the topics. Said in other words, the metadata pushed to the TU effectively programs or configures, via the indirection of identifying topics the TU is to subscribe to, the communication services that the TU is authorized to provide to the user and/or driver of the vehicle.

When a communication service changes for the TU—either an additional service is authorized for the TU (e.g., because a user has paid for an additional service) or a service currently provided by the TU is rescinded—the system commands the TU to disconnect and reconnect to the messaging gateway, it builds a new metadata file incorporating the subject change, pushes the metadata file to the TU, and the TU subscribes to topics in accordance with the new metadata file, thereby configuring an additional service or not configuring a former service. The system can support rapid changes to a communication service set that is supported by the TU, which can promote a variety of objectives of wireless communication service providers and vehicle original equipment manufacturers. In an embodiment, the system can support rapid deployment of new functionality by publishing information to a topic subscribed to by the TU that defines application programming interfaces (APIs) in the vehicle accessible via a controller area network (CAN) of the vehicle. This can enable the TU to provide functionality previously unsupported by the TU.

The disclosure teaches an authentication and authorization (A2) process for the TU to connect to a communication hub to receive wireless communication services. The process provides a variety of mechanisms to deter fraud. For example, looking up self-identifying information by reading data stored in the vehicle via the CAN bus such as the vehicle identification number (VIN) rather than storing the VIN in the TU. Thus, if the TU is removed from the vehicle it may not be operable if installed in another vehicle. Providing this looked up information in the authorization request allows the communication hub to determine the continued association of the TU with the appropriate vehicle. When an initial reply containing a temporary communication credential is sent to the TU by the communication hub, it is sent as a short message service (SMS) message to the TU at a telephone number associated with the TU in a data store in the communication hub, which acts as a further deterrence to fraud (i.e., it deters spoofing of a phone number of the TU by another device).

The disclosure further teaches a command and control (C2) process managed by the communication hub that configures the TU to provide the communication and operation functions to which the TU and/or the vehicle is entitled. When the TU connects to the communication hub, a C2 component in the hub sends a message to the TU identifying communication topics the TU should register to subscribe to or to publish to. This registration effectively configures or provisions the TU with the specific communication services to which it is entitled. This information is sent down to the TU in the form of metadata. The TU subscribes with a messaging gateway to the topics identified by the metadata. The messaging gateway publishes information on the topics subscribed to by the TU, and at least some of the information causes the TU to configure or program itself to provide specific communication services and/or other functionality. Some of the services may be preprogrammed into the TU, and the published information may cause the TU to enable the subject service, analogous to turning on a switch. Other services may be programmed in part by the published information. Some of the information included in the metadata, in addition to topics to subscribe and publish to, may comprise commands of how often to publish information to the topics the TU registers to publish to.

When a service manifest for a TU changes, the C2 component may command the TU to disconnect and then reconnect. When the TU disconnects, the previous registrations for topics to publish or subscribe to are discarded. When the TU reconnects, the C2 component sends new metadata to the TU that describes the changed services—either additional services or reduced services—to which the TU is entitled, in the form of commands to register to subscribe to or publish to topics.

The TU may provide an ability to temporarily subscribe to a settings topic, whereby the TU may receive settings published to the TU that the TU can use to configure settings such as seat position settings, mirror position settings, radio selection button settings, vehicle handling mode settings, and the like. The driver may be able to temporarily subscribe to his or her custom settings in a plurality of vehicles having different TUs. For example, the TU may provide a user interface displayed on a touchscreen display unit to select settings to be downloaded. The selection may allow a driver to select a driver 1, a driver 2, a driver 3, etc., whereby settings associated with the identified driver are subscribed to. Alternatively, the selection may allow a driver to select a driver by name.

In an embodiment, the TU or an application that executes on a server such as on an enterprise service bus system may process or transcode a user settings file to adapt the settings to a known geometry of a vehicle in which the TU is installed. For example, the settings values in the settings file may be adapted by the TU or by a centralized computer system for a first use in adjusting mirror positions and seat positions in a large sport utility vehicle (SUV) and adapted again for a second use in a sports car. The process of transcoding user settings may take into account settings limitations in different vehicles. For example, a first vehicle may support 12 FM radio programmed selection buttons while a second vehicle may support only 10 FM radio programmed selection buttons. The transcoding may drop off 2 of the FM radio programmed selection buttons when adapting the settings file to the TU of the second vehicle. The universal settings file that can be adapted to different vehicles, as taught above, may be used when a driver uses an alternative vehicle such as a spouse's vehicle, a friend's vehicle, a rental vehicle, a relative's vehicle, a co-worker's vehicle, and the like.

Turning now toFIG. 1, a system100is described. In an embodiment, the system100comprises a vehicle104having a telematics unit (TU)118or head unit installed. The TU118may communicate via wireless links to a first enhanced node B (eNB)120and to a network116. The system100further comprises a messaging gateway122having a publish-subscribe message distribution application124, an authorization-authentication (A2) server126executing an A2 application128, and a command and control (C2) server130executing a C2 application132. In some contexts the A2 application128may be referred to as an A2 application or an A2 component, and the C2 application132may be referred to as a C2 application component or a C2 component. The system100further comprises a user equipment (UE)102that communicates via wireless links to a second eNB114. The system100may comprise any number of vehicles104, TUs118, and eNBs114,120. The vehicle104may be any of an automobile, a mini-van, a van, a sport utility vehicle (SUV), a pickup truck, a delivery truck, a semi-truck, a boat, or another vehicle.

The messaging gateway122, the C2 server130, and the A2 server126may collectively constitute a communications hub or a part of a communication hub. The communication hub may comprise other applications and/or components not shown inFIG. 1. In an embodiment, two or more of the A2 application128, the C2 application132, and the publish-subscribe application124may execute on a single server or computer system. For further details about a communication hub that supports communication services for the TU118, see U.S. patent application Ser. No. 14/698,522, filed Apr. 28, 2015, entitled “Vehicle Remote Operations Control,” by Sridhar Reddy Amireddy, et al., which is incorporated herein by reference in its entirety.

The UE102may be a smart phone, a media player, a wearable computer, a headset computer, or a wireless enabled portable computer such as a laptop computer, a notebook computer, or a tablet computer. The UE102comprises a radio frequency transceiver108, a processor110, a memory112, and a vehicle remote operations command client106stored in the memory112. The TU118may register with the publish-subscribe message distribution application124to subscribe to receive remote operation commands published by the UE102and/or the vehicle remote operations command client106, for example remote door unlock commands, remote door lock commands, remote engine turn on commands, remote engine turn off commands, remote environmental control commands, remote horns and lights commands, and the like.

When the vehicle104is turned off (e.g., the vehicle104is parked at a workplace) the TU118disconnects from the messaging gateway122after a period of time of inactivity. When the vehicle104is turned back on or the TU118is commanded to wake up by an event manager component (not shown) of the communication hub, the TU118performs an authentication process, and, if authentication succeeds, connects to the messaging gateway122and/or the publish-subscribe message distribution application124. In some circumstances (e.g., when a permanent session key provided by the TU118during the authentication process expires) an authorization process may be completed before performing the authentication process. For further details about an event manager component, see U.S. patent application Ser. No. 14/703,997, filed May 5, 2015, entitled “Network Event Management Support for Vehicle Wireless Communication,” by Sridhar Reddy Amireddy, et al., which is incorporated herein in its entirety.

In the case that the authorization and authentication processes succeed, the TU118then connects to the messaging gateway122and/or the publish-subscribe message distribution application124. When connected to the messaging gateway122, the TU118may subscribe to receive notifications from specific topics and to publish notifications to specific topics. For example, the TU118may subscribe to receive vehicle remote operation commands published by the UE102and/or the vehicle remote operations client106. When the TU118receives a vehicle remote operation command, it may send a command to an appropriate device or controller in the vehicle104over a controller area network (CAN) bus of the vehicle104, for example send an unlock command over the CAN bus to an electro-mechanical door lock system. As another example, the TU118may register to publish information to a fuel level topic specific to the vehicle118and may periodically publish fuel level information to the messaging gateway122. The TU118may register to publish information to a tire inflation pressure topic, to publish information to a vehicle speed topic, to publish information to a vehicle location topic, and other topics.

Turning now toFIG. 2, a block diagram of the TU118is described. In an embodiment, the TU118comprises a cellular radio transceiver140, a processor142, and a non-transitory memory144. The non-transitory memory144may store a messaging client application146, user settings148, an entertainment application150, an environment control application152, and a remote operations event handling application158. In an embodiment, the user settings148may be stored not in the non-transitory memory144but rather in a main memory or volatile memory of the TU118. The non-transitory memory144may further store other applications (not shown) such as one or more of a backup camera application, a navigation application, a graphics display application, and other applications. The cellular radio transceiver140is configured to wirelessly communicate with the eNB118according to one of a long term evolution (LTE), a code division multiple access (CDMA), a global system for mobile communications (GSM), or a worldwide interoperability for microwave access (WiMAX) wireless communication protocol.

The messaging client application146may establish a communication connection with the publish-subscribe message distribution application124and/or the messaging gateway122. The messaging client application146may register with the publish-subscribe message distribution application124to publish to topics and to subscribe to receive messages about or from other topics. The messaging client application146may receive published messages on topics to which it has subscribed and may distribute information contained in those messages to applications executing in the TU118or to vehicle systems via the CAN bus. The messaging client application146may read information from applications executing in the TU118or read information from vehicle systems via the CAN bus and publish this information to appropriate topics that it has previously registered to publish to.

When the messaging client application146disconnects from the publish-subscribe message distribution application124and/or the messaging gateway122when the TU118goes dormant, the messaging client application146deregisters from all topics. During boot of the TU118, the messaging client application146, after completing an authentication process, connects to the publish-subscribe message distribution application124and/or the messaging gateway122(in some circumstances, e.g., when a permanent session key has expired, the TU118may complete an authorization process before performing the authentication process). When the TU118connects to the messaging gateway122, the messaging client application146may register with the messaging gateway122to a baseline topic. The C2 application132may determine that the TU118and/or the messaging client application146has connected to the messaging gateway122and/or to the publish-subscribe message distribution application124and publish a notification to the baseline topic associated with the specific TU118that comprises metadata identifying topics that the TU118and/or the messaging client application146is to register to publish to and subscribe to. Alternatively, the C2 application132may transmit the metadata directly to the TU118.

In response to receiving the baseline notification comprising the metadata, the messaging client application146registers with the messaging gateway122and/or the publish-subscribe message distribution application124for the topics identified in the metadata. Some of the topics that the messaging client application146subscribes to publish information to the messaging client application146that causes the messaging client application146to configure and/or program the TU118to provide communication services and/or other services to a user and/or driver of the vehicle104. In some cases, the information published to the messaging client application146may cause the TU118to enable or switch from an inactive to an active state pre-programmed functionality in the TU118. Other pre-programmed functionality in the TU118may remain disabled and dormant, perhaps because a user and/or driver of the vehicle104has not enrolled to receive the associated service.

Some published information sent to the messaging client application146may inform and/or describe application programming interfaces (APIs) of systems and/or controllers in the vehicle104, accessible to the TU118via the CAN bus. The published information may further enable the TU118and/or the messaging client application146to invoke and/or to build services not previously installed in the TU118based in part on using the APIs described in the published information and based in part on abstractly defined functions which are concretely or specifically defined by the published information. Thus, new functionality can be delivered via the subscription mechanism that was not previously defined or encapsulated concretely in the TU118.

As an example, a car manufacturer rolls out a brand new model of a high performance sports car, and a new feature available locally in the vehicle is the ability to record a video from the front camera with overlaid contextual information (e.g. speed, engine RPM, g-forces). In an embodiment, the C2 application132sends new modules or functionality that enable the use of previously unknown native vehicle APIs to the messaging client application146. In this embodiment, TUs118would have the same base messaging client application146, and the C2 application132may enable the messaging client application146to use various authorized API's provided by the firmware in the TU118using only some configuration parameters. The C2 application132may send metadata information about the new API to the messaging client application146. The messaging client application146could then consume this API metadata and enable a cloud-based feature that allows the user and/or driver to upload their videos via a wireless communication link provided by a cellular radio transceiver in the TU118directly from the vehicle104to some service. The metadata may contain parameters that describe the nature of the service, the messaging client application's intended role in service enablement, and how to use the new API. This would reduce time to market as it would not require an over-the-air firmware update or new messaging client application146download. It would be as simple as writing the metadata for the new API and distributing to authorized vehicles—it wouldn't even be a client code change.

The C2 application132may determine what topics to command the TU118and/or the messaging client application146to register to publish to and to subscribe to based on information about communication services that a user of the vehicle104has paid for or enrolled to receive. For example, a service manifest may be provided by a wireless communication service provider that operates the eNBs114,120and the communication hub. The service manifest may identify communication services and service level agreements for those services to which a user and/or TU118is entitled. These services may be grades of communication service to extend to the TU118, for example a transmit bandwidth to be configured into the cellular radio transceiver140or a cellular wireless communication technology to be used that is thereby configured into the cellular radio transceiver140. The services may be a volume of data that may be transferred via the cellular radio transceiver140either downloaded to the TU118or uploaded from the TU118.

The services may be a number of vehicle remote operations commands that may be performed. The C2 application132may monitor the number of times that the TU118executes remote vehicle operation commands and when an allowed number of commands have been executed, may generate and send to the TU118a second metadata that suppresses the instruction to the TU118to subscribe to the remote operation command. The C2 application132may accomplish the revision of the TU118services by sending a disconnect command to the TU118followed by a connect message to the TU118, wherein the second metadata is sent to the TU118after the TU118reconnects to the messaging gateway122.

The entertainment radio application150may be configured to provide AM radio functionality, FM radio functionality, and satellite radio functionality. The entertainment radio application150may be communicatively coupled to one or more radio receivers in the vehicle to receive broadcast audio content. In an embodiment, the entertainment radio application150may have additional functionality to condition and amplify audio content for playback through speakers. For example, the entertainment radio application150may present a control interface on the display that a driver or passenger can use to adjust volume, bass, midrange, treble, left-right balance, front-rear fade, and other operation parameters of an audio system in the motor vehicle104. In an embodiment, the entertainment radio application150may further support receiving and processing audio input from a compact disc player, from an auxiliary device such as an MP3 player, or from some other audio source. The entertainment radio application150may read from the user settings148to associate radio pre-select buttons with specific AM radio stations, FM radio stations, or satellite radio stations as defined in the user settings148.

An environment control application152may be configured to control air conditioning and heating systems of the motor vehicle to maintain the interior environment of the motor vehicle104at a temperature that is comfortable to the driver and/or passengers. In an embodiment, the environment control application152may comprise two or more environment control applications or application frameworks. For example, control of the vehicle heating system may be provided via a first environment control application framework and control of the vehicle air conditioning system may be provided by a second environment control application framework. A windshield defrosting system may be provided by a third environment control application framework, or the defrosting system may be integrated with the vehicle heating system.

The remote operations event handling application158may be configured to subscribe to vehicle remote operation events and to process those events. When the remote operations event handling application158receives a vehicle remote operation event publication from the publish-subscription distribution application124(for example relayed to it by the messaging client application146), the remote operations event handling application158processes the event and/or message. For example, the remote operations event handling application158may send a command to an electro-mechanical device in the motor vehicle104via the CAN bus.

Turning now toFIG. 3AandFIG. 3B, a method200is described. The method200may be performed, at least in part, by the messaging client application146of the TU118. At block202, the TU118reads a vehicle identification number (VIN) from the CAN bus of the vehicle104. At block204, the TU118generates a random number or a nonce. In an embodiment, the TU118may further generate a client challenge key. At block206, the TU118transmits a first communication authorization request via the cellular radio transceiver140, where the first request comprises the VIN read from the CAN bus and the random number. In an embodiment the first request may further comprise the client challenge key and identifying information about the TU118. The TU identifying information may comprise one or more of an electronic serial number (ESN) of the TU118, a mobile equipment identity (MEID) of the cellular radio transceiver140, an international mobile station equipment identity (IMEI) of the transceiver140, a mobile directory number (MDN) or phone number associated with the transceiver140, a preferred roaming list (PRL) version configured in the transceiver140, and/or other identifying information. The first request may further comprise a client identity (client ID) associated with the messaging client application146and an empty password or a null value in a password field of the first request.

The first communication authorization request may be conveyed to the A2 application128for processing. In an embodiment, the A2 application128replies to the TU118that the request is unauthorized, due to the empty password. The A2 application128requests validation that the VIN provided in the first communication authorization request is associated with a vehicle participating in the communication services supported by the communication hub, by attempting to retrieve data associated with the vehicle104and/or the TU118from a master database of the communication hub. The request for data comprises the VIN sent in the first request by the TU118. In an embodiment, the request for data further comprises TU identifying information. If an entry for the vehicle104and/or the TU118are present in the master database, an MDN or telephone number of the TU118and/or the cellular radio transceiver140is returned to the A2 application128. The A2 application128may store the client challenge key and generate a server challenge key. The A2 application may send a request to an event manager component of the communication hub to send a short message service (SMS) message on behalf of the A2 application128to the TU118, where the SMS message contains the server challenge key and the random number received from the TU118.

The A2 application128requests that the SMS message be sent to the MDN that it looked up in the master database. This operates as a kind of check on the legitimacy of the first communication request, as the A2 application128does not rely on an MDN provided in the request itself but looks the MDN up based on the VIN provided. The combination of the messaging client application146reading the VIN of the vehicle104across the CAN bus every time it sends the first communication authorization request with looking up the MDN based on the VIN by the A2 application128and using that MDN to send the SMS makes it difficult to spoof the TU118to hijack communication services that are provided for it.

At block208, the TU118receives a short message service (SMS) message via the cellular radio transceiver140, where the SMS message comprises a number. The TU118compares the received number to the random number that it transmitted in the first request. If the received number and the random number do not match, the TU118deems the authorization process to have failed. If the received number and the random number do match, at block210, based on determining that the received number equals the random number, the TU118generates a temporary communication session key. In an embodiment, the SMS message further comprises the server challenge key generated by the A2 application128, and the temporary communication session key may be built by concatenating the client challenge key and the server challenge key.

At block212, the TU118transmits a second communication authorization request via the cellular radio transceiver140, where the second request comprises the VIN and the temporary communication session key. In an embodiment, the second request further comprises one or more of the client ID and/or TU identifying information. In an embodiment, the second request may be conveyed to the A2 application128for processing. The A2 application128validates the temporary session key based on the earlier stored client challenge key and server challenge key. If a permanent session key associated with the TU118was previously stored, that permanent session key is cleared and/or deleted.

The A2 application128may validate the association of the VIN and TU identifying information. If the VIN does not match the TU identifying information, the TU118may have been swapped from a first vehicle to a second vehicle. This kind of swapping can be performed, for example, by an automobile dealer while managing his sales inventory. For example, a vehicle that was delivered from the factory with a TU installed may be sold to an individual who doesn't want to pay for this option. The dealer may have removed the TU118from the first vehicle and installed it in another vehicle. The A2 application128may request a TU swap (e.g., changing the association of the VIN to the TU identifying information provided in the second request). The A2 application128creates a permanent session key for the TU118and sends the permanent session key to the TU118.

At block214, the TU118receives a message via the cellular radio transceiver140where the message comprises a permanent session key. Blocks202through214may be considered to constitute, at least in part and from the perspective of the TU118, an authorization process.

At block216, the TU118transmits a communication authentication request via the cellular radio transceiver140, where the authentication request comprises the permanent session key and a mobile equipment identity (MEID) of the TU118and/or of the cellular radio transceiver140. Alternatively, the authentication request comprises the VIN looked up via the CAN bus of the vehicle104. Alternatively, the authentication request comprises a client identity that may be composed of one or more of the VIN, the MEID, the MDN, an electronic serial number, and/or other information about the TU118. In an embodiment, the authentication request may further comprise one or more of the client ID, a secret key, and TU identifying information. In an embodiment, the authentication request is conveyed to the A2 application128for processing. The A2 application128validates the permanent session key and then obtains an authentication token. In an embodiment, the authentication may be an OAuth token. The A2 application128transmits the authentication token to the TU118.

At block218, the TU118receives an authentication token via the cellular radio transceiver140. Blocks216and218may be considered to constitute, at least in part and from the perspective of the TU118, as an authentication process.

At block220, the TU118connects to the messaging gateway122and/or the publish-subscribe message distribution application124by sending a connection request via the cellular radio transceiver140, where the connection request comprises the authentication token. The messaging gateway122and/or the publish-subscribe message distribution application124may provide remote vehicle command communication service to the vehicle104in which the TU118is installed. The messaging gateway122and/or the publish-subscribe message distribution application124may provide other communication services related to publish and subscribe functions to the TU118as described further above.