-
Technisches
Gebiet
-
Die
vorliegende Erfindung betrifft eine Schnittstelle (LEM), die wirkt,
um einem Teilnehmerendgerät
in einem WIN-Netzwerk einen auf CAMEL basierenden Dienst bereitzustellen,
ein Verfahren zur Bereitstellung eines auf CAMEL basierenden Dienstes
für ein
Teilnehmerendgerät
in einem WIN-Netzwerk, eine Schnittstelle (LEM), die wirkt, um einem
Teilnehmerendgerät
in einem CAMEL-Netzwerk einen auf WIN basierenden Dienst bereitzustellen,
und ein Verfahren zur Bereitstellung eines auf WIN basierenden Dienstes
für ein
Teilnehmerendgerät
in einem CAMEL-Netzwerk.
-
Allgemeiner
Stand der Technik
-
Die
Mehrwertdienstablieferungsmechanismen in derzeitigen leitungsvermittelten
mobilen Netzwerken basieren im allgemeinen auf Techniken des intelligenten
Netzwerks (IN). In Netzwerken, die auf GSM (Global System for Mobiles)
oder UMTS (Universal Mobile Telecommunications System) basieren,
werden solche Dienste des IN-Typs unter Verwendung eines als CAMEL
(Customized Application for Mobile Enhanced Logic) bekannten Standards
eingesetzt. In Netzwerken, die auf ANSI IS-41 basieren, werden solche
Dienste des IN-Typs unter Verwendung eines als WIN (Wireless Intelligent
Network) bekannten Standards eingesetzt. Die beiden Protokolle CAMEL
und WIN sind nicht kompatibel. Dadurch entsteht der Umstand, daß Dienste,
die auf der CAMEL-Dienstumgebung
basieren, nicht direkt in auf WIN basierenden Netzwerken eingesetzt
werden können
und umgekehrt. Wandernden mobilen Teilnehmern können die betreiberspezifischen
Dienste (OSS – Operator
Specific Services) nicht bereitgestellt werden, während sie
in einem Netzwerk wandern, das ein inkompatibles IN-Dienstprotokoll unterstützt.
-
Von
drahtlosen Netzwerken der dritten Generation wird erwartet, daß sie das
mobile Internet realisieren werden, wodurch mobilen Teilnehmern
ein schneller Internetzugang und schnelle Datendienste angeboten werden.
Damit Netzwerkbetreiber die schnelle Entwicklung innovativer Mehrwertanwendungen
auf dem heute im Internet zu sehenden Maßstab berücksichtigen können, muß das drahtlose
Kernnetzwerk für
durch unabhängige
Softwarevertreiber bereitgestellte Anwendungen Dritter geöffnet werden.
Das Drittgenerations-Partnerschaftprojekt
(3GPP) arbeitet gerade an der Erstellung technischer Spezifikationen
zur Bereitstellung eines Mechanismus, der unabhängigen Softwarevertreibern
eine Standardschnittstelle gestatten würde, um auf Netzfähigkeiten
zuzugreifen, die traditionell Netzbetreibern selbst verfügbar sind.
In 3GPP wird dieser Mechanismus gewöhnlich als Open Service Access
(OSA) bezeichnet. Dieser Open Service Access ist vorherrschend auf
Netzwerke des Typs UMTS (Universal Mobile Telecommunications Networks)
abgezielt, wodurch Anwendungsentwickler auf die merkmalsreichen
Kernnetzwerkfähigkeiten
zugreifen können.
-
Der
Erfolg von Neudienstbereitstellung und Ablieferplattformen kann
von ihrer Fähigkeit
abhängen, sich
mit existierenden Technologien zu mischen, wodurch Programmierbarkeit
von Dienstplattformelementen wie zum Beispiel Netzwerkknoten, Steuerknoten
und Gateways geboten wird, während
in der Zwischenzeit die Integrität
der zugrundeliegenden Netzwerkgeräte erhalten wird. Ein Ansatz,
der von verschiedenen Industrieinitiativen wie. zum Beispiel Parlay
demonstriert wurde, besteht darin, eine Menge von Anwendungsprogrammierschnittstellen
(APIs) des offenen Netzwerks zu entwickeln, die diese Art von Programmierbarkeit
und Integrität
bietet. Die Ermöglichung
einer schnellen Entwicklung von Anwendungen wird erreicht, indem
das Netzwerk so geöffnet
wird, daß Anwendungsentwickler
keine extensive Kenntnis der Komplexität der Netzwerkzeichengabe besitzen
müssen.
Fernsprechzeichengabeprotokolle sind relativ komplex und die Entwicklung
neuer Dienste, die zum Beispiel auf intelligenten Netzwerken basieren,
erfordert Erfahrungskenntnis auf dem Gebiet des INAP (Intelligent
Network Application Protocol) und des TCAP (Transactions Capability
Applications Part). Eine auf dem Output der Parlay-Gruppe basierende
Architektur ist in den 3GPP-Spezifikationen als Open Service Access
(OSA) bekannt. Open Service Access liefert Anwendungsentwicklern
eine Abstraktion der Funktionalität, die in dem Kernnetzwerk
verankert ist. Die Abstraktion wird erhalten durch Definieren der
Kernnetzwerkfunktionalität über die
sogenannten Service Capability Features (SCFs), die als Technologie
unabhängige Baublöcke betrachtet
werden sollten, die über
standardisierte Schnittstellen zugänglich sind. Sie repräsentieren
die grundlegende Funktionalität,
die in dem Netzwerk verfügbar
ist. Zu Service Capability Features gehören Verbindungssteuerung, Benutzerstandortfindung
und Benutzerinteraktion, und sie werden durch Service Capability
Servers (SCS) in dem Bereich eines Netzwerkbetreibers unterstützt. Das
Service Capability Feature der Benutzerinteraktion kann zum Beispiel
auf einem WAP-Gateway (WGW) oder auf dem Heimatregister (HLR) unterstützt werden,
während
das Service Capability Feature der Verbindungssteuerung durch die
CAMEL-Dienstumgebung (CSE) unterstützt werden kann. Die Anwendungen
selbst werden auf Anwendungsservern ausgeführt, die außerhalb oder innerhalb des
Netzwerkbetreiberbereichs verankert sein können. Die Dienstlogik der auf
dem Anwendungsserver ablaufenden Anwendungen wird in Richtung der
Schnittstelle des Open Service Access ausgeführt, während die Service Capability
Servers proprietäre
Protokolle zur Kommunikation mit den Netzwerkknoten verwenden. Das
Konzept des Open Service Access ist in 1 gezeigt,
worin die Beziehung zwischen den Netzwerkknoten, SCS (Service Capability
Servers), SCF (Service Capability Features) und den Anwendungsservern
Dritter gezeigt sind. Open Service Access wird von der Drittgenerations-Projektpartnerschaft
(bekannt als 3GPP) spezifiziert. Diese Organisation veröffentlicht
Spezifikationen auf der Basis eines Herausgabephasenplans, wobei
jede Herausgabe zusätzliche
Funktionalität
bereitstellt. Die erste Menge von Spezifikationen gemäß 3GPP UMTS
wird als Release 99 bezeichnet. Nachfolgende Herausgaben werden
als Release 4 und Release 5 bezeichnet. Für jede Herausgabe ist eine
Menge von Spezifikationen für
Open Service Access (OSA) verfügbar.
-
Eine
bekannte Client-Anwendung des Open Service Access, die auf einem
Open Service Access Application Server (OSA AS) abläuft, ist
in 2 gezeigt. Das Open Service Access Gateway (OSA
GW) enthält proprietäre Schnittstellen
in Richtung einer CAMEL-Dienstumgebung (CSE) bzw. CAMEL Service
Control Point und einen WIN Service Control Point, wie in der technischen
Spezifikation 23.127 des Drittgenerations-Partnerschaftsprojekts beschrieben.
Durch Verwendung dieser Architektur können neuentwickelte Client-Anwendungen des Open
Service Access sowohl in einem 3G-Netzwerk auf WIN-Basis als auch in einem 3G-Netzwerk
auf CAMEL-Basis eingesetzt werden.
-
Bekannte
Einsätze
für die
WIN/CAMEL-Zusammenarbeit benutzten eine Einführung eines eigenen Protokollkonvertierers
zwischen der Mobilvermittlungszentrale (MSC) in dem GSM-/UMTS-Netzwerk und der WIN-Plattform
und einen Protokollkonvertierer zwischen der Mobilvermittlungszentrale
(MSC) in dem ASNI41-/IS-95-Netzwerk
und der CSE. Dies ist ein komplexer und unhandlicher Ansatz.
-
Kurze Darstellung
der Erfindung
-
Die
vorliegende Erfindung liefert eine Schnittstelle (LEM), die wirkt,
um einem Teilnehmerendgerät
in einem WIN-Netzwerk einen auf CAMEL basierenden Dienst bereitzustellen,
indem bewirkt wird, daß der
auf CAMEL besierende Dienst dem WIN-Netzwerk als eine Anwendung
gemäß dem Standard
Open Service Access (OSA) erscheint, wobei die Schnittstelle eine
Schnittstelle des Open Service Access (OSA) zu einem Open Service
Access Gateway (OSA GW) des WIN-Netzwerks umfaßt und wirkt, um empfangene
Nachrichten des Open Service Access (OSA) in CAMEL-Anwendungsprotokollnachrichten
zu konvertieren.
-
Vorteile
der vorliegenden Erfindung in ihren bevorzugten Ausführungsformen
bestehen darin, daß ein Mechanismus
zur Unterstützung
von Diensten auf der Basis der Legacy-CAMEL-Dienstumgebung (CSE)
in einem auf IS-41 WIN basierenden Netzwerk bereitgestellt wird.
Dadurch wird das Ziel erreicht, daß es möglich wird, auf CAMEL basierende
Dienste auf ein Netzwerk anzuwenden, das nur WIN unterstützt. Dies
ist wesentlich billiger als die Entwicklung einer „Legacy"-Protokollschnittstelle auf der Verbindungszustandssteuerfunktion
(CSCF – Call
State Control Function). Außerdem
dient der Ansatz als eine Überlagerungslösung über standardisierte
WIN- und CRMEL-Kernnetzwerke, d. h. es besteht keine Auswirkung
auf die existierenden Entitäten
in den WIN- und CAMEL-Netzwerken. Außerdem ist der Ansatz des Legacy
Envelope Module vollständig mit
den Standards von 3GPP/Parlay kompatibel.
-
Vorzugsweise
werden auf CAMEL-basierende Teilnehmerinformationen auf das WIN-Netzwerk
abgebildet, wobei die Schnittstelle als ein WIN-Heimatregister (HLR)
wirkt.
-
Vorzugsweise
wirkt die Schnittstelle zum Weiterleiten der Teilnehmerinformationen,
indem eine getNotification-Operation des Open Service Access (OSA)
mit einer WIN-Registrationsmodifikationsoperation (REGNOT) in Beziehung
gesetzt wird.
-
Nachdem
eine Dienstanforderung in bezug auf das Teilnehmerendgerät gestellt
wurde, wird vorzugsweise eine empfangene reportNotification des
Open Service Access (OSA) in einen Initial Detection Point des CAMEL-Anwendungsprotokolls
konvertiert.
-
Die
vorliegende Erfindung liefert außerdem ein Mobiltelekommunikationssystem,
das ein WIN-Netzwerk, eine Schnittstelle und ein Teilnehmerendgerät umfaßt, wobei
das Teilnehmerendgerät
ein CAMEL-Teilnehmerendgerät
ist, das in das WIN-Netzwerk gewandert ist, wobei die Schnittstelle
eine Schnittstelle des Open Service Access (OSA) zu einem Open Service
Access Gateway (OSA GW) des WIN-Netzwerks umfaßt und wirkt, um empfangene
Nachrichten des Open Service Access (OSA) in CAMEL-Anwendungsprotokollnachrichten
zu konvertieren.
-
Die
vorliegende Erfindung liefert außerdem ein Verfahren zur Bereitstellung
eines auf CAMEL-basierenden
Dienstes für
ein Teilnehmerendgerät
in einem WIN-Netzwerk, bei dem eine Schnittstelle (LEM) bereitgestellt
wird, die bewirkt, daß der
auf CAMEL basierende Dienst dem WIN-Netzwerk als eine Anwendung
gemäß dem Standard
Open Service Access (OSA) erscheint, wobei die Schnittstelle eine
Schnittstelle des Open Service Access (OSA) zu einem Gateway des
Open Service Access (OSA GW) des WIN-Netzwerks umfaßt und empfangene
Nachrichten des Open Service Access (OSA) in CAMEL-Anwendungsprotokollnachrichten konvertiert.
-
Die
vorliegende Erfindung liefert außerdem eine Schnittstelle (LEM),
die wirkt, um einem Teilnehmerendgerät in einem CAMEL-Netzwerk einen
auf WIN basierenden Dienst bereitzustellen, indem bewirkt wird, daß der auf
WIN basierende Dienst dem CAMEL-Netzwerk als eine CAMEL-Anwendung
(CAP) erscheint, wobei die Schnittstelle eine WIN-Schnittstelle
zu einer WIN-Plattform
des WIN-Netzwerks umfaßt
und CAMEL-Anwendungsprotokollnachrichten
in die WIN-Plattform übersetzt.
-
Die
vorliegende Erfindung liefert außerdem ein Verfahren zur Bereitstellung
eines auf WIN basierenden Dienstes für ein Teilnehmerendgerät in einem
CAMEL-Netzwerk,
bei dem eine Schnittstelle (LEM) bereitgestellt wird, die bewirkt,
daß der
auf WIN basierende Dienst dem CAMEL-Netzwerk als eine CAMEL-Anwendung (CAP) erscheint.
-
Kurze Beschreibung
der Zeichnungen
-
Es
wird nun beispielhaft und mit Bezug auf die Zeichnungen eine bevorzugte
Ausführungsform
der vorliegenden Erfindung beschrieben. Es zeigen:
-
1 eine
Diagrammdarstellung der Architektur des Open Service Access (Stand
der Technik),
-
2 eine
Diagrammdarstellung einer Anwendung des Open Service Access, die
sowohl in einem WIN- als auch einem CAMEL-Netzwerk eingesetzt wird
(Stand der Technik),
-
3 eine
Diagrammdarstellung von Diensten der Legacy-CAMEL-Dienstumgebung,
die an einen CAMEL-Teilnehmer
abgeliefert werden, der in einem WIN-Netzwerk (RNSI41/IS95) wandert,
-
4 eine
Diagrammdarstellung, wie für
die Dienstbereitstellung für
den in 3 gezeigten CAMEL-Teilnehmer ein Trigger-Profil eingerichtet
wird,
-
5 eine
Diagrammdarstellung eines Dienstaufrufs der CAMEL-Dienstumgebung
in einem WIN-Netzwerk und
-
6 eine
Diagrammdarstellung eines an einen in einem CAMEL-Netzwerk wandernden
WIN-Teilnehmer abgelieferten Dienstes.
-
Ausführliche
Beschreibung
-
CAMEL-Teilnehmer in einem
WIN-Netzwerk
-
Wieder
mit Bezug auf 1, worin gezeigt war, wie neue
Anwendungen unter Verwendung des Open Service Access (OSA) sowohl
in WIN- als auch in CAMEL-Netzwerken
eingesetzt werden konnten, entsteht die Frage, wie eine existierende
Anwendung, d. h. eine Anwendung auf der Basis der Legacy-CAMEL-Dienstumgebung
(CSE) in einem WIN-Netzwerk eingesetzt werden kann? Diese Frage
ist für
Netzwerkbetreiber relevant, die beide Arten von Netzwerken betreiben
und dabei aus wirtschaftlichen Gründen eine Wiederverwendung
existierender Dienstlogik suchen. Die Frage betrifft auch CAMEL-Teilnehmer,
die in ein WIN-Netzwerk wandern und dort immernoch wünschen würden, ihre
Operator Specific Services auf CAMEL-Basis zur Verfügung zu
haben.
-
3 zeigt
eine bevorzugte Systemarchitektur, wodurch ein GSM-/UMTS-Teilnehmer,
der in einem Netzwerk gemäß ANSI41/IS
95 wandert (mit entsprechendem Endgerät), Zugang zu seinen CAMEL-Diensten haben
kann. In dem UMTS-/GSM-Netzwerk weist das Legacy Envelope Module
LEM eine CAMEL-Anwendungsprotokollschnittstelle zu der CAMEL-Dienstumgebung
sowie zu den Mobilvermittlungszentralen (MSCs) in dem Netzwerk auf.
Von der CSE-Perspektive
aus gesehen wirkt das Legacy Envelope Module LEM als eine Vermittlungsplattform
(d. h. eine MSC), während
es von der MSC-Perspektive aus gesehen als eine auf dem Äquivalent
einer CSE ablaufende Dienstlogik wirkt.
-
In
dem ANSI41/IS95-Netzwerk weist das Legacy Envelope Module LEM eine
Schnittstelle des Open Service Access (OSA) zu dem OSA-Gateway (GW)
auf. Das OSA-Gateway (und daher das zugrundeliegende Netzwerk) sehen
das Legacy Envelope Module LEM als eine Anwendungsplattform, die
einen bestimmten Dienst bereitstellt. Das Legacy Envelope Module
LEM nimmt durch die WIN-Schnittstelle Anforderungen des Open Service
Access (OSA) von dem ANSI-41/IS95 Netzwerk an. Es konvertiert dann
die Nachrichten des Open Service Access (OSA) in CAMEL-Anwendungsprotokollnachrichten
und sendet diese zu der CSE, die dem Teilnehmer zugeordnet ist.
Die CSE empfängt
die Dienstanforderung auf dieselbe Weise, wie sie die Anforderung
von einer Mobilvermittlungszentrale MSC in einem GSM- oder UMTS-Netzwerk
empfangen hätte. Sie
verarbeitet die Anforderung als einen normalen Dienstaufruf. Die
CAMEL-Dienstumgebung (CSE) bleibt durch diese Zeichengabekonvertierung
unverändert
(sich dieser tatsächlich
unbewußt).
-
Diese
Konvertierung wird ohne eigene WIN-/CAMEL-Zusammenarbeitsfunktion erzielt. CAMEL-Dienste
eines Teilnehmers sind in der CSE des Heimatnetzwerks verankert
und werden verbindungsweise darin ausgeführt (dies ist bei CAMEL immer
der Fall). Im Normalfall muß das
Netzwerk, in das gewandert wird, dieselbe Version von CAMEL unterstützen. Das
Legacy Envelope Module LEM wurde ursprünglich als ein Mechanismus
vorgeschlagen, der es Teilnehmern in dem IP-Multimediasubsystem
(IMS) ermöglicht,
Zugang zu auf CAMEL basierenden Diensten zu erhalten. Genauer gesagt
als ein Emulator, der bewirkt, daß Legacy-Dienste auf der Anwendungsprogrammierschnittstelle
(API) zu basieren scheinen. Der Geltungsbereich des Legacy Envelope
Module LEM ist nun erweitert, um WIN-/CAMEL-Zusammenarbeit zu ermöglichen.
-
Der
vorgeschlagene Ansatz besteht darin, daß WIN/CAMEL-Zusammenarbeit
mit Open Service Access (OSA) als gemeinsamem Medium eingeführt wird.
Es besteht keine eigene Funktion, die WIN auf MAP (Mobile Application
Part) abbildet (und umgekehrt). Da Betreiber am wahrscheinlichsten
ein Gateway des Open Service Access (OSA) in WIN-Netzwerken einsetzen
werden, kann das Legacy Envelope Module LEM als eine verbesserte
Version des GSM/UMTS Open Service Access (OSA) betrachtet werden,
wobei vorteilhafterweise Infrastruktur wieder verwendet wird.
-
Dieser
Mechanismus zur Unterstützung
von auf der Legacy-CAMEL-Dienstumgebung (CSE) basierenden Diensten
in einem Netzwerk auf der Basis von IS-41 WIN wird nun ausführlicher
beschrieben.
-
Wie
in 4 gezeigt, ist der anrufende Teilnehmer ein CAMEL-Teilnehmer,
der in einem WIN-Netzwerk wandert und dessen CAMEL-Triggerprofilinformationen
bei der Registration zu seinem versorgenden WIN-System gesendet
werden. Das Triggerprofil ist eine Ansammlung von für jeden
Teilnehmer gehaltenen Informationen, die angeben, wann Mehrwertdienste
aktiviert werden sollen. Wenn eine ankommende oder abgehende Verbindung
mit dem Triggerprofil übereinstimmt,
wird ein Dienst aufgerufen, d. h. der „Trigger" wird „ausgelöst". Wie unten ausführlicher erläutert wird,
werden die CAMEL-Triggerinformationen
unter Verwendung des Methodenaufrufs getNotification des Open Service
Access in den WIN-Bereich überführt. Das
Legacy Envelope Module LEM führt
eine Abbildung von einer getNotification-Operation des Open Service
Access auf das Triggerprofil in der WIN-Protokolloperation REGNOT
durch, wobei der REGNOT die Registrationsbenachrichtigungsnachricht
ist, die im WIN zum Melden des Standorts des Teilnehmers und wahlweise
zum Erhalten und Validieren von Triggerinformationen für diesen
Teilnehmer verwendet wird. Dieses Profil bewirkt, daß ein WIN-Trigger
in dem WIN Originating-Basic Call State Model (O-BCSM) aktiviert
wird. Dieser Trigger bewirkt, daß die MSC/WIN Service Switching
Function (SSF) eine WIN-Abfrage (ORREQ) während des Verbindungsaufbaus
startet [WIN-Zwischenstandard IS-771].
-
Mit
Bezug auf die in 4 gezeigten bezifferten Schritte
lautet die Nachrichtensequenz wie folgt:
- 1.
Der CAMEL-Teilnehmer wandert in ein WIN-Netzwerk und registriert
sich bei der versorgenden Mobilvermittlungszentrale (MSC). Die versorgende
WIN-Dienstvermittlungsfunktion versucht dann, das WIN-Triggerprofil des
Teilnehmers abzurufen, indem sie eine WIN-REGNOT-Operation zu dem
Besuchsregister (VLR) sendet. Dies ist normales Verhalten, so wie
es in dem WIN-Standard [WIN-Zwischenstandard IS-771] spezifiziert
wird.
- 2. Das Besuchsregister (VLR) leitet die WIN-REGNOT-Operation an das
Legacy Envelope Module weiter (beim normalen Betrieb wird die REGNOT
zu dem Heimatregister (HLR) des versorgten Teilnehmers gesendet).
Das Legacy Envelope Module wirkt also als ein WIN-Heimatregister
(HLR) im Verhältnis
zu dem WIN-Besuchsregister (VLR) im Namen des CAMEL-Teilnehmers.
- 3. Das Legacy Envelope Module bildet die WIN-REGNOT auf einem
getNotification-Methodenaufruf des Open Service Access ab. Die Semantik
der getNotification-Methode
besteht darin, die Triggerprofilinformationen für den Teilnehmer abzurufen.
Für das
Open Service Access Gateway wirkt das Legacy Envelope Module als
ein Anwendungsserver des Open Service Access.
- 4. Das Open Service Access Gateway bildet das getNotification
auf das AnyTimeInterrogation des Mobilanwenderteils (MAP) zu dem
Heimatregister (HLR) ab. Dies ist normales Verhalten, so wie es
in [3GPP Technical Specification TS 29.198 & 3GPP Technical Report TR 29.998]
spezifiziert wird.
- 5. Das Heimatregister (HLR) gibt das Triggerprofil in der AnyTimeInterrogation-Bestätigungsoperation
des Mobilanwenderteils (MAP) zurück.
Dies ist normales Verhalten, so wie es in der Spezifikation [3G
Technical Specification TS 29.002] des Mobilanwenderteils (MAP)
spezifiziert wird.
- 6. Das in dem ACK für
AnyTimeInterrogation zurückgegebene
Triggerprofil wird in dem Out-Parameter
für die
Methodenrückkehr
des Open Service Access von getNotification geführt.
- 7. Das Legacy Envelope Module bildet das getNotification auf
die WIN-REGNOT ab, die das Triggerprofil zu dem Besuchsregister
(VLR) führt.
Das WIN-Besuchsregister (VLR) denkt dann, daß es die REGNOT, die das Triggerprofil
führt,
von dem WIN-Heimatregister
(HLR) des versorgten Teilnehmers empfangen hat. Das WIN-Besuchsregister
(VLR) nimmt dann an, daß dies
ein gewöhnliches
WIN-Triggerprofil ist, anstelle eines CAMEL-Triggerprofils, das über Open
Service Access (OSA) in ein WIN-Triggerprofil übersetzt wird.
- 8. Das Besuchsregister (VLR) leitet dann das Triggerprofil in
einer WIN-REGNOT zu der versorgenden MSC/WIN-Dienstvermittlungsfunktion
weiter.
-
Man
beachte, daß es
zur Zeit keine WIN-Protokollabbildungsempfehlungen in dem technischen
Report TR 29.998 der 3GPP gibt, aber dies entspricht dem Verhalten
für CAMEL.
Soweit es das Open Service Access Gateway in dem Heimatnetzwerk
betrifft, sieht es keinen Unterschied, ob es zu einem Anwendungsserver
des Open Service Access oder dem Legacy Envelope Module spricht.
Soweit es das WIN-Besuchsregister (VLR) betrifft, sieht es keinen
Unterschied, ob es zu einem WIN-Heimatregister
(HLR) oder dem Legacy Envelope Module spricht.
-
Mit
Bezug auf 5 lautet die Nachrichtensequenz
beim Aufruf eines Dienstes wie folgt:
- 1. Ein
mobileingeleiteter Verbindungsversuch durch den in einem WIN-Netzwerk
wandernden CAMEL-Teilnehmer
bewirkt, daß die
MSC/WIN-Dienstvermittlungsfunktion
eine WIN-Abfrage (ORREQ) während
des Verbindungsaufbaus startet [WIN-Zwischenstandard IS-771]. Der
WIN-Trigger wird ausgelöst,
da ein WIN-Triggerprofil gemäß dem in
3GPP Technical Specification Technical Specification TS 29.198 und 3GPP
Technical Report TR 29.998 beschriebenen Szenario geladen ist. Die
WIN-ORREQ wird zu dem Open Service Access Gateway des besuchten
WIN-Netzwerks gesendet. Ein ähnliches
Verhalten wird in den Open Service Access Specifications [3G Technical
Specification TS 29.198 & 3G
Technical Report TR 29.998] beschrieben. Wiederum existieren keine
WIN-Protokollabbildungsempfehlungen,
es wäre
aber zu erwarten, daß diese
den CAMEL-Abbildungen sehr ähnlich
und analog wären.
- 2. Das Open Service Access Gateway bildet dann die WIN-ORREQ
auf den reportNotification-Methodenaufruf des Open Service Access
ab, ähnlich
wie es den Initial Detection Point des CAMEL-Anwendungsprotokolls
auf ein reportNotification abbilden würde [3G Technical Report TR
29.998]. Das reportNotification des Open Service Access wird auf
dem Legacy Envelope Module aufgerufen, als ob es ein Anwendungsserver
des Open Service Access wäre.
- 3. Das Legacy Envelope Module bildet dann das reportNotification
des Open Service Access auf dem Initial Detection Point des CAMEL-Anwendungsprotokolls
ab, das dann zu der CSE gesendet wird. Für die CAMEL-Dienstumgebung
erscheint es dann, als ob das CAMEL-Anwendungsprotokoll-Initial
von einer gewöhnlichen
CAMEL-Anwendungsprotokolldienstvermittlungsfunktion empfangen worden
wäre. Die
CAMEL-Dienstumgebung führt
ihre Legacy-CAMEL-Dienstumgebungsdienstlogik
durch, die in diesem Beispiel aus einer Nummernübersetzungsanwendung besteht.
Als Ergebnis sendet die CAMEL-Dienstumgebung
ein CAMEL-Anwendungsprotokoll-Connect
mit den neuen Routing-Informationen zu dem Legacy Envelope Module,
als ob es sich um die CAMEL-Anwendungsprotokolldienstvermittlungsfunktion
handeln würde.
- 4. Das Legacy Envelope Module bildet das CAMEL-Anwendungsprotokoll-Connect
auf einen routeReq-Methodenaufruf
des Open Service Access zu dem Open Service Access Gateway ab.
- 5. Das Open Service Access Gateway bildet die routeReq-Methode
des Open Service Access auf die WIN-Orreq-Protokolloperation ab, ähnlich den
Abbildungsempfehlungen, die in [3G Technical Report TR 29.998] beschrieben
werden. Die WIN-Orreq
führt die
Routing-Informationen, so wie sie durch die Legacy-CAMEL-Dienstlogik
auf der CSE bestimmt wurden.
-
Soweit
es die CAMEL-Dienstumgebung in dem Heimatnetzwerk betrifft, sieht
sie keinen Unterschied, ob sie zu einer CAMEL-Dienstvermittlungsfunktion
(SSF) oder dem Legacy Envelope Module spricht. Soweit es das Open
Service Access Gateway in dem besuchten Netzwerk betrifft, sieht
es keinen Unterschied, ob es zu einem Anwendungsserver des Open
Service Access oder dem Legacy Envelope Module spricht.
-
WIN-Teilnehmer
in einem CAMEL-Netzwerk
-
Das
Prinzip kann erweitert werden, um Teilnehmer von ANSI-41/IS-95,
die in ein GSM-/UMTS-Netzwerk (mit dem entsprechenden Endgerät) wandern,
zu ermöglichen
und Zugriff auf ihre auf WIN basierenden Dienste zu haben. Dies
ist in 6 gezeigt. In dem ANSI-41/IS-95-Netzwerk weist das
LEM eine WIN-Schnittstelle zu einer WIN-Plattform auf. Die WIN-Plattform „sieht" das LEM als eine
Vermittlungsplattform wirkend. Das LEM weist eine Schnittstelle
des CAMEL-Anwendungsprotokolls (CAP) zu den Mobilvermittlungszentralen
(MSCs) in dem GSM-/UMTS-Netzwerk
auf, soweit es diese MSCs betrifft, wirkt das LEM als eine auf CAMEL
basierende Dienstplattform. Das LEM liefert jedoch die notwendigen Übersetzungen
zwischen den MSCs von GSM/UMTS und der WIN-Plattform. Die WIN-Plattform
weiß also
nicht, daß sie
einen Dienst durch ein GSM-/UMTS-Netzwerk bereitstellt.
-
Viele
US-Betreiber setzen auch GSM-Netzwerke ein, haben aber immernoch
WIN-Dienste, die sie verwenden könnten.
Dieser Vorschlag sollte solchen Betreibern außerdem ermöglichen, eine fortgesetzte
Bereitstellung von WIN-Diensten
für GSM-Teilnehmer
durchzuführen.
-
Ähnlichkeiten
zwischen CAMEL und WIN
-
Intelligente
Netzwerkfähigkeiten
sind alle diejenigen funktionalen Fähigkeiten, die die Erzeugung
und Ausführung
von Dienstlogikprogrammen unterstützen, die außerhalb
von Vermittlungsgeräten
verankert sind, aber auf der Basis einer gemeinsamen Definition
von Verbindungsmodellen und Protokollen (WIN Interim Standard IS-771)
mit den Vermittlungsgeräten
zusammenarbeiten. Das Verbindungsmodell stellt eine Abstraktion
einer in dem Netzwerk auftretenden Verbindung auf hoher Ebene bereit.
Die Abstraktion liefert eine beobachtbare Ansicht der Verbindung
in der Dienstvermittlungsfunktion auf das Dienstfähigkeitsmerkmal
(SCF), wodurch das Dienstfähigkeitsmerkmal
(SCF) zur Ausführung
von Dienstlogik mit der Dienstvermittlungsfunktion in Wechselwirkung
treten kann. Sowohl WIN als auch CAMEL definieren ihre eigenen Verbindungsmodelle, beide
basieren jedoch auf Verbindungsmodellen gemäß International Telecommunications
Union-Telecommunications Sector – Intelligent Networks, die
in der ITU-T-Empfehlung Q.1224 definiert werden. Der vorliegende Abschnitt
zeigt, daß die Verbindungsmodelle
von WIN und CAMEL. ähnlich
genug für
die Unterstützung
von CAMEL-Diensten in einem WIN-Netzwerk
und umgekehrt sind. Nur die O-BCSM (Originating Basic Call State Models)
des Halbverbindungsmodells werden hier betrachtet. Das O-BCSM für WIN wird
in [WIN Interim Standards IS-771, IS-826 und IS-848] beschrieben,
während
das O-BCSM für
CAMEL in [3G Technical Specification TS 23.078] beschrieben wird.
-
CAMEL
definiert die folgenden, Triggern zugeordneten Detection Points:
- – Analysed_Information
- – Route_Select_Failure
- – O_Busy
- – O_No_Answer
- – O_Answer
- – O_Disconnect
- – O_Abandon
-
CAMEL
definiert die folgenden PIC (Points in Call):
- – O_Null & Authorise_Origination
Attempt_Collect_Info
- – Analyse_Information
- – Routing & Alerting
- – O_Active
- – O_Exception
-
WIN
definiert die folgenden, Triggern zugeordneten Detection Points:
- – Origination_Attempt_Authorized
- – Collected_Information
- – Analyzed_Information
- – O_Called_Party_Busy
- – O_No_Answer
- – O_Answer
- – O_Disconnect
-
WIN
definiert die folgenden Point in Calls:
- – O_Null
- – Authorize_Origination_Attempt
- – Collect_Information
- – Analyze_Information
- – Select_Route
- – Authorize_Call_Setup
- – Send_Call
- – O_Alerting
- – O_Active
- – O_Suspended
- – O_Exception
-
Das
CAMEL Originating-Basic Call State Model wird aus Q-1224 abgeleitet,
indem die Points in Call, für
die keine Detection Points (DPs) definiert sind, kollabiert werden.
Das WIN Originating-Basic Call State Model O-BCSM wird aus Q.1224 abgeleitet, indem
Trigger nicht für
jeden möglichen
Detection Point definiert werden. Das heißt, daß, obwohl keine eindeutige
Abbildung von den beiden Originating-Basic Call State Models offensichtlich
ist, man unter Berücksichtigung
dieser Modellierungsableitungen die folgenden gemeinsamen Points
in Call und Detection Points identifizieren kann:
- – Analyzed_Information
- – O_Called_Party_Busy
- – O_No_Answer
- – O_Answer
- – O_Disconnect
- – O_Null & Authorize_Origination_Attempt & Collect_Information
- – Analyze_Information
- – Routing & Alerting (Select_Route,
Authorize_Call_Setup, Send_Call, O_Alerting)
- – O_Active
- – O_Exception
-
Alle
Points in Call von CAMEL werden auch durch WIN unterstützt, aber
CAMEL unterstützt
nicht alle Points in Call von WIN. Außer Route_Select_Failure und
O_Abandon, werden alle Detection Points von CAMEL unterstützt.
-
Diese
Analyse zeigt, daß die
meisten der üblichen
CAMEL-Dienste bei Verwendung des Originating-Basic Call State Model
unterstützt
werden können.
Dazu gehört
die Nummernübersetzung.
-
OSA-Unterstützung für die Teilmenge
der Points in Call und Detection Points von CAMEL/WIN
-
Der
obige Abschnitt hat die Gemeinsamkeiten zwischen den Verbindungsmodellen
von WIN und CAMEL identifiziert. Der vorliegende Abschnitt untersucht,
wieweit diese Modelle durch die Anwendungsprogrammierschnittstelle
des Open Service Access unterstützt
werden können.
Die Unterstützung
aus der Ereignisbenachrichtigung wird nur für die Detection Points betrachtet.
| – Analyzed_Information | P_EVENT_GCCS_ADDRESS_ANALYSED_EVENT |
| – O_Called_Party_Busy | P_CALL_REPORT_BUSY |
| – O_No_Answer | P_CALL_REPORT_NO_ANSWER |
| – O_Answer | P_CALL_REPORT_ANSWER |
| – O_Disconnect | P_CALL_REPORT_DISCONNECT |
-
Diese
Analyse zeigt, daß alle
Ereignisnamen zumindest über
die Anwendungsprogrammierschnittstelle von Open Service Access transportiert
werden können.
-
Einige Punkte
bezüglich
Unterstützung
von Open Service Access
-
Open
Service Access (OSA) unterstützt
nur Adressenbereiche als Triggerkriterien, während WIN-Triggerkriterien
z. B. Anruferinformationen, Trägerfähigkeit
und Dienstklasse umfassen. Dies ist eine innere Beschränkung der
Anwendungsprommierschnittstelle von Open Service Access und ist
nicht für
den vorgeschlagenen Ansatz des Legacy Envelope Module spezifisch.
-
Da
zwei Protokollabbildungen auftreten, z. B. von WIN zu Open Service
Access und von Open Service Access zu dem CAMEL-Anwendungsprotokoll
kann natürlich
bei jeder Abbildung ein gewisser Grad an Einzelheiten verloren gehen,
da es nicht wahrscheinlich ist, daß eindeutige Abbildungen möglich sind.
Außerdem führt jede
Abbildungsphase eine gewisse Verarbeitungsverzögerung ein. Bei diesem Ansatz
wird die Verarbeitungsverzögerung
im Vergleich mit einem einfachen Ansatz des Open Service Access
verdoppelt.