Title:
DAS ZEITLICHE LIEFERN VON OVER-THE-AIR-DATEN AN EIN FAHRZEUG
Kind Code:
A1


Abstract:

Mobiles Fahrzeug-Kommunikationssystem und Verfahren zur Verwendung dieses Systems zum Bereitstellen von Over-the-Air (OTA)-Daten von einem Fahrzeug-Backend-System an ein Zielfahrzeug. Das Verfahren beinhaltet die folgenden Schritte: Empfangen von (WCS)-zugeordneten Daten eines drahtlosen Trägersystems von einer Vielzahl von Fahrzeugen, die dem Backend-System zugeordnet sind; in Reaktion auf den Schritt des Empfangens, Ermitteln eines bevorzugten geografischen Kommunikationsbereichs aus einer Vielzahl von geografischen Kommunikationsbereichen, worin das Ermitteln auch das Ermitteln beinhaltet, dass der bevorzugte geografische Kommunikationsbereich einen Qualitätsservice (QoS)-Schwellenwert erreicht oder überschreitet, der mindestens einige der verbleibenden geografischen Kommunikationsbereiche nicht erfüllt oder überschreitet; und in Reaktion auf den Schritt des Ermittelns das Übertragen der OTA-Daten vom Backend-System zum Zielfahrzeug, wenn sich das Zielfahrzeug innerhalb des bevorzugten geografischen Kommunikationsbereichs befindet. embedded image




Inventors:
Todorovic, Monika, Mich. (Detroit, US)
Lucarelli, Christopher, Mich. (Detroit, US)
Ellard, Kyle M., Mich. (Detroit, US)
Olsen, Jeffrey J., Mich. (Detroit, US)
Application Number:
DE102017124718A
Publication Date:
04/26/2018
Filing Date:
10/23/2017
Assignee:
General Motors LLC (Mich., Detroit, US)
International Classes:



Attorney, Agent or Firm:
Manitz Finsterwald Patentanwälte PartmbB, 80336, München, DE
Claims:
Verfahren zum Bereitstellen von Over-the-Air (OTA)-Daten von einem Fahrzeug-Backend-System an ein Zielfahrzeug, umfassend folgende Schritte:
Empfangen von (WCS)-zugeordneten Daten des drahtlosen Trägersystems aus einer Vielzahl von Fahrzeugen, die dem Backend-System zugeordnet sind;
in Reaktion auf den Schritt des Empfangs, Ermitteln einer bevorzugten geografischen Kommunikationsregion aus einer Vielzahl von geografischen Kommunikationsregionen, worin das Ermitteln das Ermitteln beinhaltet, dass die bevorzugte geografische Kommunikationsregion einen Servicequalitäts (QoS)-Schwellenwert erreicht oder überschreitet, der mindestens einige der verbleibenden Vielzahl von geografischen Kommunikationsregionen nicht erfüllt oder überschreitet; und
in Reaktion auf den Schritt des Ermittelns, Übertragen der OTA-Daten vom Backend-System an das Zielfahrzeug, wenn sich das Zielfahrzeug innerhalb der bevorzugten geografischen Kommunikationsregion befindet.

Verfahren nach Anspruch 1, ferner umfassend das Ermitteln mindestens einer sekundären geografischen Kommunikationsregion unter Verwendung der WCS-zugeordneten Daten und mindestens einer tertiären geografischen Kommunikationsregion unter Verwendung der WCS-zugeordneten Daten, worin die mindestens eine bevorzugte geografische Kommunikationsregion, verglichen mit der mindestens einer sekundären oder tertiären geografischen Kommunikationsregion, mindestens eine der folgenden beinhaltet: ein weiterentwickelterer Mobilfunktechnologie-Typ als andere derzeit verfügbare Mobilfunktechnologie-Typen, eine höhere Durchsatzrate, eine höhere Signalqualität oder eine höhere Signalstärke.

Verfahren nach Anspruch 2, worin die Durchsatzraten-Daten für eine beliebige geografische Kommunikationsregion auf Daten basieren, die am Backend-System über mehrere Tage hinweg gesammelt wurden, Daten, die am Backend-System zu einer ungefähren Tageszeit oder beiden gesammelt wurden.

Verfahren nach Anspruch 1, worin die OTA-Daten ein Fahrzeugsystem-Update oder eine Benachrichtigung eines Benutzers des Zielfahrzeugs umfassen.

Verfahren nach Anspruch 1, worin eine Nutzlastgröße der übertragenen OTA-Daten kleiner als 50 Megabyte (MB) ist.

Verfahren nach Anspruch 1, ferner umfassend: vor dem Übertragen der OTA vom Backend-System an das Zielfahrzeug, das Durchführen der Schritte (a) (c):
(a) das Empfangen der dem Zielfahrzeug zugeordneten Informationen über den Standort am Backend-System;
(b) das Verwenden der Standortinformationen, Ermitteln, dass sich das Zielfahrzeug nicht innerhalb der bevorzugten geografischen Kommunikationsregion befindet; und
(c) basierend auf dem Ermitteln, dass sich das Zielfahrzeug nicht innerhalb der bevorzugten geografischen Kommunikationsregion befindet, das Durchführen der Schritte (c1) und (c2) am Backend-System:
(c1) das Speichern einer Kennung des Zielfahrzeugs in einer Datenregistrierung; und
(c2) das spätere Ermitteln, dass sich das Zielfahrzeug innerhalb der bevorzugten geografischen Kommunikationsregion befindet; und
(d) das Ausführen nachstehende Schritte (a) (c), wobei der Schritt des Übertragens der OTA-Daten vom Backend-System zum Zielfahrzeug basierend auf Schritt (c2) ausgeführt wird.

Verfahren nach Anspruch 6, worin die Standortinformationen geografische Positionsdaten und dem Zielfahrzeug zugeordnete Kursdaten beinhalten.

Verfahren nach Anspruch 7, ferner umfassend: das Verwenden der Positions- und Kursdaten des Zielfahrzeugs, Vorhersagen am Backend-System, wenn sich das Zielfahrzeug in der bevorzugten geografischen Kommunikationsregion befindet.

Verfahren nach Anspruch 1, ferner umfassend: das Empfangen eines verfügbaren Bandbreitenparameters vom Zielfahrzeug, worin der Schritt des Übertragens auftritt, wenn sich das Zielfahrzeug innerhalb der bevorzugten geografischen Kommunikationsregion befindet und der verfügbare Bandbreitenparameter einen vorbestimmten Schwellenwert überschreitet.

Verfahren zum Bereitstellen von Over-the-Air (OTA)-Daten von einem Fahrzeug-Backend-System an ein Zielfahrzeug, umfassend folgende Schritte:
das Empfangen von (WCS)-zugeordneten Daten des drahtlosen Trägersystems aus einer Vielzahl von Fahrzeugen, die dem Backend-System zugeordnet sind;
in Reaktion auf den Schritt des Empfangens das Ermitteln mindestens einer bevorzugten geografischen Kommunikationsregion unter Verwendung der WCS-zugeordneten Daten;
das Empfangen der dem Zielfahrzeug zugeordneten Informationen über den Standort am Backend-System;
wenn die Standortinformationen anzeigen, dass sich das Zielfahrzeug innerhalb der mindestens einen bevorzugten geografischen Kommunikationsregion befindet, das Übertragen der OTA-Daten zum Zielfahrzeug über ein drahtloses Trägersystem; und
wenn die Standortinformationen anzeigen, dass sich das Zielfahrzeug nicht innerhalb der mindestens einen bevorzugten geografischen Kommunikationsregion befindet, das Durchführen der Schritte (a) (c) am Backendsystem:
(a) das Speichern einer Kennung des Zielfahrzeugs in einer Datenregistrierung;
(b) das spätere Ermitteln, dass sich das Zielfahrzeug innerhalb der bevorzugten geografischen Kommunikationsregion befindet; und dann
(c) das Übertragen der OTA-Daten zum Zielfahrzeug.

Description:
TECHNISCHES GEBIET

Die vorliegende Erfindung bezieht sich auf das Bereitstellen von Over-the-Air-Daten für Fahrzeuge und insbesondere auf die zeitliche Lieferung der drahtlosen Daten, um die Auswirkungen auf den Betrieb des drahtlosen Trägersystems zu minimieren und die Auswirkungen auf die Fahrzeugkommunikation oder beides zu minimieren.

HINTERGRUND

Entfernt stationierte Computer (z. B. die mit einem Mobilfunknetz gekoppelt sind) können den Betrieb von Millionen von mobilen Fahrzeugen durch periodische Übertragung von Software-Updates an die Fahrzeuge unterstützen—z. B. sodass die Updates an Bord von Fahrzeugcomputermodulen installiert werden können und die Fahrzeugleistung verbessert wird. Das Übertragen großer Mengen dieser Updates kann zu einer Überlastung des Mobilfunknetzes führen, was zu einer lokalisierten Verschlechterung der drahtlosen Dienste (z. B. je nach Fahrzeugstandort), zu einem Verlust von Updates (z. B. durch Kollisionen) oder ähnlichem führen kann. Ferner kann das Empfangen dieser Updates am Fahrzeug zu einer Verschlechterung der Benutzererfahrung führen - z. B. wenn die Updates empfangen werden, während das jeweilige Fahrzeug einen großen Teil seiner Mobilfunkbandbreite nutzt (z. B. wenn das Fahrzeug Musik- oder Video-Streaming über eine Mobilfunkverbindung empfängt).

Somit besteht die Notwendigkeit, relativ kleine Datenübertragungen (wie beispielsweise Software-Updates, Nachrichten und Benachrichtigungen usw.) an eine große Anzahl an Fahrzeugen bereitzustellen, ohne die Leistung des Mobilfunknetzes zu beeinträchtigen oder die Benutzererfahrungen an jedem einzelnen Fahrzeug zu verschlechtern.

ZUSAMMENFASSUNG

Gemäß einer Ausführungsform der Erfindung wird ein Verfahren zum Bereitstellen von Over-the-Air (OTA)-Daten von einem Fahrzeug-Backend-System zu einem Zielfahrzeug bereitgestellt. Das Verfahren beinhaltet die folgenden Schritte: Empfangen von (WCS)-zugeordneten Daten eines drahtlosen Trägersystems von einer Vielzahl von Fahrzeugen, die dem Backend-System zugeordnet sind; in Reaktion auf den Schritt des Empfangens, Ermitteln eines bevorzugten geografischen Kommunikationsbereichs aus einer Vielzahl von geografischen Kommunikationsbereichen, worin das Ermitteln auch das Ermitteln beinhaltet, dass der bevorzugte geografische Kommunikationsbereich einen Qualitätsservice (QoS)-Schwellenwert erreicht oder überschreitet, der mindestens einige der verbleibenden geografischen Kommunikationsbereiche nicht erfüllt oder überschreitet; und in Reaktion auf den Schritt des Ermittelns das Übertragen der OTA-Daten vom Backend-System zum Zielfahrzeug, wenn sich das Zielfahrzeug innerhalb des bevorzugten geografischen Kommunikationsbereichs befindet.

Gemäß einer weiteren Ausführungsform der Erfindung wird ein Verfahren zum Bereitstellen von Over-the-Air (OTA)-Daten von einem Fahrzeug-Backend-System zu einem Zielfahrzeug bereitgestellt. Verfahren beinhaltet die Schritte: Empfangen von einem drahtlosen Trägersystem (WCS) zuzuordnenden Daten aus einer Vielzahl von Fahrzeugen, die dem Backend-System zugeordnet sind; in Reaktion auf den Schritt des Empfangens, das Ermitteln mindestens eines bevorzugten geografischen Kommunikationsbereichs unter Verwendung der WCS-zugeordneten Daten; die am Backend-System empfangene Standortinformation, die dem Zielfahrzeug zugeordnet ist; wenn die Standortinformation anzeigt, dass sich das Zielfahrzeug innerhalb des mindestens einen bevorzugten geografischen Kommunikationsbereichs befindet, übertragen der OTA-Daten über ein Drahtlos-Trägersystem an das Zielfahrzeug; und wenn die Standortinformation anzeigt, dass sich das Zielfahrzeug nicht innerhalb des mindestens einen bevorzugten geografischen Kommunikationsbereichs befindet, durchführen der Schritte (a) (c) im Backend-System: (a) Speichern einer Kennung des Zielfahrzeugs in einer Datenregistrierung; (b) später bestimmen, dass sich das Zielfahrzeug innerhalb des mindestens einen bevorzugten geografischen Kommunikationsbereichs befindet; und dann (c) Senden der OTA-Daten an das Zielfahrzeug.

Figurenliste

Eine oder mehrere Ausführungsformen der Erfindung werden im Folgenden in Verbindung mit den beigefügten Zeichnungen beschrieben, worin gleiche Bezeichnungen gleiche Elemente bezeichnen, und worin:

  • 1 ein Blockdiagramm ist, das eine Ausführungsform eines Kommunikationssystems darstellt, das fähig ist, das hierin offenbarte Verfahren zu verwenden;
  • 2 ein Flussdiagramm eines Verfahrens zum Bereitstellen von Over-the-Air (OTA)-Daten Fahrzeug-Backend-System zu einem Zielfahrzeug ist; und
  • 3 eine exemplarische Karte mit einer oder mehreren bevorzugten geografischen Kommunikationsbereichen veranschaulicht.

AUSFÜHRLICHE BESCHREIBUNG DER VERANSCHAULICHTEN AUSFÜHRUNGSFORM(EN)

Im Folgenden wird ein Fahrzeug-Backend-System beschrieben, das dazu konfiguriert ist, Mobilfunk- oder Over-the-Air (OTA)-Daten zwischen dem Backend-System und einer Anzahl an Zielfahrzeugen bereitzustellen. Insbesondere kann das Backend-System bestimmen, wann die OTA-Daten basierend auf Daten von einem drahtlosen Trägersystem, Standortinformationen der jeweiligen Zielfahrzeuge und einer Empfangsbereitschaft der OTA-Daten bei den jeweiligen Zielfahrzeugen übertragen werden sollen. Das Backend-System kann auch bestimmen, wann das Übertragen von OTA-Daten verzögert werden soll, wobei das Fahrzeug in eine Warteschlange gestellt wird, bis die Bedingungen geringer sind, dass das drahtlose Trägersystem negativ beeinträchtigt wird, eine Fahrzeugnutzererfahrung beeinträchtigt wird oder beides.

Kommunikationssystem -

Mit Bezug auf 1 ist eine Betriebsumgebung dargestellt, die ein mobiles Fahrzeugkommunikationssystem 10 umfasst, das verwendet werden kann, um das hierin offenbarte Verfahren zu implementieren. Das Kommunikationssystem 10 beinhaltet im Allgemeinen: ein oder mehrere drahtlose Trägersysteme 12; ein Landkommunikationsnetz 14; ein Fahrzeug-Backend-System 16, das mindestens einen von einem Remote-Server 18, ein Daten-Service-Center 20 oder beides beinhaltet; und eines oder mehrere telematikfähige Fahrzeuge 24, 24', 24", 24"'. Es versteht sich, dass das offenbarte Verfahren mit einer beliebigen Anzahl an unterschiedlichen Systemen verwendet werden kann und nicht speziell auf die hierin gezeigte Betriebsumgebung einschränkt ist. Auch die Architektur, Konstruktion, Konfiguration und der Betrieb des Systems 10 und seiner einzelnen Komponenten sind in der Technik allgemein bekannt. Somit stellen die folgenden Absätze lediglich einen kurzen Überblick über ein solches Kommunikationssystem 10 bereit; aber auch andere, hierin nicht dargestellte Systeme könnten die offenbarten Verfahren einsetzen.

Das drahtlose Trägersystem 12 kann jedes geeignete Mobilfunksystem sein, das eine oder mehrere der folgenden Komponenten beinhaltet (z. B. je nach Mobilfunktechnologie): Mobilfunktürme, Basisübertragungsstationen, Mobilvermittlungszentralen, Basisstationssteuerungen, entwickelte Knoten (z. B. eNodeBs), Mobilitätsmanagement-Einheiten (MMEs), Servier- und PGN-Gateways usw. sowie alle anderen Netzwerkkomponenten, die erforderlich sind, um das Drahtlosträgersystem 12 mit dem Festnetz 14 zu verbinden oder das drahtlose Trägersystem mit einer Benutzerausrüstung (UEs, z. B. Telematikausrüstung in Fahrzeugen 24, 24', 24", 24''') zu verbinden. Das Mobilfunksystem 12 kann jede geeignete Kommunikationstechnik implementieren, einschließlich beispielsweise GSM/GPRS-Technologie, CDMA- oder CDMA2000-Technologie, LTE-Technologie usw. Im Allgemeinen sind drahtlose Trägersysteme 12, deren Komponenten, die Anordnung ihrer Komponenten, das Zusammenwirken der Komponenten usw. allgemein in der Technik bekannt.

Das Festnetz 14 kann ein konventionelles Festnetz-Telekommunikationsnetzwerk sein, das mit einem oder mehreren Festnetztelefonen verbunden ist und das drahtlose Trägersystem 12 mit dem Backend-System 16 verbindet. So kann zum Beispiel das Festnetz 14 ein öffentliches Telefonnetz (PSTN) beinhalten, wie es verwendet wird, um Festnetztelefonie, paketvermittelte Datenkommunikation und die Internetinfrastruktur bereitzustellen. Ein oder mehrere Segmente des Festnetzes 14 könnten durch die Verwendung eines Standard-verdrahteten Netzwerks, eines Glasfasernetzwerks oder eines anderen LWL-Netzwerks, eines Kabelnetzwerks, von Stromleitungen, anderer drahtloser Netzwerke, wie beispielsweise drahtloser lokaler Netze (WLAN) oder von Netzwerken, die Broadband Wireless Access (BWA) oder eine beliebige Kombination davon bereitstellen, implementiert werden. Des Weiteren muss das Datenservice-Center 20 nicht über das Festnetz 14 verbunden sein, sondern könnte Funktelefonieausrüstung beinhalten, sodass es direkt mit einem drahtlosen Netzwerk, wie dem drahtlosen Trägersystem 12, kommunizieren kann.

Gemäß einer Ausführungsform beinhaltet das Fahrzeug-Backend-System 16 sowohl das Datenservice-Center 20 als auch eine Vielzahl von Remote-Servern 18—und in einigen Implementierungen verwaltet das Service-Center 20 eine oder mehrere private Verbindungen zwischen ihm und den Remote-Servern 18. Wie nachfolgend beschrieben, können das Service-Center 20 und die Server 18 so angeordnet sein, dass eine Anzahl an Fahrzeugdienstleistungen für die Fahrzeuge 24, 24', 24", 24''' bereitgestellt werden. So kann beispielsweise das Backend-System gemäß einem Teilnehmerverhältnis zwischen den Benutzern der Fahrzeuge und dem Backend-System 16 Navigationsdienste, Fahrzeugnotrufdienste, Fahrzeugsoftware-Updateservices, verschiedene Benachrichtigungsdienste usw. bereitstellen, wie im Folgenden näher erläutert wird.

In einigen Implementierungen können die Remote-Server 18 einer aus einer Anzahl an Computern sein, auf die über ein privates oder öffentliches Netzwerk, wie beispielsweise das Internet, zugegriffen werden kann. Jeder dieser Server 18 kann für einen oder mehrere Zwecke verwendet werden, wie beispielsweise als Web-Server, der über das Festnetz 14 und/oder den drahtlosen Träger 12 erreichbar ist. Weitere derartige zugängliche Server 18 können zum Beispiel sein: ein Service-Center-Computer, wobei Diagnoseinformationen und andere Fahrzeugdaten von Fahrzeugen 24, 24', 24", 24''' hochgeladen werden können, oder ein Drittanbieter, zu oder von dem Fahrzeugdaten oder andere Informationen bereitgestellt werden, sei es durch Kommunikation mit den Fahrzeugen 24, 24', 24", 24''', mit dem Daten-Service-Center 20 oder beiden. Remote-Server 18 können auch für das Bereitstellen von Internetkonnektivität wie DNS-Diensten oder als ein Netzwerkadressenserver verwendet werden, der DHCP oder ein anderes geeignetes Protokoll verwendet, um dem Fahrzeug 24, 24', 24", 24''' eine IP-Adresse zuzuweisen.

In mindestens einer Ausführungsform beinhaltet jeder Server 18 einen oder mehrere Prozessoren 52, die mit dem Speicher (oder einem oder mehreren Speichervorrichtungen) 54 gekoppelt sind. Der/die Prozessor(en) 52 kann/können jede Art von Vorrichtung sein, die in der Lage sind, Anweisungen zu verarbeiten und/oder auszuführen, worin nicht einschränkende Beispiele Mikroprozessoren, Mikrocontroller, Host-Prozessoren, Steuerungen, Server-zu-Server-Kommunikationsprozessoren und anwendungsspezifische integrierte Schaltungen (ASICs) beinhalten. Der/die Prozessor(en) 52 können einer bestimmten Backend-Systemfunktion zugeordnet sein oder einige Prozessoren können mit anderen Backend-Systemen oder anderen Remote-Server-Computern gemeinsam genutzt werden.

In mindestens einer Ausführungsform kann/können der/die Prozessor(en) 52 eine Anzahl an Anweisungen ausführen, die auf dem Speicher 54 gespeichert sind, um Over-the-Air (OTA)-Daten vom Backend-System 16 an ein bestimmtes Fahrzeug (z. B. ein Zielfahrzeug wie das Fahrzeug 24) bereitzustellen, einschließlich eines oder mehrerer der Folgenden: (1) Empfangen von zugeordneten Daten (WCS-zugeordneten Daten) von einem drahtlosen Trägersystem von mehreren Fahrzeugen 24, 24', 24", 24''', usw.; (2) Identifizieren oder anderweitiges Ermitteln einer oder mehrerer bevorzugter geographischer Kommunikationsbereiche basierend auf den WCS-zugeordneten Daten; (3) Auswählen, Identifizieren oder anderweitiges Ermitteln einer Liste oder Auflistung von Zielfahrzeugen (z. B. beispielsweise des Zielfahrzeugs 24), die Teilnehmerbeziehungen mit dem Backend-System 16 aufweisen, worin die Zielfahrzeuge dazu vorgesehen sind, OTA-Daten zu empfangen; (4) Ermitteln von Standortinformationen (z. B. Positions- und/oder Kursdaten), die den jeweiligen Zielfahrzeugen zugeordnet sind; (5) Ermitteln, welche der Zielfahrzeuge sich innerhalb eines bevorzugten geografischen Kommunikationsbereichs befinden; (6) Ermitteln, ob mindestens einige der Zielfahrzeuge basierend auf der aktuellen Nutzung am jeweiligen Fahrzeug eine verfügbare Mobilfunkbandbreite aufweisen (z. B. ob die verfügbare Bandbreite größer als ein vorbestimmter Schwellenwert ist); (7) übertragen von OTA-Daten vom Backend-System zu den Zielfahrzeugen, die als innerhalb eines bevorzugten geografischen Kommunikationsbereichs liegend identifiziert werden, die eine verfügbare Bandbreite aufweisen oder die beide innerhalb eines bevorzugten geografischen Kommunikationsbereichs liegen und eine verfügbare Bandbreite aufweisen; (8) Hinzufügen von mindestens einigen Zielfahrzeugen zu einer Datenregistrierung im Backend-System, wenn sich das jeweilige Zielfahrzeug nicht innerhalb eines der bevorzugten geografischen Kommunikationsbereiche befindet oder keine verfügbare Bandbreite aufweist; (9) Neubestimmen von Standortinformationen, die einem Zielfahrzeug zugeordnet sind, wenn sich das jeweilige Zielfahrzeug nicht in einem der bevorzugten geografischen Kommunikationsbereiche befindet (oder zuvor keine verfügbare Bandbreite aufgewiesen hat), und (10) wiederholtes Neubestimmen oder Aktualisieren der bevorzugten geografischen Kommunikationsbereiche - z. B. einschließlich der Aktualisierung der bevorzugten geografischen Kommunikationsbereiche, wenn sich das jeweilige Zielfahrzeug nicht innerhalb eines der bevorzugten geografischen Kommunikationsbereiche befindet.

Selbstverständlich können die Prozessoren 52 auch andere Anweisungen ausführen, die auf dem Speicher 54 gespeichert sind. Daher sollte beachtet werden, dass Prozessor(en) 52 mindestens einen Teil des hierin beschriebenen Verfahrens ausführen können, wie im Folgenden näher erläutert wird.

Der Speicher 54 der Server 18 kann verwendet werden, um alle geeigneten Fahrzeug-Backend-Daten, wie beispielsweise Fahrzeugdatensätze, sowie die vorstehend erläuterten exemplarischen Verfahrensanweisungen zu speichern. Der Speicher 54 beinhaltet jedes geeignete nichtflüchtige computerlesbare nutzbare Medium beinhalten, das eine oder mehrere Speichervorrichtungen oder Gegenstände kann. Exemplarische nichtflüchtige computernutzbare Speichervorrichtungen beinhalten ein herkömmliches Computersystem-RAM (random access memory), ROM (read only memory), EPROM (löschbarer, programmierbarer ROM), EEPROM (elektrisch löschbarer, programmierbarer ROM) und magnetische oder optische Platten oder Bänder. In mindestens einer Implementierung beinhaltet der Speicher 54 einen nichtflüchtigen Speicher (z. B. ROM, EPROM, EEPROM, usw.). Dies sind lediglich Beispiele; und andere Implementierungen werden hierin ebenfalls betrachtet.

Das Datenservice-Center 20 ist konzipiert, die Fahrzeuge 24, 24', 24", 24''' mit einer Anzahl an unterschiedlichen System-Back-End-Funktionen bereitzustellen, und beinhaltet im Allgemeinen einen oder mehrere Switches, Server, Datenbanken, Live-Berater sowie ein automatisiertes Sprachausgabesystem (VRS). Diese verschiedenen Komponenten des Call-Centers sind bevorzugt miteinander über ein verdrahtetes oder drahtloses lokales Netzwerk gekoppelt. Der Switch, der ein Nebenstellenanlagen (PBX)-Switch sein kann, leitet eingehende Signale weiter, sodass Sprachübertragungen gewöhnlich entweder zum Live-Berater über das reguläre Telefon oder automatisiert zum Sprachausgabesystem unter Verwendung von VoIP gesendet werden. Das Telefon des Live-Beraters kann zudem VoIP verwenden; VoIP und andere Datenkommunikationen über den Switch werden über ein Modem implementiert, das zwischen dem Switch und dem Netzwerk implementiert ist. Datenübertragungen werden über das Modem zum Server und/oder der Datenbank weitergegeben. Die Datenbank kann Fahrzeugdatensätze oder andere geeignete Kontoinformationen, einschließlich, aber nicht beschränkt auf Teilnehmerauthentisierungsinformationen, Fahrzeugidentifikatoren, Profilaufzeichnungen, Verhaltensmuster und andere entsprechende Teilnehmerinformationen, speichern. Datenübertragungen vom Service-Center 20 können auch von drahtlosen Systemen, wie beispielsweise LTE, CDMA, UMTS, GSM/GPRS, 802.11x und dergleichen durchgeführt werden. Obwohl eine Ausführungsform beschrieben wurde, als ob sie in Verbindung mit einem bemannten Datenservice-Center 20 verwendet würde, der den Live-Berater einsetzt, ist es offensichtlich, dass das Datenservice-Center stattdessen VRS als einen automatisierten Berater verwenden können oder eine Kombination von VRS und dem Live-Berater kann verwendet werden. Des Weiteren kann eine Anzahl weiterer automatisierter Fahrzeugdienste über das Daten-Service-Center 20 bereitgestellt werden, z. B. worin das Daten-Service-Center 20 mit den Fahrzeugen 24, 24', 24", 24" usw. ohne Eingreifen von Fahrern oder Benutzern der jeweiligen Fahrzeuge kommuniziert.

1 veranschaulicht mehrere Fahrzeuge 24, 24', 24", 24''' und in mindestens einer Ausführungsform kann jedes Fahrzeug (oder jeder zugehörige Fahrzeugbenutzer) eine Teilnehmerbeziehung zum Backend-System 16 aufweisen. Die Fahrzeuge 24, 24', 24", 24''' können gleich oder ähnlich sein; somit wird hierin nur ein Fahrzeug (24) beschrieben. Das Fahrzeug 24 ist als ein PKW dargestellt, aber es sollte klar sein, dass jedes andere Fahrzeug, einschließlich Motorräder, LKW, Geländewagen (SUV), Freizeitfahrzeuge (RVs), Schiffe, Flugzeuge usw. ebenfalls verwendet werden kann. Das Fahrzeug 24 kann ein Fahrzeugkommunikationssystem 30 beinhalten, unter anderem ein oder mehrere Fahrzeugsystemmodule (VSM) 32 und eine oder mehrere Netzwerkverbindungen 34.

Die Fahrzeugsystemmodule (VSMs) 32 können in Form von elektronischen Hardwarekomponenten ausgeführt sein, die sich an verschiedenen Stellen im Fahrzeug 24 befinden und typischerweise eine Eingabe von einem oder mehreren Sensoren empfangen und die erfassten Eingaben verwenden, um Diagnose-, Überwachungs-, Steuerungs-, Berichterstattungs- und/oder andere Funktionen auszuführen. Nicht einschränkende Beispiele für VSMs 32 beinhalten ein Karosserie-Steuerungsmodul (BCM) zum Steuern von Leistungsschlössern, Scheinwerfern usw., ein Motorsteuerungsmodul (ECM) zum Steuern von Kraftstoffzündung, Zündzeitpunkt usw., ein Onboard-Diagnosemodul (OBDM) zum Berichten von Diagnose-Fehlercodes und dergleichen sowie ein GPS (Global Positioning System) oder eine GLONASS (Global Navigation Satellite Service)-Vorrichtung zum Bereitstellen von Fahrzeugnavigationsdiensten und berichten von Positionsdaten zum Backend-System 16. Wie von Fachleuten auf dem Gebiet verstanden wird, sind die vorstehend genannten VSMs nur Beispiele von einigen Modulen, die im Fahrzeug 24 verwendet werden können, und zahlreiche andere Beispiele sind ebenfalls möglich.

Mindestens ein VSM 32 kann ein Gateway-Modul, wie beispielsweise eine Fahrzeugtelematikeinheit, sein, das für die drahtlose Nahbereichskommunikation und/oder Mobilfunkkommunikation geeignet ist. So kann beispielsweise ein Telematikeinheit eine OEM-installierte (eingebettete) oder eine Aftermarketvorrichtung sein, die im Fahrzeug 24 installiert ist und drahtlose Sprach- und/oder Datenkommunikation über ein drahtloses Trägersystem 12 und über eine drahtlose Vernetzung ermöglicht. Dies ermöglicht es dem Fahrzeug, mit dem Backend-System 16, anderen telematikfähigen Fahrzeugen oder einer anderen Einheit oder Vorrichtung zu kommunizieren (z. B. über zellulare Kommunikation gemäß einem LTE, GSM, CDMA oder einem anderen geeigneten Telekommunikationsstandard). Die Telematikeinheit verwendet bevorzugt Funkübertragungen, um einen Kommunikationskanal (einen Sprachkanal und/oder einen Datenkanal) mit dem drahtlosen Trägersystem 12 herzustellen, sodass Sprach- und/oder Datenübertragungen über den Kanal gesendet und empfangen werden können. Durch Bereitstellen von sowohl Sprach- als auch Datenkommunikation ermöglicht die Telematikeinheit dem Fahrzeug 24, eine Anzahl an unterschiedlichen Diensten bereitzustellen, einschließlich derjenigen, die sich auf Navigation, Telefonie, Nothilfe, Diagnose, Infotainment, Benutzerbenachrichtigungsdienste usw. beziehen. Die Daten können entweder über eine Datenverbindung, beispielsweise über eine Paketdatenübertragung über einen Datenkanal oder über einen Sprachkanal unter Verwendung von in der Technik bekannten Techniken gesendet werden. Für kombinierte Dienste, die sowohl Sprachkommunikation (z. B. mit einem Live-Berater oder einer Sprachausgabeeinheit im Daten-Service-Center 20) als auch Datenkommunikation (z. B. um GPS-Ortsdaten oder Fahrzeugdiagnosedaten an den Daten-Service-Center bereitzustellen) einschließen, kann das System einen einzelnen Anruf über einen Sprachkanal verwenden und nach Bedarf zwischen Sprach- und Datenübertragung über den Sprachkanal umschalten, und dies kann unter Verwendung von Techniken erfolgen, die dem Fachmann bekannt sind.

Wie im Folgenden näher erläutert wird, kann die Telematikeinheit 32 auch so angepasst werden, dass sie Daten von Konfigurationsänderungen des Kommunikationssystems 30 sowie Fahrzeugsystem-Updates (z. B. Software- oder Anleitungs-Updates), die einem oder mehreren der Fahrzeugsystemmodule 32 zugeordnet sind, empfängt. So kann beispielsweise die Telematikeinheit vom Backend-System 16 sogenannte OTA-Daten oder „Over-the-Air“-Mobilfunkverbindungen empfangen, die Fahrzeugsystem-Updates und/oder Konfigurationsänderungsdaten für das System 30 beinhalten. OTA-Daten können ein kurzer Daten-Burst sein und eine relativ kleine Gesamtnutzlast aufweisen—z. B. worin die Gesamtnutzlast das Fahrzeugsystem-Update oder Konfigurations-Update selbst umfasst. OTA-Daten können durch eine oder mehrere SMS-Nachrichten oder eine relativ kleine Menge an Mobilfunk-Datenpaketen übertragen werden, um nur einige Beispiele zu nennen. So kann beispielsweise die Gesamtnutzlast der OTA-Daten gemäß einer nicht einschränkenden Ausführungsform etwa 500 Megabyte (MB) oder weniger betragen. Somit umfassen OTA-Daten in mindestens einer Ausführungsform keine Streaming-Medien oder so genannte „Streaming-Daten“. Das Empfangen von OTA-Daten an der Telematikeinheit 32 (und auch die Installation der Updates) kann in einigen Fällen automatisch und ohne Eingreifen des Benutzers erfolgen.

Netzwerkverbindungen 34 beinhalten ein beliebiges verdrahtetes oder drahtloses fahrzeugeigenes Kommunikationssystem zum Verbinden oder Koppeln der VSMs 32-sowie andere fahrzeugelektronische Vorrichtungen, Sensoren usw.—miteinander. So kann beispielsweise die Netzwerkverbindung 34 ein Datenbus (z. B. ein Kommunikationsbus, Entertainmentbus, usw.) sein. Nicht einschränkende Beispiele von geeigneten drahtgebundenen Netzwerkverbindungen 34 beinhalten ein Controller Area Network (CAN), einen medienorientierten Systemtransfer (MOST), ein lokales Kopplungsstrukturnetzwerk (LIN), ein lokales Netzwerk (LAN) und andere geeignete Verbindungen wie Ethernet, Audio-Visual Bridging (AVB) oder andere, die bekannten ISO-, SAE- und IEEE-Standards und -Spezifikationen, entsprechen, um nur einige zu nennen. Nicht einschränkende Beispiele von geeigneten drahtlosen Netzwerkverbindungen 34 beinhalten jede drahtlose Nahbereichs-Kommunikationsverbindung—z. B. eine Wi-Fi-Verbindung, eine Wi-Fi-Direktverbindung, eine Bluetooth- oder BLE-Verbindung, eine Nahfeld- Kommunikationsverbindung usw.

Nachfolgend werden eine oder mehrere Verfahren zur Verwendung des Kommunikationssystems 10 beschrieben. Insbesondere wird mindestens ein Verfahren zum Bereitstellen von Over-the-Air (OTA)-Daten von einem Fahrzeug-Backend-System an mehrere Zielfahrzeuge (z. B. das Fahrzeug 24) beschrieben, wobei die Lieferung der OTA-Daten zeitlich getaktet ist, um eine Überlastung des Netzwerkverkehrs über das drahtlose Trägersystem zu minimieren. Ferner kann das Verfahren in mindestens einer Ausführungsform die OTA-Daten je nach Mobilfunknutzung und/oder verfügbarer Bandbreite an ein bestimmtes Zielfahrzeug senden oder nicht senden—z. B. um dadurch eine Beeinträchtigung der Benutzererfahrung zu vermeiden oder zu minimieren, wenn der Fahrzeugnutzer bereits über einen Sprach- und/oder Datenanruf oder eine Verbindung verbunden ist.

Das Verfahren ist in Bezug auf ein Zielfahrzeug (24) beschrieben; es sollte jedoch beachtet werden, dass dasselbe Verfahren auf mehrere Zielfahrzeuge simultan, gleichzeitig und/oder aufeinanderfolgend angewendet werden kann—wodurch die betriebliche Leistungsfähigkeit des Backend-Systems verbessert wird.

Verfahren -

Wie im Flussdiagramm von 2 dargestellt, ist ein Verfahren 200 veranschaulicht, das sich auf das Übertragen oder anderweitiges Bereitstellen von Over-the-Air (OTA)-Daten vom Backend-System 16 zum Zielfahrzeug 24 bezieht. Insbesondere bezieht sich das Verfahren 200 in mindestens einer Ausführungsform auf den Zeitpunkt der Übertragung der OTA-Daten an das Zielfahrzeug 24, die zumindest teilweise auf die gesammelten, zusammengefassten und/oder analysierten sogenannten ‚Big Data‘ basieren, die von Fahrzeugen mit mehreren Teilnehmern empfangen werden (z. B. Fahrzeuge 24', 24", 24''' und selbst Fahrzeug 24). Somit kann das Verfahren 200 die Überlastung des Mobilfunknetzverkehrs innerhalb des drahtlosen Trägersystems 12 minimieren und/oder eine negative Auswirkung auf die Benutzererfahrung innerhalb des Zielfahrzeugs 24 minimieren (oder vermeiden). Die Fahrzeuge 24, 24', 24", 24''' sind repräsentativ für Hunderte, Tausende, Millionen usw. von Fahrzeugen, die zuvor einem oder mehreren der Remote-Server 18, dem Daten-Service-Center 20 oder einer Kombination davon zugeordnet waren. Und wie hierin verwendet, bezieht sich der Ausdruck „Big-Data“ auf relativ große Mengen von dem drahtlosen Trägersystem zugeordneten Daten (WCS-zugeordnete Daten) (z. B. Sätze, die Terabytes (TBs) und größer sind), die vom Backend-System 16 empfangen und analysiert werden können, um Muster, Trends, Zuordnungen, und dergleichen zwischen den Fahrzeugen 24, 24', 24", 24''' zu bestimmen. Die WCS-zugeordneten Daten werden im Folgenden genauer beschrieben.

In der nachfolgenden Beschreibung sind die vom Backend-System 16 übertragenen OTA-Daten als Fahrzeugsystem-Update (z. B. ein Instruktions- oder Software-Update für mindestens ein Onboard-VSM 32) dargestellt; allerdings sind auch weitere Beispiele vorhanden. So könnten beispielsweise die OTA-Daten einen Fahrzeugbefehl vom Backend-System 16 oder eine Benachrichtigung oder Nachricht umfassen. Exemplarische Benachrichtigungen beinhalten eine Nachricht für einen Benutzer oder Fahrer des Fahrzeugs 24; z. B. wie eine visuelle oder hörbare Nachricht usw. Wie vorstehend erläutert, kann die Gesamtnutzlast der OTA-Daten relativ gering sein. Auf diese Weise kann das Übertragen von OTA-Daten zeit- oder planmäßig erfolgen, sodass ein sich bewegendes Zielfahrzeug die OTA-Daten zu bevorzugten Bedingungen empfangen kann, wie nachfolgend näher erläutert wird (z. B. bevor das sich bewegende Fahrzeug die gewünschten Bedingungen verlässt).

Das Verfahren 200 kann mit Schritt 205 beginnen, worin das Backend-System 16 WCS-zugeordnete Daten von den Fahrzeugen 24, 24', 24", 24''' empfangen und sammeln kann. So können beispielsweise die Fahrzeuge 24, 24', 24", 24''' periodisch oder gelegentlich sogenannte Fahrzeugdaten-Uploads zum Backend-System 16 bereitstellen—z. B. können die Fahrzeuge 24, 24', 24", 24''' die dem drahtlosen Trägersystem 12 zugeordneten Daten, ihre jeweiligen Mobilfunkverbindungen dazu usw. übertragen. So können beispielsweise die WCS-zugeordneten Daten, die von jedem Fahrzeug 24, 24', 24", 24''' bereitgestellt werden, spezifische Daten für die Mobilfunkverbindung des jeweiligen Fahrzeugs beinhalten, wie beispielsweise: die Mobilfunktechnologie der jeweiligen Verbindung (LTE, CDMA, GSM/GPRS, UMTS usw.), die Durchlaufgeschwindigkeit der Verbindung, die Signalstärke der Verbindung und die Signalqualität der Verbindung, um nur einige Beispiele zu nennen.

Wenn beispielsweise ein Fahrzeug zu einem Zielort fährt, kann es sich mit verschiedenen Mobilfunktürmen im drahtlosen Trägersystem 12 verbinden, und das Fahrzeug kann dem Backend-System 16 melden, dass es beispielsweise durch eine LTE-Zelle (oder eine andere geographische Region), dann eine CDMA-Zelle (oder eine andere geografische Region) und dann eine andere LTE-Zelle (oder eine andere geographische Region) fährt. Das Fahrzeug kann dem Backend-System 16 Positionsdaten (z. B. Breiten- und Längengradangaben—z. B. so genannte Lat-Long-Daten), die jeder Verbindung zugeordnet sind, melden. Somit kann das (die) Fahrzeug(e) 24, 24', 24", 24''' jede geeignete Anzahl an Datenpunkten (z. B. Technologieart, die mit Positionsdaten korreliert ist, wenn sie über diese Technologieart verbunden sind, Zeitstempeldaten usw.) sammeln und berichten. Darüber hinaus sind die Positionsdaten nicht auf Lat-Long-Daten beschränkt; Fachleute werden andere Arten von Positionsdaten schätzen, einschließlich prädiktiver Positionsdaten, die an das Backend-System 16 gemeldet werden können, wenn kein geeignetes GPS-Satellitensignal vorhanden ist.

Weiterführend mit dem Beispiel kann ein exemplarisches Fahrzeug auch während der Fahrt Informationen über eine schwankende Durchlaufgeschwindigkeit seiner Verbindungen sammeln. Und beispielsweise kann sich innerhalb einer geografischen Region die Durchlaufgeschwindigkeit ändern—somit können zahlreiche Durchlaufgeschwindigkeiten mit zahlreichen entsprechenden Fahrzeugstandorten korreliert werden. Weiterhin kann das Fahrzeug beispielsweise während der Fahrt Informationen über die Signalstärke und die Signalqualität seiner verschiedenen Verbindungen sammeln; es ist zu beachten, dass die Signalstärke und die Signalqualität innerhalb einer bestimmten geographischen Region auch schwanken können. Somit können zahlreiche Signalstärken und/oder Signalqualitätswerte mit einer Vielzahl von geografischen Fahrzeugstandorten korreliert werden.

Somit kann während einer einzelnen Fahrt jede geeignete Menge von Datenpunkten gemessen und durch das Fahrzeug zum Backend-System 16 berichtet werden. In mindestens einer Ausführungsvariante beinhaltet jeder berichtete Datenpunkt: Technologiedaten, Durchlaufgeschwindigkeitsdaten, Signalstärkedaten, Signalqualitätsdaten, Zeitstempeldaten und Positionsdaten. Selbstverständlich ist es nicht erforderlich, dass das Fahrzeug jeden einzelnen Datenpunkt in Echtzeit oder während des Sammelns meldet. So kann beispielsweise das Fahrzeug diese Datenpunkte speichern und ein Bündel von Datenpunkten zu einem geeigneten Zeitpunkt in einem Upload von Fahrzeugdaten zum Backend-System 16 übertragen. Somit umfassen in mindestens einer Ausführungsform die WCS-zugeordneten Daten, die vom Backend-System 16 von jedem Fahrzeug 24, 24', 24", 24''' in Schritt 205 empfangen werden, eine Vielzahl derartiger Datenpunkte.

Es ist zu beachten, dass durch das Bereitstellen dieser Datenpunkte an das Backend-System 16 durch die Fahrzeuge 24, 24', 24", 24''' (z. B. potenzielle Millionen Fahrzeuge) eine Karte oder ein geografisches Modell oder ein Algorithmus vom Backend-System 16 verwendet werden kann (z. B. durch Verwendung von Software in speziell konfigurierten Servern 18) (Schritt 210). Dieses Modell kann verwendet werden, um geografische Regionen zu bestimmen oder zu identifizieren, die aktuell wünschenswerte zelluläre oder WCS-Parameter aufweisen-z. B. höhere Durchsatzwerte, geringerer Mobilfunkverkehr, geringere Kollisionsraten, allgemein weniger Netzüberlastung usw. Somit kann das Modell beispielsweise eine Servicequalität (QoS)-Kennzahl für geografische Regionen bestimmen und kann mit einer oder mehreren der folgenden Verfahren bestimmt werden (von den Fahrzeugen 24, 24', 24", 24''' usw.): Technologiedaten, Durchlaufgeschwindigkeitsdaten, Signalstärkedaten, Signalqualitätsdaten, Zeitstempeldaten und Positionsdaten. Bei dieser Ermittlung können verschiedene Datentypen stärker als andere gewichtet werden. Wie nachstehend erläutert, kann, wenn eine durch das Modell erzeugte QoS-Kennzahl einen vorbestimmten QoS-Schwellenwert überschreitet (der auch vom Backend-System 16 festgelegt werden kann), diese bestimmte geografische Region für eine OTA-Datenübertragung als wünschenswert identifiziert werden.

Das vorstehend beschriebene Modell kann entwickelt werden, um verschiedene Tageszeiten, Wochen-, Monats- oder Jahrestage, Feiertage usw. zu berücksichtigen. Des Weiteren können die Modellierungsdaten mit lokalen Wettermustern, lokalen Ereignissen und dergleichen korreliert werden. Somit kann das geografische Modell ein sogenanntes ‚lebendes‘ Modell sein; d. h. es kann laufend aktualisiert und somit permanent weiterentwickelt und verbessert werden. Daher sollte beachtet werden, dass Schritt 205 zwar als ein erster Schritt dargestellt ist, Schritt 205 jedoch während des gesamten Verfahrens 200 fortlaufend durchgeführt werden kann.

Sobald mindestens einige WCS-zugeordnete Daten in Schritt 205 gesammelt wurden, kann das Backend-System 16 in Schritt 210 die aktuellen WCS-Parameter, eine QoS-Kennzahl usw. bestimmen und basierend auf den aktuellen WCS-Parametern, der QoS-Kennzahl usw. kann das Backend-System mindestens eine bevorzugte geografische Kommunikationsregion bestimmen oder identifizieren, in welcher die OTA-Daten an das Zielfahrzeug 24 übertragen werden sollen. Wie vorstehend erläutert, können bevorzugte Regionen 60 diejenigen Regionen sein, die eine QoS-Kennzahl aufweisen, der einen vorgegebenen QoS-Schwellenwert erreicht oder überschreitet. In mindestens einer Ausführungsvariante führt das Backend-System 16 eine Computermodellierungssoftware aus, die auf mindestens einem Computerserver 18 gespeichert ist, um automatisch eine Vielzahl von bevorzugten geografischen Kommunikationsregionen zu bestimmen. Es sollte beachtet werden, dass die Schritte 205 und 210 zumindest teilweise gleichzeitig und rekursiv erfolgen können—d. h. je mehr WCS-verknüpfte Daten vom Backend-System 16 gesammelt und analysiert werden, desto genauer (und aktueller) kann das Identifizieren von bevorzugten geografischen Kommunikationsregionen erfolgen.

3 veranschaulicht eine Karte 300 eines veranschaulichenden geografischen Bereichs mit einer Vielzahl von primären oder bevorzugten geografischen Kommunikationsregionen 60 (oder einfach bevorzugten Regionen). In einigen Fällen kann es sich bei den bevorzugten Regionen 60 um eine oder mehrere Zellen des drahtlosen Trägersystems 12 handeln; dies ist jedoch nicht erforderlich. So kann beispielsweise jede Region 60 durch die WCS-Parameter der jeweiligen Region definiert werden und jede geeignete andere Form oder Grenze aufweisen.

Wie im Folgenden näher erläutert, können auch andere geografische Kommunikationsregionen durch das Backend-System 16 bestimmt werden. So könnten beispielsweise eine oder mehrere sekundäre oder sekundär bevorzugte geografische Kommunikationsregionen 70 und eine oder mehrere tertiäre oder tertiär bevorzugte geografische Kommunikationsregionen 80 bestimmt werden (3). Gemäß einer Ausführungsform können die bevorzugten Regionen 60 zum Übertragen von OTA-Daten sehr gut geeignet sein, wobei die sekundären Regionen 70 mäßig oder ziemlich gut zum Übertragen von OTA-Daten geeignet sein können und die tertiären Regionen 80 zum Übertragen von OTA-Daten unzureichend oder noch weniger geeignet sein können. Selbstverständlich könnten auch andere kategorische Regionen durch das Backend-System 16 bestimmt werden. Die relative Größe der Regionen 60, 70, 80 kann variieren; deshalb sind die dargestellten Regionen lediglich Beispiele. Auf der Karte 300 ist das Zielfahrzeug 24 dargestellt, das sich durch eine sekundäre Region 70 bewegt - z. B. eine nach Westen gerichtete Richtung zu einer der bevorzugten Regionen 60.

Zurückkehrend zu 2 in Schritt 215, wählt oder bestimmt das Backend-System 16 auf andere Weise das Übertragen von Over-the-Air (OTA)-Daten an das jeweilige Zielfahrzeug 24. Wie vorstehend erläutert, kann das Backend-System 16 einen Fahrzeugdatensatz, der dem Zielfahrzeug 24 zugeordnet ist, auf dem Server 18 speichern, und das System 16 kann den Fahrzeugdatensatz analysieren und automatisch das Zielfahrzeug 24 basierend auf der Identifikation auswählen, dass das Fahrzeug 24 ein bestimmtes Fahrzeugsystem-Update für eines der fahrzeugseitigen VSMs 32 nicht erhalten (und/oder installiert) hat. Es ist zu beachten, dass das Backend-System 16 in Schritt 215 eine Liste oder Auflistung von Fahrzeugen erzeugen kann, die beispielsweise das Fahrzeug 24 beinhaltet—z. B. von denen jedes die jeweiligen OTA-Daten empfangen soll.

In Schritt 220 bestimmt das Backend-System 16 den Standort des Zielfahrzeugs 24. Dies kann auf unterschiedliche Weise bestimmt werden. Zum Zwecke der Veranschaulichung im Verfahren 200 stellt das Fahrzeug 24 dem Backend-System 16 Lat-Long-Daten bereit. Dies kann beispielsweise periodisch auftreten, während sich das Fahrzeug bewegt (z. B. über eine Zellverbindung oder eine SMS-Kommunikation).

In Schritt 225 bestimmt das Backend-System 16, ob sich das Zielfahrzeug 24 innerhalb eines der bevorzugten Bereiche 60 befindet. So kann beispielsweise das Backend-System 16 Lat-Long-Daten, die vom Fahrzeug 24 empfangen werden, mit einem oder mehreren der in Schritt 210 bestimmten bevorzugten Regionen 60 vergleichen, und falls die kürzlich empfangenen Lat-Long-Daten eine Position innerhalb einer bevorzugten Region 60 anzeigen, fährt das Verfahren mit Schritt 245 fort, wobei die verfügbare Bandbreite des Zielfahrzeugs 24 bestimmt oder überprüft werden kann (wie nachstehend genauer beschrieben). Wenn jedoch das Backend-System 16 bestimmt, dass sich das Zielfahrzeug 24 nicht innerhalb einer der bevorzugten Regionen 60—wie in 3 dargestellt—befindet, fährt das Verfahren mit Schritt 230 fort (z. B. Platzieren des Fahrzeugs 24 in einer Warteschlange oder Datenregistrierung).

In anderen Ausführungsformen von Schritt 225 kann das Backend-System 16 vorhersagen, dass sich das Zielfahrzeug 24 innerhalb einer bevorzugten Region 60 befindet, auch wenn die aktuellen Positionsdaten des Fahrzeugs 24 dem Backend-System 16 nicht bekannt oder verfügbar sind. So kann beispielsweise das Backend-System 16 basierend auf den letzten bekannten Lat-Long-Daten und/oder Kursdaten eine Vorhersage vornehmen. Die Kursdaten können aus sequentiell empfangenen LAT-Long-Daten oder anderen geeigneten positionsbezogenen Daten (z. B. Navigationsdaten, die eine Fahrtrichtung anzeigen usw.) bestimmt oder abgeleitet werden; das Ermitteln der Kursdaten ist im Allgemeinen bekannt und wird in diesem Zusammenhang nicht näher beschrieben.

In Schritt 230 wird das Zielfahrzeug 24 (oder genauer gesagt eine Kennung des Zielfahrzeugs 24) in der Datenregistrierung im Backend-System 16 gespeichert. Nicht einschränkende Beispiele für Kennungen beinhalten eine Fahrzeug-Identifikationsnummer (VIN) oder eine Telematikeinheitenkennung (z. B. eine Seriennummer, eine mobile Identifikationsnummer oder MIN oder eine Zugangspunktbezeichnung); andere Kennungen sind möglich.

Im folgenden Schritt 235 kann das Backend-System 16 bestimmen—z. B. berechnen oder schätzen—welche Standortinformationen dem Zielfahrzeug 24 zugeordnet sind. So kann sich beispielsweise das Zielfahrzeug 24 nicht mehr innerhalb der sekundären Region 70 befinden (wie in 3 dargestellt); vielmehr kann sich das Fahrzeug 24 nun beispielsweise in einer bevorzugten Region 60 (oder einer anderen sekundären Region 70 oder sogar einer tertiären Region 80) befinden. Diese Zielfahrzeug-Standortinformationen können auf ähnliche Weise bestimmt werden wie in Schritt 220 beschrieben.

In Schritt 240 kann das Backend-System 16 optional die Grenzen der geografischen Regionen 60, 70, 80 neu bestimmen. Es sollte beispielsweise beachtet werden, dass sich die Tageszeit auf die Bedingungen des Mobilfunknetzes auswirken kann—somit können sich z. B. die Grenzen der verschiedenen Regionen 60, 70, 80 im Tagesverlauf basierend auf der Nutzung der Benutzergeräte, HF-Störungen usw. ändern.

Nach dem Schritt 240 kann das Verfahren 200 eine Schleife zurücksetzen und den Schritt 225 wiederholen. Schritt 225 kann wie vorstehend beschrieben ausgeführt werden—z. B. durch Fortfahren mit Schritt 245 oder wenn sich das Zielfahrzeug 24 noch nicht innerhalb einer der bevorzugten Regionen 60 befindet, kann das Verfahren die Schritte 230, 235, 240 und/oder 225 wiederholen.

Wenn sich das Fahrzeug 24 innerhalb einer der bevorzugten Regionen 60 befindet, fährt das Verfahren 200 mit Schritt 245 fort. In Schritt 245 kann das Backend-System 16 bestimmen, ob eine verfügbare Bandbreite am jeweiligen Zielfahrzeug 24 einen vorgegebenen Schwellenwert überschreitet. So kann das Fahrzeug 24 beispielsweise periodisch einen verfügbaren Bandbreitenparameter an das Backend-System 16 übertragen. Oder das Backend-System 16 kann über eine bestehende Mobilfunkverbindung mit dem Zielfahrzeug 24 den Bandbreitenparameter bestimmen oder berechnen. Andere Möglichkeiten zum Ermitteln der verfügbaren Fahrzeugbandbreite werden ebenfalls in Betracht gezogen. Ferner muss der Bandbreitenparameter kein absoluter Wert sein; z. B. kann er ein Prozentsatz sein und/oder andere Faktoren berücksichtigen (z. B. Mobilfunktechnologie, Ausstattungsmerkmale usw.). Unabhängig davon kann das Backend-System nach dem Empfangen des verfügbaren Bandbreitenparameters am Backend-System 16 den Parameter mit dem vorgegebenen Schwellwert vergleichen. Wenn der Parameter für die verfügbare Bandbreite am Zielfahrzeug 24 den Schwellenwert überschreitet, kann das Verfahren 200 mit Schritt 250 fortfahren. Ist dies nicht der Fall, kann das Verfahren 200 eine Schleife zurücksetzen und den Schritt 225 (und die nachfolgenden Schritte) wiederholen. In mindestens einer Ausführungsform wird keine Bandbreite als verfügbar erkannt, wenn das Fahrzeug 24 seine Bandbreite zwischen einer bestehenden Verbindung und den OTA-Daten aufspalten muss—z. B. wenn die OTA-Daten empfangen würden, während das Fahrzeug bereits in einer anderen Mobilfunkverbindung betrieben wird.

In mindestens einer Ausführungsform ist der Schritt 245 optional. Wenn beispielsweise das Zielfahrzeug 24 in Schritt 225 bestimmt wird, dass es sich innerhalb einer bevorzugten Region 60 befindet, kann das Verfahren 200 direkt zu Schritt 250 übergehen.

In Schritt 250 überträgt das Backend-System 16 Over-the-Air (OTA)-Daten an das Zielfahrzeug 24. Weiter mit dem vorstehenden Beispiel überträgt das Backend-System 16 ein Fahrzeugsystem-Update an das Zielfahrzeug 24. Danach endet das Verfahren 200. Es sollte beachtet werden, dass jedes vom Zielfahrzeug 24 empfangene Fahrzeugsystem-Update zu jeder geeigneten Zeit installiert werden kann (z. B. wenn der Benutzer und/oder das Fahrzeug 24 bestimmt, dass die Installation sicher durchgeführt werden kann). In mindestens einer Ausführungsform wird das Fahrzeugsystem-Update bis zu einem späteren Zeitpunkt am Fahrzeug 24 gespeichert. Die Installation von Fahrzeugsystem-Updates ist im Allgemeinen bekannt und wird nachfolgend nicht näher erläutert.

Es sind auch andere Ausführungsformen vorhanden. So kann beispielsweise in mindestens einer Ausführungsform die Art der OTA-Daten (z. B. deren Inhalt) den Zeitpunkt zum Übertragen der OTA-Daten beeinflussen. Wenn beispielsweise die Nutzlastgröße der OTA ausreichend klein ist, kann das Backend-System 16 die OTA-Daten übertragen, wenn sich das Fahrzeug innerhalb einer sekundären Region 70 befindet. Oder wenn beispielsweise der Gegenstand der OTA-Daten dringend ist (z. B. mit einer hohen Priorität), können die OTA-Daten auch dann übertragen werden, wenn der verfügbare Bandbreitenparameter kleiner als der vorgegebene Schwellenwert ist. Ferner können einige OTA-Daten in bevorzugten Regionen 60 und sekundären Regionen 70, nicht aber in tertiären Regionen 80 übertragen werden. Und auch dies kann abhängig vom Inhalt, der Priorität usw. sein.

In einer anderen Ausführungsform kann das Backend-System 16 wünschen, dass gemeinsame OTA-Daten (z. B. dasselbe Fahrzeugsystem-Update oder dieselbe Benachrichtigung) in eine vorgegebene Liste von Zielfahrzeugen übertragen werden, die im Allgemeinen in unmittelbarer Nähe zueinander liegen. So kann sich beispielsweise eine Anzahl an Zielfahrzeugen gleichzeitig in derselben bevorzugten Region 60 befinden (oder es kann vorausgesagt werden, dass sie sich gleichzeitig in derselben bevorzugten Region 60 befinden), und das Backend-System 16 kann die gemeinsamen OTA-Daten an diese speziellen Zielfahrzeuge übertragen. Ähnlich könnte das Backend-System 16 verschiedene OTA-Daten an eine Auflistung von Zielfahrzeugen übertragen, die sich innerhalb eines begrenzten Zeitraums in derselben geografischen Region befinden. In noch einer weiteren Ausführungsform kann das Backend-System 16 keine OTA-Daten an mehrere benachbarte Zielfahrzeuge übertragen, wenn dies eine Schwellenmenge an gleichzeitigen Verbindungen in einem bestimmten Mobilfunkturm überschreiten würde. In allen Fällen kann die Rechenleistung des Backend-Systems erhöht werden, sodass eine größere Anzahl an Zielfahrzeugen bedient werden kann.

In einer weiteren Ausführungsform können einzelne QoS-Kriterien verwendet werden, um das Übertragen von OTA-Daten zu verzögern. So können beispielsweise unabhängig von der QoS-Kennzahl keine OTA-Daten übertragen werden, wenn die Signalstärke geringer als ein vorgegebener niedriger Schwellwert ist.

In einer weiteren Ausführungsform kann das Ermitteln der bevorzugten Regionen am Zielfahrzeug 24 vorgenommen werden. So könnte beispielsweise das Fahrzeug 24 WCS-zugeordnete Daten, die der aktuellen geografischen Region vom Backend-System 16 zugeordnet sind (oder auch vom drahtlosen Trägersystem oder einem Mobilfunkanbieter) empfangen werden, bestimmt werden, wann es eine verfügbare Bandbreite zur Verfügung hatte, und wenn das Fahrzeug 24 eine verfügbare Bandbreite aufweist und bestimmt, dass es sich innerhalb einer bevorzugten Region 60 befindet, könnte es vom Backend-System ein Übertragen von OTA-Daten anfordern. Andere geeignete Implementierungen sind ebenfalls möglich.

Somit wurde ein Verfahren zum Bereitstellen von Over-the-Air-Daten aus einem Fahrzeug-Backend-System an ein oder mehrere Zielfahrzeuge beschrieben. Das Verfahren beinhaltet das Ermitteln der Parameter des drahtlosen Trägersystems im Backend-System basierend auf Daten, die aus den mit dem Backend-System verbundenen Teilnehmerfahrzeugen gesammelt wurden. Ferner beinhaltet das Verfahren das Ermitteln bevorzugter geografischer Regionen basierend auf diesen Parametern. Wenn sich das/die Zielfahrzeug(e) dann in der/den bevorzugten Region(en) befinden, sendet das Backend-System die gewünschten Over-the-Air-Daten an die Zielfahrzeuge. Die bevorzugten geografischen Regionen können diejenigen sein, die einen weiterentwickelten Mobilfunktechnologie-Typ aufweisen, diejenigen, die einen höheren Datendurchsatz bereitstellen, diejenigen, die eine höhere Signalqualität bereitstellen, und/oder diejenigen, die eine höhere Signalstärke bereitstellen. In mindestens einer Implementierung werden die bevorzugten Regionen im Backend-System basierend auf jedem dieser Kriterien bestimmt. Das Verfahren kann ferner das Ermitteln beinhalten, ob das/die Zielfahrzeug(e) bereit sind, die Over-the-Air-Daten zu empfangen, wobei zunächst bestimmt wird, ob das Empfangen der Over-the-Air-Daten eine aktuelle drahtlose Kommunikation oder Verbindung am Zielfahrzeug beeinträchtigt. Wenn die drahtlose Kommunikation am Zielfahrzeug durch das Senden der Over-the-Air-Daten negativ beeinflusst wird, kann das Backend-System die Lieferung der Daten verzögern. Letztlich minimiert das Verfahren die Überlastung des Mobilfunknetzes und verbessert auch die Benutzererfahrung in den Zielfahrzeugen.

Es versteht sich, dass das Vorstehende eine Beschreibung einer oder mehrerer Ausführungsformen der Erfindung ist. Die Erfindung ist nicht auf die besondere(n) hierin offenbarte(n) Ausführungsform(en) beschränkt, sondern ausschließlich durch die folgenden Patentansprüche definiert. Darüber hinaus beziehen sich die in der vorstehenden Beschreibung gemachten Aussagen auf bestimmte Ausführungsformen und sind nicht als Einschränkungen des Umfangs der Erfindung oder der Definition der in den Patentansprüchen verwendeten Begriffe zu verstehen, außer dort, wo ein Begriff oder Ausdruck ausdrücklich vorstehend definiert wurde. Verschiedene andere Ausführungsformen und verschiedene Änderungen und Modifikationen an der/den ausgewiesenen Ausführungsform(en) sind für Fachleute offensichtlich. Alle diese anderen Ausführungsformen, Änderungen und Modifikationen sollten im Geltungsbereich der angehängten Patentansprüche verstanden werden.

Wie in dieser Beschreibung und den Ansprüchen verwendet, sind die Begriffe „zum Beispiel“, „beispielsweise“, „z. B.“, „wie“ und „gleich“ und die Verben „umfassen“, „aufweisen“, „beinhalten“ und ihre anderen Verbformen, wenn sie in Verbindung mit einer Auflistung einer oder mehrerer Komponenten oder anderen Gegenständen verwendet werden, jeweils als offen auszulegen, was bedeutet, dass die Auflistung nicht so berücksichtigt wird, als dass sie andere, zusätzliche Komponenten oder Elemente ausschließt. Andere Begriffe sind in deren weitesten vernünftigen Sinn auszulegen, es sei denn, diese werden in einem Kontext verwendet, der eine andere Auslegung erfordert.