DE19933547A1 - Telekommunikationsnetz und Verfahren zum Routen ankommender Verbindungen für MTC-Dienste - Google Patents

Telekommunikationsnetz und Verfahren zum Routen ankommender Verbindungen für MTC-Dienste

Info

Publication number
DE19933547A1
DE19933547A1 DE19933547A DE19933547A DE19933547A1 DE 19933547 A1 DE19933547 A1 DE 19933547A1 DE 19933547 A DE19933547 A DE 19933547A DE 19933547 A DE19933547 A DE 19933547A DE 19933547 A1 DE19933547 A1 DE 19933547A1
Authority
DE
Germany
Prior art keywords
service
network
subscriber
services
service switching
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE19933547A
Other languages
English (en)
Inventor
Alexander Aschir
Andreas Berg
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Priority to DE19933547A priority Critical patent/DE19933547A1/de
Priority to US09/408,686 priority patent/US6535741B1/en
Priority to EP00108880A priority patent/EP1049337A3/de
Publication of DE19933547A1 publication Critical patent/DE19933547A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q3/00Selecting arrangements
    • H04Q3/0016Arrangements providing connection between exchanges
    • H04Q3/0029Provisions for intelligent networking

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Telekommunikationsnetz und Verfahren zum Routen ankommender Verbindungen für MTC-Dienste DOLLAR A Falls bei der Intialisierung eines MTC-Dienstes für einen Teilnehmer (TNB) eines als Overlay-Netz realisierten Telekommunikationsnetz der zur Durchführung des Dienstes erforderliche Leistungsumfang die auf seiten des Zugangs-SSP-Knotens (SS1) unterstützte Leistungsmenge übersteigt, wird von dem Dienstesteuerknoten (SCP) aus der Rufadresse eine Routingadresse, welche eine Information zum Weiterrouten der Verbinddung zu einem zweiten, die erforderliche Leistungsmenge unterstützenden SSP-Knoten (SS2) enthält, erstellt und dem ersten SSP-Knoten (SS1) zum Weiterrouten übermittelt (5).

Description

Die Erfindung betrifft ein Telekommunikationsnetz mit
  • - einer Dienstesteuereinrichtung zum Steuern und Durchführen von Intelligenten Diensten und
  • - Dienstevermittlungseinrichtungen, welche zur Vermittlung von Leistungskomponenten Intelligenter Dienste jeweils eine vorgegebene Leistungsmenge gemäß einem vorgegebenen Anwen­ dungsprotokoll unterstützen.
Ebenso betrifft die Erfindung ein Verfahren zum Routen einer ankommenden Kommunikationsverbindung in einem Telekommunika­ tionsnetz der genannten Art, bei welchem von einer ersten Dienstevermittlungseinrichtung des Netzes in Folge einer bei ihr ankommenden Verbindungsanforderung für eine Kommunika­ tionsverbindung zu einem Teilnehmer des Netzes, welcher zu­ mindest einen für ankommende Rufe zu aktivierenden Intelli­ genten Dienst subskribiert hat, eine Dienstinitialisierungs­ nachricht an die Dienstesteuereinrichtung gesendet wird.
Im Zusammenhang mit modernen Telekommunikationsnetzen ist es bekannt, dass neben den Grunddiensten, wie z. B. dem Telefon- und Facsimiledienst eines Telefonnetzes, weitere verbindungs­ orientierte Dienste eingerichtet sind, die von einem Teilneh­ mer des Netzes angesprochen werden können und die im folgen­ den als Intelligente Dienst bezeichnet werden; das Netz, das diese Dienste unterstützt, wird als Intelligentes Netz (IN) bezeichnet. Die übliche Architektur des Intelligenten Netzes sieht neben Netzeinrichtungen mit einer Dienstevermittlungs­ funktion, den sogenannten Dienstevermittlungseinrichtungen oder SSP-Knoten ('Service Switching Point'), Dienstesteuer­ knoten ('Service Control Point', SCP) als Einrichtungen zur Steuerung und Durchführung von intelligenten Zusatzdiensten des Intelligenten Netzes vor; die Dienstevermittlungsknoten und Dienstesteuerknoten sind über Signalisierungsstrecken miteinander verbunden.
Für Mobilfunknetze nach dem GSM-Standard ('Global System for Mobile Communication') wurde eine sogenannte CAMEL-Plattform ('Customised Applications for Mobile network Enhanced Logic') definiert, um eine weltweite Nutzung der Leistungsmerkmale des Intelligenten Netzes zu ermöglichen. In einem Mobilfunk­ netz werden die Dienstevermittlungsknoten gewöhnlicherweise als M-SSP ('Mobile SSP') bezeichnet. Als Anwenderteil ('ap­ plication part') wird hierbei ein spezielles Protokoll ver­ wendet, das für das Mobilfunknetz aus dem CAP-Protokoll ('CAMEL' Application Part', vgl. GSM 09.78) besteht. Für nähe­ re Informationen zu CAMEL und dem CAP-Protokoll sei auf die folgenden GSM-Standards verwiesen: GSM 02.78 "Digital cellu­ lar telecommunications system (Phase 2+); Customised Applica­ tions for Mobile Network Enhanced Logic (CAMEL) Service Defi­ nition (Stage 1).", GSM 03.78 "Digital cellular telecommuni­ cations system (Phase 2+); Customised Applications for Mobile Network Enhanced Logic (CAMEL Phase) (Stage 2)." und GSM 09.78 "Digital cellular telecommunications system (Phase 2+); Customised Applications for Mobile Network Enhanced Logic (CAMEL) CAMEL Application Part (CAP) specification.".
Mit dem CAP wurde erstmals ein Protokoll zwischen M-SSP und SCP geschaffen, mit dem einerseits roamenden - d. h. über den Versorgungsbereich ihres Heimatnetzes (HPLMN, 'Home Public Line Mobile Network') hinaus sich auch in anderen Besucher­ netzen (VPLMN, 'Visited Public Line Mobile Network') bewegen­ den - IN-Teilnehmern Intelligente Dienste auch außerhalb ih­ res Heimatnetzes angeboten, andererseits auch Teilnehmern im Heimatnetz selbst zur Verfügung gestellt werden können. Das CAP-Protokoll sieht gemäß GSM 09.78 einen festgelegten Satz von Funktionalitäten vor, den sogenannten Capability Set 1 (CS1). Bei der Einführung des CAP-Protokolls wurde in der CAP-Phase 1 - gemäß den diesbezüglichen GSM-Standards GSM 02.78 "Digital cellular telecommunications system (Phase 1); Customised Applications for Mobile Network Enhanced Logic (CAMEL) Service Definition (Stage 1).", GSM 03.78 "Digital cellular telecommunications system (Phase 1); Customised Ap­ plications for Mobile Network Enhanced Logic (CAMEL Phase) (Stage 2)." und GSM 09.78 "Digital cellular telecommunica­ tions system (Phase 1); Customised Applications for Mobile Network Enhanced Logic (CAMEL) CAMEL Application Part (CAP) specification." - lediglich eine Teilmenge des CS1 reali­ siert, sodass die CAP-Phase 1 nur einen sehr eingeschränkten Befehlssatz des vorgesehenen CS1 enthält. Mit den sieben in der CAP-Phase 1 realisierten Operationen (statt der 29 in CS1) lassen sich komplexe Intelligente Dienste nicht ausfüh­ ren - sie benötigen einen umfangreicheren Satz an Befehlen, wie sie insbesondere von dem CS1 zur Verfügung gestellt wür­ den. Zur Durchführung eines solchen Intelligenten Dienstes wird nach bekannter Art auf der Grundlage der Zwischenamts­ signalisierung des ISUP die Verbindung zu einem M-SSP gerou­ tet, der den Dialog mit dem SCP über ein INAP-Protokoll ('In­ telligent Network Application Part') führen kann, da in dem INAP-Protokoll der Operationsumfang des CS1 realisiert ist. Dagegen werden Intelligente Dienste, die innerhalb des Um­ fangs der CAP-Phase 1 ausführbar sind, nicht weitergeroutet, sondern in dem betreffenden M-SSP durchgeführt.
Für Intelligente Dienste, die bei abgehenden Verbindungen aus Besuchernetzen - als sogenanntes MOC-Szenario (MOC = 'Mobile Originating Calls') - gestartet werden, ist in der nachveröf­ fentlichten DE 198 14 162 A1 der Anmelderin ein Verfahren zur Informationsübertragung beschrieben, durch welches zwischen SCP und M-SSP Daten und Parameter übertragen werden können, ohne dass hierfür der Bestand der Nachrichten zwischen der dem Anschluss des rufenden Teilnehmers zugeordnete Vermitt­ lungseinrichtung, den Heimatregistern und des M-SSP gegenüber den bestehenden CAP- und INAP-Protokollen geändert werden müsste. Demgemäß werden während eines ersten Dialogs über CAP der M-SSP in dem Besuchernetz des rufenden Teilnehmers mit einem SCP im Heimatnetz des rufenden Teilnehmers alle Parame­ ter der Beginnoperation, die gemäß GSM-Standard mittels einer IDP-Nachricht ('Initial Detection Part') erfolgt, zwischenge­ speichert und dann die Verbindung zu einem INAP-fähigen M-SSP im Heimatnetz weitergeroutet. Dort wird ein zweiter Dialog über das INAP-Protokoll mit demselben SCP angestoßen, in dem die ursprünglichen Parameter der Beginnoperation (IDP-Nach­ richt) mittels einer ebenfalls übertragenen Korrelations­ information ('correlation id') wiedergefunden werden, sodass dann der ursprünglich gewünschte Intelligente Dienst seitens des INAP-fähigen M-SSP gestartet werden kann.
Die genannte MOC-Lösung kann jedoch nicht ohne weiteres auf den Fall, worin der Intelligente Dienst von seiten des geru­ fenen Teilnehmers ausgelöst wird, - das sogenannte MTC-Sze­ nario (MTC = 'Mobile Terminating Calls', "ankommende Verbin­ dungen") - übertragen werden. Denn dies würde drei Dialoge mit dem SCP erforderlich machen: einen ersten Connect-Dialog gemäß dem CAP-Protokoll zu einem INAP-fähigen M-SSP, einen zweiten Connect-Dialog über das INAP-Protokoll zum Zweck der Heimatregister-Interrogation zwischen dem INAP-fähigen M-SSP und dem Heimatregister, sowie einen dritten Dialog über das INAP-Protokoll für die Durchführung von Operationen, welche durch die Dienste-Logik verlangt werden, wie z. B. Vergebüh­ rungsanwendungen (sogenanntes 'Apply Charging') und Routing- Operationen. Dies würde somit beträchtlichen Signalisierungs­ verkehr mit sich bringen. Daher erscheint eine derartige Lö­ sung für Hersteller wie Netzbetreiber kaum akzeptabel.
In diesem Zusammenhang ist anzumerken, dass ein Weiterrouten ankommender Verbindungen für einen MTC-Dienst, wenn das be­ treffende Mobilfunknetz ein voll integriertes Netz ist, in dem alle Vermittlungseinrichtungen ein INAP-Protokoll unter­ stützen, nicht erforderlich ist. Für diesen Zweck kann durch geeignete Administrierung der M-SSP-Knoten des Netzes er­ reicht werden, dass - obwohl die Besucherregister und Hei­ matregister des Netzes gemäß GSM-Standard das MAP-Protokoll ('Mobile Application Part'), insbesondere MAP Version 3, unterstützen und somit die Unterstützung der CAP-Phase 1 bie­ ten - für einen MTC-Dienst das INAP-Protokoll genutzt wird. Jedoch sind Netze, in denen nicht alle Netzknoten INAP-fähig sind, sogenannte Overlay-Netze, häufig. In Overlaynetzen ist somit nicht gewährleistet, dass der betreffende M-SSP, sofern für einen MTC-Dienst der Operationsumfang der CAP-Phase 1 nicht ausreicht, ein INAP-Protokoll nutzen kann. Das erwähnte MAP-Protokoll ist im GSM-Standard GSM 09.02 (ETS 300 974) "Digital cellular telecommunications system (Phase 2+); Mo­ bile Application Part specification" näher beschrieben.
Es ist Aufgabe der vorliegenden Erfindung, das Routen ankom­ mender Verbindungen zur Durchführung von Intelligenten Dien­ sten zu verbessern.
Diese Aufgabe wird ausgehend von einem Telekommunikationsnetz der eingangs genannten Art dadurch gelöst, dass erfindungsge­ mäß die Dienstesteuereinrichtung dazu eingerichtet ist, auf­ grund einer von einer ersten Dienstevermittlungseinrichtung her empfangenen Dienstinitialisierungsnachricht betreffend eine ankommende Kommunikationsverbindung zu einem Teilnehmer des Netzes
  • - zu überprüfen, ob in Bezug auf den Teilnehmer ein für an­ kommende Rufe zu aktivierender Intelligenter Dienst sub­ skribiert ist, der die auf seiten der ersten Dienstever­ mittlungseinrichtung angebotene Leistungsmenge übersteigt, sowie im Falle, dass dies zutrifft,
  • - aus der Rufadresse des gerufenen Teilnehmers eine Routing­ adresse, welche eine Information zum Weiterrouten der Ver­ bindung zu einer zweiten, eine für den Dienst erforderliche Leistungsmenge unterstützenden Dienstevermittlungseinrich­ tung enthält, zu erstellen und der ersten Dienstevermitt­ lungseinrichtung zu übermitteln.
Die erfindungsgemäß erstellte und an den ersten Dienstever­ mittlungsknoten gesendete Routingadresse bewirkt sodann gemäß wohlbekannter Verfahren ein Routen der Verbindung zu dem zweiten Dienstevermittlungsknoten, welcher die ursprüngliche Teilnehmeradresse zurückgewinnt und den Verbindungsaufbau einschließlich des MTC-Dienstes fortsetzt.
Durch diese Lösung ist die Ausführung von MTC-Diensten auch in Overlaynetzen gewährleistet, ohne dass ein Aufrüsten der Dienstevermittlungsknoten notwendig würde. Vorteilhaft ist insbesondere, dass nach der Erfindung das Routen mit gering­ fügigem zusätzlichem Signalisierungsaufwand auskommt.
In einer bevorzugten Ausführungsform des erfindungsgemäßen Netzes ist die Dienstesteuereinrichtung dazu eingerichtet, die Überprüfung der von den Dienstevermittlungseinrichtungen unterstützten Leistungsmengen sowie die Auswahl der zweiten Dienstevermittlungseinrichtung anhand einer von seiten der ersten Dienstevermittlungseinrichtung übermittelten Subskrip­ tionsinformation betreffend des/der dem Teilnehmer zugeordne­ ten Dienste(s) und die zugehörende(n) Leistungsmenge(n) aus­ zuführen. Dies vermeidet zusätzliche Signalisierungen zwi­ schen dem Dienstesteuerknoten und einer Teilnehmerdatenbasis für eine Abfrage der teilnehmerspezifischen Dienstdaten.
In einer besonders zweckmäßigen Ausführungsform ist das Netz als Mobilfunknetz realisiert und die Dienstevermittlungsein­ richtungen unterstützen jeweils das MAP-Protokoll oder das INAP-Protokoll. Hierbei stellt wie bereits erläutert das MAP- Protokoll eine kleinere Leistungsmenge dar, demgegenüber das INAP-Protokoll einen Gesamtumfang an Leistungsmerkmalen zur Verfügung stellt.
Ebenso wird die oben gestellte Aufgabe von einem Verfahren der eingangs genannten Art gelöst, bei welchem auf die Dienst­ initialisierungsnachricht hin erfindungsgemäß seitens der Dienstesteuereinrichtung überprüft wird, ob der zumindest ei­ ne vom Teilnehmer subskribierte Dienst die auf seiten der er­ sten Dienstevermittlungseinrichtung angebotene Leistungsmenge übersteigt, und im Falle, dass dies zutrifft,
  • a) seitens der Dienstesteuereinrichtung (SCP) aus der Ruf­ adresse des gerufenen Teilnehmers (TNB) eine Routing­ adresse, welche eine Information zum Weiterrouten der Ver­ bindung zu einer zweiten, eine für den Dienst erforderli­ che Leistungsmenge unterstützenden Dienstevermittlungsein­ richtung (SS2) enthält, erstellt und der ersten Dienste­ vermittlungseinrichtung (SS1) übermittelt (5) wird,
  • b) seitens der ersten Dienstevermittlungseinrichtung (SS1) gemäß der empfangenen Routingadresse die Verbindung zu der zweiten Dienstevermittlungseinrichtung (SS2) gerou­ tet (6) wird und
  • c) der zumindest eine vom Teilnehmer subskribierte Dienst über die zweite Dienstevermittlungseinrichtung (SS2) ver­ mittelt (10-12) wird.
Es ist hierbei günstig, wenn die erste Dienstevermittlungs­ einrichtung von einer Teilnehmerdatenbasis, welche in dem Mo­ bilfunknetz zur Speicherung von Daten der im Netz registrier­ ten Teilnehmer vorgesehen ist, eine Subskriptionsinformation betreffend des/der dem Teilnehmer zugeordneten Dienste(s) und die zugehörende(n) Leistungsmenge(n) abfragt und diese in der Dienstinitialisierungsnachricht an den Dienstesteuerknoten übermittelt und seitens der Dienstesteuereinrichtung die Überprüfung der von den Dienstevermittlungseinrichtungen un­ terstützten Leistungsmengen sowie die Auswahl der zweiten Dienstevermittlungseinrichtung anhand der Subskriptionsinfor­ mation erfolgt.
Des weiteren ist eine Realisierung des erfindungsgemäßen Ver­ fahrens in einem Mobilfunknetz besonders zweckmäßig, wobei die Dienstevermittlungseinrichtungen jeweils das MAP-Proto­ koll oder das INAP-Protokoll unterstützen.
Die Vorteile des erfindungsgemäßen Verfahrens und seiner Aus­ gestaltungen entsprechen den anhand des erfindungsgemäßen Te­ lekommunikationsnetzes dargestellten.
Die Erfindung wird anhand eines in der Zeichnung dargestell­ ten Ausführungsbeispiels näher erläutert. Im einzelnen zeigen
Fig. 1 ein beispielhaftes Overlaynetz, in dem die Erfindung realisiert ist, sowie
Fig. 2 einen Signalisierungsablauf des Routens einer Verbin­ dung für einen MTC-Dienst gemäß der Erfindung.
Das Ausführungsbeispiel betrifft die MTC-Bearbeitung eines Intelligenten Dienstes für einen Teilnehmer eines Mobilfunk­ netzes. In Fig. 1 sind, soweit für das Verständnis der Erfin­ dung von Belang, die Komponenten des Mobilfunknetzes HNB ge­ zeigt, in dem der Teilnehmer TNB angemeldet ist und das die­ sem somit als Heimatnetz zugeordnet ist. Nach bekannter Art weist das Netz HNB neben Dienstevermittlungsknoten SS1, SS2, SS3 einen als Heimatregister HLR eingerichteten Knoten sowie einen Dienstesteuerknoten SCP auf. Diese Netzknoten sind untereinander verbunden, beispielsweise durch Verknüp­ fungen wie in der Zeichnung dargestellt; jedoch ist die Topo­ logie der Verknüpfungen im dargestellten Netzverbund für die Erfindung nicht von Belang. Der Teilnehmer TNB selbst ist über eine Basisstation bei einem Mobilvermittlungsknoten VMS ('visited mobile switching center') eingebucht, der somit - zumindest vorübergehend - als der aktuelle Aufenthaltsknoten des Teilnehmers TNB dient. In dem Knoten VMS ist für die Zwecke der Verwaltung der Teilnehmerdaten des Teilnehmers TNB sowie anderer (nicht gezeigter) dort eingebuchter Mobilteil­ nehmer ein Besucherregister VLR eingerichtet.
Es sei darauf hingewiesen, dass es für die Erfindung belang­ los ist, ob die Mobilvermittlungsstelle VMS dem Heimatnetz HNB des Teilnehmers TNB angehört oder einem anderen Mobil­ funknetz VNB, in dem sich der Teilnehmer vorübergehend auf­ hält (sogenanntes 'Roaming'). In Fig. 1 ist der letztere Fall dargestellt, ohne dass dies eine Einschränkung der Erfindung bedeuten würde.
Des weiteren ist in Fig. 1 ein anderer Teilnehmer TNA ge­ zeigt, welcher für die Zwecke der Erfindungsbeschreibung den rufender Teilnehmer darstellen soll. Der rufende Teilnehmer TNA ist über eine Vermittlungsstelle VST in einem Telefonnetz NEA, beispielsweise ein von dem Netzverbund HNB, VNB unabhän­ giges Festnetz, angeschlossen. Um Verbindungen zwischen den Netzen NEA und HNB zu ermöglichen, ist eine Verknüpfung des Netzes NEA zu der Vermittlung SS1 vorgesehen und dementspre­ chend die Vermittlung SS1 als sogenannte Zugangsvermittlung eingerichtet. In Mobilfunknetzen sind Zugangsvermittlungen unter der Bezeichnung GMSC ('Gateway Mobile Switching Cen­ ter') bekannt.
Es sei an dieser Stelle darauf hingewiesen, dass die gezeigte Ausführungsform der Erfindung und insbesondere die darge­ stellte Netzkonfiguration lediglich als Beispiel zur Erläute­ rung der Erfindung dient und nicht einschränkend zu verstehen ist. Beispielsweise kann der rufende Teilnehmer TNA auch ein mobiler Teilnehmer desselben Mobilfunknetzes wie der gerufene Teilnehmer TNB sein.
Entsprechend der Voraussetzung der Erfindung ist das Netz des gerufenen Teilnehmers ein Overlaynetz. Insbesondere wird von dem als GMSC für den rufenden Teilnehmer dienende M-SSC-Kno­ ten SS1 lediglich eine Leistungsteilmenge des CAP-Protokolls wie z. B. die CAP-Phase 1, nicht jedoch ein INAP-Protokoll un­ terstützt. Daher kann der Knoten SS1 die Ausführung eines MTC-Dienstes, welcher den Befehlssatz seiner Leistungsmenge übersteigt, nicht gewährleisten.
Nach der Erfindung wird bei ankommenden Verbindungen - MTC- Szenario - in Overlaynetzen für den Fall, dass der als Zu­ gangsvermittlungseinrichtung dienende SSP-Knoten keine INAP­ fähige Dienstevermittlungseinrichtung ist - d. h. der Dialog mit dem SCP gemäß MAP Version 3 als CAP-Dialog gestartet wird - die Verbindung mit Hilfe einer Routingadresse zu einem an­ deren, INAP-fähigen M-SSP weitergeroutet.
Dies ist anhand eines beispielhaften Signalisierungsablaufs wie in Fig. 2 gezeigt, bei dem ausgehend von dem Teilnehmer TNA eine Verbindung zu dem Teilnehmer TNB hergestellt und für diesen Teilnehmer TNB ein MTC-Dienst ausgeführt wird. In Fig. 2 verläuft die Zeitachse von oben nach unten; die senk­ rechten Linien repräsentieren die signalisierenden Stationen (Teilnehmer bzw. Netzknoten) der Fig. 1 entsprechend den ver­ wendeten Bezugszeichen.
Die in dem Netz NEA des rufenden Teilnehmers ablaufenden De­ tails der Verbindungsherstellung sind in Fig. 2 nicht darge­ stellt, da sie für die Erfindung nicht von Belang und dem Fachmann wohlbekannt. Bei dem Routen der Verbindung in das Netz HNB wird nach bekannter Art an den als Zugangsvermitt­ lung dienenden M-SSC-Knoten SS1 eine Verbindungsanforderung 1 in Form einer IAM-Nachricht ('Initial Address Message') gemäß ISUP gesendet.
Aufgrund der empfangenen Verbindungsanforderung 1 wird von dem Knoten SS1 nach ebenfalls bekannter Art eine Zweischritt- Interrogation 2, 3 (sogenannte '2step-interrogation') gemäß MAP-Version 3 mit dem Heimatregister HLR, das dem Teilnehmer TNB zugeordnet ist, initiiert. Gemäß dem MAP-Protokoll be­ steht die Interrogation aus einer Anfrage 2 in Form einer SRI-Nachricht und der zugehörenden Antwort 3 in Form einer SRI-Ack-Nachricht. Sofern erforderlich führt das Heimatregi­ ster eine Aufenthaltsanfrage PSI ('Provide Subscriber Infor­ mation') gemäß MAP-Protokoll durch, um die zum Erstellen der Nachricht 3 erforderlichen Daten zu erhalten.
Die Antwortnachricht 3 enthält neben Informationen zum Auf­ enthaltsbereich des gerufenen Teilnehmers (insbesondere die Kennung des aktuellen Besucherregisters VLR) eine sogenannten T-CSI ('Terminal Call Subscriber Information') als Informa­ tion betreffend die dem Teilnehmer TNB zugeordneten MTC- Dienste. Unter Verwendung der in der T-CSI enthaltenen Infor­ mation zur Durchführung von MTC-Diensten sendet der Knoten SS1 eine IDP-Nachricht 4 an den Dienstesteuerknoten SCP. Nach der Erfindung wird seitens des Dienstesteuerknotens SCP überprüft, ob der gewünschte Dienst mit der im Knoten SS1 zur Verfügung stehende Leistungsmenge ausführbar ist. In dem hier betrachteten Beispiel wird aufgrund des Umstands, dass die Signalisierung der Nachricht 4 auf dem CAP-Protokoll anstelle eines INAP-Protokolls basiert, erkannt, dass im Knoten SS1 die zur Verfügung stehende Leistungsmenge auf dem CAP-Proto­ koll beruht und somit für den anhand der T-CSI spezifizierten Dienst nicht ausreicht. Daher erstellt der Dienstesteuer­ knoten SCP auf der Grundlage der Teilnehmerrufnummer des Teilnehmers TNB eine neue Rufadresse, welche im folgenden als Routingadresse bezeichnet wird. Die Routingadresse gewährlei­ stet erfindungsgemäß ein Weiterrouten der Verbindung zu einem INAP-fähigen Dienstevermittlungsknoten SS2. Der Dienstesteu­ erknoten SCP sendet eine CONNECT-Nachricht 5 gemäß dem CAP- Protokoll, in welcher die Routingadresse in dem CONNECT- Parameter 'destinationRoutingAddress' eingetragen ist, an den M-SSP-Knoten SS1.
In dem Beispiel wird die Routingadresse seitens des Dienste­ steuerknotens SCP dadurch gebildet, dass vor die ursprüngli­ che Teilnehmerrufnummer ein vom Betreiber des Netzes HNB für diesen Zweck vorgesehenes Präfix, z. B. eine Sequenz aus einer Anzahl von Ziffern, gesetzt wird. Diese Anzahl kann vom Be­ treiber administriert werden; ebenso sind die einzelnen Zif­ fern selbst von dem Betreiber als Präfix administrierbar. Zweckmäßigerweise wird das Präfix derart konfiguriert, dass bei der nachfolgenden Ziffernanalyse seitens des Zugangskno­ tens SS1 die Interrogation des Heimatregisters unterbleibt. Dies wird z. B. dadurch erreicht, dass der Code-Punkt in den Routingtabellen des Knotens SS1 für die Ziffernfolge des Prä­ fixes derart eingerichtet ist, dass eine Trunkbelegung er­ folgt, welche die Verbindung zu SS2 weiterroutet und eine In­ terrogation nicht erfolgt. Um möglichst große Anteile des Numerierungsplans zu schützen, können hierbei als Ziffern des Präfixes auch Hexadezimalziffern verwendet werden.
Der M-SSP-Knoten SS1 empfängt die CONNECT-Nachricht 5 und routet aufgrund dieser Nachricht die Verbindung gemäß der Routingadresse dadurch weiter, dass er eine abgehende Verbin­ dungsstrecke (einen sogenannten 'Trunk') belegt und eine IAM- Nachricht 6 an den Dienstevermittlungsknoten SS2 sendet. Für das Erstellen der Nachricht 6 seitens des Knotens SS1 werden die in der ursprünglichen Initialisierungsnachricht 1 verwen­ deten Parameter in die IAM-Nachricht 6 übertragen, mit Aus­ nahme des IAM-Parameters 'calledPartyNumber', in welchen die Routingadresse aus der CONNECT-Nachricht 5 kopiert wird. Der INAP-fähige M-SSP-Knoten SS2, zu dem die Verbindung ge­ routet wird, ermittelt im nun folgenden Schritt 7 aus der Routingadresse wieder die ursprüngliche Teilnehmerrufnummer, in dem Beispiel wird das hinzugefügte Präfix abgeschnitten. Die so gewonnene Rufadresse, die mit der 'CalledPartyAddress' der anfänglichen IAM-Nachricht 1 übereinstimmt, wird in dem Knoten SS2 nach bekannter Art der Ziffernanalyse unterworfen. Die nun folgende, von dem INAP-fähigen Knoten SS2 ausgehende Verbindungsbehandlung entspricht der Situation, als ob die Verbindungsaufforderung 1 direkt bei diesem Knoten SS2 einge­ troffen wäre: Nach einer Zweischritt-Interrogation 8, 9 (wie­ derum gegebenenfalls mit einer PSI-Anfrage) erfolgt ein Dia­ log 10, 11 zwischen dem Dienstesteuerknoten SCP und dem Dien­ stevermittlungsknoten SS2. Der Dialog 10, 11 erfolgt nach wohlbekannter Art gemäß CAMEL-Standard über das zwischen den beiden Knoten SCP, SS2 eingerichtete INAP-Protokoll; des wei­ teren wird der von dem gerufenen Teilnehmer subskribierte MTC-Dienst im Rahmen dieses INAP-Dialogs initiiert und ausge­ führt. Auch der übrige Fortgang der Verbindungsherstellung, z. B. eine nochmalige Interrogation 12 mit dem Heimatregister sowie schließlich Weiterrouten 13 der Verbindung zu dem aktu­ ellen Aufenthaltsknoten VMS des gerufenen Teilnehmers, er­ folgt nach bekannter Art, vgl. hierzu die genannten CAMEL- Standards.
Der von dem M-SSP-Knoten SS1 abgehende Trunk (vgl. Schritt 6 oben) ist entweder direkt mit dem Zielknoten SS2 verbunden oder führt zumindest in dessen Richtung, z. B. bis zu einem Knoten SS3. Für den ersteren Fall kann, in einer von dem oben dargestellten Ablauf abweichend, bereits der Knoten SS1 bei Belegung des Trunks für das Abschneiden des Präfixes sorgen, so dass insbesondere im Fall eines ISUP-Trunks die abgehende IAM-Nachricht 6 bereits die ursprünglich gewählte Rufnummer, welche nach bekannter Art in dem 'CalledPartyNumber'- Parameter der IAM-Nachricht 1 enthalten war, ohne hinzugefüg­ ten Ziffern enthält. Im letzteren Fall wird das Präfix im Zielknoten SS2 oder in einem dem Zielknoten im Routingverlauf direkt vorgeordneten Knoten SS3 abgeschnitten.

Claims (6)

1. Telekommunikationsnetz (HNB) mit
  • - einer Dienstesteuereinrichtung (SCP) zum Steuern und Durch­ führen von Intelligenten Diensten und
  • - Dienstevermittlungseinrichtungen (SS1, SS2, SS3), welche zur Vermittlung von Leistungskomponenten Intelligenter Dienste jeweils eine vorgegebene Leistungsmenge gemäß einem vorge­ gebenen Anwendungsprotokoll unterstützen,
dadurch gekennzeichnet, dass die Dienstesteuereinrichtung dazu eingerichtet ist, auf­ grund einer von einer ersten Dienstevermittlungseinrichtung (SS1) her empfangenen Dienstinitialisierungsnachricht (4) be­ treffend eine ankommende Kommunikationsverbindung zu einem Teilnehmer (TNB) des Netzes
  • - zu überprüfen, ob in Bezug auf den Teilnehmer ein für an­ kommende Rufe zu aktivierender Intelligenter Dienst sub­ skribiert ist, der die auf seiten der ersten Dienstever­ mittlungseinrichtung (SS1) angebotene Leistungsmenge über­ steigt, sowie im Falle, dass dies zutrifft,
  • - aus der Rufadresse des gerufenen Teilnehmers (TNB) eine Routingadresse, welche eine Information zum Weiterrouten der Verbindung zu einer zweiten, eine für den Dienst erfor­ derliche Leistungsmenge unterstützenden Dienstevermitt­ lungseinrichtung (SS2) enthält, zu erstellen und der ersten Dienstevermittlungseinrichtung (SS1) zu übermitteln (5).
2. Telekommunikationsnetz nach Anspruch 1, dadurch gekennzeichnet, dass die Dienstesteuerein­ richtung dazu eingerichtet ist, die Überprüfung der von den Dienstevermittlungseinrichtungen unterstützten Leistungsmen­ gen sowie die Auswahl der zweiten Dienstevermittlungseinrich­ tung (SS2) anhand einer von seiten der ersten Dienstevermitt­ lungseinrichtung übermittelten Subskriptionsinformation be­ treffend des/der dem Teilnehmer (TNB) zugeordneten Dienste(s) und die zugehörende(n) Leistungsmenge(n) auszuführen.
3. Telekommunikationsnetz nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass es als Mobilfunknetz realisiert ist und die Dienstevermittlungseinrichtungen (SS1, SS2, SS3) jeweils das MAP-Protokoll oder das INAP- Protokoll unterstützen.
4. Verfahren zum Routen einer ankommenden Kommunikations­ verbindung in einem Telekommunikationsnetz (HNB) mit
  • - einer Dienstesteuereinrichtung (SCP) zum Steuern und Durch­ führen von Intelligenten Diensten und
  • - Dienstevermittlungseinrichtungen (SS1, SS2, SS3), welche zur Vermittlung von Leistungskomponenten Intelligenter Dienste jeweils eine vorgegebene Leistungsmenge gemäß einem vorge­ gebenen Anwendungsprotokoll unterstützen,
bei welchem von einer ersten Dienstevermittlungseinrichtung (SS1) des Netzes (HNB) in Folge einer bei ihr ankommenden Verbindungsanforderung (1) für eine Kommunikationsverbindung zu einem Teilnehmer (TNB) des Netzes, welcher zumindest einen für ankommende Rufe zu aktivierenden Intelligenten Dienst subskribiert hat, eine Dienstinitialisierungsnachricht (4) an die Dienstesteuereinrichtung (SCP) gesendet wird, dadurch gekennzeichnet, dass daraufhin seitens der Dienstesteuereinrichtung (SCP) überprüft wird, ob der zumindest eine vom Teilnehmer subskri­ bierte Dienst die auf seiten der ersten Dienstevermittlungs­ einrichtung (SS1) angebotene Leistungsmenge übersteigt, und im Falle, dass dies zutrifft,
  • a) seitens der Dienstesteuereinrichtung (SCP) aus der Rufadresse des gerufenen Teilnehmers (TNB) eine Routing­ adresse, welche eine Information zum Weiterrouten der Ver­ bindung zu einer zweiten, eine für den Dienst erforderli­ che Leistungsmenge unterstützenden Dienstevermittlungsein­ richtung (SS2) enthält, erstellt und der ersten Dienste­ vermittlungseinrichtung (SS1) übermittelt (5) wird,
  • b) seitens der ersten Dienstevermittlungseinrichtung (SS1) gemäß der empfangenen Routingadresse die Verbindung zu der zweiten Dienstevermittlungseinrichtung (SS2) gerou­ tet (6) wird und
  • c) der zumindest eine vom Teilnehmer subskribierte Dienst über die zweite Dienstevermittlungseinrichtung (SS2) ver­ mittelt (10-12) wird.
5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass die erste Dienstever­ mittlungseinrichtung von einer Teilnehmerdatenbasis (HLR), welche in dem Mobilfunknetz zur Speicherung von Daten der im Netz (HNB) registrierten Teilnehmer vorgesehen ist, eine Sub­ skriptionsinformation betreffend des/der dem Teilnehmer (TNB) zugeordneten Dienste(s) und die zugehörende(n) Leistungsmen­ ge(n) abfragt (2, 3) und diese in der Dienstinitialisierungs­ nachricht (4) an den Dienstesteuerknoten (SCP) übermittelt, und dass seitens der Dienstesteuereinrichtung (SCP) die Über­ prüfung der von den Dienstevermittlungseinrichtungen unter­ stützten Leistungsmengen sowie die Auswahl der zweiten Dien­ stevermittlungseinrichtung (SS2) anhand der Subskriptionsin­ formation erfolgt.
6. Verfahren nach Anspruch 4 oder 5, dadurch gekennzeichnet, dass es in einem Mobilfunk­ netz ausgeführt wird, wobei die Dienstevermittlungseinrich­ tungen (SS1, SS2, SS3) jeweils das MAP-Protokoll oder das INAP- Protokoll unterstützen.
DE19933547A 1999-04-26 1999-07-16 Telekommunikationsnetz und Verfahren zum Routen ankommender Verbindungen für MTC-Dienste Withdrawn DE19933547A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
DE19933547A DE19933547A1 (de) 1999-04-26 1999-07-16 Telekommunikationsnetz und Verfahren zum Routen ankommender Verbindungen für MTC-Dienste
US09/408,686 US6535741B1 (en) 1999-04-26 1999-09-30 Telecommunications network and method for routing incoming calls for MTC services
EP00108880A EP1049337A3 (de) 1999-04-26 2000-04-26 Intelligente Netzwerkdienste

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE19924811 1999-04-26
DE19933547A DE19933547A1 (de) 1999-04-26 1999-07-16 Telekommunikationsnetz und Verfahren zum Routen ankommender Verbindungen für MTC-Dienste

Publications (1)

Publication Number Publication Date
DE19933547A1 true DE19933547A1 (de) 2000-11-02

Family

ID=7909706

Family Applications (1)

Application Number Title Priority Date Filing Date
DE19933547A Withdrawn DE19933547A1 (de) 1999-04-26 1999-07-16 Telekommunikationsnetz und Verfahren zum Routen ankommender Verbindungen für MTC-Dienste

Country Status (1)

Country Link
DE (1) DE19933547A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10234523B3 (de) * 2002-07-24 2004-02-19 Siemens Ag Verfahren zur Herstellung einer Verbindung zu einer Dienststeuereinrichtung

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10234523B3 (de) * 2002-07-24 2004-02-19 Siemens Ag Verfahren zur Herstellung einer Verbindung zu einer Dienststeuereinrichtung

Similar Documents

Publication Publication Date Title
DE60023252T2 (de) System und Verfahren für globalen Zugang zu Diensten für mobile Telefonteilnehmer
DE60035803T2 (de) Vorrichtung, verfahren und system zum steuern von speichervorgängen in einem sms center
EP1074154B1 (de) Durchführung von diensten eines intelligenten netzes unter nutzung eines datennetzes
EP0954937B1 (de) Verfahren zur administrierung zusätzlicher dienste in einem kommunikationsnetz
EP1142428A1 (de) Verfahren zum routen von nachrichten in mindestens einem telekommunikationsnetz nach gsm-standard
EP0988766B1 (de) Verfahren und anordnung zum anschluss von teilnehmern in mehreren telekommunikationsnetzen unter einer rufnummer
EP0962106B1 (de) Verfahren und kommunikationsnetz zur bereitstellung von ansagen
EP0978206B1 (de) Verfahren und kommunikationsnetz zur administrierung zusätzlicher dienste
EP1068744B1 (de) Verfahren zum verbindungsaufbau von einem mobilfunknetz zu einer zielrufnummer eines privaten kommunikationsnetzes
EP1033897B1 (de) Verfahren zur Bereitstellung eines persönlichen Kommunikationsdienstes sowie Verfahren zur Anrufleitung und Dienststeuereinheit
EP1049337A2 (de) Intelligente Netzwerkdienste
EP0886449B1 (de) Gebührenfreie Kommunikationsverbindung
EP0878109A2 (de) Verfahren und mobil-kommunikationssystem zum routen von anrufverbindungen
DE19814161A1 (de) Verfahren zum Verbindungsaufbau für ankommende, an einen Teilnehmer eines Kommunikationsnetzes gerichtete Anrufe sowie Dienstesteuerungseinheit zum Unterstützen des Verbindungsaufbaus
DE19933547A1 (de) Telekommunikationsnetz und Verfahren zum Routen ankommender Verbindungen für MTC-Dienste
DE19943144A1 (de) Verfahren zur Änderung von Servicedaten
DE19852774B4 (de) Telefonvermittlungssystem zur Eingliederung von Mobilnetzteilnehmern in eine CENTREX-Gruppe
DE19930146B4 (de) Verfahren zum Herstellen einer Telekommunikationsverbindung über ein Zwischennetz
EP0943215A2 (de) Verfahren und einrichtung zur ermöglichung eines zugriffs auf dienste und einrichtungen eines gsm-mobilfunknetzes über ein externes telekommunikationsnetz
EP0906706B1 (de) Verfahren zur unterstützung von privaten nummerierungsplänen durch öffentliche telekommunikationsnetze
DE19651544C2 (de) Verfahren zum Betreiben eines Telekommunikationsnetzes mit Hilfs-Vermittlungsstellen
DE19936783C2 (de) Verfahren zur Nutzung von durch ein Kommunikationsnetz bereitgestellten teilnehmerbezogenen Wirknetzinformationen in Mehrwert- oder Internetdiensten
EP1093313A2 (de) Verfahren zur Übermittlung von Dienst-Signalisierungsnachrichten, Vermittlungsstelle, Konvertierungsknoten und Dienststeuerungsknoten
EP1108341A1 (de) Verfahren und mobil-kommunikationssystem zur steuerung eines verbindungsaufbaus
EP0957645B1 (de) Netzelement für ein intelligentes Telekommunikationsnetz

Legal Events

Date Code Title Description
8139 Disposal/non-payment of the annual fee