DE102017124723B4

DE102017124723B4 - Verfahren zum Bereitstellen eines Fahrzeugdienstes sowie Fahrzeug-Backend-System zur Ausführung des Verfahrens

Info

Publication number: DE102017124723B4
Application number: DE102017124723.8A
Authority: DE
Inventors: Esteban Camacho; Alexander X. Cermak; Matthew R. Waldner; Ryan Olejniczak
Original assignee: GM Global Technology Operations LLC; General Motors LLC
Current assignee: GM Global Technology Operations LLC; General Motors LLC
Priority date: 2016-10-24
Filing date: 2017-10-23
Publication date: 2024-01-18
Anticipated expiration: 2037-10-24
Also published as: US20180116002A1; DE102017124723A1; CN108377568B; US10492234B2; CN108377568A

Abstract

Verfahren zum Bereitstellen eines Fahrzeugdienstes, umfassend die folgenden Schritte:Ermitteln am Backend-System, dass dem Fahrzeug ein Fahrzeugdienst bereitzustellen ist;basierend auf dem Ermitteln, Übertragen einer Abfrage vom Backend-System an einen Mobilfunkanbieter (WSP) oder einen WSP-Server, die dem Verbindungsstatus des Fahrzeugs zu einem von dem WSP verwendeten drahtlosen Trägersystem (WCS) zugeordnet ist;in Reaktion auf das Übertragen der Abfrage, Empfangen einer Antwort auf die Abfrage am Backend-System, wobei die Antwort in Bezug auf das WCS anzeigt, dass sich das Fahrzeug entweder in einem verbundenen Zustand oder in einem nicht verbundenen Zustand befindet; undwenn sich das Fahrzeug in dem verbundenen Zustand befindet:versuchen, die Mobilfunkverbindung zwischen dem Backend-System und dem Fahrzeug herzustellen, indem ein Mobilfunkanruf zwischen dem Backend-System und dem Fahrzeug getätigt wird; undwenn die Mobilfunkverbindung hergestellt ist, Bereitstellen des Fahrzeugdienstes über den Mobilfunkanruf in Reaktion auf die hergestellte Mobilfunkverbindung.

Description

TECHNISCHES GEBIET
Die vorliegende Erfindung bezieht sich auf ein Verfahren zum Bereitstellen eines Fahrzeugdienstes, wobei ermittelt wird, ob ein Mobilfunkanruf an ein Fahrzeug von einem Fahrzeug-Backend-System aus getätigt werden soll und insbesondere ob das Fahrzeug mit einem drahtlosen Trägersystem verbunden ist, bevor der Mobilfunkanruf getätigt wird.
HINTERGRUND
Backend-Einheiten oder Back-Offices sind vorhanden, um Fahrzeugen verschiedene Dienstleistungen, wie beispielsweise Wegbeschreibungen, Straßenverkehr usw., bereitzustellen. In einigen Fällen versucht das Back-Office, ein Fahrzeug zu kontaktieren und ist damit erfolglos. In einigen Fällen liegt dies daran, dass das Fahrzeug schlichtweg nicht mit einem hauseigenen oder einem Mobilfunknetz verbunden ist. Das Fahrzeug ist beispielsweise aufgrund seines Standorts oder dergleichen außer Reichweite. Das Back-Office kann oft wiederholte erfolglose Versuche unternehmen, das Fahrzeug zu kontaktieren, und diese wiederholten und erfolglosen Versuche können eine Verschwendung von Computerressourcen sein. Zusätzlich fügen derartige wiederholten Versuche Netzwerkverkehr hinzu und begünstigen die Überlastung des Mobilfunknetzes. Eine derartige Back-Office-Kommunikation geht der Art nach beispielsweise aus der DE 10 2014 200 226 A1 hervor. Weitergehender Stand der Technik ergibt sich ferner aus der US 2014 / 0 324 972 A1 .
Das vorstehend beschriebene Problem wird noch verschärft, da das Back-Office nicht dazu dient, ein einzelnes Fahrzeug zu bedienen, sondern vielmehr unzählige Fahrzeuge. Und zu einem bestimmten Zeitpunkt, können viele dieser Fahrzeuge möglicherweise nicht mit einem Mobilfunknetz verbunden sein, wenn das Back-Office versucht, anrufen.
Somit besteht die Notwendigkeit, die Rechenleistung im Back-Office durch Minimieren erfolgloser Anrufversuche zu verbessern.
ZUSAMMENFASSUNG
Erfindungsgemäß wird ein Verfahren zum Bereitstellen eines Fahrzeugdienstes vorgestellt.. Das Verfahren beinhaltet die Schritte: das Ermitteln am Backend-System, ob ein Fahrzeugdienst für das Fahrzeug erbracht werden soll; basierend auf dem Ermitteln, Übertragen vom Backend-System an einen Mobilfunkanbieter (WSP) oder einen WSP-Server eine dem Verbindungsstatus des Fahrzeugs zugeordnete Abfrage an ein vom WSP verwendetes drahtloses Trägersystem (WCS); in Reaktion auf das Übertragen der Abfrage, das Empfangen einer Antwort auf die Abfrage an das Backend-System, wobei die Antwort in Bezug auf das WCS anzeigt, dass sich das Fahrzeug entweder in einem verbundenen Zustand oder in einem nicht verbundenen Zustand befindet; und wenn sich das Fahrzeug in einem verbundenen Zustand befindet: das Versuchen, die Mobilfunkverbindung zwischen dem Backend-System und dem Fahrzeug, durch tätigen eines Mobilfunkanrufs zwischen dem Backend-System und dem Fahrzeug herzustellen; und wenn die Mobilfunkverbindung hergestellt ist, das Bereitstellen des Fahrzeugdienstes über den Mobilfunkanruf in Reaktion auf die hergestellte Mobilfunkverbindung.
Ferner wird ein Fahrzeug-Backend-System vorgestellt, das konfiguriert ist, um einen Fahrzeugdienst bereitzustellen. Das System beinhaltet mindestens einen Prozessor und mindestens eine Speichervorrichtung, wobei die mindestens eine Speichervorrichtung Computerprogrammanweisungen speichert, die durch den mindestens einen Prozessor ausführbar sind. Die ComputerprogrammAnweisungen beinhalten: Anweisungen zum Aufrufen einer Anwendungs-Programmierschnittstelle (API) an einen Mobilfunkanbieter (WSP), an ein mit dem WSP verbundenes Heimatregister (HLR) oder an einen mit dem WSP verbundenen Heimteilnehmer-Server (HSS), wobei der API-Anruf eine Abfrage beinhaltet, die mit einem Verbindungsstatus des Fahrzeugs zu einem drahtlosen Trägersystem (WCS) verbunden ist, das vom WSP verwendet wird; Anweisungen zum Empfangen einer Antwort auf die Abfrage in Reaktion auf das Tätigen des API-Anrufs, wobei die Antwort auf die Abfrage in Bezug auf den WCS anzeigt, dass der Fahrzeugverbindungsstatus einer der verbundenen Zustände oder ein nicht verbundener Zustand ist; Anweisungen, um zu versuchen, die Mobilfunkverbindung zwischen dem Backend-System und dem Fahrzeug herzustellen, wenn der Verbindungsstatus des Fahrzeugs der verbundene Zustand ist; und Anweisungen zum Verzögern eines Versuchs, eine Mobilfunkverbindung zwischen dem Backend-System und dem Fahrzeug für einen vorbestimmten Zeitraum herzustellen, wenn der Fahrzeugverbindungsstatus der nicht verbundene Zustand ist, und nach Ablauf des vorbestimmten Zeitraums Anweisungen zum Einleiten eines weiteren API-Anrufs und Anweisungen zum Wiederholen der Anweisungen, die mit dem Empfangen der Antwort auf die Abfrage verbunden sind, in Reaktion auf das Erstellen eines weiteren API-Anrufs.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Eine oder mehrere Ausführungsformen der Erfindung werden im Folgenden in Verbindung mit den beigefügten Zeichnungen beschrieben, wobei gleiche Bezeichnungen gleiche Elemente bezeichnen, und wobei:

1 ein Blockdiagramm ist, das eine Ausführungsform eines Kommunikationssystems darstellt, das fähig ist, das hierin offenbarte Verfahren zu verwenden; und
2 ein Flussdiagramm eines Verfahrens zum Vorqualifizieren zum Herstellen einer Mobilfunkverbindung zwischen einem Fahrzeug-Backendsystem und einem Fahrzeug ist, bevor das Backend-System versucht, die Mobilfunkverbindung herzustellen.

AUSFÜHRLICHE BESCHREIBUNG DER VERANSCHAULICHTEN AUSFÜHRUNGSFORM(EN)
Im Folgenden wird ein Fahrzeug-Backend-System beschrieben, das konfiguriert ist, um die Verfügbarkeit einer Mobilfunkverbindung zwischen diesem und dem Fahrzeug zu ermitteln. So kann beispielsweise das Backend-System konfiguriert sein, um zu ermitteln, ob ein bestimmtes Fahrzeug mit einem drahtlosen Trägersystem verbunden ist, bevor das Backend-System versucht, eine Mobilfunkverbindung herzustellen. Insbesondere kann das Backend-System die Verfügbarkeit durch Kommunizieren mit einem Mobilfunkanbieter (WSP) oder einem mit dem WSP verbundenen Clearinghouse-Server, wie beispielsweise einem Heimatregister (HLR) oder einem Heimteilnehmer-Server (HSS), ermitteln. Wie weiter unten beschrieben, können beispielsweise das WSP, das HLR oder das HSS bei einer Abfrage Informationen über den Verbindungsstatus des jeweiligen Fahrzeugs bereitstellen. Basierend auf diesen Informationen kann das Backend-System ermitteln, ob zu diesem Zeitpunkt ein Mobilfunkanruf an das jeweilige Fahrzeug erfolgen soll-oder ob der Mobilfunkanruf zu einem späteren Zeitpunkt erfolgen soll. Auf diese Weise kann das Backend-System den Aufbau einer Mobilfunkverbindung zwischen diesem und dem jeweiligen Fahrzeug vorqualifizieren- und somit weniger erfolglose Anrufe tätigen.
Darüber hinaus können die hierin beschriebenen Verfahren für eine beliebige Anzahl von Fahrzeugen, die vom Backend-System bedient werden, implementiert werden-wodurch die Rechenleistung des Backend-Systems verbessert wird. Das System und seine Implementierung werden im Folgenden näher erläutert.
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 Festnetz 14; ein Fahrzeug-Backend-System 16, das mindestens einen von einem Remote-Server 18, ein Daten-Service-Center 20 oder beides beinhaltet; einen Mobilfunkanbieter (WSP) 22; einen Clearinghaus- oder WSP-Server 23, der als Heimatregister (HLR) oder als Heimteilnehmer-Server (HSS) verkörpert ist; und ein oder mehrere Fahrzeuge 24, 24', 24'', 24'''. Es versteht sich, dass das offenbarte Verfahren mit einer beliebigen Anzahl von 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, mobile Vermittlungszentralen, Basisstationssteuerungen, entwickelte Knoten (z. B. eNodeBs), Mobilitätsmanagement-Einheiten (MMEs), Servier- und PGN-Gateways usw. sowie alle anderen Netzwerkkomponenten, die erforderlich sind, um das drahtlose Trägersystem 12 mit dem Festnetz 14 zu verbinden oder das drahtlose Trägersystem mit einer Benutzerausrüstung (UEs, z. B. welche die Fahrzeugen 24, 24', 24'', 24''' beinhalten) zu verbinden. Das Mobilsystem 12 kann jede geeignete Kommunikationstechnologie implementieren, einschließlich beispielsweise analoger Technologien, wie AMPS, oder der neueren digitalen Technologien, wie beispielsweise CDMA (beispielsweise CDMA2000), GSM/GPRS oder LTE verwenden. Im Allgemeinen sind drahtlose Trägersysteme 12, deren Komponenten, die Anordnung ihrer Komponenten, das Zusammenwirken der Komponenten usw. weitgehend im dem Stand 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 und darüber hinaus das Trägersystem 12 mit dem WSP 22 und dem WSP-Server 23 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, das WSP 22 oder der WSP-Server 23 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-in einigen Implementierungen kann das Service-Center 20 eine oder mehrere private Verbindungen zwischen ihm und lokalen Remote-Servern 18 verwalten. Wie nachfolgend beschrieben, können das Service-Center 20 und die Server 18 so angeordnet sein, dass eine Anzahl von 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 kann der Remote-Server 18 einer aus einer Anzahl von 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. Andere derartige zugängliche Computer 18 können beispielsweise sein: ein Kundendienstzentrumcomputer, wobei Diagnoseinformationen und andere Fahrzeugdaten von den Fahrzeugen 24, 24', 24'', 24''' hochgeladen werden können; ein Clientcomputer, der von dem Fahrzeugbesitzer oder einem anderen Teilnehmer für solche Zwecke wie das Zugreifen auf oder Empfangen von Fahrzeugdaten oder zum Einstellen oder Konfigurieren von Teilnehmerpräferenzen oder Steuern von Fahrzeugfunktionen verwendet wird; oder ein Drittparteispeicherstandort, zu dem oder von dem Fahrzeugdaten oder andere Informationen bereitgestellt werden, entweder durch Kommunizieren mit den Fahrzeugen 24, 24', 24'', 24''' oder dem Datenservice-Center 20 oder beiden. Der Remote-Server 18 kann 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, einschließlich Mikroprozessoren, Mikrocontroller, Host-Prozessoren, Steuerungen, Server-zu-Server-Kommunikationsprozessoren und anwendungsspezifische integrierte Schaltungen (ASICs). 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 der Prozessor 52 eine Anzahl von Anweisungen ausführen oder verarbeiten, die auf dem Speicher 54 gespeichert sind, um die Konnektivität eines Fahrzeugs mit dem drahtlosen Trägersystem 12 vorzubereiten, einschließlich eines oder mehrerer der Folgenden: (1) mit einer oder mehreren der folgenden Angaben: Identifizieren einer Liste oder Auflistung von Fahrzeugen (z. B. der Fahrzeuge 24, 24', 24'', 24''' usw.), die Teilnehmerbeziehungen zum Backend-System 16 aufweisen; (2) Beschaffen oder Abfragen in einer Datenbank oder einem Speicher 54 einer eindeutigen Kennung für jedes der in der Liste aufgeführten Fahrzeuge 24, 24', 24'', 24''' usw.; (3) Tätigen eines Anwendungs-Programmierschnittstellen (API-)Anrufs an das WSP 22 oder den WSP-Server 23, wobei der Anruf eine Abfrage beinhaltet, ob jede der in der Liste aufgeführten Fahrzeuge 24, 24', 24'', 24''' usw. gegenwärtig mit dem drahtlosen Trägersystem 12 verbunden ist;. (4) Empfangen einer Antwort auf die Abfrage mit Angabe, ob jedes der Fahrzeuge 24, 24', 24'', 24''' usw. gegenwärtig mit dem oder an das Mobilfunknetz angeschlossen sind; (5) für jedes Fahrzeug 24, 24', 24'', 24''' usw., das mit dem Mobilfunknetz registriert oder daran angeschlossen ist, versuchen einen Mobilfunkanruf über das WCS 12 zu den jeweiligen Fahrzeugen zu tätigen; und (6) für jedes Fahrzeug 24, 24', 24'', 24''' usw., das nicht mit dem Mobilfunknetz registriert ist oder nicht an diesem angeschlossen ist, zu einem späteren Zeitpunkt das WSP 22 oder den WSP-Server 23 erneut in Anspruch nehmend, um einen Mobilfunkanruf darauf vorzuqualifizieren. Die Anweisungen können Pausieren, Warten oder Hinzufügen einer Verzögerung mit einer vorgegebenen Zeitdauer vor der jeweiligen erneuten Abfrage beinhalten.
Wie hierin verwendet, bedeutet das Vorqualifizieren einer Verbindung das Ermitteln der Verfügbarkeit einer drahtlosen Kommunikationsverbindung zwischen einem drahtlosen Trägersystem und einem Fahrzeug, bevor versucht wird, eine Verbindung mit dem Fahrzeug von einem Backend-System über das drahtlose Trägersystem herzustellen. So beinhaltet beispielsweise das Vorqualifizieren einer Mobilfunkverbindung zwischen dem Fahrzeug-Backend-System 16 (z. B. dem Server 18 und/oder dem Service-Center 20) und einem der Fahrzeuge 24, 24', 24'', 24''' eine oder mehrere vorläufige Beurteilungen im Vorfeld oder vorab, ob tatsächlich Mobilfunkanrufe zu jedem der Fahrzeuge 24, 24', 24'', 24''' getätigt werden.
Selbstverständlich können die Prozessoren 52 auch andere Anweisungen ausführen, die auf dem Speicher 54 gespeichert sind. Daher sollte beachtet werden, dass der Prozessor 52 mindestens einen Teil des hierin beschriebenen Verfahrens ausführen können, wie im Folgenden näher erläutert wird.
Der Speicher 54 des Servers 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, um das Fahrzeug 24 mit einer Anzahl von 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 Kontoinformationen, wie beispielsweise Teilnehmerauthentisierungsinformationen, Fahrzeugbezeichner, Profilaufzeichnungen, Verhaltensmuster und andere entsprechende Teilnehmerinformationen speichern. Datenübertragungen können zudem durch drahtlose Systeme, wie z. B. 802.1 1x, GPRS und dergleichen, erfolgen. 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 automatisierter Fahrzeugdienste über das Daten-Service-Center 20 bereitgestellt werden, z. B. wobei das Daten-Service-Center 20 mit den Fahrzeugen 24, 24', 24'', 24'' usw. ohne Eingreifen von Fahrern oder Benutzern der jeweiligen Fahrzeuge kommuniziert.
Der Mobilfunkanbieter (WSP) 22 (a.k.a., Mobilfunk-Dienstanbieter oder Mobilfunknetzbetreiber (MNO)) beinhaltet alle Unternehmen, die das drahtlose Trägersystem (WCS) 12 verwenden, um Mobilfunkdienste für Mobilfunkgeräte bereitzustellen, einschließlich des Bereitstellens von Mobilfunkdiensten für Mobilfunkgeräte und fahrzeugseitigen Telematikausrüstungen innerhalb der Fahrzeuge 24, 24', 24'', 24'''. Somit können WSPs 22 einen oder mehrere vernetzte Computer umfassen und über jede geeignete Verbindung mit dem Festnetz 14 verbunden sein; ferner steuern sie üblicherweise verschiedene drahtlose Hard- und Softwaresysteme, um Mobilfunkdienste an Endverbraucher zu verkaufen und/oder zu liefern, wie beispielsweise die Fahrzeuge 24, 24', 24'', 24''', wie sie in der Technik gewürdigt werden. In mindestens einer Ausführungsform kann das Backend-System 16 eine Beziehung zu mindestens einem WSP aufweisen-z. B. dadurch, dass die Fahrzeuge 24, 24', 24'', 24''', die ein Teilnehmerdienstleistungsverhältnis mit dem Backend-System 16 unterhalten, folglich eine Teilnehmerdienstbeziehung zu einem bestimmten WSP 22 aufweisen.
Die WSPs 22 verwalten oder unterstützen typischerweise WSP-Server 23, die an das Kernnetz des drahtlosen Trägersystems 12 angeschlossen sind-z. B. an eine mobile Vermittlungszentrale (MSC), an eine Mobilitätsmanagement-Einheit (MME) oder dergleichen. Wie vorstehend erläutert, beinhalten nicht einschränkende Beispiele für den WSP 23 ein Heimatregister (HLR), das dem WSP 22 zugeordnet ist, oder einen Heimteilnehmer-Server (HSS), der dem WSP 22 zugeordnet ist. Die HLR/HSS kann Informationen darüber speichern, ob die Benutzerausrüstung (UE) am Trägersystem 12 registriert oder daran angeschlossen ist (oder insbesondere an einer bestimmten Zelle innerhalb des Systems 12). Die HLRs und HSSs und deren Funktionen sind im Allgemeinen bekannt und werden in diesem Zusammenhang nicht näher erläutert.
1 veranschaulicht mehrere Fahrzeuge 24, 24', 24'', 24''' und jedes Fahrzeug kann ein Teilnehmerverhältnis 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. 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 Nahbereichskommunikations- 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 von unterschiedlichen Diensten anzubieten, 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 so angepasst werden, um Daten von Konfigurationsänderungen des Kommunikationssystems 30 sowie Fahrzeugsystem-Updates (z. B. Software- oder Anleitungs-Updates), die einem oder mehreren Fahrzeugsystemmodulen 32 zugeordnet sind, zu empfangen. So kann beispielsweise die Telematikeinheit die Updates und/oder Konfigurationsänderungen vom Backend-System 16 über eine so genannte zellulare OTA- oder „Over-the-Air“-Kommunikation empfangen. Das Empfangen von OTA-Daten oder -Nachrichten - bis hin zur Installation der Fahrzeugsystem-Updates und Konfigurationsänderungen - 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 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.
Nachfolgend werden eine oder mehrere Verfahren zur Verwendung des Kommunikationssystems 10 beschrieben. Insbesondere wird mindestens eine Ausführungsform eines Verfahrens zum Vorqualifizieren der Herstellung einer Mobilfunkverbindung zwischen einem Fahrzeug-Backendsystem 16 und einem Fahrzeug 24 beschrieben, bevor das Backend-System versucht, eine derartige Mobilfunkverbindung herzustellen (oder tatsächlich herstellt). Das/die nachfolgend beschriebene (n) Verfahren kann/können auf eine Anzahl von Fahrzeugen 24, 24', 24'', 24''' usw. einzeln oder zumindest teilweise gleichzeitig angewandt werden, wie aus der nachfolgenden Beschreibung ersichtlich wird.
Verfahren -
Wie im Flussdiagramm von 2 dargestellt, ist ein derartiges Verfahren 200 zum Ermitteln der Verfügbarkeit einer Mobilfunkverbindung zwischen einem Fahrzeug-Backend-System und einem Fahrzeug, bevor das Backend-System versucht, die Mobilfunkverbindung herzustellen. Insbesondere wird das Verfahren in Bezug auf ein einzelnes Fahrzeug 24 beschrieben, das eine Teilnehmerbeziehung mit dem Backend-System 16 aufweist; jedoch ist, wie nachstehend beschrieben, davon auszugehen, dass das Verfahren unter Verwendung eines so genannten „Batch-Jobs“ durchgeführt werden kann, wobei das Backend-System 16 eine Anzahl von Fahrzeugen 24, 24', 24'', 24''' zumindest teilweise gleichzeitig vorqualifiziert.
Das Verfahren kann mit Schritt 205 beginnen, wobei das Backend-System 16 identifiziert oder bestimmt, ob ein Fahrzeugdienst über eine Mobilfunkverbindung mit dem Fahrzeug 24 bereitzustellen ist. Gemäß einer Implementierung kann das Backend-System 16 mithilfe eines auf dem Server 18 gespeicherten Fahrzeugdatensatzes automatisch ermitteln, ob das Fahrzeug 24 ein bestimmtes Fahrzeugsystem-Update empfangen sollte. (Im Allgemeinen werden die hierin beschriebenen vorqualifizierten Schritte des Verfahrens 200 im Zusammenhang mit dem Bereitstellen eines Fahrzeugsystem-Updates beschrieben; es sollte jedoch beachtet werden, dass das Backend-System 16 möglicherweise wünscht, weitere Daten an das Fahrzeug 24 zu kommunizieren-z. B. anstelle des Updates).
In Schritt 210 kann das Backend-System (z. B. der Server 18) eine eindeutige Kennung für das zugeordnete Fahrzeug 24 ermitteln oder auf andere Weise beziehen kann; diese Kennung kann auch im Server 18 gespeichert werden-z. B. im Fahrzeugdatensatz, nicht einschränkende Beispiele für die Kennung beinhalten: eine Mobilverzeichnisnummer (MDN), eine internationale Mobilfunkteilnehmer-Identität (IMSI) und eine Geräte-ID, die eine mobile Gerätekennung (MEID), eine internationale mobile Stationsausrüstungsidentität (IMEI) oder eine elektronische Seriennummer (ESN), um nur einige Beispiele zu nennen. Andere Kennungen sind ebenfalls möglich. In mindestens einer Ausführungsform bestimmt der Backend-Server 18 eine MDN - z. B. eine so genannte „Telefonnummer“. Die Schritte 205 und 210 können in beliebiger Reihenfolge oder gleichzeitig erfolgen.
Im folgenden Schritt 215 kann das Backend-System 16 eine Abfrage an mindestens eines der WSP 22 oder den WSP-Server 23 senden. Die Abfrage kann die Fahrzeugkennung beinhalten-z. B. in der vorliegenden Ausführungsform eine Telefonnummer, die einer Telematikeinheit des Fahrzeugs 24 zugeordnet ist-und kann Daten zu einem Verbindungsstatus des Fahrzeugs 24 abfragen. Wie hierin verwendet, kann der Verbindungsstatus für jedes Fahrzeug einer der verbundenen Zustände oder ein nicht verbundener Zustand sein, wobei der verbundene Zustand anzeigt, dass das Fahrzeug 24 mit einer Zelle im drahtlosen Trägersystem (WCS) 12 registriert oder daran befestigt ist, wobei der nicht verbundene Zustand anzeigt, dass das Fahrzeug 24 gegenwärtig nicht mit einer Zelle im WCS 12 registriert oder gegenwärtig nicht verbunden ist.
In mindestens einer Ausführungsform sendet oder überträgt das Backend-System 16 diese Abfrage über eine Kommunikationsverbindung des Festnetzes 14 - z. B. über das Internet; dies ist jedoch nicht erforderlich. So werden beispielsweise andere Kommunikationsverbindungen in Betracht gezogen, die drahtgebunden, drahtlos oder eine Kombination daraus sind. In mindestens einer Ausführungsform tätigt das Backend-System 16 einen Programmierschnittstellen (API)-Anruf, der die Abfrage an das WSP 22 (oder den WSP-Server 23) beinhaltet. Ferner beinhaltet die Abfrage die eindeutige Kennung von Schritt 210 (oder auch mehrere Kennungen) - die vom WSP-Server 23 dazu verwendet werden kann, das jeweilige Fahrzeug 24 zu identifizieren. n einigen Ausführungsformen kann das Backend-System 16 den Anruf automatisch tätigen, und das Backend-System 16 kann auch automatisch eine Antwort empfangen - z. B. eine automatische Antwort oder eine so genannte „Auto-Antwort“.
Im folgenden Schritt 220 kann das Backend-System die vom WSP 22 oder vom WSP-Server 23 empfangene Auto-Antwort interpretieren. Und der Inhalt der Antwort kann zum Beispiel einen Hinweis auf den Verbindungsstatus des Fahrzeugs 24 beinhalten. Insbesondere kann der Verbindungsstatus anzeigen, ob sich das Fahrzeug 24 in einem verbundenen oder nicht verbundenen Zustand befindet. Wenn sich das Fahrzeug in einem verbundenen Zustand befindet, fährt das Verfahren mit Schritt 240 fort, wobei ein Mobilfunkanruf an das Fahrzeug 24 getätigt wird; wenn sich das Fahrzeug 24 jedoch in einem nicht verbundenen Zustand befindet, fährt das Verfahren mit Schritt 225 fort (wobei ein Mobilfunkanruf zumindest zum gegenwärtigen Zeitpunkt nicht getätigt wird).
Somit sollte beachtet werden, dass das Backend-System 16 durch Abfragen des WSP 22 oder des WSP-Servers 23 und Empfangen einer automatisierten Antwort ineffiziente Rechenleistungen im Zusammenhang mit Mobilfunkanrufen an Fahrzeug 24 vermeiden kann, wenn sich das Fahrzeug in einem nicht verbundenen Zustand befindet. Des Weiteren kann zusätzlicher Mobilfunk-Datenverkehr minimiert werden, da das Backend-System die Mobilfunkverbindung über das Festnetz 14 vorqualifiziert hat.

In Schritt 225 kann die Fahrzeugkennung-z. B. die Telefonnummer der Fahrzeugtelematikeinheit 32-in einer Wiederholungstabelle im Speicher 54 (Server 18) gespeichert werden. Die Wiederholungstabelle beinhaltet Informationen zu Fahrzeugen, die sich in einem nicht verbundenen Zustand befinden (z. B. durch API-Anruf). Die Tabelle kann auch andere Informationen beinhalten, wie beispielsweise eine Fahrzeugsystem-Update-Kennung, eine Benachrichtigungskennung, einen Zeitstempel, der anzeigt, wann der API-Anruf getätigt wurde usw., um nur einige Beispiele zu nennen. Eine veranschaulichende Wiederholungstabelle ist nachfolgend dargestellt. Wie im Folgenden näher erläutert wird, können Daten aus der Tabelle verwendet werden, um einen oder mehrere zukünftige API-Anrufe zu tätigen. Während in Tabelle I eine Fahrzeugtelefonnummer als Kennung dargestellt ist, können selbstverständlich auch andere Kennungen verwendet werden. Tabelle I

	Fahrzeugbeschreibung	Zeitstempel	Empfangenes Update 001?	Empfangenes Update 002?	Empfangenes Update 003?	Zähler
24	(111) 111-1111	2016:08:06:08:30:44	JA	JA	NEIN	1
24'	(111) 111-1112	2016:08:06:08:30:44	JA	JA	NEIN	1
24''	(111) 111-1113	2016:08:06:08:30:44	JA	JA	NEIN	1
24'''	(111) 111-1114	2016:08:06:08:30:44	JA	JA	NEIN	1

In Schritt 230, der Schritt 225 folgt, kann der Backend-Server 18 eine Flagge oder einen Zähler verwenden, um anzuzeigen, wie API-Anrufe für das jeweilige Fahrzeug 24 getätigt wurden. In einigen Implementierungen kann die Zeitdauer zwischen API-Anrufen dem Zählerwert zugeordnet werden, wie nachfolgend erläutert. Somit kann der Zähler bei Weiterführung des vorliegenden Beispiels auf ‚1‘ hochgezählt werden und diese inkrementellen Daten können auch in der Wiederholungstabelle gespeichert werden. Es sollte beachtet werden, dass dieser Schritt optional ist. Somit kann das Verfahren in mindestens einer Ausführungsform Schritt 230 überspringen und direkt von Schritt 220 zu Schritt 235 übergehen.
Der folgende Schritt 235 kann ein Zeitpuffer oder eine Verzögerung sein. So kann beispielsweise in Schritt 235 ein vorgegebener Zeitraum vergehen, während dessen der Backend-Server 18 keine weitere Abfrage zum WSP 22 oder den WSP-Server 23 sendet-und das Backend-System versucht nicht, einen Mobilfunkanruf an das Fahrzeug 24 zu tätigen. Die Dauer des Zeitraums kann vom Zeitstempel in der Wiederholungstabelle aus gemessen werden und kann eine beliebige Dauer aufweisen. Wenn beispielsweise eine Priorität des Fahrzeugsystem-Updates weniger dringlich ist, kann die Dauer 24 Stunden betragen. Andere Beispiele sind ebenfalls möglich. Des Weiteren ist zu beachten, dass der Backend-Server 18 während des Schrittes 235 API-Anrufe an das WSP 22 oder den WSP-Server 23 in Bezug auf andere Fahrzeuge (z. B. in Bezug auf andere Fahrzeuge als das Fahrzeug 24) oder Mobilfunkanrufe in Fahrzeugen tätigen kann, die vorab zum Anschließen an das drahtlose Trägersystem 12 vorqualifiziert wurden. Schritt 235 endet, wenn der vorgegebene Zeitraum abläuft; danach schwenkt das Verfahren 200 zu Schritt 215 zurück.
Somit kann das Verfahren 200 mindestens die Schritte 215 und 220 wiederholen. So kann beispielsweise, während Schritt 215 wiederholt wird, ein zweiter API-Anruf in Bezug auf das Fahrzeug 24 erfolgen, und abhängig von der Auto-Antwort des WSP 22 oder des WSP-Servers 23 kann das Verfahren, wie vorstehend beschrieben, wieder zu Schritt 225 oder Schritt 240 übergehen. Wenn das Verfahren die Schritte 225, 230, 235, 215 und 220 erneut durchläuft, kann ein neuer Zeitstempel aufgezeichnet und der Zähler auf ,2' hochgezählt und die Wiederholungstabelle entsprechend aktualisiert werden.
In mindestens einer Ausführungsform ist die Dauer der vorbestimmten Zeitverzögerung in Schritt 235 dem Zählerstand zugeordnet. So kann beispielsweise die Dauer erhöht werden, wenn der Wert 2, 3, 4 ... beträgt. Oder für jede Wiederholung von Schritt 230 kann die Dauer erhöht werden. In einer Ausführungsform kann die Verzögerung konfiguriert sein, sodass API-Anrufe zu unterschiedlichen Tageszeiten usw. erfolgen. Dies sind nur Beispiele; es können auch andere Konfigurationen vorhanden sein.
Wenn in Schritt 220 die Antwort auf die Abfrage anzeigt, dass der Verbindungsstatus des Fahrzeugs 24 verbunden ist, dann versucht das Backend-System in Schritt 240, einen Mobilfunkanruf an das Fahrzeug 24 zu tätigen. Das Tätigen des Mobilfunkanrufs kann innerhalb relativ kurzer Zeit nach dem Ermitteln erfolgen, ob sich das Fahrzeug 24 in einem verbundenen Zustand befindet. Nicht einschränkende Beispiele für vordefinierte Zeiträume, in denen der Mobilfunkanruf an Fahrzeug 24 durchgeführt werden soll, beinhalten innerhalb von zehn Sekunden, innerhalb einer Minute, innerhalb von fünf Minuten usw. So sollte beispielsweise beachtet werden, dass sich der Verbindungsstatus des Fahrzeugs ändern kann, wenn (relativ gesehen) zu viel Zeit vergeht, wenn sich der Verbindungsstatus des Fahrzeugs ändert-z. B. könnte das Fahrzeug in eine Tiefgarage einfahren oder anderweitig die Verbindung mit dem drahtlosen Trägersystem 12 verlieren.
Schritt 240 kann auch das Herstellen einer Mobilfunkverbindung zwischen dem Fahrzeug-Backend-System 16 und dem Fahrzeug 24 beinhalten. Sobald die Mobilfunkverbindung hergestellt ist, kann das Backend-System das Fahrzeugsystem-Update (identifiziert in Schritt 205) an das Fahrzeug 24 liefern oder übertragen, sodass es zu gegebener Zeit installiert werden kann. Nach Schritt 240 kann das Verfahren 200 enden.
Das Backend-System 16 kann auch aus anderen Gründen das Herstellen einer Mobilfunkverbindung mit dem Fahrzeug 24 vorqualifizieren. So kann beispielsweise das Backend-System 16 eine Benachrichtigung an das Fahrzeug 24 übertragen-z. B. eine Push-Benachrichtigung, die eine Audio- oder Videodatei beinhaltet, eine Textbenachrichtigung in Bezug auf die Fahrzeugwartung usw. Auch hier handelt es sich wiederum lediglich um Beispiele; auch andere vom Backend-System 16 gewünschte Nachrichten oder Kommunikationen werden in Betracht gezogen.
2 wurde vorstehend in Bezug auf ein einzelnes Fahrzeug-Fahrzeug 24 beschrieben. Es ist jedoch zu beachten, dass das Backend-System 16 für zahlreiche Fahrzeuge ein ähnliches Verfahren durchführen kann. Zusammenfassend sind die Fahrzeuge 24, 24', 24'', 24''' veranschaulichend. In Schritt 205 kann der Backend-Server 18 identifizieren, dass für jedes dieser Fahrzeuge das Update 003 (Tabelle I) erforderlich ist. So kann das System 16 in Schritt 205 eine Liste oder Auflistung der Fahrzeuge erstellen, welche die Fahrzeuge 24, 24', 24'', 24''' beinhaltet.
Fortfahrend mit dem Beispiel, kann das Backend-System 16 in Schritt 210 für die einzelnen Fahrzeuge 24, 24', 24'', 24''' eine eindeutige Kennung erwerben-z. B. eine Telefonnummer oder dergleichen. Und in Schritt 215 kann das Backend-System 16 einen API-Anruf an das WSP 22 oder den WSP-Server 23 mit einer Batch-Abfrage senden, wobei die Batch-Abfrage die Kennungen und das Anfordern des WSP oder des WSP-Servers die den zugeordneten Verbindungsstatus der jeweiligen einzelnen Fahrzeuge 24, 24', 24'', 24''' beinhaltet. Als Antwort kann das Backend-System 16 eine Antwort empfangen, die verschiedene Verbindungszustände der Fahrzeuge 24, 24', 24'', 24''' anzeigt. Und die verbleibenden Schritte (oder geschleiften Rückwärtsschritte), die vorstehend beschrieben sind, können für jedes der Fahrzeuge 24, 24', 24'', 24''' durchgeführt werden.
Um das vorstehend beschriebene Verfahren durchzuführen, sollte beachtet werden, dass das Backend-System 16 unter Verwendung von elektronischer Hardware, Software oder dergleichen konfiguriert werden kann. So können beispielsweise ein oder mehrere Remote-Server 18 entsprechend konfiguriert werden. Zur Veranschaulichung kann die Speichervorrichtung(en) 54 von mindestens einem Server 18 die durch den Prozessor(en) 52 ausführbaren Computerprogrammanweisungen speichern. Die Anweisungen können alle erforderlichen Anweisungen, Codes usw. beinhalten, die zum Durchführen der vorstehend genannten Schritte der Verfahren erforderlich sind, einschließlich, aber nicht beschränkt auf: Anweisungen zum Anrufen einer Anwendungs-Programmierschnittstelle (API) an einen Mobilfunkanbieter (WSP), an ein mit dem WSP verbundenes Heimatregister (HLR) oder an einen mit dem WSP verbundenen Heimteilnehmer-Server (HSS), wobei der API-Anruf eine Abfrage beinhaltet, die mit einem Verbindungsstatus des Fahrzeugs zu einem drahtlosen Trägersystem (WCS) verbunden ist, das vom WSP verwendet wird; Anweisungen zum Empfangen einer Antwort auf die Abfrage in Reaktion auf das Tätigen des API-Anrufs, wobei die Antwort auf die Abfrage in Bezug auf den WCS anzeigt, dass der Fahrzeugverbindungsstatus einer der verbundenen Zustände oder ein nicht verbundener Zustand ist; Anweisungen, um zu versuchen, die Mobilfunkverbindung zwischen dem Backend-System und dem Fahrzeug herzustellen, wenn der Verbindungsstatus des Fahrzeugs der verbundene Zustand ist; und Anweisungen zum Verzögern eines Versuchs, eine Mobilfunkverbindung zwischen dem Backend-System und dem Fahrzeug für einen vorbestimmten Zeitraum herzustellen, wenn der Fahrzeugverbindungsstatus der nicht verbundene Zustand ist, und nach Ablauf des vorbestimmten Zeitraums Anweisungen zum Einleiten eines weiteren API-Anrufs und Anweisungen zum Wiederholen der Anweisungen, die mit dem Empfangen der Antwort auf die Abfrage verbunden sind, in Reaktion auf das Erstellen eines weiteren API-Anrufs.
Die Computerprogrammanweisungen, die auf dem Speicher 54 gespeichert sind und durch den/die Prozessor(en) 52 ausführbar sind, könnten auch Folgendes beinhalten: wenn die Anweisungen ermitteln, dass der FahrzeugVerbindungsstatus der nicht verbundene Zustand ist, Anweisungen zum weiteren Wiederholen der Anweisungen zum Ausführen eines weiteren API-Anrufs und in Reaktion auf das Setzen des anderen API-Anrufs Anweisungen zum Wiederholen der Anweisungen, die mit dem Empfangen der Antwort auf die Abfrage verbunden sind, wobei eine Dauer der vorbestimmten Zeitdauer mit dem weiteren Wiederholen zunimmt; Anweisungen, die am Backend-System einer dem Fahrzeug zugeordneten Kennung gespeichert sind, wenn sich das Fahrzeug in einem nicht verbundenen Zustand befindet, wobei die Kennung mit einer Vielzahl von Kennungen gespeichert ist, die einer Vielzahl anderer Fahrzeuge zugeordnet sind, die ebenfalls bestimmt werden, sich in einem nicht verbundenen Zustand zu befinden; und Anweisungen, um einen Fahrzeugdienst über einen Mobilfunkanruf bereitzustellen, der in Reaktion auf die Anweisungen eingerichtet wird, den Versuch zu unternehmen, die Mobilfunkverbindung zwischen dem Backend-System und dem Fahrzeug herzustellen, wobei der Fahrzeugdienst das Bereitstellen von mindestens einem der folgenden Punkte über den Mobilfunkanruf beinhaltet: ein Fahrzeugsystem-Update oder eine Benachrichtigung an einen Benutzer des Fahrzeugs, wobei das Bereitstellen des Fahrzeugdienstes auf einer vorher festgelegten Teilnehmerbeziehung zwischen dem Fahrzeug und dem Backend-System basiert.
Weitere geeignete Anweisungen sind ebenfalls möglich. Dies sind lediglich Beispiele.
Somit wurde ein Verfahren zum Ermitteln der Verfügbarkeit einer Mobilfunkverbindung zwischen einem Fahrzeug-Backend-System und einem Fahrzeug beschrieben, bevor das Backend-System versucht, die Mobilfunkverbindung herzustellen. Zusätzlich wurde eine Fahrzeug-Backend-Konfiguration beschrieben, die in der Lage ist, das Verfahren durchzuführen. Das Vorqualifizieren beinhaltet, dass vor dem Versuch, ein Teilnehmerfahrzeug anzurufen, eine Abfrage an einen Mobilfunkanbieter (WSP) oder einen damit verbundenen Server gesendet wird, der Informationen darüber anfordert, ob das Fahrzeug mit einem drahtlosen Trägersystem verbunden ist. Anschließend führt das Backend-System einen Mobilfunkanruf zum Fahrzeug durch oder führt keinen Mobilfunkanruf zum Fahrzeug, basierend auf einer Antwort vom WSP- oder WSP-Server durch.
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. 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.

Claims

Verfahren zum Bereitstellen eines Fahrzeugdienstes, umfassend die folgenden Schritte: Ermitteln am Backend-System, dass dem Fahrzeug ein Fahrzeugdienst bereitzustellen ist; basierend auf dem Ermitteln, Übertragen einer Abfrage vom Backend-System an einen Mobilfunkanbieter (WSP) oder einen WSP-Server, die dem Verbindungsstatus des Fahrzeugs zu einem von dem WSP verwendeten drahtlosen Trägersystem (WCS) zugeordnet ist; in Reaktion auf das Übertragen der Abfrage, Empfangen einer Antwort auf die Abfrage am Backend-System, wobei die Antwort in Bezug auf das WCS anzeigt, dass sich das Fahrzeug entweder in einem verbundenen Zustand oder in einem nicht verbundenen Zustand befindet; und wenn sich das Fahrzeug in dem verbundenen Zustand befindet: versuchen, die Mobilfunkverbindung zwischen dem Backend-System und dem Fahrzeug herzustellen, indem ein Mobilfunkanruf zwischen dem Backend-System und dem Fahrzeug getätigt wird; und wenn die Mobilfunkverbindung hergestellt ist, Bereitstellen des Fahrzeugdienstes über den Mobilfunkanruf in Reaktion auf die hergestellte Mobilfunkverbindung.
Verfahren nach Anspruch 1, ferner umfassend, wenn sich das Fahrzeug im nicht verbundenen Zustand befindet: (a) Verzögern eines Versuchs, die Mobilfunkverbindung zwischen dem Backend-System und dem Fahrzeug für einen bestimmten Zeitraum herzustellen; (b) im Anschluss an den vorbestimmten Zeitraum, Übertragen einer weiteren mit dem Verbindungsstatus des Fahrzeugs verbundenen Abfrage zum WSP- oder WSP-Server; (c) in Reaktion auf das Übertragen der weiteren Abfrage, Empfangen einer weiteren Antwort auf die weitere Abfrage am Backend-System, wobei die weitere Antwort in Bezug auf das WCS anzeigt, dass sich das Fahrzeug entweder in einem verbundenen Zustand oder in einem nicht verbundenen Zustand befindet; (d) versuchen, die Mobilfunkverbindung zwischen dem Backend-System und dem Fahrzeug herzustellen, indem der Mobilfunkanruf zwischen dem Backend-System und dem Fahrzeug getätigt wird; und wenn die Mobilfunkverbindung hergestellt ist, den Fahrzeugdienst über den Mobilfunkanruf in Reaktion auf die hergestellte Mobilfunkverbindung bereitstellen; und (e) wenn sich das Fahrzeug im nicht verbundenen Zustand befindet: Wiederholen der Schritte (a) (c) in Bezug auf die weitere Antwort auf die weitere Abfrage.
Verfahren nach Anspruch 2, wobei, wenn die Schritte (a) (c) wiederholt werden, dann eine Dauer des vorbestimmten Zeitraums verlängert wird.
Verfahren nach Anspruch 2, ferner umfassend, wenn sich das Fahrzeug im nicht verbundenen Zustand befindet: Speichern einer Kennung, die dem Fahrzeug zugeordnet ist, und Verwenden der Kennung beim Übertragen der weiteren Abfrage an das Backend-System, wobei die Kennung mit einer Vielzahl von Kennungen gespeichert wird, die einer Vielzahl anderer Fahrzeuge zugeordnet sind, die ebenfalls bestimmt werden, sich im nicht verbundenen Zustand zu befinden, und ferner das Übertragen zusätzlicher Abfragen an die Vielzahl anderer Fahrzeuge unter Verwendung der jeweiligen Vielzahl von Kennungen.
Verfahren nach Anspruch 1, wobei die Abfrage ferner eine Batch-Abfrage umfasst, wobei die Batch-Abfrage die Anforderung des WSP oder des WSP-Servers einer Vielzahl von mit dem Fahrzeug verbundenen Verbindungszuständen und einer Vielzahl anderer Fahrzeuge beinhaltet.
Verfahren nach Anspruch 1, ferner umfassend das Tätigen eines Anrufs einer Anwendungsprogrammierschnittstelle (API) vom Backend-System an das WSP- oder den WSP-Server, wobei der API-Anruf die Abfrage beinhaltet, wobei der Schritt des Empfangens weiterhin das Empfangen einer automatisierten Antwort vom WSP- oder dem WSP-Server umfasst, die den Verbindungsstatus des Fahrzeugs anzeigt.
Verfahren nach Anspruch 1, wobei der WSP-Server ein dem WSP zugeordnetes Heimatregister (HLR) oder ein dem WSP zugeordneter Heimteilnehmer-Server (HSS) ist, wobei das HLR oder HSS Daten speichert, die einer Telematikeinheit des Fahrzeugs zugeordnet sind.
Verfahren nach Anspruch 1, wobei die Abfrage eine eindeutige Kennung beinhaltet, die dem Fahrzeug zugeordnet ist, und wobei die eindeutige Kennung eine von einer mobilen Verzeichnisnummer (MDN), einer internationalen mobilen Teilnehmeridentität (IMSI) oder einer Gerätekennung ist, die eine von einer mobilen Gerätekennung (MEID), einer internationalen mobilen Stationsausrüstungsidentität (IMEI) oder einer elektronischen Seriennummer (ESN) beinhaltet.
Verfahren nach Anspruch 1, wobei der verbundene Zustand anzeigt, dass das Fahrzeug mit einer Zelle im WCS registriert oder daran befestigt ist, wobei der nicht verbundene Zustand anzeigt, dass das Fahrzeug gegenwärtig nicht mit einer Zelle im WCS registriert oder gegenwärtig nicht verbunden ist.
Fahrzeug-Backend-System, das dazu konfiguriert ist, einen Fahrzeugdienst bereitzustellen, und das mindestens einen Prozessor und mindestens eine Speichervorrichtung umfasst, wobei die mindestens eine Speichervorrichtung Computerprogrammanweisungen speichert, die durch den mindestens einen Prozessor ausführbar sind, wobei die Computerprogrammanweisungen folgendes umfassen: Anweisungen zum Tätigen eines Anwendungsprogrammierschnittstellen (API)-Anrufs zu einem von einem Mobilfunkanbieter (WSP), einem dem WSP zugeordneten Heimatregister (HLR) oder einem dem WSP zugeordneten Heimteilnehmer-Server (HSS), wobei der API-Anruf eine Abfrage beinhaltet, die einem Verbindungsstatus des Fahrzeugs zu einem von dem WSP verwendeten drahtlosen Trägersystem (WCS) zugeordnet ist; Anweisungen zum Empfangen einer Antwort auf die Abfrage in Reaktion auf das Tätigen des API-Anrufs, wobei die Antwort auf die Abfrage in Bezug auf das WCS anzeigt, dass der Fahrzeugverbindungsstatus einer von einem verbundenen Zustand oder einem nicht verbundenen Zustand ist; Anweisungen, um zu versuchen, die Mobilfunkverbindung zwischen dem Backend-System und dem Fahrzeug herzustellen, wenn der Fahrzeugverbindungsstatus der verbundene Zustand ist; und Anweisungen zum Verzögern eines Versuchs, die Mobilfunkverbindung zwischen dem Backend-System und dem Fahrzeug während eines vorbestimmten Zeitraums zu verzögern, wenn der Fahrzeugverbindungsstatus der nicht verbundene Zustand ist, und im Anschluss an den vorbestimmten Zeitraum Anweisungen zum Tätigen eines weiteren API-Anrufs und Anweisungen zum Wiederholen der Anweisungen, die dem Empfangen der Antwort auf die Abfrage zugeordnet sind, in Reaktion auf das Tätigen des anderen API-Anrufs.