DE69636500T2

DE69636500T2 - Verfahren und system für dienstprogrammierung über funk

Info

Publication number: DE69636500T2
Application number: DE69636500T
Authority: DE
Inventors: G. Edward San Diego TIEDEMANN; Irfan San Diego KHAN; Raul Alejandro San Diego HOLCMAN
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 1995-10-10
Filing date: 1996-10-10
Publication date: 2007-05-03
Anticipated expiration: 2016-10-11
Also published as: RU2227379C2; DE69636500D1; EP0855125B1; AU713489B2; IL124058A; JP2007053782A; AU7442696A; UA50751C2; JP3902658B2; EP0855125A1; US6381454B1; CN1158886C; JPH11513849A; RU2003131071A; KR100459753B1; JP4283293B2; BR9610940A; HK1015601A1; CN1202298A; ATE338434T1

Description

Gebiet der Erfindung
Diese Erfindung betrifft Kommunikationssysteme, insbesondere betrifft die vorliegende Erfindung einen Ansatz, der eine „über-die-Luft(OTA – over-the-air)"-Dienstprogrammierung einer mobilen Station unterstützt.
Beschreibung der verwandten Technik
Herkömmlicherweise ist ein Aktivierungsprozess für eine neu erworbene mobile Station ein manuell intensiver und zeitaufwendiger Prozess. Eine der Einschränkungen dieses herkömmlichen Aktivierungsprozesses ist, dass der Benutzer die mobile Station in ein Service-Center bringen muss, um die mobile Station zu aktivieren.
Eine mobile Station ist eine Teilnehmerstation in der Kategorie eines heimischen öffentlichen zellularen Funktelekommunikationsdienstes (Domestic Public Cellular Radio Telecommunications Service), die normalerweise zur Verwendung vorgesehen ist in der Bewegung oder während Aufenthalten an unspezifizierten Punkten. Die Kategorie umfasst wahre mobile Stationen, handgehaltene tragbare Stationen, feste Stationen und andere Vorrichtungen.
An dem Service-Center programmiert (speichert) ein Techniker verschiedene Parameter in die mobile Station, die eine Information umfassen, die der Einheit ermöglicht, auf dem Netzwerk zu kommunizieren, und welche die Netzwerkidentität der mobilen Station definieren. Optional kann auch eine Hersteller-spezifische Information in die mobile Station programmiert werden. Mehrere Parametersätze werden manchmal in einer mobilen Station vorgesehen, so dass zum Beispiel die mobile Station lokale Identitäten in unterschiedlichen Dienstgebieten haben kann.
Wenn eine Information, die in einer zuvor aktivierten mobilen Station gespeichert ist, geändert werden muss, ist der Prozess herkömmlicherweise auch manuell intensiv und zeitaufwendig. Eine der Einschränkungen dieses herkömmlichen Prozesses ist, dass der Benutzer die mobile Station in ein Service-Center bringen muss, damit ein Techniker die Information in der mobilen Station ändert.
WO-A-95 23487 beschreibt ein zellulares Funktelefonsystem mit aus der Entfernung programmierten mobilen Stationen. Während der Aktivierung wird eine Information, welche die elektronische Seriennummer der mobilen Station beschreibt, zusammen mit einer Information über das Verwendungsgebiet gesammelt. Eine entfernte Programmierungssitzung wird nachfolgend durchgeführt, wobei digitale Benutzer-spezifische Programmierungsdaten an die mobile Station übertragen werden.
ZUSAMMENFASSUNG DER ERFINDUNG
Demgemäß ist es ein Ziel von Ausführungsbeispielen dieser Erfindung, ein neues Verfahren vorzusehen, um eine mobile Station zur Verwendung in einem Kommunikationsnetzwerk zu aktivieren, ohne dass der Benutzer die mobile Station in ein Service-Center oder zu einem Dritten bringen muss.
Ein weiteres Ziel ist, ein neues Verfahren vorzusehen zum Ändern von Information in einer mobilen Station zur Verwendung in einem Kommunikationsnetzwerk, ohne dass der Benutzer die mobile Station in ein Service-Center oder zu einem Dritten bringen muss.
Im Folgenden werden diese beiden Ziele, nämlich eine mobile Station zu aktivieren und eine Information in einer mobilen Station zu ändern, ohne dass der Benutzer die mobile Station in ein Service-Center oder zu einem Dritten bringen muss, als eine „über-die-Luft"-Dienstprogrammierung (OTASP – over-the-air service programming) bezeichnet.
Ein weiteres Ziel ist, eine Signalisierungsinfrastruktur vorzusehen, um eine „über-die-Luft"-Dienstprogrammierung einer mobilen Station zur Verwendung in einem Kommunikationsnetzwerk unter minimaler Beteiligung einer mobilen Vermittlungsstelle (MSC – mobile switching center) und eines Besucherregisters (VLR – visitor location register) zu erreichen.
Die obigen und andere Ziele werden gemäß den Ausführungsbeispielen der vorliegenden Erfindung erreicht durch Vorsehen einer neuen und verbesserten Signalisierungsinfrastruktur und eines Verfahrens für eine „über-die-Luft"-Dienstprogrammierung einer mobilen Station zur Verwendung in einem Kommunikationsnetzwerk.
Gemäß Ausführungsbeispielen der Erfindung überträgt die mobile Station eine Nachricht, einschließlich einer „über-die-Luft"-Dienstprogrammierungs-Anforderung, der Identifizierung der mobilen Station, die momentan in der mobilen Station gespeichert ist, und die elektronische Seriennummer der mobilen Station, an eine mobile Vermittlungsstelle, die mit dem Kommunikationsnetzwerk verbunden ist. Wenn die mobile Station mehrere Identitäten haben kann, wie oben diskutiert, wählt der Benutzer die Identität der mobilen Station, die während des „über-die-Luft"-Dienstprogrammierungsverfahrens in Kraft ist.
Eine elektronische Seriennummer ist eine 32-Bit-Nummer, die von dem Hersteller der mobilen Station zugewiesen wird, welche das Gerät der mobilen Station eindeutig identifiziert.
Die Identifizierung der mobilen Station (MSID – mobile station identification) kann entweder die mobile Identifikationsnummer (MIN – mobile identification number) oder die internationale Identität der mobilen Station (IMSI – international mobile station identity) sein. Die mobile Identifikationsnummer (MIN) ist eine 34-Bit-Zahl, die eine digitale Darstellung der 10-stelligen Zahl ist, die einer mobilen Station zugewiesen ist. Die internationale Identität der mobilen Station (IMSI) ist eine Zahl bis zu 15 Ziffern in der Länge, die eine mobile Station international eindeutig identifiziert. Im Folgenden ist implizit, wenn auf eine mobile Identifikationsnummer Bezug genommen wird, dass eine IMSI sehr gut statt einer MIN verwendet werden kann.
Dies führt dazu, dass die mobile Station mit einer anfänglichen Diensteinheit über eine Sprachverbindung verbunden wird. Eine temporäre Referenznummer (TRN – temporary reference number), welche die mobile Vermittlungsstelle und die mobile Station identifiziert, wird an der mobilen Vermittlungsstelle für die mobile Station zugeteilt. Die TRN kann eine Identifikation der mobilen Station (MSID – mobile station identification), eine Telefonverzeichnisnummer oder jede andere Nummer sein.
Wenn im Folgenden auf eine mobile Identifizierungsnummer Bezug genommen wird, ist implizit, dass eine IMSI genauso verwendet werden kann statt einer MIN.
Wenn die TRN keine MSID ist, muss eine eindeutige und temporäre mobile Identifizierung (MSID) zur Verwendung während des Dienstprogrammierungsverfahrens zugeteilt werden.
Die TRN und, wenn möglich, die temporäre Identifizierung der mobilen Station (MSID – mobile station identification), wenn eine zugeteilt ist, die MSID derzeit in der mobilen Station, und die elektronische Seriennummer werden an die Diensteinheit gesendet während eines Sprachverbindungsaufbaus. Es kann nicht möglich sein, MSIDs und die elektronische Seriennummer an die Diensteinheit zu senden, da einige Systeme auf dem Aufbaupfad der Sprachverbindung nur gültige Verzeichnisnummern zu passieren erlauben können oder nur Verzeichnisnummern, die der MSC zugewiesen sind.
Wenn festgestellt wird, dass die anfängliche Diensteinheit nicht die gewünschte Diensteinheit ist, wird der Sprachanruf an eine Diensteinheit nach der anderen weitergeleitet, bis eine erwünschte Diensteinheit erreicht ist. Die TRN und möglicherweise die MSID und die elektronische Seriennummer werden ebenfalls an die endgültige Diensteinheit gesendet.
Die endgültige Diensteinheit wählt ein Heimatregister (home location register) in dem Kommunikationsnetzwerk, dem die mobile Station zugeteilt werden soll.
Das Heimatregister wird dann der mobilen Vermittlungsstelle zugeordnet, indem das Heimatregister eine Nachricht, die die TRN enthält, an die mobile Vermittlungsstelle sendet. Das Heimatregister kann eine Nachricht an die mobile Vermittlungsstelle senden, da die TRN die mobile Vermittlungsstelle identifiziert. Die mobile Vermittlungsstelle verwendet die TRN, um die mobile Station zu identifizieren, deren „über-die-Luft"-Dienstprogrammierung ausgeführt wird. Die mobile Vermittlungsstelle sendet eine Nachricht, welche die temporäre MSID, wenn an der mobilen Vermittlungsstelle eine zugeteilt wurde, die momentan in der mobilen Station enthaltene MSID und die elektronische Seriennummer der mobilen Station enthält, zurück an das Heimatregister, wenn diese an der endgültigen Diensteinheit während des Aufbaus des Sprachanrufs nicht empfangen wurden. Wenn sich die TRN von der temporären mobilen Identifizierungsnummer unterscheidet, wird sie an der mobilen Vermittlungsstelle freigegeben.
Im Folgenden wird auf eine die mobile Station betreffende Information, die in einem Netzwerkelement enthalten ist, Bezug genommen unter Verwendung der temporären MSID, welche die TRN selbst sein kann, und der elektronischen Seriennummer der mobilen Station.
Die Diensteinheit oder das Heimatregister können über das Kommunikationsnetzwerk die mobile Station nach einer in der mobilen Station enthaltenen Information abfragen. Die Diensteinheit oder das Heimatregister können eine neue permanente MSID für die mobile Station zuteilen und eine Dienstprogrammierungsinformation, möglicherweise einschließlich der neu zugeteilten permanenten MSID, an über die mobile Vermittlungsstelle unter Verwendung des Kommunikationsnetzwerks die mobile Station übertragen. Die Diensteinheit überträgt auch eine Dienstprogrammierungsinformation, die zu der mobilen Station gehört, an das Heimatregister.
Nachdem die Dienstprogrammierungsinformation erfolgreich an die mobile Station übertragen wurde, sendet die Diensteinheit oder das Heimatregister eine Nachricht über das Kommunikationsnetzwerk an die mobile Station, welche diese anweist, die Dienstprogrammierungsinformation an ihren nichtflüchtigen Speicher weiterzuleiten. Die an die mobile Station gesendete Information wird auch in dem nichtflüchtigen Speicher in dem HLR (home location register) und/oder dem Authentisierungszentrum (AC – authentication center) gespeichert.
Die mobile Vermittlungsstelle wird lediglich als ein Kanal für das Messaging verwendet, das zwischen dem Heimatregister und der mobilen Station und zwischen der Diensteinheit und der mobilen Station durchgeführt wird.
Das Heimatregister umfasst eine Datenbank, die eine Registrierungs- und Benutzerprofilinformation für die Teilnehmer des Systems enthält. Die mobile Vermittlungsstelle sieht Verbindungsdienste zwischen drahtlosen Teilnehmerstationen und zwischen drahtlosen Teilnehmerstationen und dem öffentlichen Fernsprechnetz (PSTN – public switched telephone network) über eine oder mehrere Basisstation(en) (BS – base stations) unter ihrer Steuerung vor. Das PSTN ist ein Telekommunikationsnetzwerk, auf das im Allgemeinen von herkömmlichen Telefonen, Wählanlagenvermittlungen und Datenübertragungseinrichtungen zugegriffen wird, die einen Dienst für die Allgemeinheit vorsehen. Die Basisstation ist eine feste Station, die zur Kommunikation mit mobilen Stationen verwendet wird. Abhängig von dem Kontext kann der Begriff Basisstation eine Zelle, einen Sektor in einer Zelle, ein MSC oder einen anderen Teil des zellularen Systems bezeichnen.
Das Verfahren der OTA-Dienstprogrammierung gemäß Ausführungsbeispielen der vorliegenden Erfindung minimiert die Beteiligung der MSC und des Besucherregisters (Visitor Location Register – VLR) bei der OTA-Verarbeitung. Das VLR verbindet die eine oder mehrere MSCs und umfasst eine Datenbank zum temporären Speichern eines Teils von Teilnehmerdaten und in bestimmten Fällen, Sicherheits-bezogenen Daten für eine mobile Station, die momentan von ihrer entsprechenden MSC bedient wird.
Der Vorgang der über-die-Luft-Dienstprogrammierung benötigt auch die Beteiligung des Authentisierungszentrums zum Zweck des Speicherns der Sicherheitsbezogenen Daten der mobilen Station und zum Durchführen Sicherheitsbezogener Verfahren, die erforderlich sind zum Herunterladen des Authentisierungsschlüssels (A-Key – A-Schlüssel) auf die mobile Station, und zum Aufrufen einer Sprachverschlüsselung und/oder einer Signalisierungsnachrichtenverschlüsselung für Zwecke der Sicherheit auf der Luftverbindung zwischen der mobilen Station und der Basisstation.
Das Authentisierungszentrum (AC – authentication center) ist eine Einheit, welche die Sicherheitsaspekte hinsichtlich der mobilen Station verwaltet. Der Authentisierungsschlüssel ist ein verborgenes Bitmuster, das in der mobilen Station und in dem AC gespeichert ist. Es wird verwendet, um die SSD der mobilen Station zu erzeugen und zu aktualisieren, die zur Authentisierung, Sprachverschlüsselung und Signalisierungsnachrichtenverschlüsselung verwendet werden. Gemeinsame geheime Daten (SSD – shared secret data) ist ein Bitmuster, das in der mobilen Station gespeichert ist und dem AC und möglicherweise dem VLR bekannt ist. Die gemeinsamen geheimen Daten (SSD) werden während des Abschaltens beibehalten.
Die Diensteinheit hat normalerweise eine Schnittstelle mit dem HLR. Somit findet eine Kommunikation zwischen der Diensteinheit und dem AC im Allgemeinen über das HLR statt. Um eine Kommunikation zwischen dem HLR und dem AC herzustellen, schlagen Ausführungsbeispiele der vorliegenden Erfindung neue Nachrichten zwischen dem Heimatregister und dem Authentisierungszentrum vor.
Vorteilhafte Aspekte einer OTA-Dienstprogrammierung gemäß der vorliegenden Erfindung umfassen:

1) Eine OTA-Dienstprogrammierung gemäß den Ausführungsbeispielen muß die MSC/das VLR nicht an den Details einer Dienstprogrammierung beteiligen, da der Prozess primär einer der Initialisierung der Datenbanken der mobilen Station und des HLRs/Authentisierungszentrums (ACs) ist.
2) Durch Minimierung der Beteiligung von MSC/VLR können Verbesserungen an dem Prozess der OTA-Dienstprogrammierung gemacht werden, ohne die MSC- und VLR-Software zu ändern.
3) Das HLR/AC steuert den Dienstprogrammierungsprozess und wirkt als ein Dienststeuerungspunkt (SCP – service control point), um die über-die-Luft-Dienstprogrammierung zu steuern.
4) Zur Steuerung muss die CSC nur eine Schnittstelle mit dem HLR haben. Die Sprachverbindung zu der CSC kann direkt über das Netzwerk sein oder direkt von der MSC. Das Verfahren der OTA-Dienstprogrammierung gemäß Ausführungsbeispielen der vorliegenden Erfindung unterstützt beide Verfahren.
5) Das HLR kann gewählt werden, nachdem der Aktivierungsprozess beginnt. Dies ermöglicht der mobilen Station, überall in dem Dienstgebiet des Dienstbetreibers (operators) aktiviert zu werden. Unter Voraussetzung der geeigneten Übereinkommen und der Netzwerkunterstützung gibt es nichts, das eine mobile Station daran hindert, in einem HLR mit einer Verbindung zu der MSC aktiviert zu werden.
6) Die MSC wird nur als eine Leitung für ein Messaging verwendet, das zwischen dem HLR und der mobilen Station durchgeführt wird.

Somit ist gemäß einem ersten und einem zweiten Aspekt der Erfindung ein Verfahren und ein System zum entfernten Programmieren einer mobilen Station vorgesehen, wie jeweils in den Ansprüchen 1 und 13 dargelegt wird.
Gemäß einem dritten Aspekt ist eine mobile Station vorgesehen, die für eine entfernte Programmierung konfiguriert ist, wie in Anspruch 14 dargelegt wird.
Kurze Beschreibung der Zeichnungen
Die Merkmale, Ziele und Vorteile von Ausführungsbeispielen der vorliegenden Erfindung werden offensichtlicher aus der folgenden detaillierten Beschreibung in Verbindung mit den Zeichnungen, in denen gleiche Referenzzeichen Entsprechendes identifizieren und wobei:
1 ein Blockdiagramm eines Netzwerkreferenzmodells mit einem HLR und einer CSC ist;
2 ein Blockdiagramm eines Netzwerkreferenzmodells mit mehreren HLRs und einer CSC ist;
3 ein Blockdiagramm eines Netzwerkreferenzmodells mit mehreren HLRs und getrennten CSCs ist;
4A ein Ablaufdiagramm ist, das einen Prozess zur Programmierung einer mobilen Station unter Verwendung einer OTA-Dienstprogrammierung darstellt;
4B eine Fortsetzung des Ablaufdiagramms von 4A ist;
4C ein Anruf-Ablaufdiagramm ist, das eine Signalisierung in einem beispielhaften Kommunikationsnetzwerk zeigt, in dem eine ursprüngliche Sprachverbindung von einer ersten CSC an eine zweite CSC Anrufweitergeleitet wird;
4D eine Fortsetzung des Ablaufdiagramms von 4B ist;
5 ein Anruf-Ablaufdiagramm ist, das eine Signalisierung zum Abmelden (deregistering) einer alten MSID, die zu einer mobilen Einheit gehört, gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt;
6 ein Anruf-Ablaufdiagramm ist, das ein A-Schlüssel-Übertragungsverfahren gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt;
7 ein Anruf-Ablaufdiagramm ist, das ein SSD-Aktualisierungsverfahren gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt; und
8 ein Anruf-Ablaufdiagramm ist, das ein Re-Authentifizierungsverfahren gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt.
Detaillierte Beschreibung der bevorzugten Ausführungsbeispiele
Unter Bezugnahme nun auf die Zeichnungen, in denen gleiche Referenzzeichen in den zahlreichen Ansichten identische oder entsprechende Teile bezeichnen, und insbesondere auf die 1, wird ein Blockdiagramm eines Netzwerkreferenzmodells dargestellt. In der folgenden Beschreibung wird zuerst das Netzwerkreferenzmodell erläutert und dann folgen verwandte Netzwerkmodelle, die in den 2 und 3 dargestellt werden. Darauffolgend zeigen die 4A, 4B und 4D Verfahrensschritte, die von dem Netzwerk eingesetzt werden, und die 4C, 5, 6, 7 und 8 stellen eine Signalisierung dar, die in dem Netzwerk eingesetzt wird.
Das Netzwerkreferenzmodell 100 der 1 umfasst eine mobile Station (MS) 2, die mit einer Basisstation (BS) 6 über eine Schnittstelle, U_m, 4 verbunden ist; die BS 6 ist mit einer mobilen Vermittlungsstelle (MSC – mobile switching center) 10 über eine Schnittstelle, A, 8 verbunden; die MSC 10 ist mit einem Besucherregister (VLR – visitor location register) 14 und einem Heimatregister (HLR – home location register) 18 jeweils über die Schnittstellen, B, 12, und C, 28, verbunden; das VLR 14 ist mit dem HLR 18 über eine Schnittstelle, D, 16 verbunden; und das HLR 18 ist mit einem Authentisierungszentrum (AC – authentication center) 22 und einer Kundendienstzentrale (CSC – customer service center) 26 jeweils über die Schnittstellen, H, 20 und P (proprietär) 24 verbunden. Eine Sprachverbindung wird zwischen der MSC 10 und der CSC 26 aufgebaut, wie von der gestrichelten Linie 46 dargestellt wird. Die Schnittstellen A, B, C, D, H und U_m sind Industriestandard-Schnittstellen und werden zum Beispiel in dem TIA(Telecommunications Industry association)-IS41-C-Standard für „Cellular Radiotelecommunications Intersystem Operations" verwendet. Es ist anzumerken, dass in 1 nur ein HLR zu der CSC gehört.
2 ist ein Blockdiagramm eines Netzwerkreferenzmodells mit mehreren HLRs. Zusätzlich zu den Elementen des Netzwerkreferenzmodells von 1 umfasst das Netzwerkreferenzmodell von 2 ein HLR 38, das jeweils mit der CSC 26, der MSC 10, dem VLR 14 und einem AC 42 über die Schnittstellen P (proprietär) 36, C 34, D 48 und H 40 verbunden ist. Die 2 zeigt einen Fall, in dem es eine Wahl gibt von HLRs, auf denen die Daten der mobilen Station gespeichert werden können. In diesem Fall gehört eine einzelne CSC zu den HLRs.
3 ist ein Blockdiagramm eines Netzwerkreferenzmodells mit mehreren HLRs und CSCs. Dieses Netzwerkreferenzmodell umfasst die Elemente des Netzwerkreferenzmodells von 2 mit einer zusätzlichen CSC 44 und der Sprachverbindung 54. In dieser Zeichnung ist das HLR 38 über die Schnittstelle P 36 mit der CSC 44 verbunden und die CSC 26 leitet die Sprachverbindung 46 unter Verwendung der Sprachverbindung 54 in einer Sprach-Anrufweiterleitungs-Operation an die CSC 44 weiter. In 3 entspricht jedes HLR 18, 38 jeweils einer anderen CSC 26, 44.
Der Aufruf der über-die-Luft(OTA)-Dienstprogrammierung gemäß Ausführungsbeispielen der vorliegenden Erfindung wird zuerst hinsichtlich der in den 1–3 gezeigten Netzwerkarchitekturen beschrieben. Nachfolgend werden die Funktion und die Prozesse, die beim Erreichen der OTA-Dienstprogrammierung durchgeführt werden, unter Bezugnahme auf die 4–8 beschrieben.
Unter Bezugnahme auf die 1 beginnt die OTA-Dienstprogrammierung, indem die mobile Station (MS) 2 einen OTA-Dienstprogrammierungsanruf initiiert. Der Benutzer initiiert diesen Anruf, da der Benutzer zum Beispiel gerade ein Mobiltelefon von einem Anbieter erworben hat und der Benutzer möchte das Telefon zur normalen Verwendung betreiben, ohne zur Aktivierung des Telefons in ein Servicecenter gehen zu müssen, oder da der Benutzer eine Information in der mobilen Station ändern möchte, oder da der Diensteanbieter den Benutzer anweist, einen OTA-Dienstprogrammierungsanruf zu platzieren, damit der Diensteanbieter bestimmte Informationen in der mobilen Station ändert. Um dies zu erreichen, gibt der Benutzer eine OTA-Dienstprogrammierungscodenachricht an der mobilen Station 2 ein mit einer spezifischen Präambel, z.B. „*22", was anzeigt, dass der Benutzer eine über-die-Luft-Dienstprogrammierung anfordern möchte. Nach der Präambel gibt der Benutzer Daten ein, die das gewünschte System anzeigen. Zum Beispiel gibt der Benutzer „XXX" ein, was ein spezifisches System anzeigt, an dem der Benutzer teilnehmen möchte, wie System A oder System B (*22800 oder *22801), „YYYY", wenn YYYY eine Systemidentifizierungsnummer (SID – system identification number) eines bevorzugten Diensteanbieters ist, oder „ZZZZZ", das einen TDMA(time division multiple access)-Systemoperatorcode(SOC – system operator code) anzeigt. Statt dass der Benutzer manuell die OTA-Dienstprogrammierungscodenachricht in die mobile Station eingibt, kann der Benutzer einen Knopf an der mobilen Station drücken, was zu einem ähnlichen Effekt führt wie der, wenn der Benutzer manuell die OTA-Dienstprogrammierungscodenachricht in die mobile Station eingibt. Wenn die mobile Station mehrere Identitäten haben kann, wie oben diskutiert, wählt der Benutzer die Identität der mobilen Station, die während des OTASP-Verfahrens in Effekt sein soll. Über die Luftschnittstelle 4 wird der Anruf der mobilen Station 2 über die Basisstation 6 und die Schnittstelle 8 an die versorgende bzw. liefernde (serving) MSC 10 weitergeleitet. Gleichzeitig wird eine elektronische Seriennummer (ESN – electronic serial number) der mobilen Station des Benutzers und die MSID, die in der MS momentan vorhanden ist, an die MSC 10 weitergeleitet und von der MSC 10 gespeichert.
Als Antwort auf den Anruf der mobilen Station 2 liefert die MSC 10 eine temporäre Referenznummer (TRN – temporary reference number), die zu der mobilen Station 2 gehört und welche die MSC identifiziert, und leitet den Anruf über eine Sprachverbindung 46 an die CSC 26. Die TRN kann eine Identifizierung der mobilen Station (MSID – mobile station identification), eine Verzeichnisnummer oder eine andere Nummer sein. Alternativ werden rückverfolgbare (traceable) TRNs verwendet, wenn die CSC die ankommende TRN überprüfen kann, um zu bestimmen, ob die TRN aus einem gültigen Verzeichnis von Nummern ist, das der MSC 10 zugewiesen ist. Wenn die TRN keine MSID ist, muss eine eindeutige und temporäre MSID zur Verwendung während des Verfahrens der Dienstprogrammierung zugeteilt werden.
In dem in den 1 und 2 gezeigten Netzwerk wird der Anruf direkt über eine Sprachverbindung 46 an die CSC 26 um- bzw. weitergeleitet (routed), obwohl, wie in 3 gezeigt, der Anruf über eine Anrufweiterleitung über eine zweite Sprachverbindung 54 an eine zweite CSC 44 weitergeleitet werden kann. In jedem Fall dient die TRN als die anfängliche Referenz für den Versuch der über-die-Luft-Dienstprogrammierung und wird an die CSC 26 (oder 44) als Teil des Anrufaufbaus geliefert.
Die TRN kann in einem ISDN(integrated service digital network)-Benutzer-zu-Benutzer-Element oder – Teil oder dem Nummernfeld des anrufenden Teilnehmers (calling party number field) oder einem anderen geeigneten Mittel zur Weiterleitung der Nummer gehostet werden.
Sobald der Anruf von der MSC 10 an der CSC 26 ankommt, antwortet die CSC auf die folgende Weise. Ein Sprachoperator (oder eine Sprachantworteinheit, usw.) an der CSC 26 beginnt einen Dialog mit dem Benutzer der mobilen Station 2, während dem die CSC 26 identifiziert (wählt), welches HLR 18 oder 38 (in den 2 und 3) verwendet wird, um mit der MSC 10 auf einer Datenverbindung zu kommunizieren, die zwischen dem HLR 18 und der MSC 10 aufgebaut wird. Zum Beispiel kann ein Diensteanbieter sowohl New York als auch Los Angeles mit entsprechenden HLRs versorgen. Ein Benutzer aus Los Angeles möchte die mobile Station des Benutzers programmieren, während er New York besucht. In diesem Fall kann der CSC-Operator in New York den Anruf des Benutzers an einen CSC-Operator in Los Angeles weiterleiten. Wenn das zur Programmierung gewählte HLR direkt mit der CSC 26 (1 und 2) verbunden ist, beginnt die CSC 26 die OTA-Dienstprogrammierung durch Kontaktieren des vorgesehenen HLRs (das HLR 18 über die proprietäre Schnittstelle 24 oder HLR 38 über die proprietäre Schnittstelle 36 in den 1 und 2). Die TRN, die von der MSC 10 geliefert wurde, wird an das vorgesehene HLR über die CSC 26 geliefert, wobei die CSC 26 das vorgesehene HLR auslöst, eine Datenverbindung (über das VLR 14 und die Schnittstellen 16 und 12) zu der MSC 10 aufzubauen. In 1 umfasst die Datenverbindung das HLR 18, die Schnittstelle 16, das VLR 14, die Schnittstelle 12 und die MSC 10. In 2 ist die Datenverbindung dieselbe wie in 1, wenn das HLR 18 das gewünschte HLR ist. Wenn das HLR 38 das gewünschte HLR ist, umfasst in 2 die Datenverbindung das HLR 38, die Schnittstelle 48, das VLR 14, die Schnittstelle 12 und die MSC 10. Wenn in 3 das HLR 38, das für die OTA-Dienstprogrammierung gewählt wird, nicht direkt mit der CSC 26 verbunden ist, leitet die CSC 26 den Anruf an die CSC 44, die mit dem HLR 38 verbunden ist und für die OTA-Dienstprogrammierung über eine Sprachverbindung 54 gewählt ist. Die von der MSC 10 zugewiesene TRN muss an die CSC 44 weitergeleitet werden. Durch eine Anrufweiterleitung kann die mobile Station 2 an jedem HLR bedient werden, das die OTASP-Verfahren unterstützt. In 3 umfasst die Datenverbindung das HLR 38, die Schnittstelle 48, das VLR 14, die Schnittstelle 12 und die MSC 10.
Sobald das vorgesehene HLR (18 oder 38) von der CSC 26 (in den 1 und 2) ausgelöst wurde oder das HLR 38 von der CSC 44 (in 3), baut das HLR eine Datenverbindung zu der MSC 10 auf basierend auf der TRN, die von der CSC an das HLR geliefert wird. Das HLR 18 ist konfiguriert, die Adresse der MSC aus der TRN zu identifizieren, und da das HLR 18 normalerweise Datensätze basierend auf ESN und MSID einer mobilen Station speichert, erfordert das HLR die ESN der mobilen Station und die temporäre MSID von der MSC, um einen Datensatz für die mobile Station 2 zu speichern. Das HLR erfordert auch die MSID, die sich momentan in der MS befindet, zur Verwendung in SSD-Aktualisierungsverfahren, wie später erläutert wird. Demgemäß kontaktiert das vorgesehene HLR die MSC 10 über die Datenverbindung, um die ESN der mobilen Station 2, die MSID, die momentan in der mobilen Station ist, und die temporäre MSID, wenn verschieden zu der TRN, abzurufen. Es wird angenommen, dass die temporäre MSID, die momentan in der MS gespeicherte MSID und die ESN während des Aufbaus des Sprachanrufs nicht an die CSC kommuniziert wurden und somit aus der MSC abgerufen werden müssen. Wie unter Bezugnahme auf die folgenden Ablaufdiagramme und Anrufdiagramme beschrieben wird, wird die Datenverbindung dann der mobilen Station 2 zugeordnet und sobald sie zugeordnet ist, kann die CSC 26 (oder 49) Daten an die mobile Station 2 leiten und die mobile Station programmieren.
4A ist ein Ablaufdiagramm der Schritte, die ausgeführt werden, um den erfinderischen Prozess der OTA-Dienstprogrammierung funktional durchzuführen. Der Prozess beginnt in Schritt 51, wo, um den über-die-Luft-Dienstbereitstellungsanruf zu platzieren, der Benutzer einer mit dem Telefon gelieferten Bedienungsanleitung folgt und die Aktivierungscodepräambel („*22") wählt, gefolgt von der geeigneten drei- bis fünf-stelligen Erweiterung, wie oben diskutiert, die einem spezifischen System, SID, oder TDMA SOC entspricht. Während dieses Schrittes sendet die mobile Station 2 die über-die-Luft-Dienstprogrammierungsanforderung, die MSID, die sich derzeit in der mobilen Station befindet, und ihre eindeutige ESN an die MSC, wo die MSC die ESN der mobilen Station 2 und die sich derzeit in der mobilen Station befindende MSID speichert. Die MSC teilt eine temporäre Referenznummer (TRN – temporary reference number) zu, welche die mobile Vermittlungsstelle und die mobile Station identifiziert. Wenn die TRN keine MSID ist, wird ebenso eine eindeutige und temporäre MSID zur Verwendung während des Verfahrens der Dienstprogrammierung zugeteilt.
Der Prozess geht dann zu Schritt 53, wo die die mobile Station 2 versorgende MSC eine Sprachverbindung 46 zwischen der mobilen Station 2 und der geeigneten CSC (z.B. CSC 26 in 1) aufbaut.
Nachdem die Sprachverbindung hergestellt wurde, geht der Prozess zu Schritt 55 weiter, wo der Benutzer eine Benutzer-spezifische Information (wie Wohnadresse, Kreditkartennummer, usw.) an einen CSC-Operator in der CSC 26 gibt. Angesichts der Benutzer-spezifischen Information geht der Prozess zu Schritt 57 weiter, wo die CSC 26 bestimmt, ob sie die richtige CSC ist für einen Dienst für den Benutzer (z.B. CSC 44 der 3 kann die richtige CSC sein). Wenn nicht, geht der Prozess zu Schritt 59 weiter, wo der Anruf der mobilen Station 2 an eine richtige CSC weitergeleitet wird (z.B. die CSC 44 in 3) und der Prozess geht dann zu Schritt 55. Wenn jedoch in Schritt 57 festgestellt wird, dass der Benutzer mit der richtigen CSC (z.B. CSC 26 in 1) verbunden ist, geht der Prozess direkt zu Schritt 511.
In den Schritten 53 und 59 wird die TRN von der MSC 10 an die CSC 26 in der Form von Daten durch das Sprachanrufaufbauverfahren für die Sprachverbindung 46 geliefert. Die TRN ist für den durchgeführten Anruf eindeutig und wird von der CSC 26 und der MSC 10 als ein transienter (temporärer) Identifizierer der Anforderung der mobilen Station 2 für eine über-die-Luft-Dienstprogrammierung verwendet. Attribute der TRN umfassen (1) eine Identifizierbarkeit der mobilen Station, was der CSC ermöglicht, die fragliche mobile Station zu identifizieren, und (2) eine MSC-Adressierbarkeit, was anderen Netzwerkressourcen, wie dem HLR, ermöglicht, die MSC, welche die mobile Station 2 versorgt, durch die TRN eindeutig zu identifizieren.
Bis zu diesem Punkt im Prozess wurden ein Sprachanruf und eine TRN aufgebaut, aber es wurde keine Datenverbindung errichtet, die ermöglicht, dass OTA-Programmierungsdaten an die mobile Station 2 heruntergeladen werden. Demgemäß geht der Prozess nach dem Schritt 57 zu dem Schritt 511 weiter, wo die CSC (26 oder 44) ein HLR (18 oder 38) über eine proprietäre Verbindung (P) mit einer Nachricht mit der TRN auslöst. Basierend auf dem Merkmal der MSC-Adressierbarkeit der TRN kann das HLR (18 oder 38) die Adresse der MSC 10 feststellen, welche die mobile Station 2 bedient.
Der Prozess geht dann zu Schritt 513 weiter, wo das HLR 18 eine neue über-die-Luft-Dienstprogrammierungs-INVOKE(AUFRUFEN)-Nachricht, OTA-Dienstprogrammierungs-INVOKE (OTASERPROG), über das VLR 14 an die MSC 10 sendet (siehe 1, 2 und 3). Die OTASERPROG-Nachricht wird durch das VLR 14 kommuniziert, da gemäß Industrieübereinkommen Kommunikationen von HRLs typischerweise durch VLRs geleitet werden. Alternativ kann jedoch das HLR (18 oder 38) die OTASERPROG-Nachricht direkt an die MSC 10 senden. Die Kombination des HRLs (18 oder 38), des VLRs 14 und der MSC 10 (zusammen mit den entsprechenden verbindenden Schnittstellen) bilden eine Datenverbindung zwischen der CSC (26 oder 44) und der MSC 10, die parallel verläuft zu der bestehenden Sprachverbindung 46 (oder 46 und 54) zwischen der mobilen Station 2 und der CSC (26 oder 44). Diese Datenverbindung wird später verwendet, um Dienstprogrammierungsdaten zwischen der mobilen Station 2 und dem HLR 18 (oder 38) zu kommunizieren. Nach dem Schritt 513 geht der Prozess zu Schritt 515 weiter, der in 4B gezeigt wird.
4B ist ein Ablaufdiagramm, das zusätzliche Schritte des in 4A begonnenen Prozesses zeigt. Nach dem Schritt 513 (4A) geht der Prozess zu Schritt 515, wo die MSC 10 die OTASERPROG-Nachricht empfängt. In Schritt 517 ordnet die MSC 10 die Sprachverbindung (Anruf) der Datenverbindung zu (z.B. wie in 1 gezeigt, besteht die Datenverbindung zwischen dem HLR 18, der Schnittstelle 16, dem VLR 14, der Schnittstelle 12 und der MSC 10) unter Verwendung der TRN, die in der OTASERPROG-Nachricht an sie geliefert wird.
Bis zu diesem Punkt in dem Prozess wurde eine Datenverbindung zwischen der mobilen Station 2 und dem HLR 18 (oder 38) aufgebaut, aber das HLR 18 (oder 38) hat noch nicht die spezifische Information über die mobile Station 2, um die mobile Station 2 richtig zu aktivieren. Wenn das HLR 18 (oder 38) (in Kooperation mit dem Authentisierungszentrum AC 22 (oder 42)) die mobile Station 2 ohne weitere Information programmieren würde, würden die folgenden zwei Probleme entstehen. Erstens würden „unrechtmäßige (pirated)" mobile Stationen einen Zugang zu dem Kommunikationssystem erlangen, da noch keine Rechenschaft über die ESN der mobilen Station abgelegt wurde. Zweitens erfordert das HLR 18 (oder 38) die MSID und die ESN einer mobilen Station, um Datensätze des HLRs 18 (oder 38), die der mobilen Station 2 entsprechen, eindeutig zu erzeugen und abzurufen. Auch benötigt das AC die momentan in der mobilen Station gespeicherte MSID zur Verwendung in einem SSD-Aktualisierungsverfahren, wie später erläutert wird.
Demgemäß geht nach dem Schritt 517 der Prozess zu Schritt 519 weiter, wo die MSC 10 eine OTA-Dienstprogrammierungs-RETURN RESULT(LIEFERE ERGEBNIS)(otaserprog)-Nachricht an das HLR 18 (oder 38) über die Datenverbindung sendet, wobei die otaserprog-Nachricht die ESN der mobilen Station 2, die momentan in der mobilen Station gespeicherte MSID und die temporäre MSID, wenn an der MSC 10 zugeteilt, umfasst. Wenn die temporäre MSID an der MSC zugeteilt wurde, ist die TRN nicht länger erforderlich und wird freigegeben. Im Folgenden wird die gesamte Datenkommunikation, welche die mobile Station 2 betrifft, durch die temporäre MSID (welche dieselbe sein kann wie die TRN) und die ESN referenziert. Es ist anzumerken, dass eine hier verwendete Übereinkunft zur Identifizierung ursprünglicher (originating) (INVOKE) Nachrichten GROSSBUCHSTABEN verwendet und für Antwort-(RETURN RESULT)-Nachrichten Kleinbuchstaben verwendet (vergleiche OTASERPROG und otaserprog).
Der Prozess geht dann zu Schritt 521 weiter, wo das HLR 18 (oder 38) die otaserprog-Nachricht empfängt, welche die ESN der mobilen Station 2, die momentan in der mobilen Station gespeicherte MSID und die temporäre MSID enthält. Die Kombination der ESN und der temporären MSID liefert die gesamte Information, die für das HLR 18 erforderlich ist, um einen Datensatz für die mobile Station 2 zu halten und über die Datenverbindung mit der mobilen Station 2 zu kommunizieren. Die momentan in der mobilen Station ge speicherte MSID wird an dem HLR gespeichert für eine spätere Verwendung, wenn SSD-Aktualisierungsverfahren durchgeführt werden. Es wird angenommen, dass die temporäre MSID, die momentan in der mobilen Station gespeicherte MSID und die ESN während des Sprachanrufaufbaus nicht an die CSC kommuniziert wurden und somit von der MSC abgerufen werden müssen.
Nach dem Schritt 521 geht der Prozess zu Schritt 523, wo das HLR 18 (oder 38) bestimmt, ob andere OTA-Dienste für die mobile Station 2 durchzuführen sind. Wenn dem so ist, geht der Prozess zu dem Prozess, der in dem Ablaufdiagramm der 4D gezeigt wird, und kehrt später zu Schritt 525 zurück. Wenn keine anderen Funktionen durchzuführen sind, wie in Schritt 523 festgestellt, geht der Prozess zu Schritt 525 weiter. In Schritt 525 sendet das HLR eine OTA-Datennachricht in einer OTASERPROG-Nachricht, in der Daten, die für eine Dienstprogrammierung des Telefons der mobilen Station 2 des Benutzers erforderlich sind (z.B. permanente MSID), über die Datenverbindung geleitet werden und von der mobilen Station 2 empfangen werden. Die OTA-Datennachricht ist die Nachricht, die zwischen der MS 2 und der MSC 10 kommuniziert wird. Nachfolgend wird eine zweite OTA-Nachricht (in Schritt 527) in der OTASERPROG-Nachricht an die mobile Station 2 gesendet, welche die mobile Station 2 anweist, Dienstprogrammierungsdaten, die an die mobile Station 2 gesendet wurden, an ihren nichtflüchtigen Speicher zu leiten. In Schritt 529 bestimmt die MSC 10, ob die mobile Station 2 abgemeldet werden muss (d.h. die versorgenden Systeme MSC 10/VLR 14 entfernen die MSID der mobilen Station 2 aus den Registern der versorgenden Systeme). Wenn die mobile Station 2 nicht abgemeldet werden soll, geht der Prozess zurück zu Schritt 533 in 4B. Wenn jedoch die mobile Station 2 abgemeldet werden soll, geht der Prozess zu Schritt 531 weiter, wo ein Abmeldungsprozess durchgeführt wird (der unter Bezugnahme auf 5 erläutert wird). Sobald der Abmeldungsprozess durchgeführt wurde, geht der Prozess zu Schritt 533 weiter.
Dann beendet in Schritt 533 die mobile Station 2 die Sprachverbindung mit der CSC und der Prozess endet.
4C ist ein Anrufablaufdiagramm unter Verwendung der OTASERPROG- und otaserprog-Nachrichten, das dem in den Ablaufdiagrammen der 4A und 4B Prozess entspricht. Wie oben diskutiert, ziehen Ausführungsbeispiele der vorliegenden Erfindung in Erwägung, dass das VLR 14 und die MSC 10 primär als Kanäle bzw. Leitungen (conduits) für eine Nachrichtenübertragung zwischen der mobilen Station 2 und dem HLR/AC 18/22 (oder 38/42) verwendet werden und in dem Dienstprogrammierungsprozess der mobilen Station 2 keine aktive Rolle spielen müssen. Dies wird erreicht durch Definition einer neuen (OTASERPROG) INVOKE- und RETURN RESULT-Nachricht, in der die OTA-Datennachricht, welche die Nachricht ist, die zwischen der MSC und der MS kommuniziert wird und eine die OTA-Dienstprogrammierung betreffende Information enthält, eingekapselt werden kann. Die OTASERPROG-Nachricht wird von dem HLR 18 (oder 38) oder dem AC 22 (oder 42) an die MSC 10 gesendet. Wenn eine eingekapselte OTA-Datennachricht vorhanden ist, wird sie im Allgemeinen von der MSC 10 aus der OTASERPROG-INVOKE-Nachricht extrahiert, die von dem HLR 18 (oder 38) oder dem AG 22 (oder 42) an die MSC 10 gesendet wird.
Die otaserprog-Nachricht wird von der MSC 10 an das HLR 18 (oder 38) oder das AC 22 (oder 42) gesendet. Wenn eine OTA-Datennachricht an das HLR oder das AC gesendet werden soll, wird sie von der MSC 10 in der OTASERPROG-RETURN RESULT-Nachricht eingekapselt, die von der MSC 10 an das HLR 18 (oder 38) oder das AC 22 (oder 42) gesendet wird.
Das heißt, der über-die-Luft-Dienstprogrammierungsprozess kann vorteilhafterweise ohne substanzielle Beteiligung der Verarbeitungsressourcen des VLRs 14/der MSC 10 durchgeführt werden.
Abgesehen von der Kommunikation von OTA-Datennachrichten zwischen der MS und dem HLR oder der MS und dem AC, werden die OTASERPROG-INVOKE- und RETURN RESULT-Nachrichten auch für andere Zwecke genutzt, wie „Anfügen der MSC zu dem HLR über eine Datenverbindung" und zum Senden von Verschlüsselungsparametern an die MSC.
Obwohl der Vollständigkeit halber die Anrufablaufdiagramme der 4C (sowie die anderen Ablaufdiagramme) eine Nachrichtenübertragung an das VLR/die MSC und von dem VLR/der MSC darstellen, sollte offensichtlich sein, dass das System gemäß den Ausführungsbeispielen der vorliegenden Erfindung nicht in Betracht zieht, dass während des OTASP-Prozesses Verarbeitungs- oder Steuerungsfunktionen in dem VLR/der MSC durchgeführt werden.
In 4C (sowie den anderen Anrufablaufdiagrammen) werden hinsichtlich der spezifischen Anrufe allgemeine beschreibende Beschriftungen bzw. Legenden vorgesehen. In diesen Zeichnungen stellt der gestrichelte Pfeil einen Sprach- oder Verkehrskanal dar.
Die Struktur der Anrufablaufdiagramme wird unter Bezugnahme auf die 4C beschrieben. Der obere Teil der 4C entspricht der MS 2, der MSC 10, dem VLR 14, dem HLR 18, der CSC 26, dem HLR 38 und der CSC 44, die auch in 3 gezeigt werden. Die MSC 10 und der VLR 14 bilden gemeinsam ein versorgendes System, das die MS 2 an dem momentanen geographischen Standort der MS versorgt. Das HLR 18 und die CSC 26 bilden gemeinsam einen anfänglichen Heimatdienst („anfänglich (initial)"), werden aber durch einen umgeleiteten Heimatdienst („umgeleitet (redirected)") ersetzt durch Weiterleiten des Sprachanrufs der mobilen Station 2 an den umgeleiteten Heimatdienst, wie beschrieben wird. Entlang der rechten Seite der 4C sind Labels (Schritte), die Schritte in dem Signalisierungsverfahren anzeigen.
Unter Bezugnahme auf Schritt 100 in 4C wird in Schritt 100, der den Schritten 51 und 53 von 4A entspricht, ein Anruf von der mobilen Station 2 („MS 2") an die CSC 26 geliefert. In Schritt 200 (Schritt 53 in 4A) emp fängt ein Operator an der anfänglichen CSC 26 den Anruf und beginnt einen Dialog mit dem Benutzer des Mobiltelefons. Während der Konversation des Operators der CSC mit dem Benutzer, bestimmt der Operator, dass der Benutzer dem umgeleiteten HLR 38 und der umgeleiteten CSC 44 zugewiesen werden sollte, 55 und 57 in 4A. Demgemäß initiiert in Schritt 300 der CSC-Operator ein Anrufweiterleitungsoperation (Schritt 59 in 4A), wobei der Anruf der mobilen Station 2 weitergeleitet wird an das umgeleitete HLR 38 und die umgeleitete CSC 44. Während dieser Anrufweiterleitungsoperation wird die TRN, die an der ersten CSC 26 von der MSC 10 empfangen wurde, an die umgeleitete CSC 44 gesendet. Dann spricht in Schritt 400 der Benutzer der mobilen Station 2 mit dem CSC-Operator an der umgeleiteten CSC 44 und liefert dem Operator der umgeleiteten CSC eine erforderliche Information zum Aufbau eines Dienstes für die mobile Station des Benutzers.
In Schritt 500 kontaktiert (löst aus, Schritt 511 in 4A) die CSC 44 das HLR 38 über die proprietäre Schnittstelle 36 (3) und überträgt die TRN an das HLR 38. Mit der TRN leitet das HLR die Adresse der MSC 10 ab basierend auf dem Identifizierbarkeitsmerkmal, das zu der TRN gehört.
In Schritt 600 überträgt das HLR 38 die TRN und einen Aktionscode in einer OTADienstprogrammierungs-INVOKE-Nachricht, OTASERPROG(TRN, Aktionscode) an das VLR 14, das dieselbe Nachricht in Schritt 700 einfach an die Ziel-MSC 10 weiterleitet. (Die Schritte 600 und 700 entsprechen dem Schritt 513 in 4A). Die OTASERPROG-Nachricht enthält zumindest zwei Felder, einschließlich einem Aktionscodefeld (ActionCode – Aktionscode) und einem TRN-Feld. Daten in dem Aktionscodefeld werden von der MSC 10 als „Verknüpfe die MSC mit dem HLR über eine Datenverbindung" interpretiert. Ein Wert, der die TRN darstellt, ist in dem TRN-Datenfeld enthalten und wird von der MSC verwendet, um die richtige MS der Datenverbindung zuzuordnen (d.h. HLR 38, VLR 14 und MSC 10), siehe Schritte 515 und 517 in 4B.
Die MSC 10 antwortet auf die Anforderung des HLRs 38 durch Ausgabe einer OTADienstprogrammierungs-RETURN RESULT-Nachricht, otaserprog (temporäre MSID, ESN, momentan in der mobilen Station gespeicherte MSID), siehe Schritt 519 in 4B. Die otaserprog-Nachricht berichtet effektiv die Identifikation der mobilen Station 2 an das HLR 38 in der Form einer ESN und der momentan in der mobilen Station gespeicherte MSID und sendet auch die temporäre MSID an das HLR.
In Schritt 900 leitet das VLR 14 die temporäre MSID, die momentan in der mobilen Station gespeicherte MSID und die ESN an das HLR 38 weiter, wo es von dem HLR 38 empfangen wird. Es wird angenommen, dass die temporäre MSID, die momentan in der mobilen Station gespeicherte MSID und die ESN während des Sprachanrufaufbaus nicht an die CSC kommuniziert wurden und somit von der MSC abgerufen werden müssen. Mit der temporären MSID und der ESN der mobilen Station kann das HLR 38 dann einen Datensatz der Programmierungsdaten der mobilen Station 2 speichern und kann relevante Teile der Programmierungsdaten an die mobile Station 2 senden über eine OTA-Datennachricht, die eingekapselt in eine OTESERPROG-Nachricht an die MSC gesendet wird, was in Schritt 904 gezeigt wird (Schritt 525 in 4B). Wie oben diskutiert wird, sobald die Programmierungsdaten an die mobile Station 2 heruntergeladen wurden, die mobile Station 2 von dem HLR angewiesen, die Programmierungsdaten in einem nichtflüchtigen Speicher zu speichern. Der Sprachanruf mit der umgeleiteten CSC 44 wird beendet. Als ein Ergebnis ist eine über-die-Luft-Dienstbereitstellung für die mobile Station erreicht. Die in der MS programmierte Information wird ebenso in dem nichtflüchtigen Speicher in dem HLR und/oder dem AC gespeichert.
In einem alternativen Anrufablauf weist die CSC 44 in Schritt 500 eine temporäre MSID zu, wobei das HLR 38 die TRN und die temporäre MSID in der OTASERPROG-Nachricht aufnimmt, die an die MSC 10 gesendet wird. Als Antwort sendet die MSC 10 eine ESN und die momentan in der MS gespeicherte MSID in den Schritten 800 und 900 zurück.
Zurück zu den „anderen Funktionen", die oben unter Bezugnahme auf den Schritt 523 von 4B diskutiert wurden. 4D ist ein Ablaufdiagramm der Verfahrensschritte zum Handhaben „anderer Funktionen". Die Beziehung zwischen den 4B und 4D ist derart, dass, wenn in dem Schritt 523 von 4B bestimmt wird, dass „andere Funktionen" durchgeführt werden sollen, bevor der über-die-Luft-Dienstbereitstellungsprozess weiter geht, der Prozess von Schritt 523 zu Schritt 539 in 4D weitergeht. Wenn keine „anderen Funktionen" implementiert werden sollen, geht der Prozess zu Schritt 525 weiter, wie in 4B gezeigt wird. „Andere Funktionen", wie in den Ausführungsbeispielen der vorliegenden Erfindung implementiert, werden unter Bezugnahme auf die 4D und die 6, 7 und 8 erläutert.
Die 4D ist ein Ablaufdiagramm eines Prozesses, der eine Fortsetzung des in 4B gezeigten Prozesses ist. In Schritt 539 bestimmt die CSC 26 (oder das HLR 18), ob ein A-Schlüssel-Herunterlade-Verfahren (das unter Bezugnahme auf die 6 beschrieben wird) durchzuführen ist, und führt das A-Schlüssel-Herunterlade-Verfahren in Schritt 540 aus und geht dann zu Schritt 541 weiter. Wenn in Schritt 539 bestimmt wird, dass kein A-Schlüssel-Herunterlade-Verfahren durchzuführen ist, geht der Prozess zu Schritt 541 weiter, wo abgefragt wird, ob ein SSD-Aktualisierungsverfahren (das unter Bezugnahme auf die 7 beschrieben wird) durchzuführen ist. Wenn dem so ist, geht der Prozess zu Schritt 542 weiter, wo das SSD-Aktualisierungsverfahren durchgeführt wird, und der Prozess geht zu Schritt 543 weiter. Wenn in Schritt 541 bestimmt wird, dass kein SSD-Aktualisierungsverfahren durchzuführen ist, geht der Prozess zu Schritt 543 weiter, wo abgefragt wird, ob ein Re-Authentisierungsverfahren (das unter Bezugnahme auf die 8 beschrieben wird) durchzuführen ist. Wenn dem so ist, geht der Prozess zu Schritt 544, wo das Re-Authentisierungsverfahren durchgeführt wird. Ansonsten kehrt der Prozess zu Schritt 525 in 4B zurück. Wenn ein A-Schlüssel-Herunterladen durchgeführt wird und wenn eine Sprachverschlüsselung und/oder eine Nachrichtenverschlüsselung erwünscht ist, geht die SSD-Aktualisierung notwendigerweise dem Re- Authentisierungsverfahren voraus. Das A-Schlüssel-Herunterlade-Verfahren, das SSD-Aktualisierungsverfahren und das Re-Authentisierungsverfahren werden im Folgenden detaillierter beschrieben.
Da das AC und das HLR getrennt voneinander sein können, nimmt die folgende Diskussion hinsichtlich der AC-Verfahren ein AG an, das von dem HLR getrennt ist.
Es gibt vier Operationen, an denen das AC beteiligt ist:

1) Erzeugen des A-Schlüssels und dessen Überfragen an die mobile Station (im Folgenden wird das Rivest-Shamir-Adleman(RSA)-Verfahren zum Herunterladen des A-Schlüssels implementiert, andere Verfahren für ein Herunterladen des A-Schlüssels können genauso verwendet werden);
2) Aktualisieren der SSD;
3) Erzeugen von VPMASK und SMEKEY; und
4) Speichern des A-Schlüssels und der SSD in einem nichtflüchtigen Speicher.

Es gibt mehrere Probleme, die adressiert werden müssen.

1) Wenn die Authentisierungs- und A-Schlüsselübertragungs-bezogenen Operationen initiiert werden, ist der Ansatz gemäß Ausführungsbeispielen der vorliegenden Erfindung, dies in dem AC zu tun. Somit empfängt das HLR den A-Schlüssel, den Entschlüsselungsexponenten oder das Produkt der Primzahlen P und Q nicht.
2) Wenn OTA-Datennachrichten für die A-Schlüssel-Übertragung erzeugt werden, wird die Nachricht in dem AC erzeugt, eingekapselt und entweder direkt oder über das HLR an die MSC/das VLR geleitet. Alternativ werden die Parameter in dem AC erzeugt und an das HLR geleitet, wo die OTA-Datennachrichten gebildet werden. Der erste Ansatz ist vorzuziehen.
3) Ob die CSC direkt mit dem AC eine Schnittstelle bildet oder über das HLR, das HLR hat die Steuerung und somit hat die CSC im Wesentlichen nur eine Schnittstelle mit dem HLR.
4) Das AC muss von dem HLR ausgelöst werden, um die geeigneten OTA-Datennachrichten zu erzeugen. Ähnlich muss das AC das HLR informieren, wenn das AC seine Aktion beendet hat.

Das A-Schlüssel-Herunterlade-Verfahren gemäß einem Ausführungsbeispiel der vorliegenden Erfindung wird unter Bezugnahme auf die 6 beschrieben. In 6 wird in Schritt 1500 die neue IS-41-Authentisierungscentrum-Anweisung(AuthenticationCenterDirective)-INVOKE-Nachricht, ACDIR (temporäre MSID, ESN, ACACTION) von dem HLR 18 oder 38 erzeugt und an das AC 22 oder 42 gesendet. Diese INVOKE-Nachricht enthält das ACACTION-Feld, das das AC 22 anweist, ein A-Schlüsel-Herunterladen für die fragliche mobile Station 2 durchzuführen (1). Die mobile Station 2 wird identifiziert durch Werte, die in den Datenfeldern der temporären MSID und der ESN der ACDIR-Nachricht enthalten sind.
In Schritt 1600 überträgt das AC 22 (oder 42) die temporäre MSID, die ESN und einen öffentlichen Verschlüsselungsschlüssel, der an dem AC erzeugt wird, in einer OTA-Datennachricht, OTASERPROG[MIN, ESN, OTA-Datennachricht]-Nachricht, an das HLR 18 (oder HLR 38) über eine OTA-Dienstprogrammierungs-INVOKE-Nachricht. Die OTASERPROG-Nachricht wird von dem HLR über das VLR an die MSC weitergeleitet. An der MSC wird die OTA-Datennachricht, welche den öffentlichen Verschlüsselungsschlüssel enthält, an die mobile Station gesendet. Sobald die mobile Station 2 in Besitz des öffentlichen Verschlüsselungsschlüssels ist, verwendet sie diesen, um eine Sitzungsmaske zu codieren, die sie in einer OTA-Datennachricht an die MSC überträgt.
In Schritt 1900 antwortet die MSC 10 über die OTADienstprogrammierungs-RETURN RESULT-Nachricht, otaserprog[OTA-Datennachricht], welche die codierte Sitzungsmaske in der OTA-Datennachricht enthält. Die otaserprog-Nachricht wird in den Schritten 2000 und 2100 an das AC weitergeleitet.
Das AC decodiert die Sitzungsmaske, da es den öffentlichen Verschlüsselungsschlüssel und andere Parameter hat, die verwendet werden, um den öffentlichen Verschlüsselungsschlüssel zu berechnen. Das AC wählt einen A-Schlüssel und codiert diesen unter Verwendung der Sitzungsmaske. In Schritt 2200 überträgt das AC 22 (oder 42) die temporäre MSID, die ESN und die OTA-Datennachricht, die den codierten A-Schlüssel enthält, in der OTADienstprogrammierungs-INVOKE-Nachricht, OTASERPROG(temporäre MSID, ESN, OTA-Datennachricht) an das HLR. Die Schritte 2300 und 2400 leiten den codierten A-Schlüssel des ACs an die mobile Station 2. Die MS kann den A-Schlüssel decodieren, da sie die Sitzungsmaske hat, die von dem AC verwendet wurde, um den A-Schlüssel zu codieren.
In Schritt 2500 überträgt die MSC 10 von der mobilen Station 2 eine OTA-Datennachricht, die eine Bestätigung enthält, dass der A-Schlüssel erfolgreich in einer OTA-Datennachricht empfangen wurde, in einer OTA-Dienstprogrammierungs-RETURN RESULT-Nachricht, otaserprog[OTA-Datennachricht]. In den Schritten 2600 und 2700 wird die Bestätigung der mobilen Station 2 an das AC weitergeleitet.
In Schritt 2800 sendet das AC 22 oder 42 eine leere Authentisierungscentrums-Anweisung(AuthenticationCenterDirective)-RETURN RESULT an das HLR 18 oder 38 als eine Bestätigung für das HLR 18 oder 38, dass die Anforderung des HLRs, ein A-Schlüssel-Herunterladen in Schritt 1500 aufzurufen, nun abgeschlossen ist.
Das SSD-Aktualisierungsverfahren wird unter Bezugnahme auf 7 beschrieben. Das beispielhafte Verfahrens- und Signalisierungsschema, das in 7 gezeigt wird, entspricht dem Fall, in dem die SSD nicht gemeinsam benutzt werden. Da die CSC tatsächlich nicht entscheiden kann, die Parameter festzuschreiben, die in die mobile Station 2 heruntergeladen wurden, ist es vorzuziehen, dass die SSD nicht gemeinsam benutzt werden während einer SSD-Aktualisierung während einer OTA-Dienstprogrammierung. Nichtsdestotrotz kann ein gemeinsames Benutzen von SSD verwendet wer den. Es ist anzumerken, dass signifikante Modifizierungen von IS-41-C nicht erforderlich sind, um das SSD-Aktualisierungsverfahren gemäß Ausführungsbeispielen der vorliegenden Erfindung zu implementieren. Das AC wird von dem HLR ausgelöst, um eine SSD-Aktualisierung durchzuführen, und das HLR wird von dem AC am Ende des SSD-Aktualisierungsverfahrens informiert.
Der Schritt 2900 in dem Anrufablaufdiagramm von 7 zeigt eine neue IS-41-Authentisierungscentrums-Anweisung(AuthenticationCenterDirective)-INVOKE-Nachricht, ACDIR [temporäre MSID, ESN, ACACTION, momentan in der MS vorhandene MSID], die von dem HLR an das AC übertragen wird, um anzufordern, dass ein SSD-Aktualisierungsverfahren durchgeführt wird. Die Nachricht enthält ein ACACTION-Feld, welches das AC 22 (oder 42, wenn das HLR 38 gewählt ist) anweist, eine SSD-Aktualisierung durchzuführen. Die SSD-Aktualisierungsoperation kann begonnen werden unmittelbar nachdem der A-Schlüssel auf die mobile Station heruntergeladen wurde. Die Schritte 3000–5300 sind ähnlich zu denen, die für ein SSD-Aktualisierungsverfahren in IS41-C existieren. Es sollte angemerkt werden, dass die oft in der MS gespeicherte MSID an das AC gesendet wird zur Verwendung bei der Berechnung der Authentisierungsantwort an eine Basisstation-Abfrage von der MS. Basisstation-Abfrageverfahren bilden einen Teil des SSD-Aktualisierungsverfahrens.
In Schritt 5400 sendet das HLR 18 (oder 38) eine leere Authentisierungscentrums-Anweisung(AuthenticationCenterDirective)-Nachricht, acdir[], an das AC 22 (oder 42) als eine Bestätigung, wodurch das SSD-Aktualisierungsverfahren abgeschlossen ist.
Eine Re-Authentisierung zum Ermöglichen einer Sprachverschlüsselung, Nachrichtenverschlüsselung oder beidem wird wie folgt erreicht.
Eine Re-Authentisierung wird implementiert durch den Anrufablauf, der in 8 gezeigt wird. In dieser Zeichnung enthält in Schritt 5500 die neue IS- 41-Authentisierungscentrum-Anweisung(AuthenticationCenterDirective)-INVOKE-Nachricht, ACDIR [temporäre MSID, ESN, DGTSDIAL, ACACTION] das ACACTION-Feld, welches das AC 22 (oder AC 42, wenn das HLR 38 gewählt wird) anweist, das Re-Authentisierungsverfahren durchzuführen. Ebenso sind in der Nachricht die temporäre MSID, die ESN und DGTSDIAL-Parameter (von der mobilen Station gewählte Ziffern) enthalten.
In Schritt 5600 überträgt das AC 22 (oder 42) eine OTA-Datennachricht, die eine zufällige Zahl (RAND – Random Number) enthält, an das HLR 18 (oder HLR 38, wenn gewählt) über die OTADienstprogrammierungs-INVOKE-Nachricht, OTASERPROG[OTA-Datennachricht], die schließlich von der MSC 10 empfangen wird. Die Schritte 5700 und 5800 leiten die Nachricht an die MSC 10 weiter. An der MSC 10 wird die OTA-Datennachricht, die RAND enthält, an die mobile Station gesendet. Die mobile Station berechnet eine Authentisierungsantwort (AUTHR – Authentication Response) und sendet sie zusammen mit anderen Parametern in einer OTA-Datennachricht an die MSC 10.
In Schritt 5900 antwortet die MSC 10 auf die Nachricht des ACs durch Senden der OTA-Datennachricht, die AUTHR enthält, über eine OTA-Dienstprogrammierungs-RETURN RESULT-Nachricht, otaserprog[OTA-Datennachricht], an das VLR 14. Die Schritte 6000 und 6100 leiten die Nachricht der MSC an das AC 22.
In Schritt 6200 bestimmt das AC 22, dass die mobile Station korrekt reauthentisiert wurde und sendet die SMEKEY- und VPMASK-Parameter über eine Authentisierungscentrum-Anweisung(AuthenticationCenterDirective)-RETURN RESULT-Nachricht, acdir[SMEKEY, VPMASK], an das HLR 18. Die Schritte 6300 und 6400 leiten diese Parameter in einer OTA-Dienstprogrammierungs-INVOKE-Nachricht an die MSC 10 weiter. Wenn die MSC 10 SMEKEY und VPMASK hat, ist sie eingerichtet, eine Sprachverschlüsselung und Nachrichtenverschlüsselung einzusetzen.
In Schritt 6500 sendet die MSC 10 eine leere OTADienstprogrammierungs-RETURN RESULT-Nachricht, otaserprog[], die als Bestätigung dient, dass VPMASK und SMEKEY an der MSC 10 empfangen wurden und die in Schritt 6600 an das HLR weitergeleitet wird.
Während die VPMASK und SMEKEY-Parameter in der OTADienstprogrammierungs-INVOKE-Nachricht enthalten sein können, wenn sie das erste Mal an die MSC gesendet wird, und den RAND-Parameter überträgt, der in der OTA-Datennachricht eingekapselt ist, werden vorzugsweise diese Parameter an die MSC gesendet, nachdem das AC die Re-Authentisierungs-Antwort der MS empfängt. Dies wird bevorzugt, da die MSC nicht bestimmen muss, ob der Re-Authentisierungs-Prozess der mobilen Station bei diesem Verfahren erfolgreich war, das AC kennt diese Information und sendet VPMASK und SMEKEY an nur an die MSC, wenn die MS erfolgreich re-authentisiert wird.
Modifikationen zu dem IS-41-Netzwerk gemäß Ausführungsbeispielen der vorliegenden Erfindung zur Implementierung einer Re-Authentisierung, um eine Sprachverschlüsselung, Nachrichtenverschlüsselung oder beides zu ermöglichen, sind, VPMASK und SMEKEY in der OTADienstprogrammierungs-INVOKE-Nachricht aufzunehmen.
Zurück zu Schritt 533 der oben diskutierten 4B, eine Registrierung der mobilen Station 2 nach einer OTA-Dienstprogrammierung.
Wenn die OTA-Dienstprogrammierung erfolgreich war und die MSID sich änderte, sollte die MSC/das VLR jeden Datenbankeintrag für die alte MSID löschen. Die versorgende MSC/VLR sollte eine Registrierungsbenachrichtigung an das HLR senden, um die mobile Station 2 zu registrieren und um das Profil des Benutzers zu erlangen. Wenn die MSID sieh nicht änderte, dann kann das HLR die versorgende MSC/das VLR mit der IS41 C-Betriebs-Qualifikationsanweisung und die Authentisierungsanweisung aktualisieren basierend auf der in dem HLR gespeicherten Information.
Wenn sich die MSID geändert hat, ist wünschenswert, dass die MSC/das VLR normale IS-41-Registrierungsoperationen durchführen und die Benutzerprofile erlangen. Jedoch kennt die MSC die neue MSID nicht, außer die MSC hat die OTA-Datennachricht geparst, was nicht wünschenswert ist.
In IS-683, dem CDMA-Luftschnittstellenstandard für die über-die-Luft-Dienstprogrammierung, sind die Registrierungsparameter der mobilen Station nicht auf Werte gesetzt, die eine Registrierung veranlassen, wenn die mobile Station eine OTA-Dienstprogrammierung beendet und zurückkehrt zur Überwachung eines Steuerungskanals. Da die mobile Station die korrekte Systemidentifikationsnummer (SID – system identification number), Netzwerkidentifizierungsnummer (NID – network identification number) und Registrierungszonen haben kann, kann eine Registrierung nicht stattfinden, bis die mobile Station einen Anruf tätigt, die mobile Station sich bewegt und eine Registrierung ausgelöst wird oder der Timer der mobilen Station abläuft und eine periodische Registrierung durchführt. Während des Betriebs in dem CDMA-Modus kann die mobile Station dazu gezwungen werden, sich zu registrieren (unter der Annahme, dass die geeigneten Registrierungsverfahren in der IS-95-Systemparameter-Nachricht aktiviert werden) durch Senden der „IS-95 mobile Station registriert"-Nachricht an die mobile Station, wobei die Parameter auf Werte gesetzt sind, die eine Registrierung auslösen. Zum Beispiel löst ein Setzen der SID gleich 0 eine Registrierung aus, wenn eine Parameterregistrierung oder Zonen-basierte Registrierung möglich ist. In dem CDMA-Modus kann die Basisstation die MIN (IMSI) durch eine IS-95-Statusnachricht erlangen. Diese Verfahren können bei der Durchführung einer OTA-Dienstprogrammierung in dem analogen Modus nicht verwendet werden.
Alternativ kann eine Registrierung durchgeführt werden durch Übertragen der neuen MSID an die MSC in einer der OTA-Dienstprogrammierungsnachrichten, da die MSC nur die temporäre MSID und die vorher in der MS gespeicherte MSID hat. Dies ermöglicht der MSC, die IS-41-Registrierungsbenachrichtigungsoperation durchzuführen. Eine weitere Al ternative ist, IS-683 und andere Luftschnittstellen-OTASP-Standards zu modifizieren, damit die mobile Station ihre Registrierungsvariablen löscht bei der Durchführung einer OTA-Dienstprogrammierung. Dies veranlasst die mobile Station, sich zu registrieren, wenn sie zurückkehrt zu dem CDMA-Paging-Kanal oder dem analogen Steuerungskanal.
Bei Empfang einer erfolgreichen Anzeige der OTA-Dienstprogrammierung, in der sich die MSID geändert hat, sollte die versorgende MSC auch die alte MSID aus ihrer Datenbank löschen und die existierende IS-41-C-MSInaktiv-Operation mit der alten MSID (siehe 5) an das alte HLR durchführen. Es kann wünschenswert sein, dem alten HLR anzuzeigen, dass die MSID der mobilen Station geändert wurde. Dies kann helfen, einen betrügerischen Zugang zu dem Netzwerk zu verhindern.
Eine Freigabe eines Anrufs wird wie folgt erreicht.
Der Anruf kann von der mobilen Station freigegeben werden, wenn die Dienstprogrammierungssitzung abgeschlossen ist. Er sollte auch von der CSC freigegeben werden können, wenn die Dienstprogrammierungssitzung abgeschlossen ist.
Die obige Beschreibung der bevorzugten Ausführungsbeispiele ist vorgesehen, um Fachleuten zu ermöglichen, Ausführungsbeispiele der vorliegenden Erfindung herzustellen oder zu verwenden. Die verschiedenen Modifizierungen zu diesen Ausführungsbeispielen sind für Fachleute offensichtlich und die hier definierten generischen Prinzipien können auf andere Ausführungsbeispiele angewendet werden ohne die Verwendung der erfinderischen Fakultät. Somit soll die vorliegende Erfindung nicht auf die hier gezeigten Ausführungsbeispiele beschränkt sein, sondern soll dem weitesten Umfang entsprechen, wie von den Ansprüchen definiert.

Claims

Ein Verfahren zum Fernprogrammieren einer Mobilstation (2), die ein versorgendes System besucht, wobei das Verfahren gekennzeichnet ist durch: Initiieren eines Kontaktes mit dem versorgenden System durch die Mobilstation (2); Zuweisen eines vorübergehenden bzw. Transient-Identifizierers für die Mobilstation (2) bei dem versorgenden System; Senden des Transient-Identifizierers von dem versorgenden System zu einem Heimatregister (18, 38); Aufbauen einer Datenverbindung zwischen dem Heimatregister (18, 38) und der Mobilstation (2), wobei das versorgende System als ein Transportmedium für die Datenverbindung dient; Senden von Instruktionen zu einem Prozessor der Mobilstation (2) von dem Heimatregister (18, 38).
Verfahren nach Anspruch 1, wobei das Senden des Transient-Identifizierers Folgendes aufweist: Weiterleiten des Transient-Identifizierers von dem versorgenden System zu einer Kundendienstzentrale (26, 44); und Bestimmen der Identität bei dem Heimatregister (18, 38) bei der Kundendienstzentrale (26, 44).
Verfahren nach Anspruch 2, wobei das Programmieren das Weiterleiten einer Dienstprogrammierungsnachricht über die Datenverbindung von dem Heimatregister (18, 38) zu der Mobilstation (2) aufweist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das versorgende System eine Basisstation (6) und eine Mobilvermittlungsstelle (10) aufweist.
Verfahren nach Anspruch 1, wobei der Transient-Identifizierer bei einer Vermittlungsstelle (10) innerhalb des versorgenden Systems angeordnet ist, wobei das Verfahren weiterhin Folgendes aufweist: Abrufen eines Mobilstationsidentifizierers von der Vermittlungsstelle (10) durch das Heimatregister (18, 38).
Verfahren nach Anspruch 5, wobei das Programmieren der Mobilstation (2) das Verändern von Information in der Mobilstation (2) aufweist.
Verfahren nach Anspruch 5, wobei das Programmieren der Mobilstation (2) das Authentifizieren der Mobilstation (2) aufweist.
Verfahren nach Anspruch 5, wobei das Senden des Transient-Identifizierers Folgendes aufweist: Senden des Transient-Identifizierers zu einer Kundendienstzentrale (26, 44); und Weiterleiten des Transient-Identifizierers von der Kundendienstzentrale (26, 44) zu dem Heimatregister (18, 38).
Verfahren nach Anspruch 8, wobei das Zuordnen des Transient-Identifizierers durch einen Sprachanruf von der Mobilstation (2) zu der Kundendienstzentrale (26, 44) initiiert wird.
Verfahren nach Anspruch 9, wobei das Aufbauen der Datenverbindung Folgendes aufweist: Zuordnen des Sprachanrufs zu der Datenverbindung bei der Vermittlungsstelle (10); und Zuweisen eines Registers für die Mobilstation (2) bei dem Heimatregister bzw. -registrierung (18, 38).
Verfahren nach einem der Ansprüche 5 bis 10, wobei: das Senden des Transient-Identifizierers geschieht durch ein Besucherortsregister bzw. visitor location registry (14).
Verfahren nach einem der Ansprüche 5 bis 11, wobei die Datenverbindung, die zwischen dem Heimatregister (18, 38) und der Mobilstation (2) aufgebaut ist, ausgeführt wird unter Verwendung des Mobilstationsidentifizierers.
Ein System zum Fernprogrammieren einer Mobilstation (2), wobei das System gekennzeichnet ist durch: eine Mobilvermittlungsstelle (10), die konfiguriert ist zum: Zuweisen eines vorübergehenden bzw. Transient-Identifizierers für die Mobilstation (2); und ein Heimatsystem (18, 20, 22, 38, 40, 42), das konfiguriert ist zum: Speichern eines Satzes von Instruktionen für einen Prozessor, der in der Mobilstation (2) angeordnet ist; Aufbauen einer Datenverbindung zwischen der Mobilstation (2) und dem Heimatregister (18, 38), wenn das Heimatsystem (18, 20, 22, 38, 40) den Transient-Identifizierer von der Mobilstation (2) empfängt; Senden der Instruktionen zu der Mobilstation (2) von dem Heimatregister (18, 38); wobei die Mobilvermittlungsstelle (10) verwendet wird als Leitung bzw. Weiterleitung für die Übertragung der Instruktionen.