Procedure and facility for cellular network backup connectivity

Abstract

System that includes: a processor designed to: Detecting the presence of a wireless network access point that can be used for vehicle communication; Connect to the wireless access point; and Communicating connection information regarding the connected access point to a device capable of establishing a direct cellular connection with a vehicle, identifying the connected access point as an alternative communication method when cellular communication is unavailable, and in response to a determination that a cellular signal provided to a telematics control unit has fallen below a predetermined usable threshold, searching using a vehicle computer for a usable dedicated short range communication (DSRC) access point in a communicable proximity to a vehicle and communicating connection information for the DSRC access point to a remote device along with instructions to use the DSRC access point for vehicle communication.

Description

TECHNICAL FIELD

[0001] The illustrative embodiments relate generally to a method and apparatus for cellular network backup connectivity. STATE OF THE ART

[0002] Remote communication with a vehicle (e.g., communicating with a vehicle from a remote computer) is becoming increasingly popular as remote control of vehicle functionality grows. Not only can users use a phone, personal computer (PC), tablet, etc., to connect to and control vehicle functions, but third-party service providers can also remotely connect to vehicles to diagnose vehicle problems. Original equipment manufacturers (OEMs) can connect to vehicles to retrieve usage information and provide software and firmware updates.

[0003] Connections to the vehicle are often enabled by a vehicle telematics control unit (TCU). By using an embedded modem or wireless device that provides cellular connectivity to the TCU, the TCU can enable and simplify communication with a remote source through a cellular network. This enables functions such as temperature control and remote starting from a great distance. As long as both the vehicle and the user can connect to a cellular network, the user can access remote vehicle functionality from anywhere on Earth.

[0004] US 2015 / 0087241 A1 describes a vehicle system for detecting an interference signal, which includes a receiver for receiving a signal whose properties are evaluated by a controller to determine a probability of an interference event. US 2015 / 0341862 A1 provides a method for managing the power of a telematics unit in a vehicle, which determines whether the vehicle is switched off and located in a peripheral region of a cellular network, and based on this information, the telematics unit is placed in a power-saving mode. SUMMARY

[0005] In a first illustrative embodiment, a system includes a processor configured to detect the presence of a wireless network access point usable for vehicle communication. The processor is also configured to connect to the wireless access point and communicate connection information regarding the connected access point to a device capable of establishing a direct cellular connection with a vehicle, identifying the connected access point as an alternative communication method or means for alternative communication when cellular communication is unavailable.

[0006] In a second illustrative embodiment, a system includes a processor configured to receive indicia from a vehicle that a cellular network is not usable for processor-to-vehicle communication. The processor is also configured to receive from the vehicle an identifier of a wireless access point usable for processor-to-vehicle communication. The processor is further configured to receive requests to remotely access vehicle functionality and use the wireless access point to forward the received requests to the vehicle until indicia is received from the vehicle that the cellular communication network is usable for processor-to-vehicle communication.

[0007] In a third illustrative embodiment, a computer-implemented method includes searching, using a vehicle computer, for a usable dedicated short range communication (DSRC) access point located within a communicable proximity to a vehicle in response to a determination that a cellular signal provided to a telematics control unit has fallen below a predetermined usable threshold, and communicating connection information for the DSRC access point to a remote unit along with instructions to use the DSRC access point for vehicle communication. BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 shows an illustrative vehicle data processing system; Fig. Figure 2 shows an illustrative process for setting up backup connectivity; Fig. Figure 3 shows an illustrative connectivity testing process; Fig. 4 shows an illustrative process for TCU connection configuration; and Fig. Figure 5 shows an illustrative process for remote communication routing. DETAILED DESCRIPTION

[0008] As required, detailed embodiments of the present invention are disclosed herein; however, it should be understood that the disclosed embodiments are merely exemplary of the invention that may be embodied in various and alternative forms. The figures are not necessarily to scale; some features may be exaggerated or minimized to show details of particular components. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art how to variously employ the present invention.

[0009] Fig. 1 illustrates an exemplary block topology for a vehicle-based computing system 1 (VCS) for a vehicle 31. An example of such a vehicle-based computing system 1 is the SYNC system manufactured by THE FORD MOTOR COMPANY. A vehicle enabled with a vehicle-based computing system may include an in-vehicle visual front-end interface 4. The user may also be able to interact with the interface if it is equipped with a touch-sensitive screen, for example. In another illustrative embodiment, the interaction occurs through button presses, a voice dialog system with automatic speech recognition, and speech synthesis.

[0010] At the Fig. In the illustrative embodiment shown in Figure 1, a processor 3 controls at least part of the operation of the vehicle-based computer system. The processor is provided within the vehicle and allows for in-vehicle processing of instructions and routines. The processor is further connected to both non-persistent memory 5 and persistent memory 7. In this exemplary embodiment, the non-persistent memory is random access memory (RAM), and the persistent memory is a hard disk drive (HDD) or flash memory. In general, persistent (non-volatile) memory can include any form of storage that retains data when a computer or other device is turned off. This includes, but is not limited to, HDDs, CDs, DVDs, magnetic tapes, solid-state drives, portable USB (Universal Serial Bus) drives, and any other suitable form of persistent memory.

[0011] The processor is also provided with a number of different inputs that allow the user to connect to the processor. In this illustrative embodiment, a microphone 29, an auxiliary input (Aux) 25 (for input 33), a USB input 23, a GPS input 24, a display 4, which may be a touchscreen, and a BLUETOOTH input 15 are provided. An input selector 51 is also provided to allow a user to choose between different inputs. Inputs to both the microphone and the auxiliary jack are converted from analog to digital by a converter 27 before being passed to the processor.Although not shown, many of the vehicle components and ancillary components associated with the VCS may utilize a vehicle network (such as, but not limited to, a CAN bus) to communicate data to and from the VCS (or components thereof).

[0012] Outputs to the system may include, among others, a visual display 4 and a speaker 13 or a stereo output. The speaker is connected to an amplifier 11 and receives its signal from the processor 3 through a digital-to-analog converter 9. Outputs may also be made to a remote BLUETOOTH device, such as the PND 54, or to a USB device, such as the vehicle navigation device 60, along the bidirectional data streams shown at 19 and 21, respectively.

[0013] In an illustrative embodiment, the system 1 uses the BLUETOOTH transceiver 15 to communicate 17 with a nomadic device (ND) 53 (e.g., a mobile phone, smartphone, PDA, or any other device having wireless connectivity to remote networks) of the user. The nomadic device can then be used to communicate 59 with a network 61 external to the vehicle 31, for example, by communicating 55 with a cellular tower 57. In some embodiments, the tower 57 can be a WiFi access point.

[0014] Example communication between the nomadic device and the BLUETOOTH transceiver is represented by signal 14.

[0015] Pairing of a nomadic device 53 and the BLUETOOTH (BT) transceiver 15 can be instructed by a button 52 or similar input (BT pair). Accordingly, the CPU is instructed to pair the in-vehicle BLUETOOTH transceiver with a BLUETOOTH transceiver in a nomadic device.

[0016] Data may be communicated between the CPU 3 and the network 61, for example, using a data plan, data over voice, or DTMF tones associated with the nomadic device 53. Alternatively, it may be desirable to include an in-vehicle modem 63 with an antenna 18 to communicate data between the CPU 3 and the network 61 over the voice band 16. The nomadic device 53 may then be used to communicate 59 with a network 61 external to the vehicle 31, for example, by communicating 55 with a cellular tower 57. In some embodiments, the modem 63 may establish communication 20 with the tower 57 for communication with the network 61. As a non-limiting example, the modem 63 may be a USB cellular modem, and the communication 20 may be a cellular communication.

[0017] In one illustrative embodiment, the processor is provided with an operating system including an API (Application Program Interface) for communicating with modem application software. The modem application software can access an embedded module or firmware on the BLUETOOTH transceiver to establish wireless communication with a remote BLUETOOTH transceiver (such as one found in a nomadic device). Bluetooth is a subset of the IEEE 802 PAN (Personal Area Network) protocols. The IEEE 802 LAN (Local Area Network) protocols include Wi-Fi and have considerable cross-functionality with IEEE 802 PAN. Both are suitable for wireless communication in a vehicle. Other communication means that may be used in this area include free-space optical communication (such as IrDA) and non-standardized consumer IR protocols.

[0018] In another embodiment, the nomadic device 53 includes a modem for voiceband or broadband data communication. In the Data-Over-Voice embodiment, a technique known as frequency division multiplexing may be implemented when the owner of the nomadic device can speak over the device while data is being transferred. At other times, when the owner is not using the device, the data transfer may utilize the entire bandwidth (in one example, 300 Hz to 3.4 kHz). Although frequency division multiplexing may have been and is still used for analog cellular communication between the vehicle and the Internet, it has been largely replaced for digital cellular communication by hybrids of CDMA (Code Domain Multiple Access), TDMA (Time Domain Multiple Access), and SDMA (Space-Domain Multiple Access).All of these are standards compliant with ITU IMT-2000 (3G) and offer data rates of up to 2 Mbps for stationary or walking users and 385 kbps for users in a moving vehicle. 3G standards are now being replaced by IMT-Advanced (4G), which offers 100 Mbps for users in a vehicle and 1 Gbps for stationary users. If the user has a data plan associated with the nomadic device, it is possible that the data plan allows for broadband transmission and that the system could utilize a much larger bandwidth (which speeds up data transmission). In yet another embodiment, the nomadic device 53 is replaced by a cellular communication device (not shown) installed in the vehicle 31.In yet another embodiment, the nomadic device (ND) 53 may be a wireless local area network (LAN) device capable of communicating, for example (and without limitation), over an 802.11g network (i.e., WiFi) or a WiMax network.

[0019] In one embodiment, incoming data may be routed through the nomadic device via Data-over-Voice or a data plan through the in-vehicle BLUETOOTH transceiver and into the vehicle's internal processor 3. In the case of certain temporary data, the data may be stored, for example, on the HDD or other storage medium 7 until the data is no longer needed.

[0020] Additional sources that may be interfaced with the vehicle include a mobile navigation device 54, for example, with a USB port 56 and / or antenna 58, a vehicle navigation device 60 with a USB 62 or other port, an on-board GPS device 24, and a remote navigation system (not shown) with connectivity to network 61. USB is one of a class of serial networking protocols. IEEE 1394 (FireWire™ (Apple), i.LINK™ (Sony), and Lynx™ (Texas Instruments)), EIA (Electronics Industry Association) serial protocols, IEEE 1284 (Centronics Port), S / PDIF (Sony / Philips Digital Interconnect Format), and USB-IF (USB Implementers Forum) form the backbone of standards for device-to-device serial communication. Most protocols can be implemented for either electrical or optical communication.

[0021] Furthermore, the CPU could be in communication with a variety of other auxiliary devices 65. These devices may be connected via a wireless 67 or a wired 69 connection. The auxiliary device 65 may include, among others, personal media players, wireless health devices, wearable computers, and the like.

[0022] Likewise, or alternatively, the CPU could be connected to a vehicle-based wireless router 73, for example, using a WiFi transceiver (IEEE 803.11) 71. This could allow the CPU to connect to remote networks within range of the local router 73.

[0023] In addition to example processes in certain embodiments being performed by a vehicle computing system located in a vehicle, the example processes may be performed by a computing system in communication with a vehicle computing system. Such a system may include, but is not limited to, a wireless device (e.g., and without limitation, a cellular phone) or a remote computing system (e.g., and without limitation, a server) connected via the wireless device. Collectively, such systems may be referred to as a vehicle-associated computing system (VACS). In certain embodiments, certain components of the VACS may perform certain portions of a process, depending on the particular implementation of the system. By way of example, and without limitation, if a process includes a step of sending information to one or more devices, then the process may include a step of sending information to one or more devices, such as a cellular phone or a remote computing system, such as a server.from a paired wireless device, then the wireless device likely does not perform that part of the process because the wireless device would not be sending or receiving information to or from itself. One of ordinary skill in the art will know when it is inappropriate to apply a particular computer system to a given solution.

[0024] Users are becoming increasingly accustomed to accessing advanced vehicle function control through remote communication with a vehicle. Developments in function control include, but are not limited to, remote start, remote temperature control, remote window control, remote stereo control, remote camera monitoring, remote security system control, vehicle preconditioning control, and the like. Service technicians may also be able to remotely access a vehicle to diagnose a problem. This may even include listening to a vehicle's interior while the vehicle is running to identify sounds that may indicate a problem.Even OEMs will use remote communication with a vehicle, which can be leveraged to track system usage, crowdsourced user data, deliver software and firmware updates, and a variety of other services.

[0025] With all these possible remote communication solutions utilizing a remote connection to a vehicle, it can be problematic if communication with a vehicle is lost or cannot be established. Most commonly, vehicle communication to provide the aforementioned functionality is enabled through the use of a cellular connection. In-vehicle modems or user equipment with cellular capability can be used by a telematics control unit to provide remote communication capability to a vehicle. If a cellular connection is lost or if signal strength is too low for reliable (or any) communication, functionality that relies on cellular communication for data transmission may be rendered unfeasible.

[0026] Common examples of a user losing remote connectivity include parking in an underground parking deck, driving (or parking) inside tall buildings (known as urban canyons), or driving and / or parking a vehicle in a remote location where cellular connectivity may not be available. In these and similar cases, when a user wishes to use remote connectivity for feature control, the user may discover that capabilities to which they have become accustomed are suddenly no longer available. Losing a functionality they have habitually enjoyed can diminish the user experience and may cause some degree of user dissatisfaction with a particular vehicle functionality.For example, if a user has parked a vehicle in a remote wilderness parking area and traveled to the woods for a camping trip, it is possible that the user would want to heat or cool the vehicle before returning to the vehicle after camping. Since such functionality may be commonly available at a home location, it is possible that the user has no reason to expect a loss of this functionality when traveling. Assuming the user can set up a cellular signal (for command transmission), the user may be disappointed if an attempt to remotely control a vehicle's climate fails, especially if the weather conditions are somewhat extreme. A similar problem may arise in a much more common scenario where the user has simply parked a vehicle in a garage location that is too isolated for cellular communication to occur.

[0027] The illustrative embodiments propose a system wherein, when a cellular signal is lost or weak (e.g., below a predetermined threshold for reliable communication), a backup communication methodology can be employed, so that remote function control is much less likely to be lost. The proposed solution leverages a dedicated short-range communication (DSRC) network. DSRC uses a communication bandwidth dedicated to motor vehicles, and a mesh network of DSRC transceivers is expected to be deployed along state highways and thoroughfares in the late 2010s or early 2020s. Using such a network, backup communication with a vehicle can be established if cellular service fails or signal strength drops to an unreliable level.A similar solution can be enabled by a Wi-Fi access point if the vehicle is within communicable proximity to such a transceiver.

[0028] When a vehicle encounters a DSRC access point (or usable Wi-Fi access point), it can send an identifier of the access point to a backend server, which can be used to enable remote vehicle communication. In another example, the vehicle can search for a nearby access point when a cellular signal drops below a usable / reliable level and identify the nearby access point to the remote server. In common practice, the remote server can typically receive remote access requests through the internet or a cellular network. One of the server's functions can be to act as a gatekeeper for such requests, routing them over a cellular connection to the appropriate vehicle.If the server is also notified of a network location (on a DSRC or Wi-Fi network) where the vehicle can currently be contacted, any failure in a cellular communication attempt can potentially be resolved by communicating with the vehicle over the DSRC or Wi-Fi network. Since the DSRC network can potentially extend across virtually all passable roads, it can provide a fairly reliable backup for communication in such a case. With a sufficiently wide DSRC network, there will be very few cases where a vehicle cannot be remotely reached through either a cellular or DSRC network connection.

[0029] Currently, if a user attempts to connect to a vehicle using communication routed to the vehicle through a cellular connection, and the vehicle is outside of cellular communication range, the user may encounter an error message or simply fail to connect to the vehicle. By using the illustrative embodiments and the like, the user will have access to the vehicle under a wide range of conditions and locations and will be less likely to encounter a communication error or failure.

[0030] In each of the illustrative embodiments discussed herein, an exemplary, non-limiting example of a process performable by a computer system is presented. With respect to each process, it is possible for the computer system executing the process to be configured as a special-purpose processor for the limited purpose of executing the process. Not all processes need to be performed in their entirety and are intended as examples of types of processes that may be performed to achieve elements of the invention. Additional steps may be added or removed from the exemplary processes as desired.

[0031] Fig. Figure 2 shows an illustrative process for establishing backup connectivity. With respect to the illustrative embodiments described in this figure, it should be understood that a general-purpose processor may be temporarily activated as a special-purpose processor for the purpose of performing some or all of the exemplary methods presented herein. Upon executing code that provides instructions for performing some or all of the steps of the method, the processor may be temporarily converted to a special-purpose processor until the method is completed. In another example, where appropriate, firmware operating in accordance with a preconfigured processor may cause the processor to function as a special-purpose processor provided for the purpose of performing the method or any reasonable variation thereof.

[0032] In the Fig. In the illustrative example shown in Figure 2, the vehicle will advertise a usable local wireless network connection (in this case, a DSRC connection) when a cellular signal falls below a reliable and / or usable threshold. It is also possible for the vehicle to advertise the presence of any usable local wireless transceivers (such as DSRC or Wi-Fi) for use in backup cases when a cellular connection fails. Since the vehicle can communicate with the remote server through the DSRC connection itself, a lack of a usable cellular connection should not prevent the vehicle from advertising a usable DSRC connection.

[0033] In this example, the process running on the vehicle monitors monitors a cellular signal that can be used by the TCU to establish communication over a cellular network 201. This can be a signal provided by an in-vehicle modem or by a wireless device connected to the TCU (such as a user's cell phone). If multiple cellular communication sources are available, the process can check the signal strength of all usable cellular signals before announcing a DSRC alternative. Again, as previously mentioned, it is also possible for the system to always announce the presence of a DSRC alternative, even if sufficient cellular signal strength is detected.

[0034] Here, if the cellular signal(s) has / have fallen below a reliable or predetermined threshold level 203, the process will search for a usable DSRC transceiver 205. In another related example, DSRC communication may also be continuously maintained when a suitable DSRC transceiver is located near a vehicle, so instead of searching for the transceiver, the process may simply determine or access the address of an already identified or connected DSRC transceiver.

[0035] If no DSRC transceiver is available 207, the process may check whether the vehicle is stationary 209. If the vehicle is not stationary, the process may determine whether the vehicle is within a communicable range of a public or otherwise usable Wi-Fi communication point 211.

[0036] If the vehicle is stationary or within range of a known or identified Wi-Fi access point, the process may determine whether the Wi-Fi communication point is usable. 213 This determination may also include a determination as to whether the Wi-Fi communication point should be identified at all (for example, a vehicle passing a known Wi-Fi communication point at 60 miles per hour will likely obtain very little usability from the Wi-Fi communication point before the vehicle moves out of communicable range).

[0037] If the vehicle can (and should) connect to and use the Wi-Fi communication point, the process may establish a connection with the identified Wi-Fi access point 215. The appropriateness of such a connection may be determined, for example, without limitation, by determining that a vehicle is stationary, that a vehicle route should keep the vehicle within a communicable range for a threshold period, that a vehicle is likely to stop within a communicable range of the Wi-Fi access point, that a Wi-Fi mesh or point-to-point network of which the Wi-Fi access point is part will be within a communicable range of the vehicle during a threshold period, etc.In some cases, the vehicle will only communicate the wireless access point if a determination process determines that the wireless access point will remain within communicable proximity to the vehicle for a threshold period of time.

[0038] Similarly, the vehicle may connect to a DSRC access point 217 if such an access point is available. Similar determinations regarding the adequacy of the DSRC connection could be made; however, it is possible that if, for example, the DSRC network extends along a road and / or across a parking lot, then the need for communicable area determinations may be reduced. Instead, the vehicle may connect to each DSRC transceiver in the network as it becomes available, with each point being identified as a new connection.

[0039] Once a connection to the DSRC or other wireless network has been established, the process will notify the remote routing server of the established connection 219, which may include an identifier of the access point's network MAC address. This may allow the server to route incoming remote access requests to the connected access point, where they may be sequentially routed to the vehicle. Similarly, the vehicle will register the connection locally, and any in-vehicle requests for communication with a remote device may be routed through the DSRC network (compared to an unsuccessful attempt using an unavailable or unreliable cellular connection) 221.As long as a cellular signal (which can be constantly monitored by the process) remains below a reliable or usable threshold 223, the process can continue to use the DSRC (or other) wireless network for remote communication. As the vehicle moves, it can periodically update the identified and connected DSRC transceiver as new transceivers become available and previously connected transceivers move out of communicable range. As long as one or more DSRC or other wireless access points are within communicable range (and usable by the vehicle), a reliable backup for failed cellular communication can be established.

[0040] After one or more of the cellular signals available for use by the TCU rise above the usable or reliable threshold 225, the process may switch back to using cellular communication. This may include informing the remote gateway server that the cellular connection is once again usable 227. At this point, the cellular signal monitoring process may begin again.

[0041] In an environment without the illustrative embodiments, a user may issue a remote access request, which is transmitted to the gateway server. The gateway server may then attempt to connect the vehicle to a cellular network using a known cellular number. If the vehicle is outside of cellular coverage, if the cellular network is unavailable, or if the cellular connection is intermittent and unreliable, the user may experience some frustration if the attempted remote access request fails or takes a long time to process.

[0042] Using the illustrative embodiments, the vehicle notifies the server when a cellular connection is unusable or unreliable. Since the vehicle has also identified a currently usable alternative method of communication, the remote server can simply use the alternative method of communication to efficiently and reliably forward the remote access request to the vehicle. In another example, even if the vehicle has not yet identified that cellular communication may or will fail, if the vehicle continually identifies usable alternative DSRC communication points, then a failed cellular connection attempt by the server can simply be retried through the DSRC network before an error is reported to the requesting entity.

[0043] Fig. Figure 3 shows an illustrative process for connectivity testing. With respect to the illustrative embodiments described in this figure, it should be understood that a general-purpose processor may be temporarily activated as a special-purpose processor for the purpose of performing some or all of the exemplary methods presented herein. Upon executing code that provides instructions for performing some or all of the steps of the method, the processor may be temporarily converted to a special-purpose processor until the method is completed. In another example, where appropriate, firmware operating in accordance with a preconfigured processor may cause the processor to function as a special-purpose processor provided for the purpose of performing the method or any reasonable variation thereof.

[0044] In this non-limiting example, a vehicle may experience some loss of connectivity at some point after the vehicle has been turned off. This may be problematic or annoying for a user if the cellular connection (and associated remote functionality control) is expected based on the usable presence of a cellular signal when the vehicle was initially parked. For example, it is not uncommon for a cellular signal to be rendered unusable by an extreme volume of potential users, such as at a sporting event. When a user arrives at the event, say, at 7:00 a.m., the user may be able to freely access the vehicle's functionality remotely because many attendees have not yet arrived.

[0045] Later, when a large number of mobile users have arrived at the event, the cellular network may become so overloaded that remote functionality is significantly delayed or even rendered unusable. The illustrative example in Fig. 3 provides for a communication backup in such a case.

[0046] In this example, the process detects a shutdown 301 (or, for example, a vehicle placed in a parked state) as an indication of an attempt to cease vehicle movement. In one example, the process may take the opportunity to identify one or more currently available DSRC or other usable wireless (such as Wi-Fi) access points and communicate these access points to the gateway server. In this illustrative embodiment, the process sets an alarm 303 so that the vehicle can be periodically activated (e.g., driven at reduced power for a short period of time) to determine whether a transition to a DSRC or other wireless connection should be performed (or whether a transition from a DSRC back to a cellular network should be performed).For several reasons, it may be preferable or even mandatory that cellular connections be used when such connections are available. For example, the DSRC network may be available for use only when a cellular connection cannot be reliably utilized, to reduce the load on a DSRC network and prevent excessive bandwidth consumption. In another example, transport restrictions may be applied to the DSRC network, limiting the amount of communication that can be sent to a particular vehicle over a given period of time or in a connection case.

[0047] When such restrictions apply, it may be useful not only to know when to switch from an unusable cellular connection to a DSRC, but also to know when the cellular connection becomes available again. This allows, where appropriate, unrestricted cellular communication to be used, relying only on the DSRC when it is permitted, or when cellular communication cannot be used.

[0048] In the illustrative example, when the alarm expires 305, the process may activate the vehicle 307. In this example, activating the vehicle includes providing sufficient power to power the TCU and any other communication and identification components necessary to verify the cellular connection, verify a DSRC connection, and communicate to the gateway server which connection should be used. It should also be noted that communicating which connection should be used does not necessarily need to be done to a gateway server.For example, a mobile device may use a direct connection to the TCU via a cellular network to provide vehicle function control, and in such a case, the notification may be made to the mobile device itself (so that the mobile device can route requests to the appropriate access point).

[0049] The process may check the signal strength of any usable cellular connections 309, and if the signal strength of all available cellular connections has fallen below a usable / reliable threshold 311, the process may establish an alternative DSRC connection 313. Establishing this connection may involve communicating the connection and DSRC access point information to a remote unit, such as the gateway server. At this point, the vehicle may return to a sleep state after resetting the alarm because a reliable alternative to the unusable cellular connection has been established. At the next activation point, the process may discover that the cellular signal has regained usable strength, and a switch (along with appropriate communication) may be performed 315 back to the now usable cellular communications network.This allows the process to continue to provide reliably usable, reasonable alternatives to cellular communication while a vehicle is in a parked state, allowing a user to access remote vehicle functionality with increased reliability.

[0050] Fig. Figure 4 shows an illustrative process for TCU connection configuration. With respect to the illustrative embodiments described in this figure, it should be understood that a general-purpose processor may be temporarily activated as a special-purpose processor for the purpose of performing some or all of the exemplary methods presented herein. Upon executing code that provides instructions for performing some or all of the steps of the method, the processor may be temporarily converted to a special-purpose processor until the method is completed. In another example, where appropriate, firmware operating in accordance with a preconfigured processor may cause the processor to function as a special-purpose processor provided for the purpose of performing the method or any reasonable variation thereof.

[0051] In this illustrative example, it is contemplated that a DSRC access point or other alternative to cellular communication may have some usage limits applied. These may include, but are not limited to, maximum data transfer levels (on a per-use or aggregate basis), maximum usable bandwidth, and / or restrictions on the type of transmittable requests.

[0052] In this example, it is assumed that at least one DSRC or Wi-Fi alternative to cellular communication has some form of restriction for illustrative purposes. The gateway server or other device that will communicate directly with the vehicle receives an update from the vehicle TCU identifying the currently usable connection 401. For example, the TCU may identify a DSRC access point deployed as part of a continuation of a DSRC mesh network. The device retains the connection type 403 for use in sending future remote access requests to the TCU.

[0053] Also in this example, any known restrictions may be uploaded by the TCU or identifiable based on an access point type or address (for example, using a lookup table). If the connection is unrestricted 405 (i.e., has no restrictions), the process terminates. If the connection has an associated transmission or other restrictions, the process sets a set of parameters 407. This will allow the process to route appropriately configured requests, configure requests according to the parameters, and discard requests that cannot be configured or sent according to the specified parameters.

[0054] For example, a government-owned DSRC network can be used for vehicular communication from a remote source if: a) no usable cellular connection is available; b) the request is sent in packets below a certain size; and c) the total data transfer does not exceed a predefined limit. A first request N may be made at a time when a cellular connection is also available and can thus be routed over the cellular connection (which is the connection kept at that time). A second request O may be made at a time when a cellular connection is not available and can be packaged into sufficiently small packets and thus transmitted over the DSRC network. A third request P may be received following O and may (alone or together with O) exceed the permitted total data transfer.This request will either be discarded or queued until a less restrictive form of communication with the vehicle is available.

[0055] Fig. Figure 5 shows an illustrative process for remote communication routing. With respect to the illustrative embodiments described in this figure, it should be understood that a general-purpose processor may be temporarily activated as a special-purpose processor for the purpose of performing some or all of the exemplary methods presented herein. Upon executing code that provides instructions for performing some or all of the steps of the method, the processor may be temporarily converted to a special-purpose processor until the method is completed. In another example, where appropriate, firmware operating in accordance with a preconfigured processor may cause the processor to function as a special-purpose processor provided for the purpose of performing the method or any reasonable variation thereof.

[0056] In this illustrative example, the process receives a request from a remote source (or the process is executing on the requesting unit) to remotely access the vehicle functionality 501. The process checks a stored identified connection type and, if a cellular connection is available 503, the process will send the request over the cellular connection to the TCU 505. It may also happen that the TCU has not yet informed the remote gateway or unit that the cellular connection is no longer available, in which case the remote request sent over the cellular network may fail 523.

[0057] If the cellular connection is unavailable 503 (having been identified as such by the TCU detecting that the cellular signal at the vehicle has degraded below a usable level) or if an attempt to communicate over the cellular connection fails 523, the process accesses a retained alternative communication method or means for alternative communication 507. This could, for example, be a DSRC access point, which is naturally identified when a vehicle is moving or parked, or in response to a vehicle determining that a cellular network is not currently usable.

[0058] In this example, the process also checks whether any restrictions (such as those on Fig.4) in connection with the alternative communication method 509. If there are no restrictions, the process will send the request via the alternative communication method 511. If there are restrictions, the process will check stored parameters 513 to determine whether the request is permitted to be sent via the alternative communication method 515. This permission check may also include, for example, configuring the request into a form or format that is permitted according to the stated parameters.

[0059] If the request is allowed (or can be configured to be allowed), the process will send the request to the vehicle 517. If the request is not allowed and / or cannot be configured to be allowed, the process in this example will either discard the request or queue it, if appropriate 519. Some requests, such as a request to set a vehicle interior to a particular temperature, may be suitable for queuing, while other requests, such as a request to remotely start a vehicle, may only be queued for a very limited time or may not be queued at all (for example, to prevent remote starting of a vehicle at an unexpected time).The process may also warn the user before queuing or discarding 521, and at this point the user could send another request, choose to dequeue or enqueue a request that has or has not been queued, respectively, or take any other appropriate action.

[0060] By utilizing DSRC networks and other alternatives to cellular communication, including proactive identification by a vehicle of the nearby usable alternatives, the illustrative embodiments enable improved and more reliable remote user access to a vehicle.

[0061] Although exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms of the invention. Instead, the words used in the specification are words of description rather than limitation, and it is understood that various changes may be made without departing from the spirit and scope of the invention. In addition, the features of different implementations may be combined to form further embodiments of the invention.

Claims

[1] System comprising: a processor designed to: Detecting the presence of a wireless network access point that can be used for vehicle communication; Connect to the wireless access point; and Communicating connection information regarding the connected access point to a device capable of establishing a direct cellular connection with a vehicle, identifying the connected access point as an alternative communication method when cellular communication is unavailable, and in response to a determination that a cellular signal provided to a telematics control unit has fallen below a predetermined usable threshold, searching using a vehicle computer for a usable dedicated short range communication (DSRC) access point in a communicable proximity to a vehicle and communicating connection information for the DSRC access point to a remote device along with instructions to use the DSRC access point for vehicle communication. [2] The system of claim 1, wherein the access point is a Wi-Fi access point. [3] The system of claim 1, wherein the access point is a dedicated short-range communication access point. [4] The system of any one of claims 1 to 3, wherein the processor is configured to search for the access point in response to a determination that a cellular signal has fallen below a predefined usability threshold. [5] The system of any one of claims 1 to 3, wherein the processor is configured to communicate the connection information in response to a determination that a cellular signal has fallen below a predefined usability threshold. [6] The system of any one of claims 1 to 3, wherein the processor is configured, in response to a determination that a cellular signal has fallen below a predefined usability threshold, to use the access point to communicate with the device until the processor determines that the cellular signal has risen above the predefined usability threshold. [7] The system of any one of claims 1 to 6, wherein the processor is configured to determine whether the access point will remain in communicable proximity to the vehicle for longer than a predetermined threshold period. [8] The system of claim 7, wherein the processor is configured to communicate the connection information in response to a determination that the access point will remain in communicable proximity to the vehicle for longer than the predetermined threshold period. [9] The system of claim 7 or claim 8, wherein the processor is configured to determine, based on the vehicle speed, whether the access point will remain in communicable proximity to the vehicle for longer than the predetermined threshold period. [10] The system of any one of claims 7 to 9, wherein the processor is configured to determine, based on a vehicle route, whether the access point will remain in communicable proximity to the vehicle for longer than the predetermined threshold period. [11] The system of any one of claims 7 to 10, wherein the processor is configured to determine, based on a vehicle parking condition, whether the access point will remain in communicable proximity to the vehicle for longer than the predetermined threshold period. [12] System according to one of claims 1 to 3, wherein the processor is adapted to: Determining that a vehicle has been parked; Setting a timer to periodically activate the vehicle when the vehicle is turned off; regularly activating the vehicle according to the timer; and in response to activating the vehicle, comparing a cellular signal with a predetermined usability threshold, wherein the processor is configured to: communicate a usable cellular connection when the cellular signal is above the predetermined usability threshold, and instruct the unit to use the wireless access point when the cellular signal is below the predetermined usability threshold.

Images