Virtual network interface connectivity

A mobile device receives a message from a vehicle computing platform via remote process communication (RPC), updates an origin address of the message to indicate the mobile device, sends the message to a destination address of the message, receives a response message from the destination, updates a destination address of the response message to indicate the computing platform, and sends the response message to the computing platform via the RPC. A computing platform constructs a remote procedure call (RPC) message by a virtual network interface application for a request received from a vehicle application for a network protocol unsupported by a mobile device, and sends the RPC to the mobile device to cause the mobile device to update an origin address of the request to indicate the mobile device and send the request to a destination address of the request.

TECHNICAL FIELD

Aspects of the disclosure generally relate to a virtual network interface for use by vehicle applications accessing network connectivity of a connected mobile device.

BACKGROUND

Mobile devices, such as smartphones, can be connected to a vehicle head unit to provide connected services to vehicle occupants. These connected services may include hands free calling, audio streaming, and integration with brought-in mobile device applications. Applications that are executed by the mobile device can make use of the network connectivity of the mobile device. However, applications that are executed by the vehicle require connection to the mobile device (e.g., via Wi-Fi, BLUETOOTH, or USB) to utilize the network connectivity of the mobile device.

SUMMARY

In one or more illustrative embodiments, a system includes a mobile device. The mobile device is programmed to receive a message from a vehicle computing platform via remote process communication (RPC), update an origin address of the message to indicate the mobile device, send the message to a destination address of the message, receive a response message from the destination, update a destination address of the response message to indicate the computing platform, and send the response message to the computing platform via the RPC.

In one or more illustrative embodiments, a system includes a computing platform. The computing platform is programmed to a computing platform programmed to construct a remote procedure call (RPC) message by a virtual network interface application for a request received from a vehicle application for a network protocol unsupported by a mobile device, and send the RPC to the mobile device to cause the mobile device to update an origin address of the request to indicate the mobile device and send the request to a destination address of the request.

In one or more illustrative embodiments, a method includes receiving, by a computing platform from a mobile device, indications of network protocols that are natively supported by the mobile device; receiving a request from a vehicle application utilizing a network protocol; sending the request to the mobile device for handling by a native application of the mobile device responsive to the network protocol being natively supported, and otherwise sending the request to the mobile application using a proxying approach.

DETAILED DESCRIPTION

When an application executed by a vehicle requests data using a standard protocol such as hypertext transfer protocol (HTTP), the vehicle can provide the HTTP header info to the connected device (e.g., via Smart Device Link (SDL)) and the mobile device may execute an application implementing the standard protocol as a remote service to upload or download data using the mobile device. However, if the vehicle application uses an application layer protocol such as MQ Telemetry Transport (MQTT) that is not supported by a service of the mobile device, the mobile device may be unable to fulfill the request to the vehicle application.

Although a vehicle occupant may configure a mobile device to act as a hotspot for the vehicle to use it as a modem, such a setup may prevent the occupant from using the mobile device for wireless projection to the vehicle user interface. Moreover, hotspot functionality typically requires a vehicle occupant to actively enable the hotspot that is generally not enabled.

An improved system and method for allowing vehicle applications to utilize connectivity of the mobile device is provided. An application executed by the vehicle computing platform utilizes a virtual network interface to represent a connected device network interface. Using a packet sniffer (e.g., a layer three packet sniffer), generated IP packets from the application are captured. These IP packets may be transferred to the mobile device using a remote procedure mechanism (e.g., SDL's RPC mechanism), where the source IP address of the packet is changed to the IP address of the mobile device. This updated IP packet is then sent to the destination IP from the mobile device. When a response to the packet is received back to the mobile device, the packet address is again updated, and the packet is routed back through the RPC mechanism (e.g., via to the SDL core) and therefore back to the vehicle application. The virtual network interface may further allow for vehicle applications to receive active network state information related to the connected mobile device (e.g., cellular connection, Wi-Fi connection, etc.). Further aspects of the disclosure are described in detail below.

FIG. 1illustrates an example diagram of a system100configured to provide telematics services to a vehicle102. The vehicle102may include various types of passenger vehicle, such as crossover utility vehicle (CUV), sport utility vehicle (SUV), truck, recreational vehicle (RV), boat, plane or other mobile machine for transporting people or goods. Telematics services may include, as some non-limiting possibilities, navigation, turn-by-turn directions, vehicle health reports, local business search, accident reporting, and hands-free calling. In an example, the system100may include the SYNC system manufactured by The Ford Motor Company of Dearborn, Mich. It should be noted that the illustrated system100is merely an example, and more, fewer, and/or differently located elements may be used.

The computing platform104may include one or more processors106configured to perform instructions, commands and other routines in support of the processes described herein. For instance, the computing platform104may be configured to execute instructions of vehicle applications110to provide features such as navigation, accident reporting, satellite radio decoding, and hands-free calling. Such instructions and other data may be maintained in a non-volatile manner using a variety of types of computer-readable storage medium112. The computer-readable medium112(also referred to as a processor-readable medium or storage) includes any non-transitory medium (e.g., a tangible medium) that participates in providing instructions or other data that may be read by the processor106of the computing platform104. Computer-executable instructions may be compiled or interpreted from computer programs created using a variety of programming languages and/or technologies, including, without limitation, and either alone or in combination, Java, C, C++, C#, Objective C, Fortran, Pascal, Java Script, Python, Perl, and PL/SQL.

The computing platform104may be provided with various features allowing the vehicle occupants to interface with the computing platform104. For example, the computing platform104may include an audio input114configured to receive spoken commands from vehicle occupants through a connected microphone116, and auxiliary audio input118configured to receive audio signals from connected devices. The auxiliary audio input118may be a physical connection, such as an electrical wire or a fiber optic cable, or a wireless input, such as a BLUETOOTH audio connection. In some examples, the audio input114may be configured to provide audio processing capabilities, such as pre-amplification of low-level signals, and conversion of analog inputs into digital data for processing by the processor106.

The computing platform104may also provide one or more audio outputs120to an input of an audio module122having audio playback functionality. In other examples, the computing platform104may provide the audio output to an occupant through use of one or more dedicated speakers (not illustrated). The audio module122may include an input selector124configured to provide audio content from a selected audio source126to an audio amplifier128for playback through vehicle speakers130or headphones (not illustrated). The audio sources126may include, as some examples, decoded amplitude modulated (AM) or frequency modulated (FM) radio signals, and audio signals from compact disc (CD) or digital versatile disk (DVD) audio playback. The audio sources126may also include audio received from the computing platform104, such as audio content generated by the computing platform104, audio content decoded from flash memory drives connected to a universal serial bus (USB) subsystem132of the computing platform104, and audio content passed through the computing platform104from the auxiliary audio input118.

The computing platform104may utilize a voice interface134to provide a hands-free interface to the computing platform104. The voice interface134may support speech recognition from audio received via the microphone116according to a standard grammar describing available command functions, and voice prompt generation for output via the audio module122. The voice interface134may utilize probabilistic voice recognition techniques using the standard grammar176in comparison to the input speech. In many cases, the voice interface134may include a standard user profile tuning for use by the voice recognition functions to allow the voice recognition to be tuned to provide good results on average, resulting in positive experiences for the maximum number of initial users. In some cases, the system may be configured to temporarily mute or otherwise override the audio source specified by the input selector124when an audio prompt is ready for presentation by the computing platform104and another audio source126is selected for playback.

The standard grammar135includes data to allow the voice interface134to match spoken input to words and phrases that are defined by rules in the standard grammar135. The standard grammar135can be designed to recognize a predefined set of words or phrases. A more complex standard grammar135can be designed to recognize and organize semantic content from a variety of user utterances. In an example, the standard grammar135may include commands to initiate telematics functions of the vehicle102, such as “call,” “directions,” or “set navigation destination.” In another example, the standard grammar135may include commands to control other functionality of the vehicle102, such as “open windows,” “headlights on,” or “tune to radio preset three.”

The computing platform104may also receive input from human-machine interface (HMI) controls136configured to provide for occupant interaction with the vehicle102. For instance, the computing platform104may interface with one or more buttons or other HMI controls configured to invoke functions on the computing platform104(e.g., steering wheel audio buttons, a push-to-talk button, instrument panel controls, etc.). The computing platform104may also drive or otherwise communicate with one or more displays138configured to provide visual output to vehicle occupants by way of a video controller140. In some cases, the display138may be a touch screen further configured to receive user touch input via the video controller140, while in other cases the display138may be a display only, without touch input capabilities.

The computing platform104may be further configured to communicate with other components of the vehicle102via one or more in-vehicle networks142. The in-vehicle networks142may include one or more of a vehicle controller area network (CAN), an Ethernet network, and a media oriented system transfer (MOST), as some examples. The in-vehicle networks142may allow the computing platform104to communicate with other vehicle102systems, such as a vehicle modem144(which may not be present in some configurations), a global positioning system (GPS) module146configured to provide current vehicle102location and heading information, and various vehicle ECUs148configured to corporate with the computing platform104. As some non-limiting possibilities, the vehicle ECUs148may include a powertrain control module configured to provide control of engine operating components (e.g., idle control components, fuel delivery components, emissions control components, etc.) and monitoring of engine operating components (e.g., status of engine diagnostic codes); a body control module configured to manage various power control functions such as exterior lighting, interior lighting, keyless entry, remote start, and point of access status verification (e.g., closure status of the hood, doors and/or trunk of the vehicle102); a radio transceiver module configured to communicate with key fobs or other local vehicle102devices; and a climate control management module configured to provide control and monitoring of heating and cooling system components (e.g., compressor clutch and blower fan control, temperature sensor information, etc.).

As shown, the audio module122and the HMI controls136may communicate with the computing platform104over a first in-vehicle network142-A, and the vehicle modem144, GPS module146, and vehicle ECUs148may communicate with the computing platform104over a second in-vehicle network142-B. In other examples, the computing platform104may be connected to more or fewer in-vehicle networks142. Additionally or alternately, one or more HMI controls136or other components may be connected to the computing platform104via different in-vehicle networks142than shown, or directly without connection to an in-vehicle network142.

The computing platform104may also be configured to communicate with mobile devices152of the vehicle occupants. The mobile devices152may be any of various types of portable computing device, such as cellular phones, tablet computers, smart watches, laptop computers, portable music players, or other devices capable of communication with the computing platform104. In many examples, the computing platform104may include a wireless transceiver150(e.g., a BLUETOOTH module, a ZIGBEE transceiver, a Wi-Fi transceiver, an IrDA transceiver, an RFID transceiver, etc.) configured to communicate with a compatible wireless transceiver154of the mobile device152. Additionally or alternately, the computing platform104may communicate with the mobile device152over a wired connection, such as via a USB connection between the mobile device152and the USB subsystem132. In some examples the mobile device152may be battery powered, while in other cases the mobile device152may receive at least a portion of its power from the vehicle102via the wired connection.

The communications network156may provide communications services, such as packet-switched network services (e.g., Internet access, VoIP communication services), to devices connected to the communications network156. An example of a communications network156may include a cellular telephone network. Mobile devices152may provide network connectivity to the communications network156via a device modem158of the mobile device152. To facilitate the communications over the communications network156, mobile devices152may be associated with unique device identifiers (e.g., mobile device numbers (MDNs), Internet protocol (IP) addresses, etc.) to identify the communications of the mobile devices152over the communications network156. In some cases, occupants of the vehicle102or devices having permission to connect to the computing platform104may be identified by the computing platform104according to paired device data160maintained in the storage medium112. The paired device data160may indicate, for example, the unique device identifiers of mobile devices152previously paired with the computing platform104of the vehicle102, such that the computing platform104may automatically reconnected to the mobile devices152referenced in the paired device data160without user intervention.

When a mobile device152that supports network connectivity is paired with the computing platform104, the mobile device152may allow the computing platform104to use the network connectivity of the device modem158to communicate over the communications network156with the remote telematics server162or other remote computing device. In one example, the computing platform104may utilize a data-over-voice plan or data plan of the mobile device152to communicate information between the computing platform104and the communications network156. Additionally or alternately, the computing platform104may utilize the vehicle modem144to communicate information between the computing platform104and the communications network156, without use of the communications facilities of the mobile device152.

Similar to the computing platform104, the mobile device152may include one or more processors164configured to execute instructions of mobile applications170loaded to a memory166of the mobile device152from storage medium168of the mobile device152. In some examples, the mobile applications170may be configured to communicate with the computing platform104via the wireless transceiver154and with the remote telematics server162or other network services via the device modem158.

For instance, the computing platform104may include a device link interface172to facilitate the integration of functionality of the mobile applications170configured to communicate with a device link application core174executed by the mobile device152. In some examples, the mobile applications170that support communication with the device link interface172may statically link to or otherwise incorporate the functionality of the device link application core174into the binary of the mobile application170. In other examples, the mobile applications170that support communication with the device link interface172may access an application programming interface (API) of a shared or separate device link application core174to facilitate communication with the device link interface172.

The integration of functionality provided by the device link interface may include, as an example, the ability of mobile applications170executed by the mobile device152to incorporate additional voice commands into the grammar of commands available via the voice interface134. The device link interface172may also provide the mobile applications170with access to vehicle information available to the computing platform104via the in-vehicle networks142. An example of a device link interface172may be the SYNC APPLINK component of the SYNC system provided by the Ford Motor Company of Dearborn, Mich. Other examples of device link interfaces172may include MIRRORLINK, APPLE CARPLAY, and ANDROID AUTO.

FIG. 2illustrates an example data flow diagram200of a vehicle application110utilizing the network connectivity of the mobile device152. This connectivity may be utilized by way of a virtual network interface application202of the computing platform104and a virtual network mobile application208of the mobile device152.

The virtual network interface application202may be an example of a vehicle application110stored to the storage112and executed by the one or more processors106of the computing platform104. The virtual network interface application202may include a virtual interface manager204and a virtual interface plugin206. The virtual interface manager204may be configured to receive Internet Protocol (IP) packets or other data from the vehicle application110, such as get or upload requests, and place those requests into a tunnel for processing by the virtual interface plugin206. In an example, the virtual interface manager204of the virtual network interface application202uses a packet sniffer (e.g., a layer three packet sniffer) to captures IP packets generated from the vehicle application110.

The virtual interface plugin206may be configured to access the tunnel traffic to send the traffic to the device link interface172. In some examples, the virtual network interface application202may be configurable to utilize different device link interfaces172. In such examples, the virtual network interface application202may include or otherwise have access to multiple virtual interface plugins206, and may utilize the virtual interface plugin206that corresponds to the specific device link interface172being used.

The device link interface172and the device link application core174may be configured to maintain a communication link between the computing platform104and the mobile device152. In an example, the communication link may be supported by services of the wireless transceiver150of the computing platform104(e.g., for a Wi-Fi or BLUETOOTH link), or by the services of the USB subsystem132of the computing platform104(e.g., for a USB link).

The virtual interface plugin206may utilize the device link interface172to transfer the IP packets monitored by the virtual interface manager204to the mobile device152. In an example, the virtual interface plugin206may utilize a remote procedure mechanism (e.g., the RPC mechanism available via SDL) to send the packets to the mobile device152. The device link application core174may receive data from the device link interface172, and provide the received data to the virtual network mobile application208.

The virtual network mobile application208may be an example of a mobile application170stored to the storage168and executed by the one or more processors164of the mobile device152. The virtual network mobile application208may include IP data manager210and a proxy212. The IP data manager210may be configured to receive and decode the binary packet data from the device link application core174. The IP data manager210may be further configured to send the received IP packet data to the proxy212.

The proxy212may be configured to create a new IP packet for the data received from the IP data manager210. The proxy212may also update the source IP address of the packet to be that of the IP address of the mobile device152, not that of the computing platform104. The proxy212may further create a TCP socket and write the IP data packet to the physical network interface214of the mobile device152. This updated IP packet may then be sent to the destination IP from the mobile device152via the physical network interface214.

A response to the packet may be received back to the physical network interface214of the mobile device152. The response packet may then be handed off to the virtual network mobile application208. The proxy212may receive the response packet, updates the response packet back with the address information of the computing platform104, and return it to the IP data manager210. The IP data manager210may construct a binary representation and pass the representation to the device link application core174. The device link application core174may send the response back via the RPC mechanism to the device link interface172to transfer the response to the virtual network interface application202. The virtual interface plugin206of the virtual network interface application202may decode the packet according to the protocol of the virtual interface plugin206, and may provide the decoded packet to the virtual interface manager204to be added to the tunnel. The vehicle application110may accordingly read the decoded packet from the tunnel. Accordingly, the vehicle application110may make use of the connection of the mobile device152to the communication network156, without regard for whether the mobile device152supports the particular protocol being utilized by the vehicle application110.

In addition to the flow of packets, the virtual network interface may further allow for vehicle applications110to receive active network state information related to the connected mobile device152(e.g., cellular connection, Wi-Fi connection, etc.). In an example, the vehicle application110may request network status information from the virtual network interface application202, which may in turn cause the virtual interface plugin206to query the device link interface172for the status of the connection between the device link interface172and the device link application core174. If there is no connection to a mobile device152, the device link interface172may report to the virtual interface plugin206that no connection exists, which in turn may cause the virtual network interface application202to inform the vehicle application110that no network interface is available. If, however, a mobile device152is connected, the device link application core174may provide back to the device link interface172information regarding the network state of to the connected mobile device152. In an example, the device link interface172may indicate whether the mobile device152is connected to the communications network156by the physical network interface214via a cellular connection and/or via a Wi-Fi connection. Additionally or alternately, the device link interface172may indicate other details of the network connection provided by the physical network interface214, such as data connection speed, latency, and amount of packet loss or retransmissions.

FIG. 3illustrates an example process300for the computing platform104facilitating use by the vehicle application110of network connectivity of the mobile device152. In an example, the process300may be performed utilizing the virtual network interface application202of the computing platform104.

At operation302, the computing platform104receives a request from a vehicle application110. In an example, the vehicle application110may send may send a get or upload request for MQTT to the virtual network interface application202.

At304, the computing platform104writes message data to a tunnel. In an example, the virtual interface manager204of the virtual network interface application202receives the request from the vehicle application110, and places the requests into the tunnel. At306, the computing platform104reads message data from the tunnel. In an example, the virtual interface plugin206accesses the tunnel traffic to receive the request. The virtual interface plugin206may further provide the request to the device link interface172.

At308, the computing platform104constructs a message for RPC. In an example, the device link interface172constructs the RPC message. At310, the computing platform104sends the RPC message to the connected mobile device152. In an example, the device link interface172sends the constructed RPC message to the connected mobile device152. The mobile device152may process the RPC message as discussed in further detail with respect to the process400.

At312, the computing platform104receives a response to the message from the connected mobile device152. In an example, the device link interface172receives the response as discussed in further detail with respect to the process400. The device link interface172may further send the received response RPC message to the virtual interface plugin206. At314, the computing platform104decodes the response message. In an example, the virtual interface plugin206decodes the virtual interface plugin206decodes the received message in accordance with the type of connection provided by the device link interface172.

At316, the computing platform104writes the response message to the tunnel. In an example, the virtual interface plugin206writes the decoded message data to the tunnel. At318, the computing platform104reads the response message to the tunnel. In an example, the virtual interface manage204reads the decoded message data to the tunnel responsive to a request by the vehicle application110for data from the connection. At320, the vehicle application110of the computing platform104receives the response message. Accordingly, the vehicle application110may utilize the network services of the connected mobile device via RPC, even if the requested network services are not natively supported by the mobile device152. After operation320the process300ends.

FIG. 4illustrates an example process400for the mobile device152facilitating use by the vehicle application110of network connectivity of the mobile device152. In an example, the process300may be performed utilizing the virtual network mobile application208of the mobile device152.

At402, the mobile device152receives a message from a connected vehicle102via RPC. In an example, the message may be received to the device link application core174responsive to the sending discussed above with respect to operation310of the process300. At404, the mobile device152decodes the message. In an example, the IP data manager210of the virtual network mobile application208receives the RPC message from the and decode the binary packet data from the device link application core174. The IP data manager210may be further configured to send the received IP packet data to the proxy212.

At406, the mobile device152creates a message with the mobile device152as the origin address. In an example, the proxy212may update the source address of the message to be that of the address of the mobile device152, not that of the computing platform104. At408, the mobile device152sends the message to a destination. In an example, the proxy212creates a socket and write the message to the physical network interface214of the mobile device152. This updated message may then be sent to the destination address from the mobile device152via the physical network interface214.

At410, the mobile device152receives a response message. In an example, the response to the packet may be received back to the physical network interface214of the mobile device152. The response packet may then be handed off to the virtual network mobile application208. At412, the mobile device152creates a message with the vehicle as the destination address. In an example, the proxy212updates the response packet back with the address information of the computing platform104, and return it to the IP data manager210. At414, the mobile device152constructs a response message for RPC. In an example, the IP data manager210construct a binary representation and pass the representation to the device link application core174.

At416, the mobile device152sends the response message to the computing platform104of the connected vehicle102via RPC. The response message may be received by the computing platform104as discussed above regarding operation312. After operation416the process400ends.

Variations on the aforementioned systems and processes are possible. In an example, the computing platform104may query the mobile device152for protocols that are natively supported by the mobile device152. Based on the result of the query, if the mobile device152fails to support the protocol being requested by the vehicle application110, the aforementioned processes300and400may be utilized. If, however, the mobile device152does have native capability to support the protocol, then a request for the mobile device152to utilize its native functionality may instead be sent, avoiding the tunneling and proxy operations. As a specific example, the mobile device152may respond that it supports HTTP but not MQTT or file transfer protocol (FTP). Accordingly, HTTP request for data may be sent to the mobile device via RPC to cause the mobile device152to utilize its native web browser to retrieve the requested data, and then to send back the requested data once retrieved. However, an FTP or MQTT request may be tunneled and processed using the mobile device152as a proxy.

Computing devices described herein, such as the computing platform104, mobile device152, and telematics server162, generally include computer-executable instructions where the instructions may be executable by one or more computing devices such as those listed above. Computer-executable instructions, such as those of the virtual network interface application202or virtual network mobile application208, may be compiled or interpreted from computer programs created using a variety of programming languages and/or technologies, including, without limitation, and either alone or in combination, Java™, C, C++, C#, Visual Basic, JavaScript, Python, JavaScript, Perl, PL/SQL, Prolog, LISP, Corelet, etc. In general, a processor (e.g., a microprocessor) receives instructions, e.g., from a memory, a computer-readable medium, etc., and executes these instructions, thereby performing one or more processes, including one or more of the processes described herein. Such instructions and other data may be stored and transmitted using a variety of computer-readable media.