DE60315361T2 - Verfahren und vorrichtung zum routen einer dienstanforderung - Google Patents

Verfahren und vorrichtung zum routen einer dienstanforderung Download PDF

Info

Publication number
DE60315361T2
DE60315361T2 DE60315361T DE60315361T DE60315361T2 DE 60315361 T2 DE60315361 T2 DE 60315361T2 DE 60315361 T DE60315361 T DE 60315361T DE 60315361 T DE60315361 T DE 60315361T DE 60315361 T2 DE60315361 T2 DE 60315361T2
Authority
DE
Germany
Prior art keywords
service
addressing information
server unit
usage rule
condition
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.)
Expired - Lifetime
Application number
DE60315361T
Other languages
English (en)
Other versions
DE60315361D1 (de
Inventor
Antoine De-Poorter
Maria Luisa Mas Rosique
Miguel Angel Pallares Lopez
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.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
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 Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of DE60315361D1 publication Critical patent/DE60315361D1/de
Application granted granted Critical
Publication of DE60315361T2 publication Critical patent/DE60315361T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/35—Network arrangements, protocols or services for addressing or naming involving non-standard use of addresses for implementing network functionalities, e.g. coding subscription information within the address or functional addressing, i.e. assigning an address to a function
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0263—Rule management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Exchange Systems With Centralized Control (AREA)

Description

  • GEBIET DER ERFINDUNG
  • Die vorliegende Erfindung betrifft Telekommunikationssysteme und, genauer, die Verfahren für das Routing von Dienstanforderungen in diesen Systemen und die daran beteiligten Vorrichtungen.
  • STAND DER TECHNIK
  • Ein dem Stand der Technik entsprechendes Telekommunikationssystem kann verschiedene funktionale Einheiten, die auch Telekommunikationsknoten genannt werden, umfassen, die so gestaltet sind, dass sie mehreren Teilnehmerendgeräten, die von den Teilnehmern dieses Systems benutzt werden, Kommunikation und Dienste zur Verfügung stellen können. In Abhängigkeit von den spezifischen Eigenschaften eines konkreten Telekommunikationssystems kann es verschiedene Arten von Telekommunikationsknoten umfassen, von denen jeder eine oder einen Satz von spezialisierten Funktionen ausführt; wobei, in Abhängigkeit von den Einzelheiten der Implementierung, jeder Knoten innerhalb einer einzigen physikalischen Maschine implementiert sein kann oder auf verschiedene physikalische Maschinen verteilt sein kann, von denen jede einen Teil der Gesamtfunktionalität implementiert, die für diesen Knoten gefordert und/oder standardisiert ist. Der Begriff "Servereinheit" soll in dieser Patentanmeldung im Weiteren verwendet werden, um einen Knoten in einem Telekommunikationssystem zu bezeichnen, welcher eine spezielle Funktionalität ausführt, gleichgültig, ob er innerhalb einer physikalischen Maschine oder innerhalb verschiedener zusammenwirkender physikalischer Maschinen implementiert ist.
  • Neben anderen Servereinheiten kann ein Telekommunikationssystem eine oder mehrere miteinander verbundene Kommunikationsservereinheiten (Communication Server Entities, CS) umfassen, welche berechtigt sind, in die Signalisierung einzugreifen, die mit der Bereitstellung von Kommunikationen zwischen Teilnehmerendgeräten (z.B. Sprachverbindungen, Datenverbindungen usw.) zusammenhängt, sowie in die Signalisierung, die mit der Bereitstellung von Diensten für die Teilnehmerendgeräte zusammenhängt (z.B. Nutzung von Nachrichtenübermittlungsdiensten); wobei die Bereitstellung einer Kommunikation zwischen zwei Teilnehmerendgeräten ebenso wie die Bereitstellung eines Dienstes für ein Teilnehmerendgerät den Eingriff einer oder mehrerer Servereinheiten in dem Telekommunikationssystem erfordern kann. Beispiele von Kommunikationsservereinheiten CS sind: Vermittlungs-/Routingknoten wie etwa MSCs (Mobile Switching Centres, Mobilvermittlungsstellen), SGSNs (Serving GPRS Support Nodes, bedienende GPRS-Unterstützungsknoten) oder GGSNs (Gateway GPRS Support Nodes, Gateway-GPRS-Unterstützungsknoten) in einem Mobilfunksystem; Proxyserver in einem SIP-basierten System (z.B. wie in "SIP: Session Initiation Protocol" IETF-RFC3261 beschrieben); CSCFs (Call State Control Functions, Anrufzustand-Steuerfunktionen) in dem INS (IP Multimedia Subsystem) eines Mobilfunksystems der 3. Generation (z.B. wie in der Stage-2 of the IMS, Spezifikation TS 23.228 V5.5.0, Juni 2002, beschrieben); usw.
  • Zu dem Zweck, jeden von den mehreren Teilnehmern in einem Telekommunikationssystem und/oder deren entsprechende Teilnehmerendgeräte einzeln zu identifizieren, werden den Teilnehmern eines Telekommunikationssystems Kennungen zugewiesen (im Weiteren: Teilnehmerkennungen, Teilnehmer-IDs). Die Typen von Teilnehmer-IDs und sogar die Anzahl von Teilnehmer-IDs pro Teilnehmer können in Abhängigkeit von den Eigenschaften eines Telekommunikationssystems variieren. Zum Beispiel können heutzutage einem Teilnehmer eine oder mehrere Teilnehmer-IDs von verschiedenen Typen zugewiesen sein, wie etwa: eine E.164 Nummer (auch "Telefonnummer" genannt), eine URI (Uniform Resource Identifier, einheitliche Ressourcenkennung), eine "h323-ID" usw.
  • Teilnehmer-IDs werden hauptsächlich verwendet, um einen als Partner bei einer Kommunikation fungierenden Teilnehmer zu identifizieren. Daher wird, wenn ein gegebener Teilnehmer "A" eine Sprachverbindung oder eine Datenverbindung mit einem anderen Teilnehmer "B" aufbaut, eine Kommunikationsanforderung gesendet, welche die Teilnehmer-ID des Teilnehmers "B" transportiert und welche dann verwendet wird, um diese Kommunikationsanforderung zu einem Endgerät des Teilnehmers "B" zu routen. Diese Kommunikationsanforderung kann eine oder mehrere Kommunikationsservereinheiten (CSs) durchqueren, in Abhängigkeit zum Beispiel davon, ob beide Teilnehmer "A" und "B" von derselben oder verschiedenen CSs bedient werden. Entsprechend dem verwendeten Signalisierungsprotokoll kann eine Kommunikationsanforderung in verschiedenen Signalisierungsnachrichten transportiert werden. Zum Beispiel kann eine Kommunikationsanforderung innerhalb einer IAM-(Initial Address Message)Nachricht gemäß dem ISUP (ISDN User Part, ISDN-Benutzerteil), einer INVITE-Nachricht gemäß dem SIP, einer SETUP-Nachricht gemäß H.323 usw. transportiert werden; wobei die Kommunikationsanforderung eine Teilnehmer-ID des Zielteilnehmers in einem Format enthält, welches für das Signalisierungsprotokoll geeignet ist, das zur Signalisierung der Kommunikationsanforderung verwendet wird (z.B. ISUP, SIP, H.323 usw.).
  • In ähnlicher Weise können auch manchen Diensten, die von einem dem Stand der Technik entsprechenden Telekommunikationssystem zur Verfügung gestellt werden, individuelle Kennungen (im Weiteren: Dienstkennungen, Dienst-IDs, SIDs) zugewiesen werden. Dienst-IDs können dasselbe Format haben, das oben für Teilnehmer-IDs angegeben wurde, was nicht nur ihre Verwendung durch Endbenutzer erleichtert, sondern auch ermöglicht, für Dienst-IDs und für Teilnehmer-IDs dieselben Routing-Mechanismen in dem Telekommunikationssystem zu verwenden.
  • Dementsprechend kann der Zugriff auf einen spezifischen Dienst, der durch eine spezifische Dienst-ID gekennzeichnet ist, erreicht werden, indem eine Dienstanforderung gesendet wird, welche diese Dienst-ID enthält; wobei Dienstanforderungen auch gemäß irgendeinem der oben erwähnten Signalisierungsprotokolle signalisiert werden können, welche verwendet werden, um Kommunikationsanforderungen zwischen Teilnehmern zu transportieren.
  • Jedoch im Gegensatz zu einer Teilnehmer-ID, welche einen Teilnehmer kennzeichnet (oder ein einem Teilnehmer zugewiesenes Endgerät), kennzeichnet eine Dienst-ID einen spezifischen Dienst in einer Servereinheit (im Weiteren als Anwendungsservereinheit [Application Server Entity], AS bezeichnet), welche diesen Dienst hostet, oder, anders ausgedrückt, welche Dienstlogik hostet, um diesen Dienst zu bewerkstelligen und um eine ihn betreffende Dienstanforderung zu verarbeiten. Wie anhand einiger unten angegebener Beispiele von Diensten verständlich wird, sind außerdem Dienst-IDs meist von einer in stärkerem Maße zeitweiligen Natur als Teilnehmer-IDs, da sie in Abhängigkeit vom Vorhandensein oder Nichtvorhandensein eines gegebenen Dienstes erzeugt und gelöscht werden können, während eine Teilnehmer-ID meist bestehen bleibt, solange der entsprechende Teilnehmer noch von dem Telekommunikationssystem bedient wird.
  • Einige Beispiele von Diensttypen, die üblicherweise von Anwendungsservereinheiten AS bereitgestellt werden und denen gewöhnlich Dienst-IDs für ihre individuelle Kennzeichnung zugewiesen werden, werden nun unter Bezugnahme auf "Präsenz-" und "Sofortnachrichtenversendungs-"Dienste angegeben. Eine allgemeine Beschreibung für beide Dienste, Präsenz- und Sofortnachrichtenver sendungs-Dienste, wird in IETF-RFC2778 ("A model for Presence and Instant Messaging") gegeben.
  • Kurzgesagt, umfasst der Präsenzdienst (Presence Service) die Anmeldung eines Teilnehmers für Informationen, die den Zustand eines anderen Teilnehmers oder einer Gruppe von Teilnehmern betreffen (z.B. eine "Online"/"Offline"-Zustandsinformation, die angibt, ob ein gegebener Teilnehmer gegenwärtig mit einem Endgerät in dem Telekommunikationssystem registriert ist), sowie das Finden und Abrufen der erforderlichen Daten für die Bereitstellung dieser Informationen. Bei Verwendung der Terminologie, die gegenwärtig für einen Präsenzdienst verwendet wird, wird der Teilnehmer, welcher sich anmeldet, um Zustandsinformationen eines anderen Teilnehmers oder anderer Teilnehmer zu erhalten, "Watcher" (Beobachter) genannt, während die Teilnehmer, welche diese Zustandsinformationen liefern, "Presentities" (Erzeuger von Präsenzinformationen) genannt werden. Mithin kann zum Beispiel ein Teilnehmer, der als "Watcher" agiert, sich für Präsenzinformationen anmelden, die einen anderen Teilnehmer ("Presentity") betreffen oder eine Gruppe von vordefinierten Teilnehmern betreffen. Zu diesem Zweck kann er verschiedene Listen in einer AS definiert haben, die berechtigt ist, einen Präsenzdienst für einen Watcher zu erbringen, wobei jede Liste eine oder verschiedene Teilnehmer-IDs umfasst, die den anderen Teilnehmern entsprechen, und durch eine spezifische Kennung (d.h. eine Dienst-ID) gekennzeichnet ist, welche eine Dienstinstanz eines Präsenzdienstes für einen Watcher kennzeichnet, welche die Zustandsüberwachung eines Satzes von vordefinierten Teilnehmern betrifft. Zum Beispiel kann dieser Teilnehmer eine oder mehrere Listen definiert haben, die Teilnehmer-IDs einer Gruppe von Freunden, einer Gruppe von Arbeitskollegen, einer Gruppe von Verwandten usw. enthalten. Wenn zum Beispiel angenommen wird, dass die Dienst-IDs ein URI-Format annehmen, könnte eine Dienst-ID für Listen der oben erwähnten Art durch URIs gekennzeichnet sein wie (z.B.) MyBikerFriends@PresenceService.op2.com, "AccountDepCompanyX@PresenceService.op2.com", usw.
  • Falls ein als "Watcher" agierender Teilnehmer davon benachrichtigt werden möchte, welche Freunde aus einer Gruppe von Freunden in (z.B.) einer Liste von Kameraden gegenwärtig mit dem Telekommunikationssystem verbunden sind, dann kann dieser Teilnehmer von seinem Endgerät eine Dienstanforderung senden, welche die entsprechende Dienst-ID umfasst. Falls das Protokoll, das verwendet wird, um mit Anmeldungen von Watchern beim Präsenzdienst zusammenhängende Signalisierungsnachrichten zu transportieren, SIP ist (z.B. wie im IETF-ENTWURF "Presence Event Package for SIP", draft-ietf-simplepresence-10.txt, definiert), dann wird eine SIP-Nachricht "SUBSCRIBE" (ANMELDEN), die eine dieser Dienst-IDs im Feld "Request-URI" (Anforderung URI) der SUBSCRIBE-Nachricht enthält, diese Dienstanforderung transportieren. Wenn die Dienstanforderung bei der entsprechenden AS eintrifft, kann die AS, um die Dienstanforderung zu erfüllen, weitere SUBSCRIBE-Nachrichten senden, die jeweils die Kennung einer "Presentity" umfassen, die in der entsprechenden Verteilungsliste enthalten ist.
  • Kurz gesagt, besteht der Sofortnachrichtenversendungs-Dienst (Instant Messaging Dienst) im Senden kleiner Nachrichten, welche Teilnehmern, die "online" sind (d.h. Teilnehmern, die gegenwärtig innerhalb eines Endgerätes in dem Telekommunikationssystem registriert sind), umgehend zugestellt werden. Wie beim Präsenzdienst können eine oder mehrere Listen für den Sofortnachrichtenversendungs-Dienst definiert werden, wobei jede Liste die Kennungen eines Satzes von Teilnehmern umfasst, wobei eine Instanz des Sofortnachrichtenversendungs-Dienstes durch eine individuelle Dienst-ID gekennzeichnet ist, die jeder Liste zugewiesen ist. Im Gegensatz zum Präsenzdienst, bei dem die Listen von Teilnehmern, die von einem als "Watcher" agierenden Teilnehmer überwacht werden, im Allgemeinen eine private Natur aufweisen und daher dazu bestimmt sind, von diesem Teilnehmer benutzt zu werden, können Listen für die Nachrichtenversendung (Messaging) öffentlich bekannt sein (z.B. können sie in der AS definiert sein, ohne dass ein Eingriff eines Endteilnehmers notwendig ist, zum Beispiel können sie durch den Telekommunikationsbetreiber definiert sein), wobei sie mithin mehreren Teilnehmern ermöglichen, Sofortnachrichten (Instant Messages) an eine öffentlich bekannte Liste zu senden. Wie in dem oben angeführten Beispiel könnte unter der Annahme, dass Dienst-IDs ein URI-Format annehmen, eine Dienst-ID für eine Liste zum Verteilen einer Sofortnachricht an eine bestimmte Gruppe von Teilnehmern zum Beispiel sein: "DistributionList77@MSGService.op2.com".
  • In ähnlicher Weise wie beim Präsenzdienst kann ein gegebener Teilnehmer, wenn er eine Sofortnachricht an eine gegebene Gruppe von Teilnehmern senden möchte, von seinem Endgerät eine Dienstanforderung senden, welche die entsprechende Dienst-ID umfasst. Falls das Protokoll, das verwendet wird, um mit einer Sofortnachrichtenversendung zusammenhängende Signalisierungsnachrichten zu transportieren, SIP ist (z.B. wie in IETF-RFC3428 "SIP extension for Instant Messaging" definiert), dann wird eine SIP-Nachricht "MESSAGE" (NACHRICHT), die eine dieser Dienst-IDs im Feld "Request-URI" (Anforderung URI) der "MESSAGE" (sowie die Textnachricht, deren Übermittlung gewünscht wird) enthält, diese Dienstanforderung transportieren. Wenn die Dienstanforderung bei der entsprechenden AS eintrifft, kann diese, um die Dienstanforderung zu erfüllen, weitere "MESSAGE"-Nachrichten senden, die jeweils eine Kennung eines Empfänger-Teilnehmers umfassen, die in der entsprechenden Verteilungsliste enthalten ist.
  • Weitere Beispiele von Diensten, die durch Dienst-IDs gekennzeichnet werden und von ASs bereitgestellt werden, können mit Bezug auf Einwahlkonferenz-Dienste in einem modernen Telekommunikationssystem und Fernabstimmungs-Dienste angegeben werden.
  • Bei einem Einwahlkonferenz-(Dial-in Conferencing)Dienst arrangiert ein Teilnehmer "A" eine Multikonferenz, welche zum Beispiel 3 weitere Teilnehmer haben kann: "B", "C" und "D". Der Teilnehmer "A" kann (z.B. über HTTP, WAP usw.) mit zum Beispiel einer AS in Verbindung treten, welche berechtigt ist, Multikonferenz-Dienst bereitzustellen (z.B. durch Steuern seiner zugehörigen Signalisierung und schließlich durch Steuern eines Media Handlers). Die AS weist dann eine spezielle Dienst-ID für diese spezielle Konferenz zu (z.B. "conf456@homenetwork.com") und gibt sie zurück zu Teilnehmer "A". Der als Organisator der Einwahlkonferenz agierende Teilnehmer "A" verteilt an die anderen Teilnehmer die Dienst-ID, die zu dem für die Konferenz vereinbarten Zeitpunkt verwendet werden soll (zum Beispiel kann er für diesen Zweck die oben erwähnte SIP-Nachricht "MESSAGE" verwenden oder sie mit anderen Mitteln senden, wie etwa E-Mail, Kurznachricht usw.). Stattdessen kann der Teilnehmer "A" die Einwahlkonferenz auch mit anderen Mitteln arrangieren (z.B. kann er sich an einen Betreiber wenden und von ihm die Dienst-ID empfangen). Danach können die Konferenzteilnehmer (Teilnehmer "A", "B", "C" und "D") Dienstanforderungen senden, welche diese Dienst-ID enthalten und welche dann zu der AS geroutet werden. Folglich kann zum Beispiel, wenn das zum Transportieren von Signalisierungsnachrichten verwendete Protokoll SIP ist, ein beliebiger Teilnehmer eine Dienstanforderung senden, der Konferenz beizutreten, indem er eine INVITE-Nachricht sendet, welche die der Einwahlkonferenz zugewiesene Dienst-ID (z.B. "conf456@homenetwork.com") im Feld "Request-URI" (Anforderung URI) der INVITE-Nachricht transportiert. Beim Empfang von Dienstanforderungen von den Teilnehmern der Einwahlkonferenz kann die AS anschließend die entsprechende Mediensitzung aufbauen (oder einen Medien-Handler mit ihrem Aufbau beauftragen), um einen Empfang von Medien von jeder Partei und deren anschließende Verteilung an die anderen zu ermöglichen.
  • Bei Fernabstimmungs-Diensten (Tele-Voting) können die Teilnehmer Dienstanforderungen senden, welche die entsprechende Dienst-ID enthalten, um zum Beispiel eine Rangliste zu steuern oder um bei einer öffentlichen Meinungsumfrage eine Antwort zu übermitteln. In diesem Falle würde eine Dienstanforderung, welche die entsprechende Dienst-ID enthält (z.B. "TheTeleVotingOfTodayYES@TVXZZ.com"), zu einer AS geroutet, welche zu ihrer Speicherung und weiteren Verarbeitung berechtigt sein kann.
  • Bei den oben angeführten Beispielen von Diensten kann man feststellen, dass in Abhängigkeit von den Besonderheiten eines gegebenen. Diensttyps mehrere Dienst-IDs vorhanden sein können, von denen jede eine spezifische Dienstinstanz eines Diensttyps kennzeichnet (zum Beispiel verschiedene Dienstinstanzen eines Präsenzdienstes). Daher wird, da eine spezifische Dienst-ID im Allgemeinen dazu vorgesehen ist, einen spezifischen Dienst eindeutig zu kennzeichnen, der Begriff Dienst-ID in diesem Text durchgehend verwendet, um eine Kennung eines gegebenen Dienstes zu bezeichnen, gleichgültig, ob alle möglichen Instanzen dieses Diensttyps durch dieselbe Dienst-ID gekennzeichnet werden oder nicht.
  • Bei früheren Telekommunikationssystemen waren in Kennungen (entweder Teilnehmer-IDs oder Dienst-IDs) Adressierungsinformationen eingebettet, wodurch sie das Routing einer Kommunikationsanforderung oder einer Dienstanforderung unter Verwendung der empfangenen Kennung (Teilnehmer-ID oder Dienst-ID) als solcher ermöglichten. Dies war auf die Tatsache zurückzuführen, dass diese Kennungen Endpunkten (z.B. Teilnehmerendgeräten, ASs) entsprechend Nummerierungsplänen zugewiesen waren, welche vollständig mit der geographischen Lage der Endpunkte im Zusammenhang standen, zum Beispiel entsprechend dem geographischen Standort eines Teilnehmerendgerätes, das einem Teilnehmer in dem Telekommunikationssystem zugeordnet ist, der durch eine Teilnehmer-ID gekennzeichnet ist, oder entsprechend dem geographischen Standort einer AS, die berechtigt ist, einen Dienst zu erbringen, der durch eine Dienst-ID gekennzeichnet ist.
  • Zum Beispiel konnte eine Telefonnummer wie etwa +34 91 1234567 sein: eine Teilnehmer-ID eines Teilnehmers in einem PSTN (Public Switched Telephone Network, öffentliches Telefonwählnetz), dessen Endgerät von einer CS, wie etwa einer Ortsvermittlungsstelle in dem PSTN, bedient wird, die sich in Spanien (34) befindet, im Bereich Madrid (91), und welche den Zugang für (z.B.) 1000 Teilnehmer (z.B. nummeriert von 4000 bis 4999) ermöglicht. In ähnlicher Weise konnte es die Dienst-ID eines einzelnen Sprachmailbox-Dienstes sein, der von einer AS in Spanien im Bereich Madrid erbracht wird, wobei diese AS (z.B.) 1000 einzelne Sprachmailboxen (z.B. 4000... 4999) bedient.
  • Daher war eine so zugewiesene Kennung (Teilnehmer-ID oder Dienst-ID) direkt für das Routing einer Anforderung (Kommunikationsanforderung oder Dienstanforderung), welche sie enthielt, zu ihrem Endziel verwendbar.
  • Als jedoch neuer Bedarf entstand (wie etwa Mobilität, die einem gegebenen Teilnehmer ermöglicht, sich dynamisch von verschiedenen geographischen/physikalischen Aufenthaltsorten aus anzumelden), tendierte diese enge (d.h. nicht dynamische) Beziehung Kennung-Standort dazu, zu verschwinden; damit ermöglichte sie eine Unabhängigkeit zwischen einer Teilnehmer-ID und den entsprechenden Adressierungsinformationen (AI), die für das Routing einer Kommunikationsanforderung zu einem Endgerät des Teilnehmers verwendbar sind.
  • Insbesondere führten für Dienste andere Notwendigkeiten, die mit Faktoren wie Skalierbarkeit, Zuverlässigkeit und flexible Zuweisung von Ressourcen zusammenhingen, ebenfalls dazu, Dienst-IDs vom physikalischen Aufenthaltsort der jeweiligen ASs unabhängig zu machen, und damit unabhängig von den entsprechenden Adressierungsinformationen, die für das Routing von Dienstanforderungen zu ihnen verwendbar sind. Trotzdem wird durch alles Obengesagte nicht ausgeschlossen, dass in manchen Fällen die Adressierungsinformationen, welche einer gegebenen Kennung entsprechen (Teilnehmer-ID oder Dienst-ID), dieselben sind wie diese Kennung
  • Um eine flexible Beziehung zwischen Kennungen (Teilnehmer-IDs und Dienst-IDs) (gewöhnlich statisch) und ihren entsprechenden Adressierungsinformationen (gewöhnlich dynamisch) zustande zu bringen, wird in Telekommunikationssystemen nach dem Stand der Technik eine spezialisierte Servereinheit (im Weiteren als Standortservereinheit [Location Server Entity], LS bezeichnet) vorgesehen. Beispiele von Standortservereinheiten LS sind: HLRs (Home Location Registers, Heimatregister) in Mobilfunksystemen der 2. Generation, HSS (Home Subscriber Servers) in Mobilfunksystemen der 3. Generation, "Umleitungsserver" ("Redirect Servers") in SIP-basierten Systemen, oder "Gatekeepers" in H.323-basierten Systemen.
  • Eine LS speichert das, was allgemein Standort-Informationen genannt wird und was mehrere Kennungen (Teilnehmer-IDs und/oder Dienst-IDs) und die entsprechenden (dynamischen) Adressierungsinformationen (AI) umfasst, die für das Routing von Anforderungen verwendbar sind, welche irgendeine dieser Kennungen enthalten.
  • Die Art der Adressierungsinformationen AI, die für eine gegebene Teilnehmer-ID oder Dienst-ID in einer LS gespeichert werden, kann entsprechend unterschiedlichen Implementierungen variieren. Zum Beispiel können die AI enthalten: Netzadressen (d.h. ISO Schicht-3-Adressen, wie etwa IP-Adressen); Sicherungsschicht-Adressen (d.h. ISO Schicht-2-Adressen); Alias-Adressen wie etwa URIs, welche weiter übersetzt werden können in (z.B.) die entsprechende Netzadresse, zum Beispiel mittels einer weiteren DNS (Domain Name System, Domänennamensystem) Anfrage; usw. Außerdem kann die Einheit, die von den AI adressiert wird, die im Zusammenhang mit einer gegebenen Kennung gespeichert sind, variieren; so können zum Beispiel die AI eine Adresse einer CS enthalten, welche berechtigt ist, den Zugriff auf ein gegebenes Teilnehmerendgerät oder auf eine AS zu ermöglichen, eine Adresse eines Teilnehmerendgerätes oder eine Adresse einer AS, der einen Dienst hustet, usw. Ferner können die Adressierungsinformationen AI, zusätzlich zu einer Adresse oder anstelle einer solchen, Daten enthalten (im Weiteren als "Adressenbestimmungs-Fähigkeit" bezeichnet), welche verwendet werden können, um ferner eine CS auszuwählen, welche den Zugriff auf ein gegebenes Teilnehmerendgerät oder auf eine AS ermöglichen kann (z.B. Fähigkeits-Daten von CS, welche verwendet werden können, um eine CS zu finden, die mit dieser Fähigkeit übereinstimmt). Beispiele für diesen letzten Fall, in denen eine Adressenbestimmungs-Fähigkeit benutzt wird, sind in Kapitel 6.1.1 ("User registration status query") der Spezifikation TS 29.228 (V5.2.0, Dez. 2002) des Partnerschaftsprojektes der 3. Generation 3GPP zu finden, bezeichnet als Serving-CSCF Fähigkeiten ("S-CSCF Fähigkeiten"); und außerdem in den Kapiteln 3.5 ("Location-Info-Answer LIA Command") und 5.5 "Server-Capability AVP" des IETF-ENTWURFES "Diameter Multimedia Application (draftbelinchon-aaa-diameter-mm-app-00.txt, Feb. 2003), bezeichnet als "Server-Fähigkeiten".
  • Dementsprechend kann eine Kommunikationsservereinheit CS bei Empfang einer Kommunikationsanforderung oder einer Dienstanforderung von einer LS die Adressierungsinformationen erhalten, die sie benötigt, um diese empfangene Anforderung zu ihrem Endziel zu routen; wobei, wie später ausführlich erläutert wird, die Art und Weise, wie eine CS Adressierungsinformationen für Kennungen (Teilnehmer-IDs oder Dienst-IDs) von einer LS erhält, entsprechend verschiedenen Alternativen der Implementierung variieren kann (z.B. eine Standortabfrage, eine Umleitungsangabe). Zusammengefasst, ermöglichen wohlbekannte Techniken, Dienstanforderungen in einem dem Stand der Technik entsprechenden Telekommunikationssystem entsprechend den Dienst-IDs, die sie enthalten, zu routen, so dass diese Dienstanforderungen zu den entsprechenden AS unter Verwendung derselben (oder im Wesentlichen ähnlicher) Routingverfahren weiterzuleiten, wie diejenigen, die für das Routing von Kommunikationsanforderungen zwischen Teilnehmerendgeräten verwendet werden.
  • Eine AS kann berechtigt sein, einen gegebenen Dienst für alle seine Instanzen oder für einige von ihnen zu erbringen, oder sie kann sogar so beschaffen sein, dass sie mehrere verschiedene Dienste erbringt. In jedem Falle kann, da die Bereitstellung eines gegebenen Dienstes den Eingriff einer zu seiner Erbringung berechtigten AS erfordert, die Verfügbarkeit dieser AS von großer Bedeutung sein, da wahrscheinlich anzunehmen ist, dass sie sehr häufig Dienstanforderungen von unterschiedlichen Teilnehmern empfängt. Daher dürfte es wünschenswert sein, dass ihre Verarbeitungsmittel hauptsächlich dazu bestimmt sind, nur diejenigen Dienstanforderungen zu bedienen, die berechtigt sind, bedient zu werden, bei gleichzeitiger Minimierung der Verarbeitungszeit und der Ressourcen, die verwendet werden, um diejenigen Dienstanforderungen, welche aus irgendeinem Grunde nicht geeignet sind, bedient zu werden, zu erkennen (und letztendlich zurückzuweisen).
  • Das zum Stand der Technik gehörende Dokument US 6,282,574 von Voit et al., 28. August 2001, beschreibt einen verbesserten Namensübersetzungsserver, der in Reaktion auf Anfragen oder Anforderungen betreffs Namensübersetzungen eine bedingte Analyse durchführt.
  • KURZDARSTELLUNG DER ERFINDUNG
  • Es ist eine Aufgabe der vorliegenden Erfindung, in einem Anwendungsserver die Auswirkungen derjenigen Dienstanforderungen, welche wahrscheinlich nicht bedient werden, auf ein Minimum zu begrenzen.
  • Diese Aufgabe wird durch ein Verfahren gelöst, wie in Anspruch 1 beansprucht. Diese Aufgabe wird außerdem durch eine Standortservereinheit gelöst, wie in Anspruch 13 beansprucht, oder durch eine Kommunikationsservereinheit, wie in Anspruch 21 beansprucht, welche mit einer Anwendungsservereinheit zusammenwirken kann, wie in Anspruch 27 beansprucht. Diese Aufgabe wird außerdem durch ein Computerprogramm gelöst, wie in Anspruch 28 beansprucht, oder durch ein Computerprogramm, wie in Anspruch 29 beansprucht.
  • Gemäß einem Aspekt betrifft die Erfindung ein Verfahren für das Routing einer Dienstanforderung in einem Telekommunikationssystem, die einen Dienst betrifft, der durch eine gegebene Dienstkennung gekennzeichnet ist und in einer Anwendungsservereinheit gehostet wird. Wenn eine Dienstanforderung bei einer Kommunikationsservereinheit in diesem Telekommunikationssystem eintrifft, wird eine Verwendungsregel geprüft, bevor die Verwendung der entsprechenden Adressierungsinformationen, welche sich auf diese Dienstkennung beziehen, gestattet wird. Die Verwendungsregel kann eine oder mehrere einzelne Bedingungen umfassen, welche eine Dienstanforderung, die eine gegebene Dienstkennung enthält, erfüllen soll, bevor sie weiter zu der entsprechenden Anwendungsservereinheit geroutet wird. Die Verwendungsregel kann von einer Anwendungsservereinheit zu einer Standortservereinheit gesendet werden, welche mehrere Kommunikationsservereinheiten mit Standortinformationen versorgt, so dass, wenn zum Beispiel eine Standortanfrage in diesem Standortserver empfangen wird, welche Adressierungsinformationen anfordert, die für das Routing einer eine gegebene Dienstkennung enthaltenden Dienstanforderung verwendbar sind, die entsprechende Verwendungsregel geprüft werden kann und daher dieser Standortserver die entsprechenden Adressierungsinformationen dementsprechend zur Verfügung stellen oder verweigern kann. Stattdessen kann die Verwendungsregel auch auf eine oder verschiedene Kommunikationsservereinheiten heruntergeladen werden, entweder direkt von einem Anwendungsserver oder von einem Standortserver, so dass jede beliebige von den Kommunikationsservereinheiten bei Empfang einer Dienstanforderung die Verwendungsregel prüfen kann, welche der in dieser Anforderung enthaltenen Dienstkennung entspricht, bevor sie weitere Schritte ausführt, um sie zu ihrem Ziel zu routen.
  • Ein Verfahren gemäß der Erfindung stellt sicher, dass nur Dienstanforderungen, welche gemäß der entsprechenden Verwendungsregel wahrscheinlich von dem entsprechenden Anwendungsserver bedient werden, zu ihm geroutet werden. Da eine Dienstanforderung in einem frühen Stadium gestoppt (d.h. nicht weitergeroutet) werden kann, bevor sie zum Anwendungsserver gelangt, werden hierdurch die ungünstigen Auswirkungen von Dienstverweigerungs-(Denial Of Service)Attacken gegen die Ressourcen eines Telekommunikationssystems auf ein Minimum begrenzt, insbesondere was die von Anwendungsservern gehosteten und/oder genutzten Ressourcen anbelangt. Mit einer geeigneten Einstellung der entsprechenden Verwendungsregeln ermöglicht das Verfahren außerdem, unterschiedliche Routing-Bedingungen für das Routing von Dienstanforderungen, die mehrere unterschiedliche Dienste betreffen, anzuwenden.
  • Gemäß einem weiteren Aspekt betrifft die Erfindung eine Standortservereinheit, welche in einer Beziehung zueinander die Kennung eines auf einer Anwendungsservereinheit gehosteten Dienstes und Adressierungsinformationen, die für das Routing einer diese Dienstkennung enthaltenden Dienstanforderung verwendbar sind, speichert, und welche dazu vorgesehen ist, diese Adressierungsinformationen für das Routing einer diese Kennung enthaltenden Dienstanforderung zur Verfügung zu stellen. Gemäß der Erfindung speichert die Standortservereinheit ferner eine Verwendungsregel, welche die Bedingung(en) für das Gestatten der Verwendung dieser Adressierungsinformationen für Zwecke des Routings festlegt, und sie ist ferner dazu vorgesehen, diese Adressierungsinformationen nur zur Verfügung zu stellen, wenn dies nicht gegen die Verwendungsregel verstößt. Ferner betrifft die Erfindung gemäß einem anderen Aspekt ein Computerprogramm, welches, sobald es auf eine computerbasierte Maschine geladen worden ist, wie etwa einen computerbasierten Standortserver, dafür sorgt, dass diese Informationen für das Routing einer Dienstanforderung zur Verfügung stellt, wie hier im Zusammenhang mit einer Standortservereinheit gemäß der Erfindung beschrieben.
  • Eine Standortservereinheit, wie sie hier beschrieben wird, verhindert, indem sie die Bereitstellung der erforderlichen Adressierungsinformationen verweigert, dass eine unzulässige oder "unreife" Dienstanforderung, die eine gegebene Dienstkennung enthält, zu dem Anwendungsserver gelangt, welcher den durch diese Dienstkennung gekennzeichneten Dienst hostet.
  • Gemäß einem weiteren Aspekt betrifft die Erfindung eine Kommunikationsservereinheit, welche dazu vorgesehen ist, eine Dienstanforderung zu empfangen, Adressierungsinformationen zu beschaffen, die eine in der Dienstanforderung enthaltene Dienstkennung betreffen, und die Dienstanforderung unter Verwendung der beschafften Adressierungsinformationen weiter zu routen. Gemäß der Erfindung ist die Kommunikationsservereinheit ferner dazu vorgesehen, eine Verwendungsregel zu beschaffen, welche bestimmt, ob die Adressierungsinformationen für Zwecke des Routings verwendet werden können, und die empfangene Dienstanforderung nur dann weiter zu routen, wenn dies nicht gegen die Verwendungsregel verstößt. Ferner betrifft die Erfindung gemäß einem anderen Aspekt ein Computerprogramm, welches, sobald es auf eine computerbasierte Maschine geladen worden ist, wie etwa einen computerbasierten Kommunikationsserver, dafür sorgt, dass diese eine empfangene Dienstanforderung routet, wie hier im Zusammenhang mit einer Kommunikationsservereinheit gemäß der Erfindung beschrieben.
  • Eine Kommunikationsservereinheit, wie sie hier beschrieben wird, verhindert, dass eine unzulässige oder "unreife" Dienstanforderung, die eine gegebene Dienstkennung enthält, zu dem Anwendungsserver gelangt, welcher den durch diese Dienstkennung gekennzeichneten Dienst hostet, indem sie das weitere Routing der Dienstanforderung verweigert.
  • Gemäß einem weiteren Aspekt betrifft die Erfindung eine Anwendungsservereinheit, welche dazu vorgesehen ist, mit einer zweiten Servereinheit zu kommunizieren, welche in die Signalisierung einer Dienstanforderung eingreifen kann, wie etwa einer Standortservereinheit oder einer Kommunikationsservereinheit. Gemäß der Erfindung sendet die Anwendungsservereinheit an eine zweite Servereinheit eine Verwendungsregel, welche die Verwendung der entsprechenden Adressierungsinformationen gestattet, welche zu einer gegebenen Dienstkennung gehören. Eine Anwendungsservereinheit gemäß der Erfindung kann somit ferner so beschaffen sein, dass sie einer beliebigen von den Ausführungsformen des zuvor beschriebenen Verfahrens entspricht.
  • Durch ihr Zusammenwirken mit einer Standortservereinheit und/oder mit einer Kommunikationsservereinheit ermöglicht eine Anwendungsservereinheit, wie sie hier beschrieben wurde, jederzeit die Bedingung(en) für das Routing einer einen Dienst betreffenden Dienstanforderung einzustellen oder zu ändern, indem sie einfach die neue oder anderweitig geänderte Verwendungsregel einem Standortserver mitteilt, welcher diesen Dienst betreffende Standortinformationen speichert, oder einem Kommunikationsserver, welcher einen diesen Dienst betreffende Dienstanforderung empfangen und weiter routen kann. Der Inhalt der Verwendungsregel, die von der Anwendungsservereinheit gesendet wird, kann zum Beispiel von dynamischen Bedingungen abhängen, die dem Anwendungsserver bekannt sind, und kann mit einem Dienst zusammenhängen, welchen er hostet oder welcher von einem anderen Anwendungsserver gehostet wird.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • 1 zeigt eine aus Schichten aufgebaute schematische Ansicht eines Telekommunikationssystems nach dem Stand der Technik, die verschiedene funktionale Einheiten auf jeder Schicht zeigt.
  • 2 zeigt eine schematische Ansicht einiger funktionaler Elemente in einer Servereinheit nach dem Stand der Technik in einem Telekommunikationssystem.
  • 3 zeigt ein Beispiel einer Datenstruktur, die in einer Servereinheit gemäß der Erfindung gespeichert ist.
  • 4, 5 und 6 zeigen vereinfachte Signalflüsse gemäß verschiedenen Ausführungsformen der Erfindung.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Einige beispielhafte Ausführungsformen der Erfindung sollen nun unter Bezugnahme auf die 1 bis 6 ausführlich beschrieben werden.
  • 1 zeigt eine logisch aus Schichten aufgebaute schematische Ansicht eines allgemeinen Telekommunikationssystems nach dem Stand der Technik, die verschiedene Servereinheiten zeigt. Die abstrakte Darstellung in 1 soll sich nicht auf ein spezielles Telekommunikationssystem beziehen, und es ist damit auch nicht beabsichtigt, alle möglichen Servereinheiten darzustellen, welche darin existieren können, sondern vielmehr diejenigen, welche gewöhnlich in modernen Telekommunikationssystemen implementiert sind und gleichzeitig für die Veranschaulichung der Erfindung relevant sind.
  • Die unterste Schicht (1), die in 1 dargestellt ist, umfasst einen Satz von Zugangspunkten (4, 5a, 5b), welche die physikalische (drahtgebundene oder drahtlose) Verbindung der Teilnehmerendgeräte (nicht dargestellt) mit dem Telekommunikationssystem gewährleisten, so dass sie diesen Endgeräten ermöglichen, Signalisierung und/oder Medien mit Servereinheiten in dem Telekommunikationssystem auszutauschen. Die Art eines Zugangspunktes bestimmt die Funktionen, welche er zu gewährleisten hat. Zugangspunkte können von einfachen verdrahteten Punkt-zu-Punkt-Verbindungen bis zu komplexeren Verbindungen reichen, welche eine Umcodierung von Signalisierung und/oder Medien für die Informationen erfordern können, die mit Endgeräten und anderen Servereinheiten in dem Telekommunikationssystem ausgetauscht werden. Eine Politik des lokalen Zugangs und Steuerungsfunktionen können ebenfalls durch Zugangspunkte ausgeführt werden. In Abhängigkeit von den Zugangstypen, die in einem Telekommunikationssystem unterstützt werden, kann diese Schicht (1) umfassen: Funkbasisstationen (4), die mobilen Endgeräten einen Funkzugang zur Verfügung stellen; LANs (Local Area Networks, lokale Netze) (5a) oder WLANs (Wireless LANs, drahtlose lokale Netze) (5b), welche einen Zugang zu Endgeräten zur Verfügung stellen, die drahtgebunden bzw. drahtlos an diese LANs oder WLANs angeschlossen sind; Punkt-zu-Punkt-Kabel und/oder Fasern, die ein Teilnehmerendgerät mit einer Kommunikationsservereinheit (CS) verbinden; usw.
  • Die zweite Schicht (2), die in 1 dargestellt ist, umfasst einen Satz von Servereinheiten (CS1, CS2, CS3, LS1, LS2), welche dazu vorgesehen sind, in die Signalisierung von Kommunikationen und Diensten einzugreifen, welche durch das Telekommunikationssystem zur Verfügung gestellt werden. Letztendlich können CSs auch in die Vermittlung, das Routing oder die Steuerung der Medien eingreifen, die in diesen Kommunikationen und Diensten ausgetauscht werden. Da ein Telekommunikationssystem viele Zugangspunkte (4, 5a, 5b) umfassen kann, die sich an sehr weit entfernten geographischen Standorten befinden, umfasst es gewöhnlich mehrere Kommunikationsservereinheiten (CS1, CS2, CS3), die berechtigt sind, Signalisierung zu/von zwei (oder mehr) Endpunkten einer Kommunikation (z.B. zwei oder mehr Endgeräten, einem Endgerät und einer AS usw.) zu empfangen und weiter zu routen. Wie oben erwähnt, sind in Telekommunikationssystemen nach dem Stand der Technik verschiedene Arten von Kommunikationsservereinheiten (CS) bekannt; wobei einige von ihnen speziell dazu bestimmt (oder zugewiesen) sein können, den Zugang zu Endpunkten zu bedienen, indem sie zu/von ihnen die Signalisierung routen, die Kommunikationen oder Dienste betrifft, und, wenn nötig, diese Signalisierung zu/von anderen CSs routen, während andere CSs speziell dazu bestimmt sein können, Verbindungen zwischen CSs zu gewährleisten (z.B. Vermaschung von CSs unterschiedlicher Netzbetreiber und/oder verschiedener geographischer Bereiche innerhalb eines Telekommunikationssystems).
  • Die Standortservereinheiten (LS1, LS2), die in der zweiten Schicht (2) von 1 dargestellt sind, speichern Adressierungsinformationen, die für das Routing von Kommunikationsanforderungen und/oder Dienstanforderungen anhand einer Kennung (Teilnehmer-ID, Dienst-ID), die in den Anforderungen enthalten ist, verwendbar sind. Dementsprechend sind LSs dazu vorgesehen, den CSs die notwendigen Adressierungsinformationen zur Verfügung zu stellen, um Dienst- und Kommunikationsanforderungen, die in diesen CSs empfangen wurden, zu routen; allerdings sind sie bei einigen Implementierungen dazu vorgesehen, die geeigneten Adressierungsinformationen einem Teilnehmerendgerät zur Verfügung zu stellen, so dass das Teilnehmerendgerät eine Kommunikationsanforderung oder eine Dienstanforderung unter Verwendung der empfangenen Adressierungsinformationen routen kann (z.B. wie für einen H.323 Gatekeeper in 26 in der ITU-T Empfehlung H.323, Nov. 2000, in Bezug auf den "Direct Endpoint Call Signalling" Modus beschrieben ist).
  • Innerhalb eines Telekommunikationssystems kann mehr als eine LS existieren, was zum Beispiel von Faktoren der Skalierbarkeit und Zuverlässigkeit abhängt und auch von der Anzahl der Netzbetreiber und/oder Netzdomänen in dem System abhängt.
  • Die Art und Weise, wie eine CS Adressierungsinformationen für Kennungen (Teilnehmer-IDs oder Dienst-IDs) beschafft, kann entsprechend verschiedenen Alternativen der Implementierung variieren.
  • Zum Beispiel kann eine bei einer Signalisierung vermittelnde CS, welche eine Signalisierungsnachricht empfangen hat, die eine Dienstanforderung transportiert (z.B. eine SETUP-Nachricht, eine INVITE-Nachricht, eine IAM-Nachricht usw.), an eine LS eine Standortanfrage senden, welche die in dieser Anforderung empfangene Dienstkennung enthält. Beispiele von Standortanfragen sind: MAP(Mobile Application Part, Mobilanwendungsteil-)Operationen wie etwa "SendRoutingInfo" in einem Mobilfunksystem der 2. Generation, "Cx-query" oder "Cx-Location-Query" in dem IMS eines Mobilfunksystems der 3. Generation, "Location Request" (LRQ) in einem H.323 System, DNS Anfragen (z.B. wie in IETF-RFC3263 beschrieben), usw. Im Ergebnis dieser Standortanfrage sendet die LS eine Antwort zurück (z.B. "SendRoutingInfoACK", "Cx-query Resp", "Cx-Location-Query Resp", "Location Confirm", LCF usw.), welche die entsprechenden Adressierungsinformationen enthält, die für das Routing der empfangenen Dienstanforderung verwendbar sind. Stattdessen kann eine LS auch eine Signalisierungsnachricht empfangen, welche eine Dienstanforderung von einer CS transportiert, und zurück an diese CS mit einer Umleitungsangabe-Nachricht antworten, welche die entsprechenden Adressierungsinformationen enthält, die für das Routing dieser Anforderung verwendbar sind (z.B. eine Redirection (Umleitungs-)Antwort "3XX", wie in IETF-RFC3261 für das SIP-Protokoll definiert).
  • In einigen Fällen kann eine CS LS-Funktionalität einbetten, oder, anders ausgedruckt, es kann eine CS-LS-Kolokation von Funktionalitäten vorliegen. Zum Beispiel kann eine CS Cache-Techniken anwenden und Standortinformationen speichern (z.B. während einer vordefinierten Zeit), so dass eine weitere Anfrage bei einer LS vermieden wird; daher kann diese CS Adressierungsinformationen für eine Kennung (Teilnehmer-ID oder Dienst-ID) verwenden, welche zuvor bei einer früheren Anfrage bei einer LS mit derselben Kennung beschafft wurden. Außerdem kann eine CS Adressierungsinformationen für Kennungen (Teilnehmer-IDs oder Dienst-IDs) von einer LS ohne eine vorherige Anfrage nachricht, die von der CS zu der LS gesendet wird, im Ergebnis einer Dienst- oder Kommunikationsanforderung erhalten, die in dieser CS empfangen wird. Somit kann zum Beispiel eine CS Offline-Informationen von einer LS empfangen, um Routing-Tabellen aufzubauen, die mehrere Kennungen mit ihren entsprechenden Adressierungsinformationen umfassen. Ferner kann eine CS Adressierungsinformationen für einige Kennungen von einem Managementsystem empfangen (z.B. als Teil ihrer Konfigurationsdaten). In anderen Fällen kann eine CS, da sie an dem Prozess der Registrierung und/oder Zulassung eines Endpunktes (z.B. eines Teilnehmerendgerätes oder einer AS für einen Dienst) beteiligt sein kann, während dieses Prozesses eine Adresse des Endpunktes erfahren und sie als Adressierungsinformation speichern, die für ein Routing von weiterer Signalisierung zu diesem Endpunk verwendbar ist.
  • Die dritte Schicht (3) von 1 umfasst spezialisierte Servereinheiten, die für die Bereitstellung von Diensten bestimmt sind (Anwendungsservereinheiten AS1, AS2). Ebenso wie es für Teilnehmerendgeräte geschieht, kann eine CS zugewiesen sein, um eine Signalisierung zu/von den AS in Bezug auf Dienste, die sie zu erbringen berechtigt ist, zu bedienen.
  • In 1 sind Kommunikationsleitungen (6, 7) dargestellt, um (auf einfache Weise) die Kommunikation zwischen Einheiten in den verschiedenen in der Figur dargestellten logischen Schichten (1, 2, 3) zum Austauschen von Signalisierung, Steuerungsdaten usw. zu veranschaulichen. Selbstverständlich können jedoch auch Servereinheiten innerhalb derselben logischen Schicht (wie in dem abstrakten Schema von 1 dargestellt) kommunizieren. Die Einzelheiten zum Erzielen der Kommunikation zwischen den Servereinheiten (CSs, LSs, ASs) hängen von den Einzelheiten der Implementierung des (der) Kommunikationsnetze(s) ab, die in dem Telekommunikationssystem vorhanden sind. Zum Beispiel kann eine Kommunikation zwischen Servereinheiten über ein oder mehrere zugrunde liegende Kommunikationsnetze unter Verwendung derselben oder unterschiedlicher zugrunde liegender Kommunikationstechnologien, (z.B. ATM-basiert, IP-basiert usw.) stattfinden, kann gemäß demselben oder gemäß unterschiedlichen Kommunikationsprotokollen (z.B. SIP, H.323 usw.) codiert werden und kann den Eingriff anderer Servereinheiten, die in 1 nicht dargestellt sind, beinhalten (wie etwa DNS-Server, Signalisierungs-Gateways usw.).
  • 2 zeigt eine schematische Ansicht einiger funktionaler Elemente in einer Servereinheit (8) nach dem Stand der Technik, wie etwa einer CS, einer LS oder einer AS. Im Allgemeinen umfasst eine Servereinheit in einem Telekommunikationssystem Verarbeitungsmittel, welche dazu vorgesehen sind, mit anderen Servereinheiten in einem Telekommunikationssystem Informationen auszutauschen (z.B. Signalisierungsnachrichten, Anfragen, Konfigurationsinformationen, Steuerungsdaten usw. zu senden und/oder zu empfangen) und sie zu verarbeiten. In Abhängigkeit von der speziellen Funktionalität, die von der Servereinheit (8) ausgeführt wird, können diese Verarbeitungsmittel dazu vorgesehen sein, verschiedene Funktionen auszuführen. Zum Beispiel können Verarbeitungsmittel in einer CS dazu vorgesehen sein, Signalisierungsnachrichten zu empfangen, die Anforderungen transportieren, und sie weiter zu handhaben; wobei diese weitere Handhabung die Analyse des Inhalts einer empfangenen Nachricht und auch deren anschließendes Routing zu einer anderen Servereinheit oder zu einem Teilnehmerendgerät umfassen kann, zusammen mit der Beschaffung von Adressierungsinformationen, wenn sie benötigt werden. In einer LS können deren Verarbeitungsmittel dazu vorgesehen sein, Standortanfragen und/oder Dienstanforderungen zu empfangen und zurück mit (je nachdem) Anfrageantworten und/oder Umleitungsangaben zu antworten, welche die ent sprechenden Adressierungsinformationen enthalten, die für das Routing verwendbar sind.
  • Für diese Zwecke (und unter der Annahme, dass die Servereinheit 8 innerhalb einer computerbasierten Maschine implementiert ist) können die Verarbeitungsmittel einen Prozessor (PR) und einen Speicher (MEM), der die von dem Prozessor (PR) auszuführenden Verarbeitungsanweisungen speichert, sowie eine oder mehrere Kommunikationseinrichtungen (IOD) zum Senden und Empfangen dieser Signalisierung und zum Austauschen von Informationen anderer Art mit anderen Einheiten oder Einrichtungen über Kommunikationsleitungen (9, 11) umfassen. Es können ein oder mehrere interne Busse (10) vorgesehen sein, um einen internen Austausch von Daten zwischen den Verarbeitungselementen (PR, MEM, IOD) zu ermöglichen, die in der Servereinheit 8 von 2 dargestellt sind.
  • Für die Speicherung von Daten, welche benötigt werden können, wenn empfangene Anforderungen, Anfragen usw. verarbeitet werden, können in einer Servereinheit 8 außerdem Datenspeichermittel (LDB) vorgesehen sein. So können diese Datenspeichermittel zum Beispiel eine Liste von Zuordnungen zwischen Teilnehmer- und/oder Dienstkennungen und den entsprechenden Adressierungsinformationen für jede dieser Kennungen enthalten. Da das Volumen der zu speichernden Informationen groß sein kann, können die Speichermittel extern angeordnet sein (z.B. in einem dedizierten Speicherserver, auf welchen die Servereinheit 8 über eine Kommunikationsleitung 11 zugreift, wie etwa eine Standortdienst-Datenbank (Location Service Data Base), oder sie können mit in derselben Maschine angeordnet sein, welche die Servereinheit 8 implementiert. Im letzteren Falle können dieselben Speichermittel dazu vorgesehen sein, sowohl die Verarbeitungsanweisungen als auch die oben erwähnte Zuordnung Kennungen-Adressierungsinformationen zu speichern.
  • In einem Telekommunikationssystem der weiter oben unter Bezugnahme auf 1 beschriebenen Art kann eine Signalisierungsnachricht, die eine Dienstanforderung von einem Endgerät transportiert, bevor sie zu der entsprechenden Anwendungsservereinheit (AS) gelangt, eine oder verschiedene Kommunikationsservereinheiten (CS) durchlaufen, und sie kann den Eingriff einer oder mehrerer Standortservereinheiten (LS) bedingen. So kann zum Beispiel die Dienstanforderung eine erste CS durchlaufen, die den Zugang des anfordernden Endgerätes bedient (z.B. CS1), eine zweite CS, die den Zugang der AS bedient (z.B. CS3), und eine dritte CS (z.B. CS2), die als Übergang zwischen CS1 und CS3 agiert. Sie kann jedoch auch nur die Vermittlung von nur einer CS bedingen, zum Beispiel in dem Falle, wenn diese CS beides bedient: das anfordernde Teilnehmerendgerät und die AS.
  • Gemäß der Erfindung kann eine Verwendungsregel (Usage Rule, UR) benutzt werden, um eine Dienstanforderung zu blockieren, bevor sie zu der AS gelangt, welche die Dienstlogik für die Bedienung einer solchen Anforderung hostet, indem sie die Verwendung der Adressierungsinformationen AI, die benötigt werden, um diese Dienstanforderung zu routen, unterlässt oder gestattet, womit sie einen unerwünschten, unberechtigten oder "unreifen" Zugriff auf einen Dienst verhindert.
  • In Abhängigkeit von den Einzelheiten der Implementierung kann eine Dienst-ID von der AS, von einem Teilnehmer oder in einer Kombination davon definiert werden. Zum Beispiel kann bei einer Dienst-ID wie etwa "FriendList4@PresenceService.op2.com" der Teil "FriendList4" von dem Teilnehmer definiert werden und der Teil "PresenceService.op2.com" von der AS definiert werden. In jedem Falle soll die gesamte Dienst-ID grundsätzlich eindeutig sein, so dass sie ermöglicht, einen speziellen Dienst oder eine spezielle Dienstinstanz eines Dienstes in der entsprechenden AS zu kennzeichnen. Daher kann eine Verwendungsregel (Usage Rule, UR) gemäß der Erfindung definiert werden, um den Zugriff auf den Dienst zu steuern, den sie betrifft, und die so strukturiert ist (wie später ausführlich erläutert wird), dass sie einen oder mehrere mit dem Dienst zusammenhängende Aspekte überwacht, welche bewirken können, dass es angebracht oder nicht angebracht ist, seine Ausführung zu veranlassen.
  • Vorzugsweise ist eine Verwendungsregel UR jeweils für eine Dienst-ID definiert, obwohl auch andere Ausführungsformen möglich sind, bei denen dieselbe UR für mehr als eine Dienst-ID gelten kann (z.B. für verschiedene Dienst-IDs von verschiedenen Diensten, für alle Dienst-IDs, die denselben Diensttyp betreffen, usw.).
  • Obwohl eine Verwendungsregel in Verbindung mit einer Dienst-ID definiert werden kann, kann sie in Verbindung mit einer Dienst-ID und/oder mit den entsprechenden Adressierungsinformationen AI für diese Dienst-ID gespeichert werden; demnach kann in Abhängigkeit von den Einzelheiten der Implementierung des Speichers eine UR entweder direkt oder indirekt in Verbindung mit einer Dienst-ID und ihren entsprechenden AI gespeichert werden. 3 zeigt eine Darstellung einer möglichen Speicherstruktur (SID, AI, UR), welche als Beispiel drei verschiedene Dienst-IDs (Spalte SID) in Verbindung mit ihren entsprechenden Adressierungsinformationen (Spalte AI) und Verwendungsregeln (Spalte UR) enthält.
  • Eine Standortservereinheit (LS) kann somit eine Datenstruktur wie in 3 speichern, welche auch UR umfasst. In ähnlicher Weise kann, da manche CSs auch Standortinformationen speichern können (z.B. aufgrund der oben genannten Merkmale von CSs, die den Aufbau von Routing-Tabellen im Offline-Betrieb, Cache von Standortinformationen, Beteiligung an einem Registrierungsprozess usw. betreffen), die Datenstruktur von 3 auch in einer CS gespeichert werden.
  • Im Folgenden werden unter Bezugnahme auf den in 3 dargestellten Beispielfall einige Ausführungsformen angegeben, die mit der möglichen Struktur und Funktion der Verwendungsregel UR zusammenhängen.
  • Es versteht sich, dass entsprechend der Granularität, die gewünscht wird, um zu verhindern, dass für einen gegebenen Dienst ungeeignete Dienstanforderungen zu einer Anwendungsservereinheit gelangen, die entsprechende zu prüfende UR eine oder mehrere Verwendungsbedingungen (T1, T2, T3, M, U) enthalten kann, die jeweils eine bestimmte Anforderung dafür festlegen, dass eine Dienstanforderung zu ihrem Ziel weitergesendet wird. Die in einer gegebenen UR definierten Verwendungsbedingungen (T1, T2, T3, M, U) sollen vorzugsweise die dynamische/zeitweilige Natur des Dienstes, den sie betrifft, erfassen, und damit die dynamische/zeitweilige Natur der entsprechenden Dienst-ID. Dementsprechend können die Verwendungsbedingungen, die eine gegebene UR strukturieren, vorzugsweise Faktoren erfassen wie: die Zeit, wann ein gegebener Dienst erbracht werden kann (oder sollte), die Zeit, wann dieser Dienst nicht erbracht werden kann (oder sollte), die maximale Zeit, welche vergehen kann, seit der Dienst erbracht werden kann, gerechnet ab seiner ersten Erbringung, die maximale Anzahl, wie oft der Dienst erbracht werden kann, der Teilnehmer (oder die Teilnehmer), denen gestattet ist, den Dienst anzufordern, usw.; und Kombinationen davon. Daher wird bei einer bevorzugten Ausführungsform eine UR für einen gegebenen Dienst von einer Anwendungsservereinheit an weitere Servereinheiten verteilt, welche in die Signalisierung einer diesen Dienst betreffenden Dienstanforderung eingreifen können (z.B. an LSs und/oder CSs verteilt). Außerdem kann bei einer bevorzugten Ausführungsform die UR (oder ein Teil ihrer Verwendungsbedingungen) in dem Anwendungs server AS anhand von dynamischen und/oder zeitweiligen Bedingungen, die dem AS bekannt sind (z.B. seiner gegenwärtigen Verkehrslast, der Angemessenheit, einen gegebenen Dienst in einem gegebenen Zeitabschnitt zu erbringen, usw.), sowie von ständigen Bedingungen festgelegt werden.
  • Vorzugsweise soll eine Dienstanforderung nur dann zu ihrem Ziel weitergesendet werden, wenn sämtliche Verwendungsbedingungen, die in der entsprechenden Verwendungsregel UR für in ihr enthaltene Dienst-ID angegeben sind, erfüllt sind. Es sind auch andere Ausführungsformen möglich, bei denen zum Beispiel, wenn die Prüfung einer Verwendungsbedingung einer UR negativ ausfällt, andere, von einer Verweigerung des Dienstes verschiedene Aktionen ausgeführt werden können, wie etwa die Verwendung nur eines bestimmten Adressierungselementes aus einer Vielzahl von Adressierungselementen, welche, wie später näher erläutert wird, in den Adressierungsinformationen für die Dienst-ID gespeichert sein können.
  • Die erste Dienst-ID, die in 3 angegeben ist, kann zu einer Einwahlkonferenz gehören, welche durch die Dienst-ID "confABC@ConfService.op2.com" gekennzeichnet ist. Ihre entsprechende UR legt fest, wie angegeben: eine Bedingung "erste Zeit" (T1), eine Bedingung "anfordernder Teilnehmer" (U) und eine Bedingung "maximale Verwendung" (M), welche verwendet werden können, um zu steuern: einen Anfangszeitpunkt (z.B. "p"), ab dem der Dienst erbracht werden kann, bzw. die Kennung des Teilnehmer oder der Teilnehmer, welche den Dienst anfordern können (z.B. Teilnehmer-IDs wie etwa "bob@op2.com", "joe@op3.com", "alf@op2.com", "kate@op1.com"), bzw. die Anzahl, wie oft eine Dienstanforderung für den Dienst gesendet werden kann (z.B. "n" mal). Somit kann gemäß diesem Beispielfall beginnend ab der Uhrzeit und/oder dem Datum, die bzw. das durch die Anfangszeitpunkt-Bedingung T1 bestimmt ist, jeder beliebige von den Teilnehmern, die unter der Bedingung "anfordernder Teilnehmer" U aufgelistet sind ("bob@op2.com", "joe@op3.com", "alf@op2.com", "kate@op1.com"), eine Dienstanforderung senden, um sich der Einwahlkonferenz anzuschließen.
  • Die Bedingung "maximale Verwendung" M könnte in manchen Fällen redundant sein, in denen, wie bei dem oben angeführten Beispiel mit der Einwahlkonferenz, die maximale Verwendung eines gegebenen Dienstes implizit durch die Anzahl der Teilnehmer begrenzt sein kann, die berechtigt sind, Dienstanforderungen zu senden (z.B. 4 Teilnehmer in dem oben angeführten Beispielfall für die Einwahlkonferenz). Sie kann jedoch für Fälle von Nutzen sein, in denen keine Bedingung "anfordernder Teilnehmer" (U) festgelegt worden ist, oder für Fälle, in denen mit U eine umfangreiche Liste von Teilnehmern festgelegt worden ist, welche sich versuchsweise anschließen können oder einen anderen gelisteten Teilnehmer delegieren können. In jedem Falle kann M verwendet werden, um die Anzahl festzulegen, wie oft eine Dienstanforderung, welche die Dienst-ID des betreffenden Dienstes enthält, zu der entsprechenden Anwendungsservereinheit (AS) weitergesendet werden kann; daher kann M auf vorteilhafte Weise verwendet werden, um eine maximale Verwendung eines gegebenen Dienstes im Voraus festzulegen, z.B. in Abhängigkeit von der bezahlten (oder zu zahlenden) Gebühr für das Zugreifen auf den Dienst, von den Ressourcen in einem AS, die für einen gegebenen Dienst reserviert sind, von der Relevanz und/oder Angebrachtheit, einen Dienst öfter als eine gegebene Anzahl Male zu erbringen, usw.
  • Für eine gegebene Verwendungsregel UR kann die Bedingung "anfordernder Teilnehmer" U eine oder mehrere Teilnehmer-IDs von einem oder mehreren Teilnehmern speichern, wobei diese Teilnehmer-IDs in irgendeinem wohlbekannten Format gespeichert werden (z.B. URI, E.164, h323-ID usw.). Die Kennung des Teilnehmers, welcher eine Dienst anforderung sendet, kann aus der die Anforderung transportierenden Signalisierungsnachricht selbst erhalten werden und kann, zusammen mit der empfangenen Dienst-ID, in eine anschließenden Standortanfrage aufgenommen werden, welche gesendet wird, um die Anforderung weiter zu routen; zum Beispiel kann sie aus dem Nachrichtenkopf "from" in einer gemäß SIP codierten Dienstanforderung erhalten werden, oder aus den Parametern "sourceAddress" oder "Calling Party Number" in einer Dienstanforderung, die gemäß der ITU-T Empfehlung H.225.0 codiert ist. Dementsprechend speichert, da, wie oben erwähnt, in einem Telekommunikationssystem manchen Teilnehmern mehrere Teilnehmer-IDs zugewiesen sein können, vorzugsweise eine Bedingung "anfordernder Teilnehmer" U einer gegebenen Verwendungsregel UR die mehreren Teilnehmer-IDs eines gegebenen Teilnehmers, welcher in dieser Bedingung "anfordernder Teilnehmer" U aufgelistet werden soll.
  • Die Zeitinformation, die in der ersten Zeitbedingung T1 gespeichert ist, kann in Abhängigkeit von der gewünschten Genauigkeit des Anfangszeitpunktes, den sie steuert, variieren. Zum Beispiel kann T1 eine Form mit einem Uhrzeit- und Datumswert (z.B. Tag/Monat/Jahr:Uhrzeit) enthalten, welche eine gegebene Uhrzeit an einem gegebenen Datum bestimmen würde; wobei die Genauigkeit entsprechend der gespeicherten minimalen Zeiteinheit (z.B. Stunde, Minute usw.) festgelegt werden kann. In ähnlicher Weise kann T1 auch nur einen Datumswert (z.B. 23/12/2003) enthalten; womit jeder Zeitpunkt an diesem Datum zulässig ist, um das Anfordern des Dienstes zu starten, auf den T1 sich bezieht. Außerdem kann T1 auch nur einen Zeitwert (z.B. 14:00) enthalten, welcher eine Anfangs-Uhrzeit festlegt, unabhängig vom Tag, von welcher an der Dienst erbracht werden kann. Die in T1 gespeicherten Zeitinformationen können auch mehrere Werte enthalten, die jeweils einen anderen Uhrzeit-/Datumswert angeben und so ermöglichen, unterschiedliche Anfangszeiten für unterschiedliche Tage festzulegen.
  • Die zweite Dienst-ID in 3 ("distlist7@MSGService.op2.com") kann sich auf einen Sofortnachrichtenversendungs-Dienst für die Nachrichtenverteilung beziehen. Die Bedingungen T1 und U haben dieselbe Bedeutung, wie oben für die erste Dienst-ID beschrieben, während für diesen Fall die Verwendungsregel (UR) außerdem eine Bedingung "zweite Zeit" (T2) enthält, welche einen Abbruchzeitpunkt (z.B. "q") steuert, ab dem der Dienst nicht mehr erbracht werden soll. Somit kann er gemäß dem für diesen Dienst dargestellten Beispielfall für die in U aufgelisteten Teilnehmer ("ann@op2.com", "awk@op1.com", "mat@op2.com", "john@op3.com") in der Weise erbracht werden, dass jedem von ihnen ermöglicht wird, eine die obige Dienst-ID enthaltende Dienstanforderung zu senden, welche bewirkt, dass eine "Sofortnachricht" an den Teilnehmer/die Teilnehmer gesendet wird, welche(r) in der entsprechenden Verteilungsliste definiert wurde(n); wobei das Empfangen von Dienstanforderungen von diesen Teilnehmern beginnend frühestens zum Zeitpunkt "p" und endend spätestens zum Zeitpunkt "q" gestattet würde.
  • Es ist anzumerken, dass die zweite Zeitbedingung T2, deren Inhalt und Genauigkeit so eingestellt werden können, wie es weiter oben für die erste Zeitbedingung (T1) beschrieben wurde, unabhängig von der ersten Zeitbedingung arbeiten kann; sie ermöglicht somit, eine Dienstanforderung für einen gegebenen Dienst zu einem gegebenen Abbruchzeitpunkt zu stoppen, unabhängig von irgendeinem vordefinierten Anfangszeitpunkt.
  • Die dritte Dienst-ID in dem in 3 dargestellten Beispielfall ("friendList@PresenceService.op2.com") kann sich auf einen Präsenzdienst beziehen, so dass einem als "Watcher" agierenden Teilnehmer Präsenzinformationen zur Verfügung gestellt werden, die eine Liste von Teilnehmern betreffen. Die Anfangszeitpunkt-Bedingung T1 hat dieselbe Bedeutung, wie es oben für die in 3 als Beispiel angegebene erste oder zweite Dienst-ID beschrieben wurde. In diesem Beispielfall enthält die Bedingung "anfordernder Teilnehmer" U die Teilnehmer-ID nur eines Teilnehmers ("joe@op3.com"), da es aufgrund der Art des Dienstes angebracht sein kann, dass nur der Teilnehmer, der sich für den Präsenzdienst angemeldet hat und den (oder die) Teilnehmer definiert hat, von welchem (welchen) er Präsenzinformationen erhalten möchte, berechtigt ist, die anschließenden Dienstanforderungen zu senden. In diesem Falle umfasst die Verwendungsregel (UR) ferner eine Bedingung "dritte Zeit" (T3), welche den maximalen Zeitabstand für die Annahme von Dienstanforderungen für diesen Dienst, gerechnet ab dem ersten Zeitpunkt, zu dem er angefordert wurde, steuert. Somit kann in diesem Beispielfall der Teilnehmer, der in der Bedingung "anfordernder Teilnehmer" U aufgelistet ist ("joe@op3.com"), Dienstanforderungen, welche die oben erwähnte Dienst-ID ("friendList@PresenceService.op2.com") enthalten, beginnend ab der Uhrzeit/dem Datum senden, die bzw. das durch T1 bestimmt wird ("p"); wobei der Dienst für diese Dienst-ID nach einer gegebenen Zeit, die durch T3 bestimmt wird ("r"), ausgehend von der ersten Dienstanforderung, nicht mehr erbracht wird.
  • Entsprechend verschiedenen Alternativen der Implementierung kann die Genauigkeit des Zeitabstandes, der durch die dritte Zeitbedingung T3 bestimmt wird, entsprechend eingestellt werden. Zum Beispiel kann der Wert von T3 durch einen ganzzahligen Wert dargestellt werden, wobei seine Genauigkeit von der Zeiteinheit abhängen kann (z.B. Tage, Stunden, Minuten usw.), welche diese ganze Zahl darstellt.
  • Für eine gegebene Verwendungsregel UR, welche eine Zeitbedingung T1 und/oder T2 enthält, muss eine Servereinheit, welche diese Bedingung prüft (z.B. eine LS oder eine CS), mit Uhrzeit-Datum-Mitteln ausgestattet sein, die so gestaltet sind, dass sie einen aktualisierten Wert unterhalten, der die aktuelle Uhrzeit und/oder das aktuelle Datum repräsentiert; so kann, wenn die spezifizierten Zeitbedingungen T1 und/oder T2 einer Verwendungsregel UR zu einem gegebenen Zeitpunkt geprüft werden müssen, die aktuelle Zeit, die in diesen Uhrzeit-Datum-Mitteln dargestellt ist, mit jeder beliebigen von den Zeitbedingungen verglichen werden, und es kann somit bestimmt werden, ob die Dienstanforderung, welche diese Prüfung zu diesem Zeitpunkt ausgelöst hat, zu ihrer entsprechenden Ziel-AS weitergesendet werden kann oder nicht. Wie in vielen der wohlbekannten computerbasierten Vorrichtungen (wie etwa Personalcomputern) sind Uhrzeit-Datum-Mittel gewöhnlich in den meisten Servereinheiten eines Telekommunikationssystems für verschiedene Zwecke implementiert, wie etwa für das Versehen von Nachrichten mit Zeitstempeln, das Protokollieren von Ereignissen usw.; wobei diese Uhrzeit-Datum-Mittel sich auf eine interne Uhr innerhalb der Servereinheit und/oder Uhrzeit-Datum-Signale, die von einer weiteren Einheit empfangen werden, stützen können. Daher müssen gemäß der Erfindung nur die Verarbeitungsmittel eines Standortservers LS oder eines Kommunikationsservers CS, in welchem diese Uhrzeit-Datum-Mittel bereits implementiert sind, weiter so gestaltet werden, dass sie die Uhrzeit und/oder das Datum, die auf diesen Uhrzeit-Datum-Mitteln dargestellt werden, mit der Uhrzeit und/oder dem Datum vergleichen, das von einer Zeitbedingung (T1 und/oder T2) einer Verwendungsregel UR angegeben wird.
  • In ähnlicher Weise ist für eine gegebene Verwendungsregel UR, welche eine dritte Zeitbedingung T3 enthält, eine Servereinheit, welche diese Bedingung prüft (z.B. eine LS oder eine CS), gemäß der Erfindung so gestaltet, dass sie die Zeit überwacht, die vergangen ist, seit eine diese dritte Zeitbedingung T3 enthaltende UR in dem Server zum ersten Mal geprüft worden ist (was der ersten Dienstanforderung entsprechen kann, welche die Dienst-ID enthält, auf die sich die UR bezieht), bis eine weitere Prüfung stattfindet. Es können verschiedene Alternativen der Implementierung gewählt werden, um dieses Merkmal zu erzielen. Zum Beispiel wenn die Servereinheit zum ersten Mal irgendeine der Bedingungen einer UR prüft, speichert sie in Verbindung mit der UR einen Zeitstempel, der die aktuelle Zeit dieser Prüfung enthält; wobei der Zeitstempel Tag, Stunde, Minute usw. entsprechend den oben erwähnten Erwägungen betreffs der erwünschten Genauigkeit enthalten kann. Danach kann, wenn eine nachfolgende Überprüfung von Bedingung T3 der UR stattfindet, ein Vergleich zwischen der vergangenen Zeit (d.h. aktuelle Zeit minus Zeit, die in dem Zeitstempel angegeben ist) und der durch T3 angegebenen maximalen Zeit durchgeführt werden.
  • Stattdessen kann auch ein taktgesteuerter Zähler verwendet werden. Wenn die erste Überprüfung einer UR stattfindet, kann dieser Zähler auf einen Wert null oder auf seinen maximalen Wert gestellt werden, und danach kann er inkrementiert bzw. dekrementiert werden, während die Zeit läuft. Dies kann zum Beispiel mit einer zeitbezogenen Verarbeitungsroutine erreicht werden, welche periodisch gestartet wird und welche, neben anderen möglichen Aktionen, den Wert dieses Zählers inkrementiert oder dekrementiert. Dementsprechend wird eine nachfolgende Überprüfung der Bedingung T3 dieser UR bewerkstelligt, entweder indem der aktuelle Zählerwert mit dem in T3 gespeicherten Wert verglichen wird (falls der Zähler zu Beginn auf null gestellt wurde), oder indem geprüft wird, ob der Zählerwert nicht null ist (falls der Zähler zu Beginn auf den maximalen Wert gestellt wurde). Die Option, bei welcher der Zähler periodisch entsprechend der vergangenen Zeit dekrementiert wird, ermöglicht es, den Zähler innerhalb desselben Speicherbereiches zu implementieren, in welchem der Wert T2 einer UR gespeichert ist; somit würde zu einem gegebenen Zeitpunkt der Wert, der im Feld T3 einer UR gespeichert ist, die "Restzeit" angeben, welche verblieben ist, um eine Dienstanforderung zu akzeptieren, welche die Dienst-ID enthält, auf die sich die UR bezieht.
  • Um die Bedingung "maximale Verwendung" (M) einer Verwendungsregel UR zu steuern, kann eine ähnliche Technik wie die oben angegebene Alternative für T3 implementiert werden, indem ein Zähler implementiert wird, welcher auf null gestellt und mit jeder Prüfung inkrementiert werden kann, bis er seinen maximalen Wert erreicht, oder mit jeder Prüfung dekrementiert werden kann, bis er, ausgehend von seinem maximalen Wert, null erreicht. Außerdem kann, wie oben im Zusammenhang mit der Option eines dekrementierenden Zählers von T3 erläutert wurde, der Wert von M mit jeder Prüfung direkt dekrementiert werden, so dass die Notwendigkeit eines zusätzlichen Zählers für M entfällt. Dementsprechend kann, wenn der Wert von M einer UR geprüft werden soll, zuerst überprüft werden, ob dieser Wert von null verschieden ist. Falls er nicht null ist, muss M dekrementiert werden. Vorteilhafterweise wird die Bedingung M einer UR als letzte geprüft, falls andere Bedingungen (T1, T2, T3, U) für diese UR existieren; so wird es nur dekrementiert (oder inkrementiert), falls alle in der UR angegebenen Bedingungen erfüllt sind.
  • Wie weiter oben erläutert, umfassen die Standortinformationen, die in einem Standortserver LS oder in einem Kommunikationsserver CS gespeichert sind, eine Kennung und die entsprechenden Adressierungsinformationen AI für das Routing einer Dienstanforderung, welche diese Kennung enthält. Die Art eines Elementes, das als AI gespeichert ist, kann entsprechend verschiedenen Implementierungen der Adressierung und Optionen der Adressierung in einem Telekommunikationssystem variieren. Das in 3 dargestellte Beispiel berücksichtigt einige von ihnen, welche mit "AA" (eine Adresse eines Anwendungsservers AS), "AC" (eine Adresse eines Kommunikationsservers CS) und "AD" (eine Adressenbestimmungs-Fähigkeit, welche benutzt werden kann, um eine damit übereinstimmende CS zu finden, und welche ferner eine Dienstanforderung mit dieser Kennung zu ihrem Endziel routen kann) bezeichnet wurden. Es versteht sich jedoch, dass die in der Figur verwendete Bezeichnung (AA, AC, AD) nicht notwendigerweise zur Folge hat, dass die Art der gespeicherten Adressierungsinformationen zusammen mit den Adressierungsinformationen, auf die sie sich bezieht, codiert werden muss, so dass sie deren Typ spezifiziert (z.B. ob es eine Adresse einer AS oder eine Adresse einer CS oder eine Adressenbestimmungs-Fähigkeit ist).
  • In 3 umfassen für den Einwahlkonferenz-Dienst, der durch die Dienstkennung "confABC@ConfService.op2.com" gekennzeichnet ist, die Adressierungsinformationen (AA) eine URI der AS, welche berechtigt ist, ihn zu erbringen, "ConfServer27.op2.com". So kann zum Beispiel der Netzbetreiber "OP2" mehrere ASs haben, wobei einem von ihnen (z.B. mit dem Alias-Namen "ConfServer27") die Aufgabe zugewiesen wurde, den durch diese Dienst-ID gekennzeichneten Dienst zu erbringen.
  • Die Adressierungsinformationen, die in 3 für den mit der Dienst-ID "distlist7@MSGService.op2.com" gekennzeichneten Sofortnachrichtenversendungs-Dienst angegeben sind, enthalten zwei Elemente. Das erste (AA) enthält eine IP-Adresse der AS, die für diesen Dienst bestimmt ist, "231.64.82.162", und das zweite (AC) ist eine URI einer Kommunikationsservereinheit CS, welche die CS sein kann, die den Zugriff auf diese AS bedient, oder eine CS sein kann, welche die erforderlichen Fähigkeiten aufweist, um in die Signalisierung zu/von der AS einzugreifen. Die zwei Adressierungselemente (AA, AC), die in diesem Beispielfall angegeben sind, sollen lediglich veranschaulichen, dass in Abhängigkeit von verschiedenen Alternativen der Adressierung die für eine Dienst-ID gespeicherten Adressierungsinformationen hinsichtlich ihrer Art variieren können und es sich sogar um mehrere Informationen handeln kann, so dass sie ermöglichen, eine von ihnen auszuwählen und sie für das Routing der Dienstanforderung zu verwenden, in Abhängigkeit von Adressierungspolitiken, welche zum Beispiel festlegen können, ob eine Dienstanforderung unter Verwendung einer Adresse der betreffenden AS direkt geroutet werden kann, oder ob sie zuerst über eine gegebene CS geroutet werden muss, usw. Diese Adressierungspolitiken können wiederum von solchen Faktoren abhängig sein, wie der Uhrzeit oder dem Datum, der Ursprungsdomäne der Anforderung, usw., und auch (wie weiter oben erwähnt) davon abhängig sein, ob eine gegebene Verwendungsbedingung (T1, T2, T3, M, U) der entsprechenden Verwendungsregel UR von der Dienstanforderung nicht erfüllt worden ist.
  • Ein weiteres Beispiel mehrerer Adressierungselemente für dieselbe Dienst-ID ist in 3 für den Präsenzdienst angegeben, der durch die Dienst-ID "FriendList@PresenceService.op2.com" gekennzeichnet ist. In diesem Falle umfassen die entsprechenden Adressierungsinformationen AI zwei Adressierungselemente (AA, AD), wobei das erste (AA) eine URI der AS enthält, die dazu bestimmt ist, eine diese Dienst-ID enthaltende Anforderung zu bedienen, "PresenceServer9.op.com", und das zweite (AD) den Wert einer Adressenbestimmungs-Fähigkeit enthält, um eine Kommunikationsservereinheit CS zu wählen, welche in die Signalisierung zu/von dieser AS eingreifen kann, welcher als eine Hexadezimaldarstellung eines 32-Bit-Wertes "H'9A17FBC6" gemäß der Unsigned32 Codierung angegeben ist, die in dem oben erwähnten IETF-ENTWURF "Diameter Multimedia Application" (draftbelinchon-aaa-diameter-mm-app-00.txt) dargelegt ist. Es versteht sich, dass, wenn eine Adressenbestimmungs-Fähigkeit verwendet wird, um eine CS zu wählen, eine weitere Verarbeitung erforderlich ist, um eine Adresse einer CS aus einem speziellen Unsigned32 Wert zu bestimmen (z.B. eine Nachschlagtabelle, die CSs vorzeichenlosen 32-Bit-Werten zuordnet). Diese weitere Verarbeitung liegt jedoch außerhalb des Rahmens der vorliegenden Erfindung.
  • Im Folgenden werden einige Ausführungsformen der Erfindung, die verschiedene Fälle des Routings einer Dienstanforderung sowie die Verteilung und Anwendbarkeit einer Verwendungsregel UR gemäß der Erfindung zeigen, unter Bezugnahme auf die Signalflüsse der 4 bis 6 beschrieben. In allen diese Figuren war eine Anwendungsservereinheit (AS) berechtigt, Dienstanforderungen zu verarbeiten, die einen mit einer gegebenen Dienst-ID gekennzeichneten Dienst betreffen.
  • Beim Routing einer Dienstanforderung vom Ursprungs-Endpunkt zur Ziel-Anwendungsservereinheit AS können mehr Servereinheiten eingreifen (d.h. bei der Signalisierung und/oder der Bereitstellung von Adressierungsinformationen vermitteln), als diejenigen, die in den in 4 bis 6 dargestellten Fällen des Routings abgebildet sind (CS, CS1, CS2, LS). Zum Beispiel kann die Dienstanforderung, welche als erste empfangene in einem Kommunikationsserver (CS, CS1) erscheint (Fluss f2 in 4, g3 in 5, h2 in 6), von einem anderen Kommunikationsserver (nicht dargestellt) kommen. In ähnlicher Weise kann die Dienstanforderung, welche am Ende erscheint, um von einem Kommunikationsserver (CS, CS2) direkt zu dem AS gesendet zu werden, über einen weiteren Kommunikationsserver (nicht dargestellt) geroutet werden. Um einer größeren Klarheit willen wurden jedoch in jedem Falle nur diejenigen Servereinheiten dargestellt, welche von Bedeutung sind, um einen Aspekt der Erfindung zu veranschaulichen.
  • In Fluss f1 von 4 sendet die AS Standortinformationen, welche eine oder mehrere Dienst-IDs und die entsprechenden Adressierungsinformationen für das Routing von Dienstanforderungen, welche diese Dienst-ID(s) enthalten, an eine Standortservereinheit (LS). Wie weiter oben erläutert, können die Adressierungsinformationen zum Beispiel eine Adresse einer AS und/oder eine Adresse einer Kommunikationsservereinheit (CS), welche in die Signalisierung zu dieser AS eingreifen kann, oder eine Adressenbestimmungs-Fähigkeit, um eine Adresse dieser CS zu bestimmen, enthalten.
  • Die Informationen, die in Fluss f1 gesendet werden, können ferner eine Verwendungsregel UR umfassen, um die Verwendung der empfangenen Adressierungsinformationen zu gestatten. Zum Beispiel können sie eine UR für jede der angegebenen Dienst-IDs enthalten, oder eine UR für mehr als eine der (oder alle) angegebenen Dienst-IDs. Gemäß verschiedenen Alternativen der Implementierung kann die UR von der AS zu der LS innerhalb derselben Nachricht gesendet werden wie die Adressierungsinformationen, oder in einer separaten Nachricht, welche zum Beispiel die Dienst-ID enthalten kann, um die UR mit der Dienst-ID, auf die sie sich bezieht, zu korrelieren. Diese letzte Option ermöglicht es, die UR eines gegebenen Dienstes zu modifizieren, ohne irgendwelche anderen mit ihr zusammenhängenden Daten (z.B. Dienst-ID oder Adressierungsinformationen) zu ändern.
  • Der Fluss f1a zeigt eine optionale Ausführungsform, wobei die AS eine Verwendungsregel UR in Verbindung mit der Dienst-ID, auf die diese UR sich bezieht, zu einer Kommunikationsservereinheit (CS) sendet. Da, wie weiter oben erwähnt, manche CS Adressierungsinformationen speichern können, um eine Dienstanforderung auf der Basis ihrer eigenen gespeicherten Adressierungsinformationen für eine in dieser Anforderung enthaltene Dienst-ID zu routen (und somit eine weitere Anfrage bei einer LS zu vermeiden), können die in Fluss f1a gesendeten Informationen auch die entsprechenden Adressierungsinformationen für die empfan gene(n) Dienst-ID(s) umfassen; wobei, wie oben für die LS erwähnt, die Standortinformationen für einen gegebenen Dienst (Dienst-ID, Adressierungsinformationen) in der CS zusammen mit der entsprechenden UR oder separat empfangen werden können.
  • Der Inhalt einer Verwendungsregel UR für eine gegebene Dienst-ID kann entsprechend verschiedenen Alternativen bestimmt werden. Zum Beispiel kann er automatisch innerhalb einer Servereinheit (AS, LS, CS) bestimmt werden (z.B. nach Tabellen, welche Dienst-IDs oder einen Teil von ihnen mit den entsprechenden UR-Werten verknüpfen). Außerdem kann, zusätzlich zu dem Empfang einer UR von einer Anwendungsservereinheit, wie oben erläutert, eine UR durch andere Mittel in einer LS und/oder in einer CS definiert werden, wie etwa mit Hilfe von OAM (Operation, Administration, Maintenance; Betrieb, Administration, Wartung) Prozeduren; wobei dies für Fälle von Nutzen ist, in denen dieselbe UR für mehrere Dienst-IDs gelten kann.
  • Gemäß den in 4 bis 6 dargestellten Signalisierungsflüssen scheinen die AS, welche in die Übertragung der UR zu einer LS (oder zu einer CS) eingreifen, dieselben zu sein wie die AS, welche schließlich die Dienstanforderungen empfangen (Flüsse f5, g4, h6). Jedoch sind auch andere Ausführungsformen möglich, bei denen eine andere Servereinheit (wie etwa eine AS, die speziell für die Verteilung von URS berechtigt ist), welche nicht die AS ist, die berechtigt ist, die entsprechende Dienstanforderung zu empfangen, in die Übertragung einer UR eingreift (Flüsse f1, f1a, g1, g1a, h1, h1a).
  • Der Fluss f2 stellt den Empfang einer eine Dienst-ID enthaltenden Dienstanforderung in der CS dar. Wenn angenommen wird, dass die CS nicht zuvor Adressierungsinformationen für diese Dienst-ID gespeichert hat, sendet sie eine Standortanfrage (Fluss f3) an die LS, welche die empfangene Dienst-LD enthält. Stattdessen kann der Fluss f3 auch ein Weiterleiten der in der CS empfangenen Dienstanforderung zu der LS darstellen; dies könnte der Fall sein, wenn zum Beispiel ein unbedingtes Routing innerhalb der CS programmiert ist (z.B. für alle empfangenen Anforderungen oder entsprechend einer Kennung, die in einer Anforderung empfangen wird) und wenn die LS sich wie ein Umleitungsserver (Redirect-Server) verhält. In jedem Falle prüft die US dann die Verwendungsregel UR, welche sich auf die empfangene Dienst-ID bezieht, und überprüft, ob alle Verwendungsbedingungen, die in dieser Regel festgelegt sind, erfüllt sind.
  • Im Falle einer erfolgreichen Prüfung der UR antwortet die LS in Fluss f4 zurück an die CS (entweder Abfrageantwort, oder eine Umleitungsangabe) mit den entsprechenden Adressierungsinformationen, welche, wie weiter oben erläutert, eine Adresse der AS sein können, welche diese Dienstanforderung empfangen soll. Danach sendet die CS unter Verwendung dieser Adressierungsinformationen in Fluss 5 die empfangenen Anforderungen zu der AS weiter.
  • Falls die Prüfung der UR fehlschlägt, kann das negative Ergebnis in Fluss f4 von der LS zu der CS gesendet werden; dies kann zum Beispiel bewerkstelligt werden, indem in f4 ein leerer Wert in den Adressierungsinformationen (oder ein vordefinierter "Standardwert") gesendet wird, und/oder indem explizit ein negatives Ergebnis angegeben wird. Der Empfang eines negativen Ergebnisses würde bewirken, dass die empfangene Dienstanforderung von der CS in Fluss f6 entsprechend dem verwendeten Signalisierungsprotokoll zurückgewiesen wird (z.B. eine Request Failure (Anforderung Fehlschlag) Antwort "4XX", wie in IETF-RFC3261 definiert, falls das SIP-Protokoll verwendet wird und eine INVITE Nachricht empfangen wurde, eine RELEASE COMPLETE Nachricht, falls das H.225.0 Protokoll verwendet wird und eine SETUP Nachricht empfangen wurde, usw.). Stattdessen können auch, wie weiter oben erwähnt, im Falle eines Fehlschlags bei der Prüfung der UR (oder irgendeiner ihrer Verwendungsbedingungen) andere Aktionen (nicht dargestellt), die von der Zurückweisung des Dienstes verschieden sind, ausgeführt werden, wie etwa, die empfangene Dienstanforderung über eine gegebene Servereinheit zu routen (z.B. eine weitere CS oder eine weitere AS). Dies kann bewerkstelligt werden, indem in Fluss f4 ein Adresselement (AA, AC, AD) zurückgegeben wird, das für diesen Zweck vorgesehen ist.
  • 5 zeigte eine alternative Ausführungsform, wobei die Verwendungsregel UR in einem Kommunikationsserver CS geprüft wird, welcher eine Dienstanforderung empfängt. In 5 sind die Flüsse g1 und g1a äquivalent zu den Flüssen f1 bzw. f1a, die zuvor unter Bezugnahme auf die in 4 dargestellte Ausführungsform beschrieben wurden, mit der Besonderheit, dass als Option bei dieser Ausführungsform die CS die UR in Verbindung mit der Dienst-ID, auf die sie sich bezieht, und auch in Verbindung mit den entsprechenden Adressierungsinformationen von einer LS empfangen kann, wie durch Fluss g2 dargestellt, welcher sich von Fluss g1 fortsetzt. Dementsprechend kann bei Empfang einer Dienstanforderung in der CS (Fluss g3) die entsprechende UR intern in dieser CS erhalten werden und in dieser CS geprüft werden, und danach entweder: die Anforderung zu der AS weitersenden (Fluss g4), falls die Prüfung erfolgreich war, oder andernfalls die Dienstanforderung zurückweisen (Fluss g5).
  • Die in 6 dargestellte Ausführungsform zeigt schematisch das Routing einer Dienstanforderung in einem Szenarium, welches wenigstens zwei Kommunikationsservereinheiten (CS1, CS2) enthält; obwohl, wie weiter oben erwähnt, noch weitere CSs (nicht dargestellt) vorhanden sein könnten, die bei der Signalisierung der Dienstanforderung vermitteln. 6 kann außerdem dazu dienen, teilweise das Routing einer Dienstanforderung in einem Szenarium zu veranschaulichen, welches verschiedene Kommunikationsservereinheiten (CS1, CS2) enthält, die bei diesem Routing jeweils unterschiedliche Aufgaben haben. Ein Beispiel eines Routing-Szenariums, das verschiedene CSs mit jeweils unterschiedlichen Aufgaben umfasst, ist für das IP Multimedia Subsystem IMS eines Mobilfunksystems der 3. Generation in der oben erwähnten 3GPP Spezifikation TS 23.228 beschrieben, welche verschiedene Aufgaben für die CSCFs (Call State Control Functions, Verbindungszustand-Steuerfunktionen) definiert. So kann 6 zum Beispiel einen Teil des Routings einer Dienstanforderung in dem IMS darstellen, das für die Veranschaulichung der Erfindung relevant ist; wobei der Kommunikationsserver CS1 eine CSCF repräsentieren kann, die als eine "Interrogating-CSCF" (I-CSCF, abfragende CSCF) agiert, und der Kommunikationsserver CS2 eine CSCF repräsentieren kann, die als eine "Serving-CSCF" (S-CSCF, bedienende CSCF) agiert, während der in der Figur abgebildete Standortserver einen "Home Subscriber Server" (HSS, Heimat-Teilnehmerserver) darstellen kann.
  • Die Flüsse h1 und h1a sind den weiter oben erläuterten Flüssen f1 und f1a (oder g1 und g1a) ähnlich. In dem speziellen Fall des Multimedia Subsystems IMS kann die Übertragung von Informationen von der AS zu der LS (Fluss h1) oder zu der CS2 (Fluss h1a), welche die Übertragung einer Verwendungsregel UR umfasst, entsprechend der Signalisierung stattfinden, die in der 3GPP Spezifikation TS 29.328 (V5.2.1, Januar 2003) für die so genannte "Sh Schnittstelle" (Schnittstelle, die zwischen einem HSS und einer AS definiert ist) definiert ist, welche dahingehend erweitert werden kann, dass sie auch Kommunikationen zwischen einer AS und einer CSCF gemäß der Erfindung berücksichtigt; während der Fluss h2a (welcher, als zum Fluss g2 äquivalent, als eine Implementierungsoption eine Fortsetzung des Flusses h1 ist) entsprechend der Signalisierung stattfinden kann, die in der oben erwähnten 3GPP Spezifikation 29.228 für die so genannte "Cx Schnittstelle" (zwischen einem HSS und einer S-CSCF definiert) definiert ist. Insbesondere definieren die oben erwähnten 3GPP Spezifikationen TS 29.328 und TS 29.228 ein Datenmodell (in diesen Spezifikationen als "Sh-Daten" bzw. "IMS Subscription" bezeichnet), welches Profildaten enthält, die mit einem Teilnehmer verknüpft sind und die zu der S-CSCF übertragen werden können, die dazu vorgesehen ist, diesen Teilnehmer über die Cx Schnittstelle zu bedienen. Vorteilhafterweise können Profildaten auch (unabhängig von den Teilnehmer-Profildaten irgendeines Teilnehmers) mit einem gegebenen Dienst verknüpft sein (z.B. mit einer Dienst-ID dieses Dienstes verknüpft sein), oder sogar mit den Profildaten, die mit einer Anwendungsservereinheit AS verknüpft sind (z.B. für einige oder alle Dienst-IDs der Dienste, die er hostet), und können auch (z.B. über eine Sh Schnittstelle) zu einem HSS übertragen werden, der Standortinformationen für einen gegebenen Dienst speichert, der in einer AS gehostet wird, und/oder (z.B. über eine Sh Schnittstelle oder Cx Schnittstelle) zu einer S-CSCF, die dazu vorgesehen ist, Signalisierung zu/von dieser AS zu bedienen.
  • Dementsprechend kann in dem speziellen Fall des IP Multimedia Subsystems IMS eine Verwendungsregel UR zum Beispiel in einem HSS (LS) und/oder in einer S-CSCF (CS2) gespeichert werden, entweder als Teil von Profildaten, die einen gegebenen Teilnehmer betreffen, oder als Teil von Profildaten, die einen gegebenen Dienst (oder eine gegebene AS) betreffen, oder beides, welcher zusammen mit den relevanten Profildaten gemäß dem Datenmodell, das in den oben erwähnten 3GPP Spezifikationen TS 29.328 und TS 29.228 beschrieben wird, eine Verwendungsregel UR gemäß der Erfindung umfassen würde. Im ersten Fall (d.h. UR als ein Teil der Profildaten, die einen gegebenen Teilnehmer betreffen) kann die UR in der S-CSCF geprüft werden, die dazu vorgesehen ist, die Signalisierung zu diesem Teilnehmer zu bedienen, wenn sie eine Dienstanforderung von ihm erhält (d.h. wie bei der in 5 beschriebenen Ausführungsform in einer CS geprüft werden, welche für den vorliegenden Fall die S-CSCF darstellen könnte, die diesem Teilnehmer bei seiner Registrierung in dem IMS zugewiesen wird). Im zweiten Fall (d.h. UR als ein Teil der Profildaten, die einen gegebenen Dienst betreffen) kann die UR geprüft werden, wenn die S-CSCF, die dazu vorgesehen ist, die Signalisierung zu dieser AS zu bedienen, eine Dienstanforderung für einen Dienst empfängt (oder im Begriff ist zu empfangen), welcher in dieser AS gehostet wird; wobei diese Prüfung entweder in dieser S-CSCF stattfinden kann, oder in dem HSS, wenn er eine Standortanfrage mit der betreffenden Dienst-ID empfängt.
  • Ob die Verwendungsregel UR einer gegebenen Dienst-ID mit den Profildaten eines gegebenen Teilnehmers verknüpft ist, und/oder mit den Profildaten, die zu einer gegebenen Dienst-ID gehören, ist eine Implementierungsoption, welche entsprechend der Art des Dienstes gewählt werden kann, auf den sich die Dienst-ID bezieht. Zum Beispiel kann es für eine Dienst-ID, welche einen Dienst kennzeichnet, der dazu bestimmt ist, nur von einem gegebenen Teilnehmer verwendet zu werden (wie etwa die Dienst-ID, welche einen Präsenzdienst für einen gegebenen, als Watcher agierenden Teilnehmer kennzeichnet), angebracht sein, eine UR mit den Teilnehmerprofildaten dieses Teilnehmers zu verknüpfen; falls sich dagegen die Dienst-ID z.B. auf eine Public Messaging Liste (Liste der öffentlichen Nachrichtenübermittlung) bezieht, kann es vorteilhaft sein, die entsprechenden Profildaten unabhängig für diese Dienst-ID zu definieren. Diese Alternativen schließen jedoch nicht aus, dass für eine gegebene Dienst-ID verschiedene Verwendungsregeln definiert sind, welche mit den Profildaten mehrerer Teilnehmer verknüpft sind, sowie mit Profildaten, die unabhängig für diese Dienst-ID definiert sind.
  • Falls die UR von der AS zu der LS übertragen wird (Fluss h1), kann die LS, als eine Implementierungsoption, sie ferner zu der Kommunikationsservereinheit CS2 übertragen, wie durch einen alternativen Fluss h2a dargestellt ist. Dadurch kann, wie weiter oben unter Bezugnahme auf die in 5 dargestellte Ausführungsform erläutert wurde, eine weitere Signalisierung zwischen CS2 und LS vermieden werden, indem eine frühzeitige Prüfung der UR in CS2 durchgeführt wird.
  • Wie bei den äquivalenten Flüssen von 4 und 5 stellt der Fluss h2 das Eintreffen einer Dienstanforderung bei einer Kommunikationsservereinheit (CS1) dar. Wenn die Dienstanforderung bei CS1 eintrifft, sendet CS1 (Fluss h3) an die LS eine Standortanfrage, welche die empfangene Dienst-ID umfasst. Wie im Falle von Fluss f3 in 4 kann der Fluss h3 (ebenso wie der weitere Fluss h5a) auch das Weitersenden der empfangenen Dienstanforderung an eine LS darstellen, die als ein Umleitungsserver (Redirect-Server) agiert. An dieser Stelle kann die LS die UR prüfen, welche der Dienst-ID entspricht, und entsprechend dieser Prüfung in Fluss h4 die entsprechenden Adressierungsinformationen zurücksenden, oder (wie weiter oben unter Bezugnahme auf 4 beschrieben wurde) ein negatives Ergebnis, welches bewirken würde, dass CS1 mit einer Zurückweisung des Dienstes zurück antwortet (Fluss h8). Im Falle einer erfolgreichen Prüfung der UR kann die LS eine Adresse einer weiteren Kommunikationsservereinheit (CS2) zurücksenden und sie verwenden, um die empfangene Dienstanforderung zu routen (Fluss h5).
  • In dem Spezialfall des IMS kann der Fluss h2 das Eintreffen einer Dienstanforderung bei einer I-CSCF (CS1) des Netzbetreibers darstellen, welche den Zugriff auf die Anwendungsservereinheit AS regelt, und die Flüsse h3/h4 würden die anschließenden "Cx-Location-Query"/"Cx-Location-Query Resp" (Cx-Standortanfrage/Cx-Standortanfrage-Antwort) zur Beschaffung von Adressierungsinformationen darstellen, die für das Routing der empfangenen Anforderung verwendbar sind. Somit kann, falls die Prüfung der entsprechenden UR erfolgreich ist, der HSS (LS) eine Adresse einer S-CSCF (CS2) zurücksenden, welche diejenige sein kann, die dazu vorgesehen ist, die Signalisierung zu/von der entsprechenden Anwendungsservereinheit (AS) zu bedienen.
  • Verschiedene alternative Aktionen können stattfinden, wenn die Dienstanforderung bei CS2 eintrifft (Fluss h5), die neben anderen Faktoren davon abhängen, ob der Kommunikationsserver CS2 eine Verwendungsregel UR gespeichert hat, welche der Dienst-ID entspricht, die in der Dienstanforderung enthalten ist, die er in Fluss h5 empfängt (z.B. ob die Flüsse h1a oder h2a stattgefunden haben). Falls zum Beispiel CS2 die entsprechende UR hat, kann CS2 so agieren, wie weiter oben unter Bezugnahme auf 5 beschrieben wurde, und entweder die Dienstanforderung zurückweisen (Fluss h7, welcher sich mit Fluss h8 fortsetzen würde), falls die Prüfung nicht erfolgreich war, oder sie weiter zu der AS routen (Fluss h6), falls die Prüfung erfolgreich war. Andernfalls, wenn CS2 über keine UR verfügt, die sich auf die empfangene Dienst-ID bezieht, kann CS2 zum Beispiel die Dienstanforderung weiter zu ihrem Ziel routen (z.B. die UR kann früher geprüft worden sein), unter Verwendung von Adressierungsinformationen, die CS2 für die empfangene Dienst-ID gespeichert haben kann (z.B. aus dem Fluss h2a), oder eine Standortanfrage an eine LS senden (Fluss h5a), um Adressierungsinformationen zu erhalten. In diesem letzteren Falle kann die entsprechende UR, wenn sie auf der Standortservereinheit LS gespeichert ist, die die Anfrage erhält (welche, obwohl sie als mit der LS identisch dargestellt ist, welche die Standortanfrage h3 empfängt, auch eine andere LS sein kann), dort geprüft werden, bevor in Reaktion auf diese Standortanfrage die Adressierungsinformationen zurückgesendet werden (Fluss h5b).
  • In dem speziellen Fall eines INS können die Flüsse h5a und h5b Anforderungs- bzw. Antwortoperationen einer Serverzuweisung darstellen, mittels welcher eine S-CSCF, welche eine Dienstanforderung (CS2) empfängt, die eine Dienst-ID enthält, für welche sie noch nicht ihre entsprechenden Adressierungsinformationen gespeichert hat, Adressierungsinformationen von dem HSS anfordert und erhält und feststellt, dass sie (CS2) dazu vorgesehen wird, Signalisierung zu der Einheit zu bedienen, die durch diese Adressierungsinformationen adressiert wird. In dem INS können diese Anforderungs- und Antwortoperationen einer Serverzuweisung, welche Dienste betreffen, durch Operationen bewerkstelligt werden, welche den Operationen "Cx-Put/Resp" und "Cx-Pull/Resp" ähnlich sind, die in der 3GPP Spezifikation 29.228 beschrieben sind, welche die betreffende Dienst-ID (in der Anforderung, h5a) und die zugehörigen Adressierungsinformationen, die für das Routing zu der AS verwendbar sind, die berechtigt ist, den durch diese Dienst-ID gekennzeichneten Dienst zu erbringen (in der Antwort, h5b), beinhalten würden; wobei die Verwendungsregel UR entweder in dem HSS geprüft werden kann, bevor die Adressierungsinformationen für die AS zu CS2 zurückgesendet werden, oder zusammen mit den Adressierungsinformationen gesendet werden kann (z.B. wenn entsprechend der gewählten Implementierung nicht zuvor in CS2 in den Flüssen h1a oder h2a empfangen wird). Daher versteht es sich, dass die Flüsse h2a oder h1a sowie die Flüsse h5a und h5b zwei verschiedene, alternative Implementierungsoptionen darstellen können, um eine S-CSCF (CS2) festzulegen, welche die Signalisierung zu der betreffenden AS für eine Dienst-ID bedienen soll, und um diese S-CSCF mit den entsprechenden Adressierungsinformationen und/oder der Verwendungsregel UR zu versorgen; wobei bei der ersten alternativen Option (Flüsse h2a oder h1a) die UR in der S-CSCF geprüft werden kann, während die zweite alternative Option (Flüsse h5a–h5b) beides ermöglicht: die UR in die S-CSCF herunterzuladen (h5b), damit sie dort weiter geprüft werden kann, oder die UR in dem HSS zu prüfen (bei Empfang von Fluss h5a), bevor die entsprechenden Adressierungsinformationen zur Verfügung gestellt werden (Fluss 5b).
  • Bevor sie den durch Fluss h2 dargestellten Punkt des Routing erreicht, kann die Dienstanforderung zuvor (eine) weitere Kommunikationsservereinheit(en) CS(s) (in 6 nicht dargestellt) durchlaufen haben, so dass die Dienstanforderung mittels der entsprechenden UR geprüft worden sein kann, bevor sie weiter geroutet wurde (entweder in einer früheren CS oder in einer früheren LS – in 6 nicht dargestellt –, welche Adressierungsinformationen zur Verfügung gestellt haben kann, um zu CS1 zu gelangen). Wenn zum Beispiel der anfordernde Teilnehmer an das IMS angeschlossen ist, hat die Dienstanforderung zuvor die S-CSCF durchlaufen, welche ihm während seiner Registrierung in dem IMS zugewiesen wurde, bevor sie zu der S-CSCF gelangt, die der betreffenden AS zugewiesen ist. Somit erhält man ein vollständigeres Bild eines möglichen Routing-Flusses sowie der möglichen Ausführungsformen betreffs der Verteilung und Anwendbarkeit der UR, wenn man mit den Signalisierungsflüssen beginnt, die in den Ausführungsformen von 4 oder 5 dargestellt sind, und mit dem Signalisierungsfluss fortfährt, der in der Ausführungsform von 6 dargestellt ist; wobei der letzte Fluss, der in 4 dargestellt ist (d.h. Fluss f5, bevor die AS erreicht wird), oder der letzte Fluss, der in 5 dargestellt ist (d.h. Fluss g4, bevor die AS erreicht wird), dem Fluss h2 in 6 entsprechen sollte. Demzufolge kann eine Dienstanforderung, bevor sie zu der entsprechenden AS gelangt, einmal oder mehrmals in Bezug auf die entsprechende UR geprüft worden sein, während die Anforderung verschiedene CSs passiert (z.B. wenn sie eine CS erreicht, die dazu vorgesehen ist, den anfordernden Teilnehmer zu bedienen, eine Transit-CS, eine CS, die dazu vorgesehen ist, die AS zu bedienen, usw.), wodurch ermöglicht wird, in verschiede nen Phasen des Routings unerwünschten Signalisierungsverkehr zu der AS zu stoppen.
  • Es ist anzumerken, dass für jede beliebige der Ausführungsformen, die unter Bezugnahme auf 4 bis 6 beschrieben wurden, ein Kommunikationsserver (CS, CS1, CS2) eine Verwendungsregel in Verbindung mit einer Dienst-ID unabhängig davon speichern kann, ob er auch die entsprechenden Adressierungsinformationen für diese Dienst-ID speichert oder nicht; somit kann eine weitere unnötige Signalisierung zum Anfordern von Adressierungsinformationen (falls benötigt) bei einer LS vermieden werden, wenn beim Empfang einer Dienstanforderung zuerst die UR geprüft wird.
  • Moderne Servereinheiten in einem Telekommunikationssystem sind gewöhnlich in computerbasierten Maschinen implementiert. Dementsprechend werden Computerprogramme mir computerlesbaren Programmcodes gewöhnlich auf eine Servereinheit (z.B. eine CS, eine LS, eine AS) eines Telekommunikationssystems geladen, was bewirkt, dass sich die Servereinheit in einer vordefinierten Art und Weise verhält, welche mit ihrer spezifischen Funktionalität im Einklang steht. Fachleute auf dem Gebiet des Erstellens und/oder Modifizierens von Computerprogrammen, die dazu bestimmt sind, auf computerbasierte Servereinheiten geladen zu werden, können somit, ohne von den Lehren der vorliegenden Erfindung abzuweichen, diese Lehren anwenden, um Computerprogramme zu erstellen und/oder zu modifizieren, welche, wenn sie auf einem computerbasierten Kommunikationsserver (CS), Standortserver (LS) oder Anwendungsserver (AS) ausgeführt werden, bewirken, dass diese sich entsprechend irgendeiner der beschriebenen Ausführungsformen verhalten.
  • Die Erfindung wurde unter Bezugnahme auf einige beispielhafte Ausführungsformen auf eine veranschaulichende und nicht einschränkende Art und Weise beschrieben. Mögliche Abwandlungen sind für einen Durchschnittsfachmann leicht ersichtlich. Aus diesem Grunde ist die Erfindung im Hinblick auf die Ansprüche zu interpretieren und zu begrenzen.

Claims (29)

  1. Verfahren für das Routing einer Dienstanforderung in einem Telekommunikationssystem, die einen Dienst betrifft, welches die folgenden Schritte umfasst: – Empfangen (f2, g3, h2, h5) einer Dienstanforderung, die eine Dienstkennung (SID) enthält, welche den Dienst kennzeichnet, in einer Kommunikationsservereinheit (CS, CS1, CS2); – Beschaffen (f3–f4, h3–h4, h5a–h5b, g2) von Adressierungsinformationen (AI), welche sich auf die Dienstkennung beziehen, und – Routing (f5, g4, h5, h6) der Dienstanforderung unter Verwendung der Adressierungsinformationen; – Prüfen einer Verwendungsregel (UR), welche die Verwendung der Adressierungsinformationen gestattet, wobei die Verwendungsregel wenigstens eine Verwendungsbedingung umfasst, die gewählt ist aus: – einer Zeitbedingung (T3), die den maximalen Zeitabstand für die Verwendung der Adressierungsinformationen festlegt, gerechnet ab dem ersten Zeitpunkt, zu dem sie verwendet werden, – einer Bedingung "maximale Verwendung" (M), welche die Anzahl festlegt, wie oft die Adressierungsinformationen verwendet werden können, und wobei der Schritt des Routings der Dienstanforderung ausgeführt wird, falls die Prüfung erfolgreich war.
  2. Verfahren nach Anspruch 1, wobei die Verwendungsregel ferner wenigstens eine Verwendungsbedingung umfasst, die gewählt ist aus: – einer ersten Zeitbedingung (T1), die einen Anfangszeitpunkt für die Verwendung der Adressierungsinformationen festlegt, – einer zweiten Zeitbedingung (T2), die einen Abbruchzeitpunkt für die Verwendung der Adressierungsinformationen festlegt, – einer Bedingung "anfordernder Teilnehmer" (U), die wenigstens eine Teilnehmerkennung wenigstens eines Teilnehmers angibt und festlegt, dass dieser Teilnehmer berechtigt ist, den Dienst zu nutzen.
  3. Verfahren nach Anspruch 1, wobei die Adressierungsinformationen wenigstens ein Element umfassen, das gewählt ist aus: – einer Adresse (AA) einer Anwendungsservereinheit (AS), welche den Dienst hostet, – einer Adresse (AC) einer Kommunikationsservereinheit (CS2), welche in das Routing einer Dienstanforderung, welche die Dienstkennung enthält, eingreifen kann, – einer Adressenbestimmungs-Fähigkeit (AD), die verwendet werden kann, um eine Adresse einer Kommunikationsservereinheit (CS2) zu bestimmen, welche in das Routing einer Dienstanforderung, welche die Dienstkennung enthält, eingreifen kann.
  4. Verfahren nach einem der Ansprüche 1 bis 3, welches ferner den folgenden vorangehenden Schritt umfasst: – Speichern der Dienstkennung, der Adressierungsinformationen und der Verwendungsregel in einer Standortservereinheit (LS).
  5. Verfahren nach Anspruch 4, welches ferner den folgenden vorangehenden Schritt umfasst: – Empfangen (f1, g1, h1) der Verwendungsregel in der Standortservereinheit von einer Anwendungsservereinheit (AS).
  6. Verfahren nach Anspruch 4 oder 5, wobei der Schritt des Prüfens der Verwendungsregel in der Standortservereinheit ausgeführt wird.
  7. Verfahren nach Anspruch 6, wobei der Schritt des Beschaffens von Adressierungsinformationen die folgenden Schritte umfasst: – Senden (f3, h3, h5a) einer Standortanfrage, welche die Dienstkennung enthält, von der Kommunikationsservereinheit an die Standortservereinheit, und – Empfangen (f4, h4, h5b) einer Anfrageantwort in der Kommunikationsservereinheit, welche die Adressierungsinformationen enthält, falls die Prüfung erfolgreich war.
  8. Verfahren nach Anspruch 6, wobei der Schritt des Beschaffens von Adressierungsinformationen die folgenden Schritte umfasst: – Senden (f3, h3, h5a) der empfangenen Dienstanforderung von der Kommunikationsservereinheit an die Standortservereinheit, und – Empfangen (f4, h4, h5b) einer Umleitungsangabe in der Kommunikationsservereinheit, welche die Adressierungsinformationen enthält, falls die Prüfung erfolgreich war.
  9. Verfahren nach einem der Ansprüche 1 bis 3, welches ferner den folgenden vorangehenden Schritt umfasst: – Speichern der Dienstkennung und der Verwendungsregel in der Kommunikationsservereinheit (CS, CS2).
  10. Verfahren nach Anspruch 9, welches ferner den folgenden vorangehenden Schritt umfasst: – Empfangen (g2, h2a) der Verwendungsregel in der Kommunikationsservereinheit von einer Standortservereinheit.
  11. Verfahren nach Anspruch 9, welches ferner den folgenden vorangehenden Schritt umfasst: – Empfangen (f1a, g1a, h1a) der Verwendungsregel in der Kommunikationsservereinheit von einer Anwendungsservereinheit.
  12. Verfahren nach einem der Ansprüche 9 bis 11, wobei der Schritt des Prüfens der Verwendungsregel in der Kommunikationsservereinheit ausgeführt wird.
  13. Standortservereinheit (LS), welche aufweist: – Speichermittel, die so beschaffen sind, dass sie Adressierungsinformationen (AI) speichern, die sich auf eine Dienstkennung (SID) beziehen, welche einen Dienst kennzeichnet, und – Verarbeitungsmittel, die so beschaffen sind, dass sie auf die Speichermittel zugreifen, um die Adressierungsinformationen bereitzustellen, wobei: – die Speichermittel ferner eine Verwendungsregel (UR), um die Verwendung der Adressierungsinformationen zu gestatten, speichern, und – die Verarbeitungsmittel ferner so beschaffen sind, dass sie die Verwendungsregel prüfen, um zu bestimmen, ob die Adressierungsinformationen zur Verfügung gestellt werden können oder nicht; dadurch gekennzeichnet, dass die Verwendungsregel wenigstens eine Verwendungsbedingung umfasst, die gewählt ist aus: – einer Zeitbedingung (T3), die in der Standortservereinheit den maximalen Zeitabstand für das Bereitstellen der Adressierungsinformationen festlegt, gerechnet ab dem ersten Zeitpunkt, zu dem sie von dem Standortserver bereitgestellt werden, – einer Bedingung "maximale Verwendung" (M), welche in der Standortservereinheit die Anzahl festlegt, wie oft die Adressierungsinformationen von der Standortservereinheit bereitgestellt werden können, wobei die Verarbeitungsmittel so beschaffen sind, dass sie wenigstens eine dieser Bedingungen prüfen.
  14. Standortservereinheit nach Anspruch 13, wobei die Verwendungsregel ferner wenigstens eine Verwendungsbedingung umfasst, die gewählt ist aus: – einer ersten Zeitbedingung (T1), die in der Standortservereinheit einen Anfangszeitpunkt für das Bereitstellen der Adressierungsinformationen festlegt, – einer zweiten Zeitbedingung (T2), die in der Standortservereinheit einen Abbruchzeitpunkt für das Bereitstellen der Adressierungsinformationen festlegt, – einer Bedingung "anfordernder Teilnehmer" (U), die wenigstens eine Teilnehmerkennung wenigstens eines Teilnehmers angibt und in der Standortservereinheit festlegt, ob dieser Teilnehmer berechtigt ist, den Dienst zu nutzen, und wobei die Verarbeitungsmittel ferner so beschaffen sind, dass sie wenigstens eine dieser Bedingungen prüfen.
  15. Standortservereinheit nach Anspruch 13, wobei die Adressierungsinformationen wenigstens ein Element umfassen, das gewählt ist aus: – einer Adresse (AA) einer Anwendungsservereinheit (AS), welche den Dienst hostet, – einer Adresse (AC) einer Kommunikationsservereinheit (CS2), welche in das Routing einer Dienstanforderung, welche die Dienstkennung enthält, eingreifen kann, – einer Adressenbestimmungs-Fähigkeit (AD), die verwendet werden kann, um eine Adresse einer Kommunikationsservereinheit (CS2) zu bestimmen, welche in das Routing einer Dienstanforderung, welche die Dienstkennung enthält, eingreifen kann.
  16. Standortservereinheit nach einem der Ansprüche 13 bis 15, welche ferner so beschaffen ist, dass sie eine Verwendungsregel in Verbindung mit einer Dienstkennung empfängt und speichert.
  17. Standortservereinheit nach Anspruch 16, welche ferner so beschaffen ist, dass sie die Verwendungsregel von einer Anwendungsservereinheit empfängt.
  18. Standortservereinheit nach einem der Ansprüche 13 bis 17, welche ferner so beschaffen ist, dass sie eine Verwendungsregel in Verbindung mit einer Dienstkennung an eine Kommunikationsservereinheit sendet, welche in eine Dienstanforderung, welche die Dienstkennung enthält, eingreifen kann.
  19. Standortservereinheit nach einem der Ansprüche 13 bis 17, welche ferner so beschaffen ist, dass sie eine Standortanfrage empfängt, welche die Dienstkennung enthält, und mit einer Anfrageantwort antwortet, welche die Adressierungsinformationen enthält, falls die Prüfung erfolgreich war.
  20. Standortservereinheit nach einem der Ansprüche 13 bis 17, welche ferner so beschaffen ist, dass sie eine Dienstanforderung empfängt, welche die Dienstkennung enthält, und mit einer Umleitungsangabe antwortet, welche die Adressierungsinformationen enthält, falls die Prüfung erfolgreich war.
  21. Kommunikationsservereinheit (CS, CS1, CS2), welche Verarbeitungsmittel aufweist, die so beschaffen sind, dass sie: – eine Dienstanforderung empfangen, die eine Dienstkennung (SID) enthält, welche einen Dienst kennzeichnet, – Adressierungsinformationen (AI) beschaffen, die sich auf die Dienstkennung beziehen, und – eine empfangene Dienstanforderung unter Verwendung der Adressierungsinformationen routen, – eine Verwendungsregel (UR) zum Gestatten der Verwendung der Adressierungsinformationen beschaffen, – die Verwendungsregel prüfen, um zu bestimmen, ob eine empfangene Dienstanforderung, welche die Dienstkennung enthält, geroutet werden soll oder nicht; dadurch gekennzeichnet, dass die Verwendungsregel wenigstens eine Verwendungsbedingung umfasst, die gewählt ist aus: – einer Zeitbedingung (T3), die in der Kommunikationsservereinheit den maximalen Zeitabstand für das Routing von Dienstanforderungen, welche die Dienstkennung enthalten, festlegt, gerechnet ab dem ersten Zeitpunkt, zu dem eine Dienstanforderung, welche die Dienstkennung enthält, von der Kommunikationsservereinheit geroutet wurde, – einer Bedingung "maximale Verwendung" (M), welche in der Kommunikationsservereinheit die Anzahl festlegt, wie oft sie Dienstanforderungen, welche die Dienstkennung enthalten, routen kann, wobei die Verarbeitungsmittel so beschaffen sind, dass sie wenigstens eine dieser Bedingungen prüfen.
  22. Kommunikationsservereinheit nach Anspruch 21, wobei die Verwendungsregel ferner wenigstens eine Verwendungsbedingung umfasst, die gewählt ist aus: – einer ersten Zeitbedingung (T1), die in der Kommunikationsservereinheit einen Anfangszeitpunkt für das Routing von Dienstanforderungen, welche die Dienstkennung enthalten, festlegt, – einer zweiten Zeitbedingung (T2), die in der Kommunikationsservereinheit einen Abbruchzeitpunkt für das Routing von Dienstanforderungen, welche die Dienstkennung enthalten, festlegt, – einer Bedingung "anfordernder Teilnehmer" (U), die wenigstens eine Teilnehmerkennung wenigstens eines Teilnehmers angibt und in der Standortservereinheit festlegt, ob dieser Teilnehmer berechtigt ist, eine Dienstanforderung, welche die Dienstkennung enthält, zu senden; und wobei die Verarbeitungsmittel ferner so beschaffen sind, dass sie wenigstens eine dieser Bedingungen prüfen.
  23. Kommunikationsservereinheit nach Anspruch 21 oder 22, die ferner so beschaffen ist, dass sie eine Standortanfrage an einen Standortserver sendet, um die Adressierungsinformationen und die Verwendungsregel zu erhalten.
  24. Kommunikationsservereinheit nach Anspruch 21 oder 22, die ferner Speichermittel umfasst, die so beschaffen sind, dass sie die Verwendungsregel in Verbindung mit der Dienstkennung speichern, wobei die Verarbeitungsmittel ferner so beschaffen sind, dass sie die Verwendungsregel aus den Speichermitteln beschaffen.
  25. Kommunikationsservereinheit nach Anspruch 24, die ferner so beschaffen ist, dass sie die Verwendungsregel von einer Standortservereinheit empfängt und sie in den Speichermitteln speichert.
  26. Kommunikationsservereinheit nach Anspruch 24, die ferner so beschaffen ist, dass sie die Verwendungsregel von einer Anwendungsservereinheit empfängt und sie in den Speichermitteln speichert.
  27. Anwendungsservereinheit (AS), welche Verarbeitungsmittel aufweist, die so beschaffen sind, dass sie Informationen mit einer zweiten Servereinheit (LS, CS, CS2) austauschen, welche in die Signalisierung einer Dienstanforderung, die einen Dienst betrifft, eingreifen kann; wobei die Verarbeitungsmittel ferner so beschaffen sind, dass sie an die zweite Servereinheit eine Verwendungsregel (UR) in Verbindung mit einer Dienstkennung (SID) zum Gestatten der Verwendung der Adressierungsinformationen (AI), die für das Routing einer die Dienstkennung enthaltenden Dienstanforderung verwendbar sind, senden, dadurch gekennzeichnet, dass die Verwendungsregel wenigstens eine Verwendungsbedingung umfasst, die gewählt ist aus: – einer Zeitbedingung (T3), die den maximalen Zeitabstand für die Verwendung der Adressierungsinformationen festlegt, gerechnet ab dem ersten Zeitpunkt, zu dem sie verwendet werden, – einer Bedingung "maximale Verwendung" (M), welche die Anzahl festlegt, wie oft die Adressierungsinformationen verwendet werden können.
  28. Computerprogramm zum Bereitstellen von Informationen für das Routing einer Dienstanforderung, die eine Dienstkennung (SID) enthält, welche einen Dienst kennzeichnet, welches umfasst: – einen computerlesbaren Programmcode, um zu bewirken, dass ein computerbasierter Standortserver Adressierungsinformationen (AI) bereitstellt, welche die Dienstkennung betreffen, – einen computerlesbaren Programmcode, um zu bewirken, dass der computerbasierte Standortserver eine Verwendungsregel (UR) prüft, welche die Verwendung der Adressierungsinformationen gestattet, um zu bestimmen, ob die Adressierungsinformationen zur Verfügung gestellt werden können oder nicht, dadurch gekennzeichnet, dass die Verwendungsregel wenigstens eine Verwendungsbedingung umfasst, die gewählt ist aus: – einer Zeitbedingung (T3), die den maximalen Zeitabstand für die Verwendung der Adressierungsinformationen festlegt, gerechnet ab dem ersten Zeitpunkt, zu dem sie verwendet werden, – einer Bedingung "maximale Verwendung" (M), welche die Anzahl festlegt, wie oft die Adressierungsinformationen verwendet werden können, wenn das Programm auf dem Server läuft.
  29. Computerprogramm für das Routing einer Dienstanforderung, die eine Dienstkennung (SID) enthält, welche einen Dienst kennzeichnet, welches umfasst: – einen computerlesbaren Programmcode, um zu bewirken, dass ein computerbasierter Kommunikationsserver Adressierungsinformationen (AI) beschafft, welche sich auf die Dienstkennung beziehen, und – einen computerlesbaren Programmcode, um zu bewirken, dass der computerbasierte Kommunikationsserver die empfangene Dienstanforderung unter Verwendung der Adressierungsinformationen routet; – einen computerlesbaren Programmcode, um zu bewirken, dass der computerbasierte Kommunikationsserver eine Verwendungsregel (UR) beschafft, welche die Verwendung der Adressierungsinformationen gestattet, und – einen computerlesbaren Programmcode, um zu bewirken, dass der computerbasierte Kommunikationsserver die Verwendungsregel prüft, um zu bestimmen, ob eine empfangene Dienstanforderung, welche die Dienstkennung enthält, geroutet werden soll oder nicht, dadurch gekennzeichnet, dass die Verwendungsregel wenigstens eine Verwendungsbedingung umfasst, die gewählt ist aus: – einer Zeitbedingung (T3), die den maximalen Zeitabstand für die Verwendung der Adressierungsinformationen festlegt, gerechnet ab dem ersten Zeitpunkt, zu dem sie verwendet werden, – einer Bedingung "maximale Verwendung" (M), welche die Anzahl festlegt, wie oft die Adressierungsinformationen verwendet werden können, wenn das Programm auf dem Server läuft.
DE60315361T 2003-08-01 2003-08-01 Verfahren und vorrichtung zum routen einer dienstanforderung Expired - Lifetime DE60315361T2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2003/008553 WO2005015870A1 (en) 2003-08-01 2003-08-01 Method and apparatus for routing a service request

Publications (2)

Publication Number Publication Date
DE60315361D1 DE60315361D1 (de) 2007-09-13
DE60315361T2 true DE60315361T2 (de) 2008-05-15

Family

ID=34129890

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60315361T Expired - Lifetime DE60315361T2 (de) 2003-08-01 2003-08-01 Verfahren und vorrichtung zum routen einer dienstanforderung

Country Status (6)

Country Link
US (1) US20060195565A1 (de)
EP (1) EP1649658B1 (de)
AT (1) ATE369003T1 (de)
AU (1) AU2003253373A1 (de)
DE (1) DE60315361T2 (de)
WO (1) WO2005015870A1 (de)

Families Citing this family (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ATE551811T1 (de) * 2002-10-09 2012-04-15 Nokia Siemens Networks Oy Kommunikationssystem
US8229389B2 (en) * 2003-10-17 2012-07-24 Apple Inc. Method for obtaining location information for emergency services in wireless multimedia networks
GB0409496D0 (en) * 2004-04-28 2004-06-02 Nokia Corp Subscriber identities
US9503528B2 (en) * 2004-06-14 2016-11-22 Alcatel-Lucent Usa Inc. System for provisioning service data utilizing the IMS defined Sh interface's transparent data
US7453876B2 (en) * 2004-09-30 2008-11-18 Lucent Technologies Inc. Method and apparatus for providing distributed SLF routing capability in an internet multimedia subsystem (IMS) network
JP4348271B2 (ja) * 2004-10-05 2009-10-21 パナソニック株式会社 Ｓｉｐ端末制御システム
US20060089965A1 (en) * 2004-10-26 2006-04-27 International Business Machines Corporation Dynamic linkage of an application server and a Web server
US7567553B2 (en) * 2005-06-10 2009-07-28 Swift Creek Systems, Llc Method, system, and data structure for providing a general request/response messaging protocol using a presence protocol
US7761600B2 (en) * 2005-07-19 2010-07-20 Elefonaktiebolaget L M Ericsson (Publ) Method and apparatus for distributing application server addresses in an IMS
EP1753199B1 (de) 2005-08-11 2015-10-28 Swisscom AG Verfahren und System zur Abonnementenbindung eines Benutzers an einen Dienst
EP1933577A4 (de) * 2005-09-05 2009-06-24 Huawei Tech Co Ltd Verfahren zum realisieren eines dienstaktivierungsbetriebs und das verahren realisierendes benutzerendgerät
CN100384130C (zh) * 2005-09-05 2008-04-23 华为技术有限公司 一种通信的计费方法
DE102005043040B4 (de) * 2005-09-09 2007-06-21 Siemens Ag Verfahren zum gezielten Blockieren von Diensten in einem IP Multimedia Subsystem
US7509124B2 (en) 2005-09-16 2009-03-24 At&T Intellectual Property I, L.P. Methods, systems, and computer program products for providing multimedia information services over a communication network
US8194701B2 (en) 2005-12-06 2012-06-05 Lippershy Celestial Llc System and/or method for downstream bidding
US8014389B2 (en) 2005-12-06 2011-09-06 Lippershy Celestial Llc Bidding network
US9686183B2 (en) 2005-12-06 2017-06-20 Zarbaña Digital Fund Llc Digital object routing based on a service request
US8055897B2 (en) * 2005-12-06 2011-11-08 Lippershy Celestial Llc Digital object title and transmission information
WO2007079579A1 (en) * 2006-01-10 2007-07-19 Research In Motion Limited Domain selection system and method operable in a network environment including ims
KR100886548B1 (ko) 2006-04-26 2009-03-02 삼성전자주식회사 인터넷 프로토콜 멀티미디어 서브시스템 네트워크에서단말의 성능 정보를 전달하기 위한 방법 및 시스템
JP4804244B2 (ja) * 2006-07-03 2011-11-02 株式会社日立製作所 アプリケーションをフィルタリングする装置、システム及び方法
US8077701B2 (en) 2006-07-20 2011-12-13 At&T Intellectual Property I, Lp Systems, methods, and apparatus to prioritize communications in IP multimedia subsystem networks
US20080076453A1 (en) * 2006-09-25 2008-03-27 Yigang Cai SMS message delivery to non-SMS devices
EP1914973B1 (de) * 2006-10-16 2014-02-26 Motorola Mobility LLC System und Verfahren zum Bereitstellen von zusammenhängenden Diensten für anonyme Anrufer
US8516116B2 (en) * 2006-11-30 2013-08-20 Accenture Global Services Limited Context-based routing of requests in a service-oriented architecture
US7822035B2 (en) * 2007-03-07 2010-10-26 Nokia Corporation Use of communication service identifiers
EP2140664B1 (de) 2007-03-29 2015-08-12 Telefonaktiebolaget LM Ericsson (publ) Verfahren und vorrichtung zur verwendung in einem kommunikationsnetz
US20080270546A1 (en) * 2007-04-30 2008-10-30 Morris Robert P Methods And Systems For Communicating Task Information
CN101309447A (zh) * 2007-05-15 2008-11-19 中兴通讯股份有限公司 一种在终端上进行业务配置的方法及系统
US8867483B1 (en) * 2007-12-18 2014-10-21 Sprint Communications Company L.P. SCIM peering
US8306507B2 (en) * 2008-04-11 2012-11-06 Research In Motion Limited Differentiated message delivery notification
CN101478753B (zh) * 2009-01-16 2010-12-08 中兴通讯股份有限公司 Wapi终端接入ims网络的安全管理方法及系统
CN102595466A (zh) * 2011-01-10 2012-07-18 华为技术有限公司 最小化路测测量方法、装置和系统
CN110222069A (zh) 2013-03-15 2019-09-10 美国结构数据有限公司 用于批量和实时数据处理的设备、系统和方法
CN105683984A (zh) * 2013-09-28 2016-06-15 迈克菲股份有限公司 数据交换层上高效的请求－响应路由
US9847963B2 (en) * 2013-10-09 2017-12-19 Cisco Technology, Inc. Communicating service denials back to client during MDNS service discovery
CN104660494B (zh) * 2015-02-11 2018-11-27 深圳市奔跑科技有限公司 一种通信系统

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5651059A (en) * 1993-06-29 1997-07-22 Lucent Technologies Inc. Service package field update for a-i-net SCN and SCP
US5953389A (en) * 1993-11-16 1999-09-14 Bell Atlantic Network Services, Inc. Combination system for provisioning and maintaining telephone network facilities in a public switched telephone network
US5568544A (en) * 1995-03-13 1996-10-22 Siemens Rolm Communications Inc. Routing incoming calls to a PBX in response to route requests from a host computer
US6118776A (en) * 1997-02-18 2000-09-12 Vixel Corporation Methods and apparatus for fiber channel interconnection of private loop devices
US6104711A (en) * 1997-03-06 2000-08-15 Bell Atlantic Network Services, Inc. Enhanced internet domain name server
US6604140B1 (en) * 1999-03-31 2003-08-05 International Business Machines Corporation Service framework for computing devices
US6415323B1 (en) * 1999-09-03 2002-07-02 Fastforward Networks Proximity-based redirection system for robust and scalable service-node location in an internetwork
WO2001086492A1 (en) * 2000-05-05 2001-11-15 Abm Industries Pty. Ltd. End user to mobile service provider message exchange system based on proximity
AU2001287121A1 (en) * 2000-09-08 2002-03-22 Spontaneous Networks, Inc. Systems and methods for packet distribution
US20030028599A1 (en) * 2001-06-19 2003-02-06 Kolsky Amir D. Method and system for a communication scheme over heterogeneous networks
NL1018494C2 (nl) * 2001-07-09 2003-01-10 Koninkl Kpn Nv Methode en systeem voor het door een dienstproces aan een client leveren van een dienst.

Also Published As

Publication number Publication date
WO2005015870A1 (en) 2005-02-17
ATE369003T1 (de) 2007-08-15
EP1649658B1 (de) 2007-08-01
EP1649658A1 (de) 2006-04-26
AU2003253373A1 (en) 2005-02-25
DE60315361D1 (de) 2007-09-13
US20060195565A1 (en) 2006-08-31

Similar Documents

Publication Publication Date Title
DE60315361T2 (de) Verfahren und vorrichtung zum routen einer dienstanforderung
DE60218545T2 (de) Verfahren zum Verkehrlastausgleich zwischen Dienstanbietern
DE60303004T2 (de) Kommunikationsknoten-architektur
DE60202527T2 (de) Verfahren und system zur behandlung von mehrfachanmeldungen
DE69923856T2 (de) Verfahren und vorrichtung zur wirkungsgradverbesserung des verbindungsaufbaues im multimedia- kommunikationssystem
DE60313167T2 (de) Verfahren und system zum teilnehmen an ereignissen unter verwendung des sip-protokolls
DE60132387T2 (de) Richtlinien-Koordination in einem Kommunikationsnetz
DE60213484T2 (de) Kommunikationssystem
EP2469885B1 (de) Verfahren zur Integration von Funktionen eines Telekommunikationsnetzes in ein Datennetz
DE60020879T2 (de) Verteilung von ortsinformationen in ip-netzen durch intelligente endpunkte
EP1503558A1 (de) Verbindung von Teilnehmern in hybriden Kommunikationsnetzen
EP1207670A2 (de) Dienst zur automatischen Übermittlung von Paketdaten
DE10004811A1 (de) Kommunikationssystem, Verfahren und Steuereinrichtung zum Leiten von Anrufen innerhalb von privaten Netzen, die über geographische beabstandete Zonen verteilt sind
DE60313814T2 (de) Vorrichtung zum verhandeln von managementaufgaben
DE602004006171T2 (de) Sitzungseinleitungsprotokollsignalisierung (sip)
DE60017917T2 (de) Verbindungsaufbau in einem multimediennetz
WO2006048317A2 (de) VERFAHREN UND SYSTEM ZUR IDENTIFIZIERUNG EINES TEILNEHMERS UND DES BENUTZTEN ANSCHLUSSES BEI VoIP VERBINDUNGEN
WO2009153176A1 (de) Verfahren zur ermittlung aktiver kommunikationssitzungen und kommunikationssitzungs-informationsserver
EP2031885B1 (de) Verfahren zur Portierung und Vermittlung von Nummern in IMS-Domänen
DE102008019032A1 (de) Universelle Adressierung eines Kommunikationspartners über verdeckte dynamische Zuordnung einer Rufnummer
DE102005063048A1 (de) Vermittlungseinheit für ein IP Multimedia Subsystem
DE102022121507B4 (de) Verfahren und IP-Multimedia-Subsystem zum Durchführen einer Datenübertragung, Computerprogrammprodukt und Speichermedium
DE102005043040B4 (de) Verfahren zum gezielten Blockieren von Diensten in einem IP Multimedia Subsystem
DE10254904B3 (de) Betriebsmodus für ein Kommunikationssystem
EP1313301A1 (de) Multimediales Kommunikationssystem mit aktivierbaren Zusatzdiensten während einer Konferenz

Legal Events

Date Code Title Description
8364 No opposition during term of opposition