DE60127869T2 - Verfahren zum zuteilen von dienstparameterwerten an übertragungen, funkzugangsnetze und netzwerkelemente - Google Patents

Verfahren zum zuteilen von dienstparameterwerten an übertragungen, funkzugangsnetze und netzwerkelemente Download PDF

Info

Publication number
DE60127869T2
DE60127869T2 DE60127869T DE60127869T DE60127869T2 DE 60127869 T2 DE60127869 T2 DE 60127869T2 DE 60127869 T DE60127869 T DE 60127869T DE 60127869 T DE60127869 T DE 60127869T DE 60127869 T2 DE60127869 T2 DE 60127869T2
Authority
DE
Germany
Prior art keywords
service
values
radio access
value
access network
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 - Fee Related
Application number
DE60127869T
Other languages
English (en)
Other versions
DE60127869D1 (de
Inventor
Jukka Immonen
Juha Ala-Laurila
Jarkko Jouppi
Juha Kalliokulju
Kari O. Virtanen
Serge Haumont
Sami Hartala
Tuija Hurtta
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.)
Nokia Oyj
Original Assignee
Nokia Oyj
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 Nokia Oyj filed Critical Nokia Oyj
Publication of DE60127869D1 publication Critical patent/DE60127869D1/de
Application granted granted Critical
Publication of DE60127869T2 publication Critical patent/DE60127869T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data

Landscapes

  • Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

  • GEBIET DER ERFINDUNG
  • Die Erfindung betrifft ein Verfahren zur Zuweisung von Werten von Dienstattributen (Serviceattributen) auf Übermittlungen zwischen einem Nutzergerät und einem Funkzugangsnetzwerk. Die Erfindung betrifft sowohl solche Funkzugangsnetzwerke als auch Netzwerkelemente von solchen Netzwerken.
  • HINTERGRUND DER ERFINDUNG
  • Funkzugangsnetzwerke ermöglichen drahtlose Übermittlungen von Informationen zu und von einem Nutzergerät. Jede Übermittlung wird mit einer Vielfalt an Serviceattributen von Werten, die für die Übermittlung bestimmt werden müssen, durchgeführt. Der Begriff Funkzugangsnetzwerk wird in diesem Dokument benutzt, um ein vollständiges Netzwerk zu kennzeichnen, auf das über Funkverbindungen zugegriffen werden kann, z.B. ein gesamtes Mobilfunknetzwerk, wobei die Kernnetzwerkteile mit eingeschlossen sind.
  • Bei zukünftigen Funkzugangsnetzwerken können ausgeklügelte Servicesteuerungsmechanismen, wie zum Beispiel die Steuerung der Dienstgüte (QoS: Quality of Service), die für jede Übermittlung vorgesehen wird, eine wichtige Rolle spielen. Solche Servicesteuerungsmechanismen können zur Differenzierung zwischen verschiedenen Anwendungen, wie zum Beispiel Echtzeit- gegenüber Nichtechtzeit-Anwendungen, oder zwischen verschiedenen Nutzergruppen, z.B. Business- gegenüber Low-Budget-Nutzern, benutzt werden. Bei 3G (3. Generation) Netzwerken ist die Ausstattung mit einem gewissen QoS und einer auf QoS basierenden Fakturierung ein inhärenter Bestandteil des Servicemodells. Servicesteuerungsmechanismen werden realisiert, indem die Werte der für eine Übermittlung benutzten Attribute variiert werden.
  • Ein Kunde kann ein Nutzergerät für ein spezifisches Funkzugangsnetzwerk registrieren. Um Servicesteuerungsmechanismen zu ermöglichen, muss sich außerdem über ein subskribiertes teilnehmerspezifisches Serviceprofil geeinigt werden. Solch ein Serviceprofil definiert z.B. die Quality of Service, die für Übermittlungen zwischen dem Nutzergerät und dem Netzwerk gestattet oder garantiert ist, und es hängt für gewöhnlich davon ab, was der Kunde bereit ist, für diese Übermittlungen zu zahlen. Genauer gesagt umfasst das subskribierte Serviceprofil Werte von verschiedenen Serviceattributen, die die Qualität einer Übermittlung kennzeichnen, oder es verweist auf solche. Die von dem subskribierten Serviceprofil definierten Werte können für alle Übermittlungen zu und von dem jeweiligen Nutzergerät benutzt werden. Alternativ ist dem Nutzergerät gestattet, für jede Übermittlung Werte für die benötigten Serviceattribute, die geringer oder gleich dem Level der subskribierten Werte der Attribute sind, anzufordern. Für den Fall, dass eine Übermittlung angefordert wird, ohne die ausdrückliche Angabe der für die angeforderten Serviceattribute gewünschten Werte, sind die Grundeinstellungsattribute bereit zu stellen.
  • Es gibt eine beträchtliche Anzahl von Serviceattributen, die für jede Verbindung zu bestimmen sind. Für UMTS (Universal Mobile Telecommunications System), wurden QoS-Attribute in 3GPP TS 23.107 V3.4.0 (2000-07) spezifiziert: „3rd Generation Partnership Project; Technical Specification Group Services and Aspects; QoS Concept and Architecture; Release 1999". Alle Übermittlungen werden auf vier verschiedenen Verkehrsklassen verteilt, eine Konversationsklasse, eine Streamingklasse, eine interaktive Klasse und eine Hintergrundklasse. Der wichtigste Unterscheidungsfaktor zwischen diesen Klassen liegt darin, wie verzögerungssensibel der Verkehr ist. Die Konversationsklasse ist für Verkehr gedacht, der sehr verzögerungssensibel ist, während die Hintergrundklasse die verzögerungsunsensibelste Verkehrsklasse ist. Die Konversationsklasse und die Streamingklasse sind hauptsächlich dazu gedacht, benutzt zu werden, um Echtzeitverkehrsflüsse zu befördern. Ein Beispiel für Verkehr der Konversationsklasse ist Sprache und ein Beispiel für Verkehr der Streamingklasse ist Streamingvideo. Die interaktive Klasse und die Hintergrundklasse sind hauptsächlich dazu gedacht, benutzt zu werden, um Nichtechtzeitverkehrsflüsse zu befördern. Ein Beispiel für Verkehr der interaktiven Klasse ist Webbrowsing und ein Beispiel für Verkehr der Hintergrundklasse ist der Download von E-Mails im Hintergrund. Der Standard definiert, welche Attribute für welche Klasse zu definieren sind und er gibt ebenso Wertbereiche für die unterschiedlichen Serviceattribute vor.
  • Gemäß dem Standard müssen für jede der vier Klassen die maximale Bitrate, die Lieferreihenfolge, die maximale Größe der SDU (Service Data Unit), die SDU-Fehlerhäufigkeit, die restliche Bitfehlerhäufigkeit (BER: Bit Error Ratio), die Lieferung von fehlerhaften SDUs und die Zuteilungs/Zurückhaltungspriorität festgelegt werden. Die Angabe der Verkehrsklasse selbst bildet ebenso eines der für alle Klassen benötigten Attribute. Für die Konversationsklasse und die Streamingklasse sind zusätzlich SDU-Format-Informationen, die Transferverzögerung und eine garantierte Bitrate zu bestimmen. Für die interaktive Klasse ist zusätzlich eine Verkehrsabwicklungspriorität VAP (THP: Traffic Handling Priority) zu bestimmen.
  • Alle subskribierten Attribute werden gegenwärtig zusammen mit anderen Informationen in dem HLR/HSS (Horne Location Register/Horne Subscriber Server) des Nutzergerätes in dem Funkzugangsnetzwerk, bei dem das Nutzergerät registriert ist, gespeichert. Der genannte UMTS-Standard definiert jedoch nicht genau, wie die in den HLR/HSS gespeicherten QoS-Attribute zu berücksichtigen sind, wenn die Entscheidung über den Satz an Attributen, der für eine spezifische Verbindung zu benutzen ist, getroffen wird. Der Standard spezifiziert nur, dass ein QoS-Profil für jede Kunden-Subskription gespeichert ist. Das Nutzergerät kann dann spezifische Werte von Serviceattributen anfordern, wobei das subskribierte Profil die oberen Grenzen für den bereit gestellten Service definiert. Um in der Lage zu sein, Services mit einer hohen Übermittlungsqualität zu benutzen, muss der Nutzer ein QoS-Profil mit Werten von Serviceattributen, die eine hohe Qualität ermöglichen, subskribieren.
  • Der Standard schlägt vor, sowohl das subskribierte Profil, als auch das Grundeinstellungs-QoS-Profil zu benutzen. Der Nachteil einer solchen Vorgehensweise liegt darin, dass selbst wenn ein Kunde keine spezifischen Werte von Attributen für einen Verkehrsstrom benötigt, ein möglicherweise hohes subskribiertes QoS-Profil ohne eine dafür bestehende Notwendigkeit benutzt wird.
  • Ein anderes Problem ergibt sich aus der Vorgehensweise, die bei dem UMTS-Standard, 3G TS 23.060, Version 3.4.0. vorgeschlagen wird. Gemäß diesem Standard ist es für ein Nutzergerät möglich, einige der QoS-Attribute in einer PDP (Packet Data Protocol) Kontext-Aktivierung undefiniert zu belassen. Der Standard definiert jedoch keine Funktionalität, die ein Netzwerk dazu befähigen würde, die benutzerdefinierten QoS-Attribute auf eine intelligente Art und Weise zu evaluieren, wenn der Rest der Attribute bestimmt wird. Die fehlenden Attribute werden einfach aus dem HLR/HSS abgerufen, was ebenso in der technischen Spezifikation 3GPP 24.008 V3.4.0 beschrieben ist: „Mobile Radio Interface Layer 3 Spezification; Core Network Protocols, Stage 3, Release 1999". Dies kann zu einer Situation führen, bei der ein Konflikt zwischen den angeforderten und den abgerufenen QoS-Attributen besteht. Solch ein Konflikt liegt zum Beispiel vor, wenn von dem Nutzergerät eine sehr geringe Verzögerung angefordert wird, was für einen Echtzeitverkehr wesentlich ist, und eine sehr gute subskribierte Paketfehlerhäufigkeit, die nur für Nichtechtzeitverkehr wesentlich sein würde, von dem HLR/HSS abgerufen wird. Solch eine Kombination von Attributen ist unmöglich zu implementieren. Da die Funknetz-Steuereinrichtung (RNC = Radio Network Controller), die die tatsächliche Übermittlung zwischen einem Nutzergerät und einem Node B eines UTRAN (UMTS terrestrial radio access network) steuert, nicht in der Lage ist, über QoS-Parameter zu verhandeln, wird ein angeforderter PDP-Kontext zurückgewiesen, selbst wenn nur leicht unzutreffende Parameter von dem SGSN eingestellt werden. Außerdem können die subskribierten QoS-Parameter nicht alle benötigten QoS-Parameter enthalten, z.B. wenn die subskribierte Verkehrsklasse die „Konversationsklasse" ist, mag das erforderliche Serviceattribut "Verkehrsabwicklungspriorität" nicht definiert sein. Daher wird es bei der Einrichtung von PDP-Kontexten ein hohes Niveau von Fehlschlägen geben.
  • Es ergibt sich noch ein weiteres Problem mit den gegenwärtigen Spezifikationen aus den unklaren Definitionen. Gemäß den gegenwärtigen Spezifikationen ist es so, dass wenn das Nutzergerät einen gültigen Wert für ein QoS-Serviceattribut in der PDP-Kontext-Aktivierung- Anforderungsnachricht anfordert, der Serving Gateway Support Node (SGSN) überprüfen sollte, dass dieser Wert nicht das im HLR subskribierte QoS-Profil überschreitet, welches somit als Maximum genommen wird. Während jedoch der Begriff Maximum z.B. für das Serviceattribut Bitrate klar ist, ist die Interpretation für die Attribute Bitfehlerrate oder Verzögerung nicht ganz klar. In dem letzteren Fall sollte der subskribierte Wert in dem HLR eher als Minimalwert angesehen werden, so dass das Nutzergerät nicht weniger bekommen kann als die subskribierte Verzögerung, und nicht als Maximalwert, so dass das Nutzergerät immer weniger bekommt als die zugewiesene Verzögerung.
  • Andere Probleme bei der Zuweisung von Werten von Serviceattributen zu angeforderten Übermittlungen ergeben sich aus dem Umstand, dass der Nutzer eines Nutzergerätes nicht notwendigerweise darauf beschränkt ist, eine Verbindung in dem Funkzugangsnetzwerk anzufordern, in dem das Gerät registriert ist. Insbesondere bei lokalen drahtlosen Hotspots, wie beispielsweise in Hotels und Flughäfen, kann ein örtlich begrenztes Funkzugangsnetzwerk für Verbindungen zu dem öffentlichen Internet oder zu einem Firmennetzwerk zur Verfügung gestellt werden. Solch ein drahtloses Zugangsnetzwerk kann zum Beispiel als drahtloses lokales Netzwerk (WLAN = Wireless Local Area Network) ausgeführt werden. Ein Nutzergerät kann auf das lokale Funkzugangsnetzwerk zugreifen, wenn es entweder dem Betreiber des Funkzugangsnetzwerk gehört, bei dem das Nutzergerät registriert ist, oder wenn es einem anderen Betreiber gehört, der ein Roaming-Abkommen mit dem Betreiber des besagten Funkzugangsnetzwerk, bei dem das Nutzergerät registriert ist, hat.
  • Jedes Nutzergerät ist mit einer Karte (Smartcard) ausgestattet, wie zum Beispiel mit einem GSM (Global System for Mobile Communication) SIM-Karte (SIM = Subscriber Identification Module), die die Informationen enthält, die für die Authentifizierung des Nutzers und für die Fakturierung in einem öffentlichen Funkzugangsnetzwerk, insbesondere in einem Mobilfunknetzwerk, bei dem das jeweilige Nutzergerät registriert ist, benötigt werden. Der Betreiber des öffentlichen Funkzugangsnetzwerkes, z.B. ein GSM- oder ein 3G-Netzwerk, kann in einem lokalen Funkzugangsnetzwerk, z.B. WLAN, für die Mobilfunknutzer zusätzlich drahtlose Breitbandservices anbieten, indem die vorhandene Mobilfunkinfrastruktur zur Authentifizierung des Nutzers und zur Fakturierung benutzt wird. Die Informationen über die Authentifizierung und über die Fakturierung werden über Gateways zwischen dem lokalen Funkzugangsnetzwerk und dem öffentlichen Funkzugangsnetzwerk befördert. Proprietäre Protokolle kümmern sich um die Signalisierung zwischen den verschiedenen Netzwerkelementen.
  • Bei herkömmlichen WLAN-Netzwerken empfangen alle Nutzer einen ähnlichen Service von dem Netzwerk, den so genannten „Best-Effort Service". Dieser Service stellt dem Nutzergerät einfach Mittel zu Verfügung um Verkehr zu dem Netzwerk zu senden und Verkehr von dem Netzwerk zu empfangen. Diese Vorgehensweise gestattet jedoch nicht, den verschiedenen subskribierten Teilnehmer verschiedene Service- oder Qualitätsstufen zur Verfügung zu stellen.
  • Ferner sind PDP-Kontexte zu beachten, die benutzt werden, um spezifischen Verkehr zu befördern. Diese PDP-Kontexte können eine erhöhte Serviceattribut-Einstellung in dem Netzwerk benötigen.
  • Ein Beispiel ist der signalisierende PDP-Kontext, der für die Steuerung von IP-basierten Anwendungen verwendet wird, und der für dasselbe Nutzergerät andere Serviceattribute benötigen kann, als die Übermittlung von Nutzerdaten. Es wurde vorgeschlagen, dass das Nutzergerät zur Anforderung eines signalisierenden PDP-Kontextes nur den Wert eines einzelnen Serviceattributes zu dem Netzwerk übermitteln sollte. Dieses einzelne Serviceattribut soll der zusätzliche QoS-Parameter „Source Statistics Descriptor SSD" sein, und der zugewiesene Wert soll „Signalisierung" sein. Das Netzwerk muss dann die Werte für die anderen benötigten Serviceattribute gemäß den Anforderungen für den Signalisierungsverkehr für die Sitzungssteuerung einstellen, aber es wurde bisher nicht vorgeschlagen, wie das Netzwerk diese Werte auswählen soll.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Es ist ein Ziel der Erfindung, eine verbesserte Zuweisung von Werten von Serviceattributen auf Übermittlungen zu ermöglichen, welche von einem Nutzergerät in einem Funkzugangsnetzwerk zwischen dem besagten Nutzergerät und dem besagten Funkzugangsnetzwerk angefordert werden.
  • Dieses Ziel wird erreicht mit dem vorgeschlagenen Verfahren zur Zuweisung von Werten von Serviceattributen, die eine Quality of Service einer Übermittlung definieren, zu Übermittlungen zwischen einem Nutzergerät und einem Funkzugangsnetzwerk. Auf Anforderung einer solchen Übermittlung durch ein Nutzergerät eines subskribierten Teilnehmers, der bei einem Funkzugangsnetzwerk registriert ist, werden Werte von Serviceattributen bestimmt, die für die angeforderte Übermittlung zu benutzen sind. Die Werte werden einerseits basierend auf zumindest einem Wert von zumindest einem Serviceattribut, das durch ein gespeichertes für einen subskribierten Teilnehmer spezifisches Serviceprofil definiert wird, und andererseits basierend auf zumindest einem allgemeinen Wert von zumindest einem Serviceattribut für alle subskribierten Teilnehmer, bestimmt.
  • Die Erfindung entspringt der Überlegung, dass eine Vielzahl von unabhängigen Faktoren die am besten geeigneten Attribute bestimmt, die für eine Übermittlung zwischen einem Nutzergerät und einem Funkzugangsnetzwerk zu benutzen sind. Diese Faktoren werden insbesondere von der gegenwärtigen Anforderung eines Nutzergerätes für eine spezifische Übermittlung gegeben, durch Werte von Serviceattributen, die von einem subskribierten Serviceprofil definiert sind, und durch Werte von Serviceattributen, die dazu bestimmt sind, in dem Fall benutzt zu werden, dass das Nutzergerät eine Übermittlung anfordert, ohne die gleichzeitige Anforderung von spezifischen Werten oder einer Angabe von solchen Werten von Serviceattributen. Diese Faktoren und ihre Interdependenzen können auf effektive Art und Weise berücksichtigt werden, wenn einerseits ein Serviceprofil gespeichert wird, das der Subskription eines spezifischen subskribierten Teilnehmers entspricht, und wenn andererseits allgemeine Werte von Serviceattributen für alle subskribierten Teilnehmer zur Verfügung gestellt werden. Welche der Werte der Serviceattribute für eine spezifische Übermittlung ausgewählt werden, wird gemäß einer Anforderung durch ein Nutzergerät bestimmt. Die Komposition der Attribute und ihrer Werte für eine angeforderte Übermittlung kann variieren von der alleinigen Benutzung von Werten aus dem subskribierten Satz von Werten, über die Benutzung von teilweise subskribierten Werten und teilweise allgemeinen Werten, bis hin zur alleinigen Benutzung von allgemeinen Werten, abhängig von der angeforderten Übermittlung.
  • Mit der vorgeschlagenen Vorgehensweise können die Art der angeforderten Übermittlung und die durch die Subskription vorgegebenen Einschränkungen berücksichtigt werden, während es zugleich ermöglicht wird, dass Konflikte, die sich aus einer Kombination von angeforderten Attributen und subskribierten Attributen ergeben, vermieden werden können. Alles in allem kann jede Art von Anforderung in einer effizientesten Weise gehandhabt werden, d.h. insbesondere mit einem Service, der weder schlechter noch besser ist, als das, wofür der Kunde bereit ist, für eine spezifische Übermittlung zu bezahlen.
  • Eine angeforderte Übermittlung, der Werte von Serviceattributen zuzuweisen sind, kann eine Übermittlung in jede Richtung zwischen dem anfordernden Nutzergerät und einem Funkzugangsnetzwerk sein.
  • Vorzugsweise definieren die Werte der durch ein für einen subskribierten Teilnehmer spezifisches Serviceprofil definierten Serviceattribute und die allgemeinen Werte der Serviceattribute die Quality of Service einer Übermittlung. Ergänzend oder alternativ können die Werte für jede andere Art von Attributen, die von dem Betreiber als für eine Übermittlung nützlich angesehen werden, verfügbar gemacht werden.
  • Vorteilhafterweise kann das Nutzergerät zusammen mit einer Übermittlung spezifische Werten von Serviceattributen für die Übermittlung anfordern. Diese Werte werden bei der Bestimmung der Werte, die für die Übermittlung zu benutzen sind, ergänzend berücksichtigt.
  • Bei einer weiteren vorteilhaften Ausführungsform der Erfindung definieren die für einen subskribierten Teilnehmer spezifischen Serviceprofile die oberen und/oder die unteren Grenzen der Werte, die für die Serviceattribute für zumindest eine Übermittlungsart, so wie sie für das entsprechende Nutzergerät subskribiert wurde, zugelassen sind. Für den Fall, dass spezifische Werte von Attributen von einem Nutzergerät angefordert werden, bedeutet das, dass die von dem Nutzergerät angeforderten Werte als zu benutzende Werte bestimmt werden, solange sie nicht die Werte überschreiten, die von dem gespeicherten für einen subskribierten Teilnehmer spezifischen Serviceprofil definiert werden. Wenn ein angeforderter Wert in einer vordefinierten Richtung den entsprechenden subskribierten Wert überschreitet, wird als der für die angeforderte Übermittlung zu benutzende Wert der subskribierte Wert bestimmt.
  • Die für einen subskribierten Teilnehmer spezifischen Werte von Attributen, die von den Profilen definiert werden, können insbesondere die Werte von Attributen umfassen, welche den Quality of Service für angeforderte Echtzeitverkehrsübermittlungen definieren. Für Echtzeitübermittlungen können die Werte von Attributen, die von den für den subskribierten Teilnehmer spezifischen Profile definiert sind, ebenso als Grundeinstellungswerte benutzt werden, falls nicht alle oder keine Werte von Serviceattributen von einem Nutzergerät für eine angeforderte Übermittlung angefordert werden. Alternativ, aber vorzugsweise zusätzlich, können die für einen subskribierten Teilnehmer spezifischen Werte von Attributen Werte von zumindest einem Attribut umfassen, das einen Teil des Quality of Service für Nichtechtzeitverkehrsübermittlungen darstellt, insbesondere Werte für die Verkehrsabwicklungspriorität. Die für einen subskribierten Teilnehmer spezifischen Werte von Attributen können ebenso in anderen geeigneten Fällen als Grundeinstellungswerte benutzt werden.
  • Anstelle von einem Satz von Grenzwerten ist es auch möglich, mehrere Sätze von Grenzwerten zu speichern, wobei der bereit zu stellende Satz für jede Übermittlung entsprechend einer Eigenschaft der angeforderten Übermittlung ausgewählt wird, z.B. entsprechend dem Zugangspunkt, der von dem Nutzergerät benutzt wird. Ferner können Speichermittel, die die subskribierten Nutzerprofile speichern, ein Servicedegradationprofil für jeden Nutzer umfassen, welches die Werte von Attributen angibt, die in dem Falle anzuwenden sind, wenn eine Übermittlung nicht vorgenommen werden kann oder nicht auf der gewünschten Servicestufe gehalten werden kann, auch wenn die Subskription die angeforderte Servicestufe zulassen würde. Solche Servicedegradationsprofile sind in der gleichzeitig anhängigen US-Patentanmeldung mit dem Titel „Apparatus, and associated method for controlling service degradation Performance of communications in a radio communication system" und angemeldet am 28. Oktober 1999, detailliert beschrieben.
  • Die allgemeinen Werte von Attributen umfassen vorzugsweise zumindest einen Grundeinstellungswert für zumindest ein Attribut, das in dem Falle zu benutzen ist, wenn das Nutzergerät keinen spezifischen Wert für das besagte zumindest eine Attribut für eine spezifisch angeforderte Übermittlung benötigt. Insbesondere können die allgemeinen Werte von Attributen einen Grundeinstellungswert für zumindest ein Attribut umfassen, das in dem Falle zu benutzen ist, wenn das Nutzergerät keinen spezifischen Wert für das besagte zumindest eine Attribut für eine angeforderte Nichtechtzeitübermittlung benötigt. In dem Falle, dass Werte von anderen Attributen, die für diese Art von Übermittlung erforderlich sind, von dem für einen subskribierten Teilnehmer spezifischen Profil zur Verfügung gestellt werden, ist es möglich, dass diese für einen subskribierten Teilnehmer spezifischen Werte einerseits für die Übermittlung benutzt werden, während andererseits die zur Verfügung gestellten allgemeinen Werte für die darüber hinaus erforderlichen Werte benutzt werden. Die Übermittlung kann daher in dem Fall, dass das Nutzergerät keine Werte anfordern, sowohl auf die gemeinsamen Werte als auch auf die für einen subskribierten Teilnehmer spezifischen. Werte basiert werden. Dies ist von besonderem Interesse für Nichtechtzeitübermittlungen, bei denen die Konformität der Werte eines Teils der Attribute mit dem für einen subskribierten Teilnehmer spezifischen Profil möglicherweise überprüft werden muss.
  • Ähnlich wie bei den für einen subskribierten Teilnehmer spezifischen Profilen können ein oder mehrere Sätze von gemeinsamen Werten für zumindest ein Attribut zur Verfügung gestellt werden. Einer der Sätze kann als Basis für eine Übermittlung, zum Beispiel abhängig von einer Gruppe ausgewählt werden, der das anfordernde Nutzergerät zugewiesen wurde, oder entsprechend dem Zugangspunktnamen, der von dem Nutzergerät vergeben wurde. Ebenso können sich die Lastsituation oder andere Informationen von dem Funkzugangsnetzwerk auf die Auswahl des zu benutzenden Satzes von Grundeinstellungsattributen auswirken. Tatsächlich würde es mit einer solchen Vielzahl an Sätzen von allgemeinen Werten sogar möglich sein, nur den entsprechenden Satz von allgemeinen Parametern zu benutzen, ohne das Hinzufügen von Informationen von den Speichermitteln mit den für einen subskribierten Teilnehmer spezifischen Werten, immer dann, wenn eine Nichtechtzeitübermittlung ohne die Anforderung von Werten für die angeforderten Serviceattribute angefordert wird.
  • Wie bereits gesagt wurde kann ein Nutzergerät spezifische Werte für einige der angeforderten Serviceattribute anfordern, aber nicht für alle. Selbst wenn die fehlenden Attributwerte als gespeicherte für einen subskribierten Teilnehmer spezifische Werte zur Verfügung gestellt werden, können diese immer noch nicht passend zu den von dem Nutzergerät angeforderten Werten sein. Bei einer besonders bevorzugten Ausführungsform der Erfindung wird daher vorgeschlagen, dass eine Verhandlung stattfindet, die die von dem Nutzergerät angeforderten Werte, die gespeicherten für einen subskribierten Teilnehmer spezifischen Werte, insbesondere HLR-Werte, und die definierten allgemeinen Werte kombiniert.
  • Vorherbestimmte Regeln werden zur Durchführung der Verhandlung benutzt, d.h. zur Kombination von angeforderten Werten, von gespeicherten für einen subskribierten Teilnehmer spezifischen Serviceattributen und von definierten allgemeinen Serviceattributen in einer koordinierten Art und Weise. Die allgemeinen Werte können mittels dieser Regeln dazu definiert werden, maximale oder minimale Werte, oder Grundeinstellungswerte zu sein. Die maximalen und die minimalen Werte können zum Beispiel einen jeweiligen Bereich definieren, innerhalb dessen einem Wert eines spezifischen Serviceattributes, das von einem Nutzergerät angefordert wird, gestattet wird zu liegen. Ein Grundeinstellungswert kann z.B. für ein Serviceattribut benutzt werden, für das kein Wert angefordert wurde und für das kein Wert als für einen subskribierten Teilnehmer spezifischer Wert gespeichert ist, oder für das der für einen subskribierten Teilnehmer spezifische Wert nicht benutzt werden soll, wegen eines möglichen Konflikts mit einem angeforderten Wert von einem Attribut. Anstelle von einem einzigen Grundeinstellungswert kann ein Satz von Grundeinstellungswerten für ein Serviceattribut definiert werden, wobei jeder Grundeinstellungswert eines Satzes für spezifische angeforderte Werte von einem anderen Attribut oder von anderen Attributen anzuwenden ist. Ebenso können Regeln für die Bedeutung von gespeicherten für einen subskribierten Teilnehmer spezifischen Serviceattributwerten und für das Verhältnis zwischen gespeicherten für einen subskribierten Teilnehmer spezifischen Serviceattributwerten und allgemeinen Serviceattributwerten zur Verfügung gestellt werden.
  • Es wird insbesondere vorgeschlagen, dass, wenn ein Nutzergerät einen Wert für einen ersten Parameter ausdrücklich anfordert, zum Beispiel für die Verkehrsklasse, aber nicht für einen zweiten angeforderten Parameter, zum Beispiel für die SDU-Fehlerhäufigkeit, ein subskribierter Wert für den besagten zweiten Parameter nur benutzt werden darf, wenn der angeforderte erste Parameterwert dem subskribierten ersten Parameterwert entspricht. Sonst wird der zweite Parameter auf einen vorher konfigurierten Wert eingestellt, dessen Wert vorzugsweise von dem angeforderten Wert des ersten Parameters abhängt.
  • Mit einer solchen Vorgehensweise ist es möglich, für jede Situation ein durchführbares QoS-Profil für eine angeforderte Übermittlung zu erzielen.
  • Die definierten allgemeinen Attributwerte können zusammen mit Übertragungsregeln in einem Netzwerkelement eines Funkzugangsnetzwerks, zum Beispiel in einem SGSN, gespeichert werden. Dies würde das Netzwerkelement mit einer vorher konfigurierten Verfahrensweise versorgen, gemäß welcher es zu verhandeln hat, wie die Parameter zu übertragen sind. Alternativ befinden sich die Attributwerte und/oder die Regeln für die Verhandlung unter der Kontrolle eines Betreibers. Die Schnittstelle zur Steuerung dieser Regeln kann eine COPS-Schnittstelle zu einem SGSN sein, das diesen Satz von Regeln als eine Verfahrensweise trägt. Diese Verfahrensweise bestimmt die Reihenfolge der Verhandlung der Parameter, z.B. kann die Verkehrsklasse zuerst bestimmt werden müssen, und wie neue Attributwerte, die auf bereits verhandelten Attributwerten basieren, zu definieren sind.
  • Ein Beispiel für eine solche Regel, die von einem Betreiber gesteuert wird:
    Wenn der verhandelte Parameter 1 = {Wert 1 oder 2 oder 3 oder 4 oder subskribiert}, dann ist Parameter 2 = {festgelegter Wert; festgelegter Wert, wenn angeforderter Parameter {>; <; =}{spezifischer Wert oder subskribierter Wert} oder angeforderter Wert;...}.
  • Die Regel kann natürlich von mehr als einem Parameter abhängen, zum Beispiel wie folgt:
    Wenn der übertragene Parameter 1 = {Wert 1 oder 2 oder 3 oder 4 oder subskribiert} UND Parameter 2 = {Wert 1 oder 2 oder 3}, dann ist Parameter 3 = {festgelegter Wert; festgelegter Wert, wenn Parameter angefordert wird {>; <; =}{spezifischer Wert oder subskribierter Wert} oder angeforderter Wert;...}.
  • Der erste Parameter kann zum Beispiel die Verkehrsklasse der Übermittlung und der zweite Parameter die Zuteilungs/Zurückhaltungspriorität sein.
  • Solche Regeln ermöglichen es einem Betreiber, flexibel zu entscheiden, welcher subskribierte Teilnehmer welche QoS für welche Subskription bekommen kann, z.B. welche Verzögerung, BER, usw.
  • Das dargelegte Ziel wird ferner mit einem Netzwerkelement eines Funkzugangsnetzwerkes erreicht, welches Verarbeitungsmittel zur Bestimmung von Werten oder einer Angabe von solchen Werten von Serviceattributen umfasst, die die Quality of Service einer Übermittlung definieren, die für eine Übermittlung zu benutzen ist, die von einem Nutzergerät eines subskribierten Teilnehmers, der bei einem Funkzugangsnetzwerk registriert ist, angefordert wird. Die Verarbeitungsmittel bestimmen die Werte oder die Angabe von solchen Werten basierend auf zumindest einem zur Verfügung gestellten allgemeinen Wert von zumindest einem Serviceattribut für alle subskribierten Teilnehmer, der zumindest einer Art von Übermittlung zugewiesen werden kann, und basierend auf zur Verfügung gestellten Werten von Serviceattributen, die von einem für einen subskribierten Teilnehmer spezifischen Serviceprofil definiert sind.
  • Gemäß einem ersten Aspekt der Erfindung wird die Erfindung innerhalb eines einzigen Funkzugangsnetzwerks verwirklicht. Für diesen Aspekt kann das für einen subskribierten Teilnehmer spezifische Serviceprofil zum Beispiel in dem ersten Speichermittel eines ersten Netzwerkelements dieses Netzwerks, und die allgemeinen Werte in einem Speichermittel eines zweiten Netzwerkelements dieses Netzwerks gespeichert werden. In diesem Fall umfasst das zweite Netzwerkelement vorzugsweise darüber hinaus Regeln zur Bestimmung von Werten von Serviceattributen, die für eine von einem Nutzergerät angeforderte Übermittlung zu benutzen sind. Wie oben dargelegt können die allgemeinen Werte und/oder Regeln zur Bestimmung von Werten von Serviceattributen, die für die von dem besagten Nutzergerät angeforderte Übermittlung zu benutzen sind, ebenso von einem Betreiber des Funkzugangsnetzwerks für jede angeforderte Übermittlung zu dem Netzwerkelement geliefert werden, das die notwendige Verarbeitung durchgeführt.
  • Für diesen ersten Aspekt der Erfindung wird das erwähnte Ziel der Erfindung ebenso mit einem Funkzugangsnetzwerk erreicht, das Speichermittel zur Speicherung von für subskribierte Teilnehmer spezifischen Serviceprofilen umfasst, die Werte von zumindest einem Serviceattribut definieren, die zumindest einer Übermittlungsart zugewiesen werden können. Das vorgeschlagene Funkzugangsnetzwerk umfasst ferner Verarbeitungsmittel zur Bestimmung von Werten von Serviceattributen, die für die Übermittlung zu benutzen sind, die von einem Nutzergerät eines subskribierten Teilnehmers, der bei dem besagten Funkzugangsnetzwerk registriert ist, angefordert wird, basierend auf zumindest einem der Werte der Serviceattribute, der von einem entsprechenden für den subskribierten Teilnehmer spezifischen Serviceprofil, das in dem Speichermittel gespeichert ist, definiert ist, und auf zumindest einem zur Verfügung gestellten allgemeinen Wert von zumindest einem Serviceattribut, das zumindest einer Übermittlungsart zugewiesen werden kann. Das entsprechende für den subskribierten Teilnehmer spezifische Serviceprofil bedeutet, dass es sich um ein Serviceprofil handelt, das für den subskribierten Teilnehmer gespeichert ist, der das Nutzergerät besitzt, das die Übermittlung anfordert. Die angeforderte Übermittlung wird dann mit den bestimmten Werten der Serviceattribute durchgeführt.
  • Das Ziel wird ebenso mit einem Netzwerkelement für ein Funkzugangsnetzwerk erreicht, das Verarbeitungsmittel umfasst, die den für den ersten Aspekt der Erfindung vorgeschlagenen Verarbeitungsmitteln des Funkzugangsnetzwerks entspricht.
  • Der Einsatz der Erfindung in ihrem ersten Aspekt kann insbesondere, jedoch nicht ausschließlich, mit UMTS und GPRS (General Packet Radio Service) gesehen werden.
  • Gemäß einem zweiten Aspekt der Erfindung wird die Erfindung in zwei zusammenarbeitenden Funkzugangsnetzwerken verwirklicht. Wie für den ersten Aspekt ist der zumindest eine Wert des zumindest einen Serviceattributs, das von einem für einen subskribierten Teilnehmer spezifischen Serviceprofil definiert wird, in einem Speichermittel von einem ersten Funkzugangsnetzwerk, bei dem ein Nutzergerät registriert ist, gespeichert. Der zumindest eine gemeinsame Wert des zumindest einen Serviceattributs wird dagegen in einem zweiten Funkzugangsnetzwerk, auf das von dem besagten Nutzergerät zur Anforderung einer Übermittlung zugegriffen wird, verfügbar gemacht.
  • Für diesen zweiten Aspekt der Erfindung wird das erwähnte Ziel der Erfindung mit einem weiteren vorgeschlagenen Funkzugangsnetzwerk erreicht, in welchem es einem Nutzergerät eines subskribierten Teilnehmers, der bei einem anderen Funkzugangsnetzwerk registriert ist, gestattet wird, eine Übermittlung anzufordern. Das vorgeschlagene Funkzugangsnetzwerk umfasst Verarbeitungsmittel zur Bestimmung von Werten von Serviceattributen, die für eine von dem besagten Nutzergerät angeforderte Übermittlung zu benutzen sind, basierend auf Werten von Serviceattributen, die von einem für den subskribierten Teilnehmer spezifischen Serviceprofil definiert sind, das von dem anderen Funkzugangsnetzwerk empfangen wird, und auf zumindest einem gemeinsamen Wert von zumindest einem Serviceattribut, das den Verarbeitungsmitteln zur Verfügung gestellt wird, wobei der zumindest eine allgemeine Wert zumindest einer Übermittlungsart zugewiesen werden kann. Dieses Funkzugangsnetzwerk entspricht dem zweiten Netzwerk, das für den zweiten Aspekt der Erfindung genannt wird.
  • Das Ziel wird ebenso mit einem Netzwerkelement für ein Funkzugangsnetzwerk erreicht, in welchem es einem Nutzergerät, das bei einem anderen Funkzugangsnetzwerk registriert ist, gestattet wird, eine Übermittlung anzufordern, wobei es ein Speichermittel entsprechend dem zweiten Speichermittel und Verarbeitungsmittel entsprechend den Verarbeitungsmitteln des für den zweiten Aspekt der Erfindung vorgeschlagenen Funkzugangsnetzwerks umfasst. Die Verarbeitungsmittel des vorgeschlagenen Funkzugangsnetzwerks könnten jedoch auf mehrere Netzwerkelemente verteilt werden. Daher können die Verarbeitungsmittel des Netzwerkelements der Erfindung nur einen Teil der Funktionen der Verarbeitungsmittel des Funkzugangsnetzwerks besitzen. Insbesondere kann es ausgelegt sein, nur eine Angabe der Werte von Serviceattributen, die für die angeforderte Übermittlung von einem anderen Netzwerkelement zu benutzen sind, zur Verfügung zu stellen, anstatt die spezifischen Werte zu bestimmen. Das andere Netzwerkelement sollte dann in der Lage sein, die spezifischen Werte der angeforderten Serviceattribute gemäß der Angabe zuzuweisen und zu benutzen. Dieses Netzwerkelement ist ein Teil des genannten zweiten Funkzugangsnetzwerks.
  • Das Nutzergerät kann auf das zweite Funkzugangsnetzwerk zugreifen, entweder weil es demselben Betreiber wie das erste Funkzugangsnetzwerk gehört, oder weil die Betreiber der beiden Netzwerke ein Roaming-Abkommen haben und der subskribierte Teilnehmer, dem das Nutzergerät gehört, darüber hinaus ein Roaming-Abkommen mit dem Betreiber des Netzwerkes hat, bei dem er oder sie registriert ist. Das erste Netzwerk kann insbesondere ein öffentliches Mobilfunknetzwerk, und das zweite Netzwerk ein lokal beschränktes Netzwerk sein.
  • Der zweite Aspekt der Erfindung basiert auf der Annahme, dass Betreiber des jeweiligen ersten Funkzugangsnetzwerks in der Lage sein möchten, verschiedene Stufen von Servicequalität für verschiedene Nutzergeräte anzubieten, für die ein Roaming in das jeweilige zweite Funkzugangsnetzwerk erfolgt. Wenn zum Beispiel eine Gruppe von subskribierten Teilnehmern oder von Kunden des ersten Funkzugangsnetzwerks für einen Service mehr bezahlt als eine andere Gruppe von Kunden, um eine bessere Servicequalität zu bekommen, dann sollte diese Information in dem zweiten Funkzugangsnetzwerk verfügbar sein, um die zutreffende Servicequalität für den Kunden zur Verfügung zu stellen, auch wenn das Nutzergerät eine Übermittlung in dem zweiten Funkzugangsnetzwerk anfordert.
  • Wenn ein Nutzergerät in das zweite Funkzugangsnetzwerk roamt, muss der Betreiber des zweiten Netzwerks wissen, welche Subskriptionsart der Nutzer mit dem ersten Funkzugangsnetzwerk vereinbart hat, um in der Lage zu sein, den entsprechenden Service zur Verfügung zu stellen. Die Subskription kann Dinge einschließen, wie zum Beispiel die Abrechnung und die Quality of Service. Eine einfache Lösung würde darin bestehen, sich auf die Informationen zu verlassen, die das Nutzergerät an das zweite Netzwerk liefert: Diese würde ausschließlich auf Anwendungen basieren, die auf dem Nutzergerät laufen, und auf dem Service, den sie von dem Netzwerk aus anfordern. Wenn das Nutzergerät zum Beispiel eine Echtzeitanwendung startet, wie beispielsweise eine Voice- oder Videoanwendung, würde das Nutzergerät eine Quality of Service-Klasse mit hoher Priorität für diesen IP- (internet protocol) Fluss anfordern. Die netzwerkseitigen Quality of Service-Kontrollfunktionen würden überprüfen, ob die Anforderung akzeptiert werden kann. Ein Signalisierungsprotokoll würde die Informationen über den angeforderten Service zwischen dem Nutzergerät und den Einheiten des zweiten Netzwerks befördern. Das Problem bei dieser Lösung liegt darin, dass die Informationen, die von den Terminals ausgegeben werden, nicht notwendigerweise mit der Subskription, d.h. mit dem Service, für den der Nutzer gegenwärtig zahlt, übereinstimmen müssen.
  • Mit dem vorgeschlagenen Verfahren, dem Funkzugangsnetzwerk und dem Netzwerkelement dagegen wird das zweite Funkzugangsnetzwerk mit zuverlässigen Informationen versorgt, auf deren Basis der zutreffende Service zur Verfügung gestellt werden kann. Der Betreiber des ersten Funkzugangsnetzwerks, bei dem ein subskribierter Teilnehmer, der ein Nutzergerät benutzt, registriert ist, speichert für jeden subskribierten Teilnehmer zumindest ein für den subskribierten Teilnehmer spezifisches Serviceprofil, gemäß der Subskription des Kunden. Wenn das Nutzergerät auf das zweite Funkzugangsnetzwerk zugreift, steuern die Einheiten des zweiten Netzwerks die Services und die lokalen Netzwerkressourcen, gemäß den Informationen über das für den subskribierten Teilnehmer spezifische Serviceprofil, die von dem ersten Funkzugangsnetzwerk zur Verfügung gestellt werden. Auf diese Weise wird dem Betreiber des ersten Funkzugangsnetzwerks die Kontrolle über die Services und die Art und Weise, nach der die Services abgerechnet werden, auch bei dem zweiten Funkzugangsnetzwerk gegeben. Bei der einfachsten Vorgehensweise enthalten die für einen subskribierten Teilnehmer spezifischen Informationen nur die Nummer einer Gruppe, zu der der subskribierte Teilnehmer gehört, wobei jeder unterschiedlichen Gruppe eine unterschiedliche Quality of Service zugewiesen wird. Die allgemeinen Werte von Serviceattributen können demgegenüber lokal in dem Speichermittel des zweiten Netzwerks geführt werden, da sie von der Subskription eines spezifischen subskribierten Teilnehmers unabhängig sind.
  • Offensichtlich könnten die allgemeinen Werte jedoch ebenfalls in dem Speichermittel des ersten Funkzugangsnetzwerks gespeichert werden, und zu dem zweiten Funkzugangsnetzwerk zusammen mit den für einen subskribierten Teilnehmer spezifischen Werten übermittelt werden.
  • Bei dem zweiten Aspekt der Erfindung stellt das erste Netzwerk das gespeicherte Profil für einen subskribierten Teilnehmer dem zweiten Netzwerk vorteilhafterweise zur Verfügung, wenn ein Nutzergerät des subskribierten Teilnehmers authentifiziert wird, um zum Eintritt in das zweite Netzwerk zugelassen zu werden. Die gesamte Verarbeitung kann dann ausschließlich in dem zweiten Netzwerk ausgeführt werden, auch wenn das für einen subskribierten Teilnehmer spezifische Profil dauerhaft nur an einem Ort gespeichert ist, d.h. in Speichermitteln des Netzwerks, bei dem das Nutzergerät registriert ist.
  • Das zweite Funkzugangsnetzwerk sollte Mittel umfassen zum Abbilden der einzusetzenden Werte von Serviceattributen zu den Servicefunktionen, welche bei dem besagten zweiten Funkzugangsnetzwerk für eine angeforderte Übermittlung eingesetzt werden, da die eingesetzten Attribute nicht mit den Attributen identisch sein müssen, die bei dem ersten Funkzugangsnetzwerk eingesetzt werden. Die Abbildung sollte Folgendes berücksichtigen: die empfangenen für einen subskribierten Teilnehmer spezifischen Werte, sowie die Werte, die von dem Nutzergerät angefordert werden, und allgemeine Werte, in dem Falle, dass keine Werte von dem Nutzergerät angefordert werden oder in jedem anderen geeigneten Fall, wofür oben Beispiele gegeben wurden.
  • Der Einsatz des zweiten Aspekts der Erfindung kann insbesondere, wenn auch nicht ausschließlich, mit einem WLAN als zweites Funkzugangsnetzwerk, das ein zweites Speichermittel umfasst, gesehen werden. Das erste Funkzugangsnetzwerk, bei dem das Nutzergerät registriert ist, kann insbesondere, wenn auch nicht ausschließlich, ein 3G-Netzwerk sein.
  • Die bis jetzt behandelten Übermittlungen können insbesondere Übermittlungen von Nutzerdaten sein. Für spezifische Übermittlungen, z.B. für die signalisierenden PDP-Kontexte, wird außerdem eine weitere Vorgehensweise vorgeschlagen. Diese Vorgehensweise geht von einem Nutzergerät aus, das angibt, welche Verkehrsart es übermitteln wird. Das Nutzergerät kann z.B. einen signalisierenden PDP-Kontext anfordern, indem eine Angabe übermittelt wird, dass die angeforderte Übermittlung ein signalisierender PDP-Kontext ist. Diese Angabe besteht vorzugsweise aus der Einstellung des Wertes des QoS-Parameters SSD auf „Signalisierung", wie in dem Abschnitt „Hintergrund der Erfindung" erwähnt. Erfindungsgemäß wird ein dediziertes Serviceprofil, welches die Serviceattributwerte für die signalisierenden PDP-Kontexte definiert, in dem Netzwerk gespeichert. In dem Falle, dass eine Übermittlungsanforderung von einem Nutzergerät empfangen wird, welche anzeigt, dass die angeforderte Übermittlung ein signalisierender PDP-Kontext sein soll, kann das Netzwerk dann einfach die angeforderten Werte der Serviceattribute von dem gewidmeten Serviceprofil als Attributwerte, die für die Übermittlung zu benutzen sind, auswählen.
  • Für UMTS werden zwei unterschiedliche Ausführungsformen für diese den signalisierenden PDP-Kontext betreffende Vorgehensweise dargestellt.
  • Bei einer ersten Ausführungsform wird ein dediziertes für einen subskribierten Teilnehmer spezifisches Profil für signalisierende PDP-Kontexte als neuer Informationssatz in das HLR eingegeben. Dem Home-Betreiber wird es dadurch ermöglicht, zu spezifizieren, welche Werte von Serviceattributen jedem subskribierten Teilnehmer gestattet sind für einen signalisierenden PDP-Kontext. Die gespeicherten für einen subskribierten Teilnehmer spezifischen Serviceprofile werden von dem HLR zu dem SGSN befördert, und sie werden von dem Netzwerk eingesetzt zur Auswahl der Werte von einem Serviceattribut für eine Übermittlung, wann immer ein Nutzergerät anzeigt, dass eine angeforderte Übermittlung ein signalisierender Kontext sein soll.
  • Die erste bevorzugte Ausführungsform impliziert auch Änderungen für den SGSN. Der SGSN versucht normalerweise, das jeweilige für einen subskribierten Teilnehmer spezifische Serviceprofil für einen PDP-Kontext in einem HLR zu finden, basierend auf den folgenden Parametern: PDP-Art, PDP-Adresse und APN, die bei einer Übermittlungsanforderung von einem Nutzergerät eingeschlossen sind. Der Parameter APN wird benutzt, wenn es mehr als ein für den subskribierten Teilnehmer spezifisches Serviceprofil für die gleiche PDP-Art und die gleiche in dem HLR gespeicherte PDP-Adresse gibt. Gegenwärtig wird ein in dem HLR gespeichertes für einen subskribierten Teilnehmer spezifisches Serviceprofil mit diesen drei Parametern in eindeutiger Weise identifiziert. Mit der ersten bevorzugten Ausführungsform könnte es jedoch nun zumindest zwei für einen subskribierten Teilnehmer spezifische Serviceprofile für die gleiche PDP-Art, die gleiche PDP-Adresse und den gleichen APN geben. Der SGSN sollte daher ebenso überprüfen, welches Serviceprofil den Wert „Signalisierung" einschließt, z.B. in dem SSD. Es sollte verhindert werden, dass der SGSN das falsche Serviceprofil auswählt, weil die Serviceattribute für eine Übermittlung von Nutzerdaten für Signalisierungszwecke bei weitem nicht ausreichend sein können.
  • Darüber hinaus sollte die QoS-Parameter-Abwicklung im SGSN für die erste bevorzugte Ausführungsform geändert werden. Genauer gesagt sollte in dem Falle, dass ein signalisierender PDP-Kontext angefordert wurde, der SGSN mit Ausnahme des SDD-Wertes alle QoS-Parameterwerte von dem HLR nehmen. Ein herkömmlicher SGSN versteht den SDD-Wert „Signalisierung" nicht, sondern ändert den Wert „Signalisierung" in „unbekannt".
  • Bei der zweiten bevorzugten Ausführungsform der die Signalisierung betreffenden Vorgehensweise werden Werte von Serviceattributen eines dedizierten Serviceprofils für signalisierende PDP-Kontexte in dem SGSN gespeichert. Mit dieser Vorgehensweise können die QoS-Parameter spezifisch für den besuchten Betreiber sein.
  • Bei einer ersten Alternative dieser Vorgehensweise speichert der SGSN die Werte von allen Serviceattributen. Bei einer zweiten Alternative wird ein Teil der Serviceattributwerte in dem SGSN gespeichert und ein anderer Teil in dem Radio Network Controller (RNC). Der SGSN sollte dann die Werte für die Serviceattribute speichern, die in dem Packet Core von Bedeutung sind, z.B. die Verkehrsklasse, die maximale Bitrate, die garantierte Bitrate, die Lieferreihenfolge, die maximale Größe der SDU, die Zuteilungs/Zurückhaltungspriorität und die Verkehrsabwicklungspriorität. Der RNC sollte demgegenüber die Werte von allen Serviceattributen speichern, die in dem Funkzugangsnetzwerk RAN (Radio access network) von Bedeutung sind, z.B. die SDU-Format-Informationen, die Lieferung von fehlerhaften SDUs, die Transferverzögerung, die restliche Bitfehlerhäufigkeit und die SDU-Fehlerhäufigkeit.
  • Ein herkömmlicher SGSN kann Grundeinstellungswerte für Serviceattribute speichern. Diese Grundeinstellungswerte sind dazu bestimmt, für Übermittlungen von Nutzerdaten benutzt zu werden. Der SGSN sollte diese Grundeinstellungswerte nicht benutzen, wenn eine Anzeige auf die Signalisierung von dem Nutzergerät empfangen wird, weil die Serviceattribute für eine Übermittlung von Nutzerdaten für Signalisierungszwecke bei weitem nicht ausreichend sein können. Beim Empfangen der Anzeige über eine Signalisierung wählt der SGSN die Grundeinstellungswerte aus, die „Signalisierung" einschließen, z.B. in dem SSD.
  • Ein Beispiel von einem signalisierenden PDP-Kontext ist oben beschrieben. Der gleiche Mechanismus kann ebenso für andere Verkehrsarten benutzt werden, wenn ein Nutzergerät anzeigt, welche Verkehrsart es übermitteln will. Ein Beispiel ist die Notfall-Signalisierung, die zum Beispiel eine höhere Priorität als die herkömmliche Signalisierung benötigen kann.
  • Bevorzugte Ausführungsformen der Erfindung sind in den Unteransprüchen eingeschlossen.
  • KURZE BESCHREIBUNG DER FIGUREN
  • Die Erfindung wird im Folgenden detaillierter und unter Bezugnahme auf die Zeichnungen beschrieben werden, in welchen
  • die 1 eine Implementierung eines Verfahrens gemäß dem ersten Aspekt der Erfindung veranschaulicht;
  • die 2 ein Flussdiagramm für das Verfahren bei der Implementierung der 1 ist;
  • die 3 eine High-Level-Netzwerkarchitektur für ein WLAN-Mobilfunknetzwerk-Zusammenarbeit zeigt; und
  • die 4 eine Implementierung einer WLAN-QoS-Architektur zeigt, die bei dem zweiten Aspekt der Erfindung zu benutzen ist.
  • DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
  • Die 1 veranschaulicht das Zusammenarbeiten zwischen einem Nutzergerät NG 11, einem Serving Gateway Support Node SGSN 12 und einem Home Location Register HLR 13 eines UMTS-Netzwerkes zur Zuweisung von Werten von Serviceattributen auf eine angeforderten Übermittlung gemäß einer Implementierung des ersten Aspekts der Erfindung.
  • Ein SGSN wird bei Mobilfunknetzwerken eingesetzt, um den Standort jedes Nutzergerätes im Auge zu behalten und zur Vornahme von Sicherheitsfunktionen und der Zugangssteuerung. Bei dem SGSN 12 der 1 wird ein statisches Nichtechtzeit- und Grundeinstellungs-QoS-Profil 14 für eine zusätzliche QoS-Steuerungsfunktion gespeichert. Das Profil 14 umfasst einen einzigen Satz von allgemeinen Werten für einige NRT-Serviceattribute für alle Kunden. Genauer gesagt werden Werte für die Lieferreihenfolge, die maximale Größe der SDU, die SDU-Fehlerhäufigkeit, die restliche BER, die Lieferung von fehlerhaften SDUs und für die Zuteilungs/Zurückhaltungspriorität zur Verfügung gestellt. Diese Werte sind zu benutzen, wenn spezifische angeforderte Werte von QoS-Attributen nicht von einem Nutzergerät für eine angeforderte Nichtechtzeitübermittlung, wie zum Beispiel eine interaktive oder eine Hintergrund-Verkehrsklassenübermittlung angezeigt werden. Die gemeinsamen Werte von Serviceattributen werden auf einen guten Mittelwert einer Nichtechtzeit-QoS-Stufe eingestellt, der von den Attributwerten ausgewählt wird, die für die interaktive Verkehrsklasse verfügbar sind.
  • In dem HLR 13 wird für jeden Kunden/subskribierten Teilnehmer ein für den subskribierten Teilnehmer spezifisches Serviceprofil Max QoS gespeichert. Das Serviceprofil 15 schließt den für jedes QoS-Attribut bestmöglichen Wert ein, gemäß der Subskription des jeweiligen Kunden. Es enthält hauptsächlich die subskribierten Werte für die unterschiedlichen Attribute, die für eine Echtzeitverkehrsklasse erforderlich sind, entweder für die Konversationsklasse oder für die Streamingklasse, d.h. Werte für die maximale Bitrate, die Lieferreihenfolge, die maximale Größe der SDU, SDU-Format-Informationen, die SDU-Fehlerhäufigkeit, die restliche BER, die Lieferung von fehlerhaften SDUs, die Zuteilungs/Zurückhaltungspriorität, die Transferverzögerung und für die garantierte Bitfehlerhäufigkeit. Außerdem ist ein subskribierter Wert für die Verkehrsabwicklungspriorität für Nichtechtzeitverkehrsklassen in jedem für einen subskribierten Teilnehmer spezifischen Serviceprofil 15 in dem HLR 13 eingeschlossen.
  • Ein Nutzergerät 11, das eine Übermittlung wünscht, sendet eine Verbindungsanforderung an den SGSN 12. Darüber hinaus kann das Nutzergerät 11 ebenso gewünschte Werte von Serviceattributen an den SGSN 12 übermitteln, die für die angeforderte Übermittlung zu benutzen sind. Der Anforderung von einem Nutzergerät 11 für eine Übermittlung folgend wird das für einen subskribierten Teilnehmer spezifische Serviceprofil 15 für den Kunden, der dieses Nutzergerät besitzt, von dem HLR 13 zu dem SGSN 12 transferiert. In dem Falle, dass es in dem SGSN 12 immer noch ein vor kurzem übermitteltes Profil 15 für den Kunden gibt, der das anfordernde Nutzergerät 11 besitzt, ist eine neue Übermittlung nicht erforderlich.
  • Folglich gibt es nun bis zu drei Sätze von Serviceprofilen, die in dem SGSN 12 akkumuliert sind. Basierend auf diesen Serviceprofilen wird dann in dem SGSN 12 bestimmt, welche Werte für die unterschiedlichen Attribute, die für die angeforderte Verbindung benötigt werden, einzusetzen sind.
  • Die Auswahl der Werte von Attributen, die für die angeforderte Übermittlung zu benutzen sind, wird nun detaillierter und mit Bezug auf das Flussdiagramm der 2 erklärt.
  • Das Nutzergerät 11 kann eine Übermittlung in jeder der vier verfügbaren Übermittlungsklassen anfordern, in der Konversationsklasse, in der Streamingklasse, in der interaktiven Klasse, oder in der Hintergrundverkehrsklasse. Ferner, wie oben erwähnt, kann das Nutzergerät 11 ein gewünschtes QoS-Profil für die angeforderte Übermittlung anfordern, muss dies aber nicht.
  • Nachdem eine Übermittlungsanforderung von dem SGSN 12 angefordert worden ist, wird zunächst in dem SGSN 12 bestimmt, ob die Anforderung von dem Nutzergerät 11 eine Anforderung für ein spezifisches QoS-Profil enthält.
  • In dem Fall, dass kein spezifisches QoS-Profil von dem Nutzergerät 11 angefordert wird, wird von der Konfiguration in dem SGSN 12 überprüft, welche Werte von Attributen als Grundeinstellungsprofil für die angeforderte Verbindung zu benutzen sind. Die Konfiguration kann von dem Betreiber des Netzwerks eingestellt werden, und sie bestimmt, ob nur die Werte von Attributen, die in dem HLR 13 gespeichert sind, zu benutzen sind, oder ob eine Kombination von einigen der Werte von Attributen in dem HLR 13 und von den Werten von Attributen in dem SGSN 12 für eine spezifische angeforderte Verbindung zu benutzen sind.
  • Bei der Implementierung gemäß dem Flussdiagramm der 2 werden in dem Falle, dass das Echtzeitprofil als Grundeinstellungsprofil benutzt wird, alle Werte in dem Serviceprofil, die von dem HLR 13 empfangen werden, mit Ausnahme des VAP-Werts, ausgewählt, um für die Verbindung benutzt zu werden. Eine Echtzeit-PDP-Verbindung wird dann mit diesen Attributen aktiviert.
  • In dem Falle, dass das Nichtechtzeitprofil als Grundeinstellungsprofil benutzt wird, werden die von dem HLR 13 empfangenen Werte für die VAP und für die maximale Bitrate in dem Profil 15 ausgewählt, um als Werte der entsprechenden Attribute für die angeforderte Verbindung benutzt zu werden. Zusätzlich werden die in dem SGSN 12 gespeicherten Werte von Attributen in dem Profil 14 ausgewählt, um für die übrigen angeforderten Attribute für die Verbindung benutzt zu werden. Es wird dann eine Nichtechtzeitverbindung mit diesen kombinierten Werten von Attributen aktiviert.
  • In dem Falle, dass ein spezifisches QoS-Profil von einem Nutzergerät 11 angefordert wird, ist der Verkehr auf die subskribierten Attributstufen zu beschränken. Zu diesem Zweck wird bei einem anderen Schritt in dem SGSN 12 bestimmt, ob eine Echtzeit- oder eine Nichtechtzeitverkehrsklasse von dem Nutzergerät 11 angefordert wird.
  • In dem Falle, dass eine Echtzeitverkehrsklasse von dem Nutzergerät angefordert wird, wird in dem SGSN 12 ferner bestimmt, ob die angeforderten QoS-Werte die in dem von dem HLR 13 empfangenen Profil 15 vorherbestimmten Werte überschreiten. Wenn sie die vorherbestimmten Werte nicht überschreiten, wird mit dem angeforderten QoS-Profil eine Echtzeitverbindung aktiviert. Wenn einer der angeforderten Werte von Attributen den jeweils subskribierten Wert jedoch überschreitet, dann wird mit dem von dem HLR 13 empfangenen entsprechenden maximal subskribierten Wert die Echtzeitverbindung aktiviert.
  • In dem Falle, dass ein Nichtechtzeitverkehr von dem Nutzergerät angefordert wird, wird in dem SGSN 12 bestimmt, ob der angeforderte Wert für die VAP oder für den angeforderten maximalen Bitratenwert den jeweiligen subskribierten Wert in dem von dem HLR 13 empfangenen Profil 15 überschreitet. Wenn sie die subskribierten Werte nicht überschreiten, wird die Nichtechtzeitverbindung mit dem angeforderten QoS-Profil aktiviert. Wenn jedoch einer der angeforderten Werte den subskribierten VAP-Wert oder den maximalen Bitratenwert überschreitet, werden die überschreitenden Werte mit den entsprechenden subskribierten Werten, die von dem HLR 13 empfangen werden, ersetzt, und die Nichtechtzeitverbindung wird mit diesen ersetzten Werten aktiviert. Weitere Attribute, für die die Werte beschränkt sein müssen, könnten in der gleichen Weise behandelt werden.
  • Zusammengefasst kann das in dem ersten Speichermittel in dem HLR 13 gespeicherte QoS-Profil für den Echtzeitverkehr angepasst sein, während ein Wert eines zusätzlichen Attributes, das für den Nichtechtzeitverkehr wichtig ist, zusammen mit diesem Profil gespeichert werden kann. Wenn ein Echtzeitprofil angefordert wird, werden die Werte der angeforderten Attribute zusammengestellt, allein basierend auf den Werten in dem Profil in dem HLR 13 und möglicherweise auf angeforderten Werten. Wenn von dem Nutzergerät 11 eine Nichtechtzeitübermittlung angefordert wird, wird das QoS-Profil für diese Verbindung zusammengestellt, indem einige QoS-Attributwerte von dem ersten Speichermittel in dem HLR 13 und einige von dem zweiten Speichermittel in dem SGSN 12 benutzt werden, wobei zusätzlich eine mögliche Anforderung von Werten von dem Nutzergerät 11 berücksichtigt wird. Dadurch können die QoS des Echtzeitverkehrs und die des Nichtechtzeitverkehrs getrennt voneinander gesteuert werden.
  • Anstatt zusätzliche Werte von QoS-Attributen für Nichtechtzeitverkehr in dem HLR zu speichern, können diese Werte auf mehreren verschiedenen Wegen erhalten werden, die auf den Attributen basieren, die in dem HLR für den Echtzeitverkehr gespeichert sind. Zwei Möglichkeiten werden als weitere Ausführungsformen des ersten Aspekts der Erfindung kurz beschrieben.
  • Bei der ersten Alternative wird die Zuteilungs/Zurückhaltungspriorität in dem empfangenen HLR-Profil benutzt. Die Zuteilungs/Zurückhaltungspriorität wird in dem oben erwähnten Standard 3GPP TS 23.107 definiert als Spezifizieren „der relativen Bedeutung verglichen mit anderen UMTS-Trägern zur Zuteilung und Zurückhaltung des UMTS-Trägers. Das Attribut der Zuteilungs/Zurückhaltungspriorität ist ein Subskriptionsattribut, welches nicht mit dem mobilen Terminal verhandelt wird." Der SGSN kann das Attribut der Zuteilungs/Zurückhaltungspriorität von dem empfangenen HLR-QoS-Profil einlesen und dann von ihm den Nichtechtzeitwert für die VAP ableiten. Beide von ihnen besitzen drei Werte 1, 2 und 3.
  • Bei der zweiten Alternative wird der garantierte Bitratenwert in dem empfangenen HLR-Profil in dem SGSN evaluiert, wo ein Abbilden von gewissen Bitratenwerten auf gewisse VAP-Werte definiert wird. Zum. Beispiel kann sich ein Wert von 128 kbit/s für die garantierte Bitrate in dem HLR-Profil in der besten VAP resultieren, ein Wert von 64 kbit/s in der zweitbesten VAP, ein Wert von 32 kbit/s in der niedrigsten VAP, und ein Wert von 0 kbit/s kann in einer Behandlung als Hintergrundklasse resultieren.
  • Es würde ebenso möglich sein, ein vollständiges QoS-Profil sowohl für Echtzeitverkehr als auch für Nichtechtzeitverkehr in Speichermitteln zu speichern. Das Echtzeitprofil würde dann die angeforderten Profile für den Echtzeitverkehr limitieren und das Nichtechtzeitprofil würde die angeforderten Profile für den Nichtechtzeitverkehr limitieren. Das Nichtechtzeitprofil könnte außerdem in dem Falle, dass kein Profil von dem Nutzergerät angefordert wird, als Grundeinstellungs-QoS-Profil für das Nutzergerät benutzt werden. Dies würde bedeuten, dass das erste und das zweite Speichermittel durch ein einziges Speichermittel realisiert sind.
  • In ähnlicher Weise kann ein dediziertes QoS-Profil sogar für jede der vier Verkehrsklassen für jedes Nutzergerät in Speichermitteln des Funkzugangsnetzwerks gespeichert werden. Das Nutzergerät könnte dann zum Beispiel nur das Attribut der Verkehrsklasse definieren, und der Rest der Attributwerte würde von dem entsprechenden QoS-Profil in dem Speichermittel abgerufen werden. Die vier QoS-Profile in solchen Speichermitteln können für typische Anwendungen angepasst werden, die die in Frage stehende Verkehrsklasse benutzen. Zum Beispiel wird das QoS-Profil der Konversationsverkehrsklasse an die Bedürfnisse einer typischen VoIP- (Voice over Internet Protocol) Anwendung angepasst, das QoS-Profil der Streamingverkehrsklasse wird an das Videostreaming angepasst, das QoS-Profil der interaktiven Verkehrsklasse wird an das Webbrowsing angepasst, und das QoS-Profil der Hintergrundverkehrsklasse wird an den Best-Effort-Datentransfer angepasst. Wenn das Terminal überhaupt keine Werte von QoS-Attributen anfordert, sollten die Werte für das interaktive Profil oder für das Hintergrundprofil benutzt werden. Deswegen sind das erste und das zweite Speichermittel bei dieser Implementierung wieder durch ein einziges Speichermittel realisiert.
  • Im Falle, dass zwei oder sogar vier vollständige QoS-Profile für jedes Nutzergerät in einem kombinierten ersten und zweiten Speichermittel gespeichert werden sollen, werden diese Speichermittel am Besten in dem HLR integriert, in dem die Authentifizierungs- und die Fakturierungsinformationen für das jeweilige Nutzergerät gespeichert werden. Auf eine Übermittlungsanforderung von einem Nutzergerät hin, können dann Informationen zu einer Signalisierung von dem SGSN zu dem HLR/HSS über die Verkehrsklasse, die angefordert wird, hinzugefügt werden. Auf diesen Informationen basierend kann der HLR das richtige QoS-Profil für die Verkehrsklasse zu dem SGSN senden. Daher braucht in dem SGSN einfach das empfangene Profil angewendet zu werden. Eine andere Lösung würde darin bestehen, alle Profile zu dem SGSN in der PDP-Kontext-Aktivierung zu transferieren, wobei das richtige in dem SGSN gemäß der Anforderung von dem Nutzergerät ausgewählt wird.
  • Wie zum Hintergrund der Erfindung erwähnt, wird die Gesamt-QoS durch ein QoS-Profil definiert, das aus 12 Serviceattributen besteht. Diese Attribute haben einen beachtlichen Einfluss aufeinander. Eine zweite Ausführungsform des ersten Aspekts der Erfindung wird dargestellt, welche das Setzen von jedem der angeforderten Attribute detaillierter behandelt, auf eine Art und Weise, dass Konflikte zwischen den ausgewählten Attributen, und damit abgewiesene Übermittlungsanforderungen vermieden werden.
  • Für die zweite Ausführungsform wird wieder auf die 1 Bezug genommen, da die Grundstruktur eines Mobilfunksystems, in dem sie entworfen ist, das gleiche wie bei der ersten Ausführungsform ist. Ein Mobilfunksystem umfasst einen SGSN 12 und einen HLR 13 eines UMTS-Netzwerks und ein Nutzergerät NG 11. Das HLR 13 speichert ein für einen subskribierten Teilnehmer spezifisches QoS-Profil mit zumindest zwei unterschiedlichen QoS-Service-Attributen. Der SGSN 12 speichert außerdem allgemeine Werte von Serviceattributen. Für einen gewünschten PDP-Kontext kann das Nutzergerät 11 von dem SGSN 12 ein spezifisches QoS-Profil anfordern, bei dem jedes Serviceattribut auf einen numerischen Wert oder auf einen Grundeinstellungswert „subskribiert" eingestellt werden kann. Der SGSN 12 kann das subskribierte QoS-Profil von dem HLR 13 herunterladen, mit dem Nutzergerät 11 ein QoS-Profil verhandeln, und jeden Attributwert, der von dem HLR 13 empfangen wird oder in dem SGSH 12 gespeichert ist als Grundeinstellungswert, Maximalwert oder Minimalwert interpretieren. Zu diesem Zweck werden mehrere Regeln in dem SGSN 12 implementiert, die die Bestimmung aller Attributwerte gestatten, die für einen angeforderten PDP-Kontext benötigt werden können. Die Regeln schließen ebenfalls die Reihenfolge, in dem die Attributwerte bestimmt werden. Alternativ sind diese Regeln in dem SGSN 12 nicht fest codiert, sondern unter der Kontrolle eines Betreibers eines Mobilfunksystems, wobei der Betreiber den SGSN 12 über eine COPS-Schnittstelle mit den Regeln versorgt.
  • Das erste Serviceattribut, das gemäß den in dem SGSN 12 implementierten Regeln zu bestimmen ist, ist die Verkehrsklasse. Der jeweilige Wert des ersten Attributs gibt die Art der Anwendung an, für die der eingesetzte Radio Access Bearer-(RAB) Service optimiert ist. Mögliche Werte sind „Konversationsklasse", „Streamingklasse", „interaktive Klasse" oder „Hintergrundklasse". Die Verkehrsklasse sollte zuerst bestimmt werden, da sie die Verkehrsart angibt, und daher dazu erforderlich ist, ein korrektes Einstellen der anderen Attribute zu gestatten. In dem Falle, dass das Nutzergerät 11, das einen PDP-Kontext anfordert, einen spezifischen Wert für dieses Attribut anfordert, wird der verhandelte Wert der Wert sein, der von dem Nutzergerät 11 gesendet wird, wenn dieser Wert kleiner als oder gleich dem subskribierten Wert ist. In dem Falle, dass der von dem Nutzergerät 11 gesendete Wert „subskribiert" ist, wird die subskribierte Verkehrsklasse, die in dem HLR 13 eingestellt ist, als verhandelter Wert benutzt. In dem Falle jedoch, dass das Nutzergerät 11 einen höheren Wert als den subskribierten Wert anfordert, wird der subskribierte Wert als verhandelter Wert benutzt.
  • Ein zweites einzustellendes Serviceattribut ist die maximale Bitrate, die für Uplink- und Downlink-Übermittlungen, jeweils in kbit/s, gestattet ist. Es gibt die maximale Anzahl von Bits an, die durch UTRAN und zu UTRAN an einem Service Access Point (SAP) innerhalb einer Zeitperiode geliefert werden, geteilt durch die Dauer der Periode. In beiden Fällen ist der verhandelte Wert der von dem Nutzergerät 11 angeforderte Wert, sofern vorhanden, in dem Falle, dass dieser Wert kleiner als oder gleich dem jeweiligen subskribierten Wert ist. In dem Falle, dass der von dem Nutzergerät 11 gesendete Wert „subskribiert" ist, wird die jeweilige subskribierte maximale Bitrate, die in dem HLR 13 eingestellt ist, als verhandelter Wert benutzt. In dem Falle, dass das Nutzergerät 11 einen Wert anfordert, der höher als die jeweilige subskribierte maximale Bitrate ist, wird der subskribierte Wert als verhandelter Wert benutzt.
  • Ein drittes angefordertes Serviceattribut ist die garantierte Bitrate für Uplink- und Downlink-Übermittlungen in kbit/s. Es gibt die garantierte Anzahl von Bits an, die an einem SAP innerhalb einer Zeitperiode geliefert werden, geteilt durch die Dauer der Periode. Die Bestimmung des zu benutzenden Attributwertes entspricht der Bestimmung des Wertes für die ersten zwei Serviceattribute. Das heißt für die garantierte Bitrate in beiden Richtungen, ist der verhandelte Wert der von dem Nutzergerät 11 angeforderte Wert, sofern vorhanden, in dem Falle, dass dieser Wert kleiner als oder gleich dem jeweiligen subskribierten Wert ist. In dem Falle, dass der von dem Nutzergerät 11 gesendete Wert „subskribiert" ist, wird die jeweilige subskribierte garantierte Bitrate, die in dem HLR 13 eingestellt ist, als verhandelter Wert benutzt. In dem Falle, dass das Nutzergerät 11 einen Wert anfordert, der höher als die jeweilige subskribierte garantierte Bitrate ist, wird der subskribierte Wert als verhandelter Wert benutzt. Es ist jedoch keine garantierte Bitrate zu bestimmen, wenn die übertragene Verkehrsklasse eine „interaktive Klasse" oder eine „Hintergrundklasse" ist.
  • Das vierte einzustellende Serviceattribut ist die Lieferreihenfolge, die angibt, ob der RAB eine In-Reihenfolge SDU-Lieferung zur Verfügung stellen soll oder nicht. Es kann den Wert „Ja" oder „Nein" haben. Bei dem ersten 3G-Release ist dieser Parameter immer auf „Nein" eingestellt. In der Zukunft jedoch, falls und wenn eine Nutzung für dieses Attribut gefunden wird, sollte es dem Prinzip folgen, das für die ersten drei Serviceattribute angegeben ist, d.h. der verhandelte Wert ist entweder der von dem Nutzergerät 11 angeforderte Wert oder die subskribierte Lieferreihenfolge, die in dem HLR 13 eingestellt ist.
  • Das fünfte einzustellende Serviceattribut ist die maximale Größe der SDU in Oktetten, die die maximal zulässige SDU-Größe anzeigt. In dem Falle, dass das Nutzergerät 11 einen Wert sendet, der von dem für dieses Attribut subskribierten Wert abweicht, wird dieser angeforderte Wert als verhandelter Parameter benutzt. In dem Falle, dass das Nutzergerät 11 den „subskribierten" Wert anfordert, und in dem Falle, dass darüber hinaus die verhandelte Verkehrsklasse der subskribierten Verkehrsklasse entspricht, wird die subskribierte maximale SDU-Größe benutzt. Andernfalls wird die maximale Größe der SDU auf den subskribierten Wert oder auf 1500 Oktette eingestellt, je nach dem welcher Wert größer ist. Der Grund für die zuletzt genannte Regel besteht darin, dass die Konversationsverkehrsklasse zusammen mit einer kleineren maximalen SDU-Größe subskribiert sein kann, welche für Sprache optimiert ist. Jedoch würde eine Erzwingung dieses kleinen Wertes für andere Klassen außer der subskribierten Konversationsverkehrsklasse, wie zum Beispiel die „Streamingklasse", z.B. für Videoframes, die „interaktive Klasse", z.B. für Webbrowsing, oder die „Hintergrundklasse", z.B. für das Herunterladen von Dateien, keinen Sinn haben. Wenn die PDP-Art PPP benutzt wird, wird die passende SDU-Größe von 1502 Oktetten, welche größer als 1500 ist, automatisch von dem HLR 13 genommen werden.
  • Es ist anzumerken, dass der subskribierte Wert für dieses Serviceattribut nicht als Maximalwert benutzt werden muss, d.h. der verhandelte Wert muss nicht kleiner als der subskribierte Wert sein.
  • Das sechste einzustellende Serviceattribut ist die SDU-Format-Information in Bits. Es enthält die Liste von möglichen exakten Größen von SDUs und/oder von RAB-Subflow-Combination-Bitraten. In den zitierten Spezifikationen kann ein Wert für diesen Parameter weder von einem Nutzergerät 11 angefordert werden, noch kann er in dem HLR 13 konfiguriert werden. Wenn dieses Serviceattribut später als ein normales QoS-Serviceattribut hinzugefügt wird, wird vorgeschlagen, dass der von dem Nutzergerät 11 angeforderte Wert als verhandelter Wert benutzt wird. Nur wenn das Nutzergerät 11 den „subskribierten" Wert anfordert, wird die subskribierte SDU-Format-Information in dem Falle als verhandelter Wert benutzt, falls die verhandelte Verkehrsklasse der subskribierten Verkehrsklasse entspricht. Es wird keine SDU-Format-Information bestimmt, falls die verhandelte Verkehrsklasse eine „interaktive Klasse" oder eine „Hintergrundklasse" ist.
  • Das siebte einzustellende Serviceattribut ist die Lieferung von fehlerhaften SDUs, welches angibt, ob die SDUs mit festgestellten Fehlern geliefert werden sollten oder nicht. Es kann die Werte „Ja", „Nein" und „Keine Fehlererfassungsberücksichtigung" annehmen. Ein von dem Nutzergerät 11 angeforderter Wert, der von dem „subskribierten" Wert abweicht, wird für diesen Parameter verwendet. In dem Falle, dass das Nutzergerät 11 den „subskribierten" Wert anfordert, und falls die verhandelte Verkehrsklasse der subskribierten Verkehrsklasse entspricht, wird der Wert benutzt, der für die Lieferung von fehlerhaften SDUs subskribiert ist. Andernfalls wird der Parameter auf „Nein" eingestellt. Es ist anzumerken, dass der subskribierte Wert nicht als Maximalwert behandelt wird.
  • Das achte einzustellende Serviceattribut ist die SDU-Fehlerhäufigkeit. Es gibt den Anteil von verloren gegangenen oder von als fehlerhaft erfassten SDUs an. Wenn das Nutzergerät 11 einen besonderen numerischen Wert für dieses Attribut anfordert, vergleicht der SGSN 12 den angeforderten Wert mit dem statischen Bereich von Werten, der für die verhandelte Verkehrsklasse zugelassen ist. Der jeweilige Bereich wird durch einen Minimalwert und durch einen Maximalwert definiert, die als gemeinsame Serviceattributwerte in dem SGSN 12 gespeichert sind. Wenn der angeforderte Attributwert nicht innerhalb dieses Bereiches liegt, wird der angeforderte Attributwert durch den Maximalwert oder durch den Minimalwert dieses Bereiches ersetzt. Für die Konversationsverkehrsklasse und für die Streamingverkehrsklasse könnte der Bereich z.B: von 10–4 bis 10–1 reichen. Für die Hintergrundverkehrsklasse und für die interaktive Verkehrsklasse könnte der Bereich z.B. von 10–6 bis 10–3 reichen. Wenn das Nutzergerät 11 den „subskribierten" Wert sowohl für die SDU-Fehlerhäufigkeit als auch für die Verkehrsklasse anfordert, wird der subskribierte Wert von dem HLR 13 abgerufen. Aber es wird ebenso überprüft, ob dieser Wert im zulässigen Wertbereich liegt, der in dem SGSN 12 gespeichert ist. Wenn das Nutzergerät 11 den „subskribierten" Wert für die SDU-Fehlerhäufigkeit und einen anderen als den „subskribierten" Wert für die Verkehrsklasse anfordert, dann wird für die SDU-Fehlerhäufigkeit ein für die Verkehrsklasse spezifischer „Grundeinstellungs-" wert benutzt. Dieser Grundeinstellungswert ist ebenso in dem SGSN 12 als ein gemeinsamer Serviceattributwert gespeichert.
  • Es ist anzumerken, dass das Serviceattribut „SDU-Fehlerhäufigkeit" immer dann nicht erforderlich ist, wenn das Serviceattribut Lieferung von fehlerhaften SDU auf „Keine Fehlererfassungsberücksichtigung" eingestellt ist.
  • Das neunte einzustellende Serviceattribut ist die restliche Bitfehlerhäufigkeit, die die nicht erfasste Bitfehlerhäufigkeit für jeden Subflow in der gelieferten SDU angibt. Die restliche Bitfehlerhäufigkeit wird in ähnlicher Weise bestimmt, wie die SDU-Fehlerhäufigkeit. Daher vergleicht der SGSN 12 den angeforderten Wert mit dem statischen Bereich von Werten, der für die verhandelte Verkehrsklasse zugelassen ist, wenn das Nutzergerät 11 einen besonderen numerischen Wert für die restliche Bitfehlerhäufigkeit anfordert. Der jeweilige Bereich wird ebenfalls durch einen Minimalwert und einen Maximalwert definiert, die als gemeinsame Serviceattributwerte in dem SGSN 12 gespeichert sind. Wenn der angeforderte Attributwert nicht innerhalb dieses Bereiches liegt, wird der angeforderte Parameterwert durch den Maximalwert oder durch den Minimalwert dieses Bereiches ersetzt. Für die Konversationsverkehrsklasse und für die Streamingverkehrsklasse könnte der Bereich z.B. von 10–5 bis 10–2 reichen. Für die Hintergrundklasse und für die interaktive Klasse könnte der Bereich z.B. von 10–8 bis 10–3 reichen. Wenn das Nutzergerät 11 den „subskribierten" Wert sowohl für die restliche Bitfehlerhäufigkeit als auch für die Verkehrsklasse anfordert, wird der subskribierte Wert von dem HLR 13 abgerufen. Aber es wird ebenso überprüft, ob dieser Wert in dem zulässigen Wertbereich liegt, der in dem SGSN 12 gespeichert ist. Wenn das Nutzergerät 11 den „subskribierten" Wert für die restliche Bitfehlerhäufigkeit und einen anderen als den „subskribierten" Wert für die Verkehrsklasse anfordert, dann wird für die restliche Bitfehlerhäufigkeit ein für die Verkehrsklasse spezifischer „Grundeinstellungs-" wert benutzt. Dieser Grundeinstellungswert wird ebenso in dem SGSN 12 als ein gemeinsamer Serviceattributwert gespeichert.
  • Das zehnte einzustellende Serviceattribut ist die Transferverzögerung in ms. Es gibt die maximale Verzögerung für das 95. Perzentil der Verzögerungsverteilung für alle gelieferten SDUs während der Lebenszeit eines RAB an, wobei die Verzögerung für eine SDU als die Zeit von einer Anforderung eines Transfers einer SDU an einem SAP bis zu seiner Lieferung an den anderen SAP definiert ist. Wenn die verhandelte Verkehrsklasse die „interaktive Klasse" oder die „Hintergrundklasse" ist, wird dieses Attribut ignoriert. Ein von dem Nutzergerät 11 angeforderter Wert wird in dem Falle, dass dieser Wert kleiner als oder gleich dem subskribierten Wert ist, als verhandelter Wert benutzt. Wenn das Nutzergerät 11 den „subskribierten" Wert anfordert oder einen Wert, der größer als der subskribierte Wert ist, wird die subskribierte Transferverzögerung als verhandelter Wert benutzt, falls außerdem die verhandelte Verkehrsklasse der subskribierten Verkehrsklasse entspricht oder wenn sie die Konversationsklasse ist. Andernfalls in dem Falle, dass die verhandelte Klasse die Streamingklasse ist, wird die Transferverzögerung auf 250 ms oder auf den subskribierten Wert eingestellt, wenn der subskribierte Wert höher als 250 ms ist, was in Abhängigkeit von dem RNC zu überprüfen ist.
  • Bei einer ausgeklügelteren Vorgehensweise könnte ebenso die SDU-Fehlerhäufigkeit berücksichtigt werden, wenn ein Wert für die Transferverzögerung bestimmt wird.
  • Das elfte einzustellende Serviceattribut ist die Verkehrsabwicklungspriorität. Sie spezifiziert die relative Bedeutung für die Abwicklung von allen SDUs, die zu dem RAB gehören, verglichen mit den SDUs von andern Trägern. Dieses Attribut ist nur für die interaktive Verkehrsklasse gültig. Wenn für diesen Parameter von dem Nutzergerät 11 ein Wert angefordert wird, der größer als der subskribierte Wert ist, wird der angeforderte Wert als verhandelter Wert benutzt. Andernfalls wird der subskribierte Wert benutzt, wenn er für dieses Nutzergerät 11 in dem HLR 13 vorhanden ist. Wenn er nicht in dem HLR 13 vorhanden ist, wird der Wert des Attributs „Verkehrsabwicklungspriorität" auf einen Wert eingestellt, der für das Serviceattribut „Zuteilungs/Zurückhaltungspriorität" benutzt wird.
  • Die Zuteilungs/Zurückhaltungspriorität als zwölftes Serviceattribut wird nicht mit dem Nutzergerät 11 verhandelt. Vielmehr wird der in dem HLR 13 gespeicherte subskribierte Wert zu dem RNC und einem GGSN (Gateway General Packet Radio System Support Node) übermittelt. Dieser Parameter spezifiziert die relative Bedeutung, verglichen mit anderen RABs zur Zuteilung und Zurückhaltung des RAB.
  • Die oben erwähnte Spezifikation 25.413 definiert zusätzliche Parameter, die der Zuteilungs/Zurückhaltungspriorität untergeordnet sind. Einer dieser zusätzlichen Parameter ist die Präemptionsfähigkeit, die die Präemptionsfähigkeit der Anforderung auf andere RABs angibt. Ein anderer Parameter ist die Präemptionsverletzbarkeit, welche die Verletzbarkeit des RAB auf die Präemption von anderen RABs angibt. Eine einfache Regel zur Beachtung dieser Parameter besteht darin, niemals die Präemption zu benutzen.
  • Die Zuteilungs/Zurückhaltungspriorität ist mit der jeweiligen Subskription eines Nutzergeräts verbunden, und auf deren Werte wird manchmal Bezug genommen als 1 = Gold, 2 = Silber und 3 = Bronze. Basierend auf diesen Werten wird als eine fortschrittlichere Regel vorgeschlagen, die Präemptionsfähigkeit auf den Wert „Präemption kann eingeleitet werden" einzustellen, wenn die Zuteilungs/Zurückhaltungspriorität gleich 1 ist, und andernfalls auf den Wert „Präemption sollte nicht eingeleitet werden". Darüber hinaus wird vorgeschlagen, die Präemptionsverletzbarkeit auf den Wert „Präemption möglich" einzustellen, wenn die Zuteilungs/Zurückhaltungspriorität gleich 3 ist, und andernfalls auf den Wert „Präemption nicht möglich".
  • Es ist wichtig, anzumerken, dass einige in dem RANAP (Radio Access Network Application Part) der technischen Spezifikation 3GPP 25.413 V3.4.0 (2000-12): „3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu Interface RANAP Signaling (Veröffentlichung 1999)" definierten Parameter nicht von dem Nutzergerät 11 verhandelt werden können oder in dem HLR 13 eingestellt werden können. Daher wird in einer erweiterten Ausführungsform für die RANAP-Signalisierung gemäß der Spezifikation 25.413 vorgeschlagen, den Parameter „Source Statistics Descriptor", der Merkmale der Quelle der bereitgestellten SDUs spezifiziert, für die Verkehrsklassen „Konversationsklasse" und „Streamingklasse" stets auf „unbekannt" einzustellen. Darüber hinaus wird vorgeschlagen, den Parameter „Relokalisierungsanforderung", der spezifiziert, auf welche Weise der Radio Access Bearer im Falle der Relokalisierung behandelt werden soll, stets auf „keine" einzustellen. Der Parameter „Queuing gestattet", der angibt, ob die Anforderung in eine Ressourcen-Zuteilungswarteschlage platziert werden kann oder nicht, wird stets auf „Queuing gestattet" eingestellt. Diese drei Parameter werden auch als Parameter definiert, die dem Zuteilungs/Zurückhaltungsattribut untergeordnet sind. Außerdem sollte der Parameter „SDU-Format-Information" nicht bei dieser erweiterten Ausführungsform eingeschlossen werden.
  • Die 3 zeigt eine High-Level-Netzwerkarchitektur für ein Zusammenarbeiten von einem WLAN und einem Mobilfunknetzwerk, wobei für die Architektur eine Implementierung des zweiten Aspekts der Erfindung einzusetzen ist.
  • In der 3 ist ein WLAN 32 mit zwei Zugangspunkten 33 dargestellt. Das WLAN 32 ist über einen Public Access Controller (PAC) 34 mit einem öffentlichen IP-Netzwerk 35 verbunden, und ferner über ein Gateway 36 mit einem öffentlichen Mobilfunknetzwerk 37, genauer gesagt mit einem GSM-Netzwerk, verbunden. Das Mobilfunknetzwerk 37 umfasst mehrere Home Register- und Fakturierungsserver 38, von denen einer gezeigt ist. Das WLAN 32 ist bei einem drahtlosen Hotspot lokalisiert und es wird von einem privaten Eigentümer zur Verfügung gestellt. Der Betreiber des Mobilfunknetzwerks 37 hat ein Roaming-Abkommen mit dem Betreiber des WLAN 32.
  • Ein mobiles Terminal 31 mit einem SIM (GSM Subscriber Identification Module) ist in dem Zugangsbereich des WLAN 32 lokalisiert. Das Terminal 31 ist mit dem Mobilfunknetzwerk 37 registriert. Die Authentifizierungs- und die Fakturierungsinformationen für das Terminal 31 sind in dem dargestellten Home Register- und Fakturierungsserver 38 gespeichert. Entsprechende Informationen sind in dem SIM des Terminals 31 gespeichert. Das Terminal 31 hat ein WLAN-Roaming-Abkommen mit dem Betreiber des Mobilfunknetzwerks 37.
  • Die Authentifizierungs- und die Fakturierungsinformationen für das Terminal 31, das auf das WLAN 32 zugreift, werden über das Gateway 36 zwischen dem WLAN 32 und dem Mobilfunknetzwerk 37 übermittelt. Proprietäre Protokolle kümmern sich um die Signalisierung zwischen den verschiedenen Netzwerkelementen. Mögliche Details eines Authentifizierungsmechanismus sind z.B. in der gleichzeitig anhängigen US-Patentanmeldung mit dem Titel „Authentication in a packet data network" von Jyri Rinnemaa et al., angemeldet am 31. März 2000, dargestellt.
  • Der zweite Aspekt der Erfindung stellt eine Möglichkeit dar, ein Terminal 31, das bei dem Mobilfunknetzwerk 37 registriert ist, auch in dem WLAN 32 mit der Quality of Service zu versorgen, die mit dem Betreiber des Mobilfunknetzwerks 37 vereinbart wurde.
  • Die 4 veranschaulicht, wie die Serviceprofilinformationen in den Home Register- und Fakturierungsservern 38 der Architektur der 3 mit einer spezifischen WLAN-QoS-Architektur gemäß dem zweiten Aspekt der Erfindung kombiniert werden kann.
  • Die QoS-Architektur auf der WLAN-Seite schließt den PAC 34 des WLAN 32, einen Zugangspunkt (AP: Access Point) 33 des WLAN 32 und ein mobiles Terminal 31 ein. Der PAC 34 ist die Schnittstelle des WLAN 32 zu dem Mobilfunknetzwerk 37, und der Zugangspunkt 33 stellt einen Zugang zu dem WLAN 32 für das mobile Terminal 31 zur Verfügung.
  • Der PAC 34 hat einerseits eine Physical Layer Verbindung PHY zu dem Mobilfunknetzwerk 37 und andererseits eine Ethernet-Verbindung zu dem ZP 33. Außerdem umfasst er eine IP-verarbeitende Dateneinheit mit einer IP-Paket-Klassifizierungsfunktion. Ferner werden eine PCF (Point Coordination Function) Control Protocol (PCP)-Einheit, eine QoS-Steuereinheit und eine PAC-Cell Einheit zur Verfügung gestellt. In der QoS-Steuereinheit ist ein Grundeinstellungs-QoS-Profil gespeichert.
  • Der AP 33 umfasst einerseits die erwähnte EthernetVerbindung mit dem PAC 34 und andererseits eine IEEE 802.11 PCF-Verbindungsoption zu mobilen Terminals. Genau wie der PAC 34 besitzt er darüber hinaus eine IP-verarbeitende Einheit und eine PCP-Einheit für eine entsprechende Kommunikation mit dem PAC 34.
  • Das mobile Terminal 31 umfasst schließlich eine 802.11 PCF-Verbindungsoption zu dem AP 33, und eine IP-verarbeitende Einheit mit einer IP-Paket-Klassifizierungsfunktion und eine QoS-Steuerungseinheit für die Kommunikation mit der entsprechenden Dateneinheit des PAC 34.
  • Die Steuerung der QoS von Downlink-Übermittlungen, die mit der vorliegenden Architektur bereitgestellt wird, werden nun beschrieben.
  • Das mobile Terminal 31 ist bei dem Mobilfunknetzwerk 37 registriert. Ergänzend zu den Authentifizierungsinformationen ist ein Serviceprofil in einem spezifischen Home Register- und Fakturierungsserver 38 des Mobilfunknetzwerks 37 gespeichert. Das Serviceprofil basiert auf Subskriptionsinformationen, die der Nutzer des mobilen Terminals 31 mit dem Betreiber des Mobilfunknetzwerks 37 für angeforderte Übermittlungen vereinbart hat. Die aktuellen Attribute, für die Werte in dem Serviceprofil umfasst sind, werden von dem Betreiber bestimmt. Es kann zum Beispiel die maximalen QoS-Werte enthalten, die von einem spezifischen Terminal 31 angefordert werden können.
  • Das mobile Terminal 31 roamt in das WLAN 32, das in der Lage ist, Breitbandübermittlungen für Terminals 31 zur Verfügung zu stellen, die ein Roaming-Abkommen mit dem Betreiber des Mobilfunknetzwerks haben. Zunächst findet eine Authentifizierung des Terminals 31 statt, basierend auf den Authentifizierungsinformationen, die in dem SIM des Terminals 31 und in dem Home Register- und Fakturierungsserver 38 des Mobilfunknetzwerks 37 gespeichert sind. Zur gleichen Zeit wird das subskribierte Serviceprofil von dem Home Register- und Fakturierungsserver 38 des Mobilfunknetzwerks 37 zu dem PAC 34 des WLAN 32 übermittelt. Die PAC-Cell Einheit des PAC 34 wird als Steuerungsprotokoll zwischen dem PAC 34 und einem Gateway in dem Mobilfunknetzwerk 37 benutzt. Sie wird zur Übermittlung von Signalisierungsnachrichten von dem WLAN 32 zu dem Mobilfunknetzwerk 37 und umgekehrt benutzt. Zum Beispiel werden die Nutzerauthentifizierungsnachrichten von diesem Protokoll getragen. Basierend auf dem empfangenen Serviceprofil konstruiert der PAC 34 eine IP-Paket-Filtertabelle und hält diese aufrecht, die Filterinformationen für alle IP-Flüsse oder Nutzer, die Nicht-Grundeinstellungs-QoS anfordern, enthält. Das bedeutet, dass die IP-Paket-Filter in dynamischer Art und Weise eingestellt werden. Die IP-Paket-Filter können ergänzend auf von dem Terminal 31 gesendete Anforderungen basiert werden, welche anfordern, gewisse IP-Flüsse zu priorisieren. Insbesondere wenn die Flüsse in dynamischer Art und Weise mit dynamischen UDP/TCP-Anschlüsse kreiert werden, ist es nicht möglich, die IP-Paket-Filtertabelle im Voraus festzulegen. Das Terminal sendet die Anforderungen, indem das QoS-Kontrollprotokoll benutzt wird.
  • Wenn eine Downlink-Übermittlung mit einer spezifischen QoS von dem Terminal 31 angefordert wird, sind die angeforderten Serviceprofilinformationen auf die WLAN-QoS-Klassen abzubilden, die für Übermittlungen in dem WLAN 32 definiert sind. Die Zur-Verfügung-Stellung eines spezifischen QoS wird von den QoS-Steuereinheiten in dem mobilen Terminal 31 und in dem PAC 34 gesteuert. Der Header von jedem von dem PAC 34 empfangenen Downlink-IP-Paket enthält Informationen, die eine für die Übermittlung der IP-Pakete angeforderte QoS angeben. Jedes Downlink-IP-Paket wird daher in der IP-Dateneinheit des PAC 34 verarbeitet, um die richtige WLAN-QoS-Klasse, die für die IP-Pakete zu benutzen ist, zu bestimmen. Genauer gesagt, wird der Header von jedem IP-Paket verarbeitet, und basierend auf den Header-Informationen und auf den IP-Paket-Filter-Informationen wird das Paket für eine gewisse WLAN-QoS-Klasse eingeplant.
  • Nachdem der PAC 34 die IP-Pakete klassifiziert hat wird die QoS-Klasse, z.B. Echtzeit oder Nichtechtzeit, bestimmt. Der PAC 34 markiert die Downlink-IP-Pakete gemäß der Klassifizierung, indem 802.1p Bits benutzt werden. Die p-Bits sind ein Teil des Ethernetframeheaders und sie können daher zur Markierung von verschiedenen QoS-Klassen auf dem Ethernet-Level benutzt werden.
  • Wenn von dem Terminal 31 eine Downlink-Übermittlung ohne eine spezifische QoS angefordert wird, können die p-Bits gemäß dem gespeicherten Grundeinstellungsprofil markiert werden, wenn die empfangenen IP-Pakete klassifiziert wurden.
  • Die markierten IP-Pakete werden über Ethernet von dem Zugangspunkt 33 empfangen, welcher dazu ausgelegt ist, in der Lage zu sein, die 802.1p Bits einzulesen und die verschiedenen QoS-Klassen und die entsprechenden p-Bit-Muster zu verstehen. Der AP 33 ist dadurch in der Lage, die Downlink-Pakete gemäß den 802.1p Bits einzuplanen, während keine IP-Paket-Verarbeitung der Nutzdaten in dem AP 33 erforderlich ist. Die IP-Pakete werden einfach von den Ethernetframes zu der Warteschlange der richtigen WLAN-QoS-Klasse gemappt.
  • Ergänzend wird ein PCP zwischen dem PAC 34 und dem AP 33 eingesetzt, zur Steuerung der Übermittlung zwischen dem AP 33 und dem mobilen Terminal 31 von den 802.11-Verbindungen. Das QoS-Kontrollprotokoll in dem PAC 34 benutzt PCP, um die PCF-Funktion in dem AP 33 zu steuern, d.h. um die PCF-Aufrufliste auf den neuesten Stand zu bringen.
  • Die WLAN-QoS-Steuerungsfunktionen in der QoS-Steuereinheit des PAC 34 kümmern sich um die IP-Paket-QoS, sowie um die Funkverbindungspaketablaufplanung. Ferner können die QoS-Steuerungsfunktionen eine Schnittstelle zu den Steuerungsprotokollen auf der Anwenderebene haben, wie zum Beispiel SIP und H.323, um in der Lage zu sein, Informationen von gewissen IP-Flüssen und ihren QoS-Anforderungen zu empfangen. SIP ist ein SMDS- (Switched Multimegabit Data Services) Schnittstellenprotokoll, und H.323 ist ein ITU-T-Satz von Standards für paketbasierte Multimedianetzwerke, die VoIP-Services zulassen, um eine Verbindung mit herkömmlichen leitungsvermittelten Voice-Netzwerken herzustellen. Die Informationen des für einen subskribierten Teilnehmer spezifischen Serviceprofils, die von dem Mobilfunknetzwerk 37 empfangen werden, können zur Priorisierung von gewissen Nutzergeräten oder von gewissen Anwendungen benutzt werden, oder sie können als Eingabe für die Zulassungssteuerungsfunktion benutzt werden.
  • Während die Downlink-Paket-Klassifizierung in dem PAC 34 des WLAN 32 durchgeführt wird, findet die Uplink-Paket-Klassifizierung in der IP-Einheit des mobilen Terminals 31 statt.
  • Daher kann der Betreiber des Mobilfunknetzwerks Serviceprofile für Nutzer definieren, die ein WLAN-Roaming-Abkommen mit dem Betreiber haben. Die WLAN-Einheiten steuern den Zugang zu lokalen und externen Netzwerk-Ressourcen, gemäß den in dem Mobilfunknetzwerk definierten Informationen des für einen subskribierten Teilnehmer spezifischen Serviceprofils. Auf diese Weise kann der Betreiber des Mobilfunknetzwerks die Kontrolle haben über die Services und die Art und Weise, nach der die Services berechnet werden, wenn Nutzer in WLAN-Hotspots roamen.
  • Als eine Alternative zu der unter Bezugnahme auf die 4 beschriebenen QoS-Steuerung kann ein einfacher Verkehrssteuerungsmechanismus in dem PAC 34 implementiert werden. Zu diesem Zweck wird eine gewisse Verkehrsmenge, die einem Nutzer gestattet wird zu empfangen, als ein Wert eines der Attribute in dem Serviceprofil, das der PAC 34 von dem Mobilfunknetzwerk 37 während der Authentifizierung empfängt, gespeichert. Der PAC 34 kann dann den Downlink-Verkehr der Nutzer gemäß der zulässigen Verkehrsmenge steuern. Die Nutzer können zum Beispiel in drei Gruppen kategorisiert werden, wobei jede Gruppe ein gewisses Verkehrslimit mit einem gewissen Preis hat. Wenn ein Nutzer dieses Verkehrslimit überschreitet, beginnt der PAC 34 mit dem Absenken des überschüssigen Verkehrs. Dies ist ein einfacher Mechanismus, der zur Priorisierung von verschiedenen Nutzern benutzt werden kann.

Claims (38)

  1. Verfahren zur Zuweisung von Werten von Dienstattributen, die eine Dienstgüte einer Übermittlung definieren, zu Übermittlungen zwischen einem Nutzergerät (11, 31) und einem Funkzugangsnetzwerk (32), welches auf Anforderung einer solchen Übermittlung hin durch ein Nutzergerät (11, 31) eines Teilnehmers, der bei einem Funkzugangsnetzwerk (37) registriert ist, ein Bestimmen von Werten von Dienstattributen umfasst, die für die von dem besagten Nutzergerät (11, 31) angeforderte Übermittlung zu benutzen sind, dadurch gekennzeichnet, dass die besagten Werte von Dienstattributen, die für die Übermittlung benutzt werden sollen, basierend auf zumindest einem Wert von zumindest einem Dienstattribut, der durch ein gespeichertes, teilnehmerspezifisches Diensteprofil (15) definiert wird, und basierend auf zumindest einem gemeinsamen Wert von zumindest einem Dienstattribut für alle Teilnehmer, bestimmt werden.
  2. Verfahren nach Anspruch 1, wobei die Werte der Dienstattribute, die für die angeforderte Übermittlung benutzt werden sollen, darüber hinaus basierend auf Werten von Dienstattributen, die von dem Nutzergerät (11, 31) angefordert werden, bestimmt werden.
  3. Verfahren nach Anspruch 1 oder 2, wobei die Werte der Dienstattribute, die durch ein teilnehmerspezifisches Diensteprofil (15) und durch die gemeinsamen Werte der Dienstattribute definiert sind, die Dienstgüte einer Übermittlung definieren.
  4. Verfahren nach einem der vorherigen Ansprüche, wobei die Werte der Dienstattribute, die durch ein teilnehmerspezifisches Diensteprofil (15) definiert sind, Minimalwerte und/oder Maximalwerte bestimmen, die für die Dienstattribute für zumindest eine Übermittlungsart, so wie sie durch das entsprechende Nutzergerät (11, 31) subskribiert wurde, zugelassen sind.
  5. Verfahren nach einem der vorherigen Ansprüche, wobei die Werte der Dienstattribute in einem teilnehmerspezifischen Diensteprofil (15) zumindest einen Grundeinstellungswert für zumindest ein Dienstattribut umfassen, der in dem Falle zu benutzen ist, dass ein Nutzergerät (11, 31) eine Übermittlung anfordert, ohne einen spezifischen Wert für das besagte zumindest eine für die angeforderte Übermittlung benötigte Dienstattribut anzufordern.
  6. Verfahren nach einem der vorherigen Ansprüche, wobei die Werte der Dienstattribute, die durch ein teilnehmerspezifisches Diensteprofil (15) definiert sind, die Werte von Dienstattributen umfassen, die die Dienstgüte für angeforderte Echtzeitverkehrübermittlungen definieren.
  7. Verfahren nach einem der vorherigen Ansprüche, wobei die Werte der Dienstattribute, die durch ein teilnehmerspezifisches Diensteprofil (15) definiert sind, die Werte zumindest eines Dienstattributes umfassen, das zumindest ein Teil der Dienstgüte für angeforderte Nichtechtzeitverkehrübermittlungen definiert.
  8. Verfahren nach einem der vorherigen Ansprüche, wobei im Falle, dass das besagte Nutzergerät (11, 31) einen Teil der Werte von Dienstattributen anfordert, die für eine angeforderte Übermittlung erforderlich sind, die Werte von Dienstattributen, die von einem teilnehmerspezifischen Diensteprofil (15) definiert sind, nur für die übrigen angeforderten Attributwerte benutzt werden, falls sie für die angeforderte Übermittlung geeignet sind, wenn die angeforderten Werte von Dienstattributen benutzt werden.
  9. Verfahren nach einem der vorherigen Ansprüche, wobei die gemeinsamen Werte von Dienstattributen zumindest einen Grundeinstellungswert für zumindest ein Dienstattribut umfassen, der in dem Falle zu benutzen ist, dass ein Nutzergerät (11, 31) eine Übermittlung anfordert, ohne einen spezifischen Wert für das besagte zumindest eine Dienstattribut, das für die angeforderte Übermittlung erforderlich ist, anzufordern.
  10. Verfahren nach Anspruch 9, wobei zumindest ein Grundeinstellungswert von zumindest einem Dienstattribut der besagten gemeinsamen Werte von Dienstattributen nur in dem Falle als Dienstattributwert für eine angeforderte Übermittlung benutzt wird, dass ein Wert, der von dem teilnehmerspezifischen Profil (15) für das besagte Dienstattribut definiert wird, für die angeforderte Übermittlung nicht geeignet ist, wenn Werte von Dienstattributen benutzt werden, die von einem Nutzergerät (11, 31) angefordert werden, oder in dem Falle, dass kein Wert in dem teilnehmerspezifischen Profil (15) für das besagte Dienstattribut gespeichert ist.
  11. Verfahren nach einem der vorherigen Ansprüche, wobei die gemeinsamen Werte von Dienstattributen einen Bereich von Werten für zumindest ein Dienstattribut definieren, wobei das besagte Verfahren Folgendes umfasst: Das Anpassen eines Wertes für das besagte zumindest eine Dienstattribut, der von einem Nutzergerät (11, 31) angefordert wird und außerhalb des jeweiligen definierten Bereiches liegt, so dass er innerhalb des besagten Bereiches liegt.
  12. Verfahren nach einem der vorherigen Ansprüche, wobei die gemeinsamen Werte von Dienstattributen einen Satz von Werten für zumindest ein Dienstattribut umfassen, wobei jeder Wert des besagten Satzes einem spezifischen Wert von zumindest einem anderen Dienstattribut zugewiesen ist, wobei das besagte Verfahren Folgendes umfasst: Das Auswählen eines Wertes für ein Dienstattribut, für das solch ein Satz zur Verfügung gestellt wird und für das von einem Nutzergerät (11, 31) kein Wert angefordert wird aus dem besagten Satz von Werten, gemäß dem Wert von zumindest einem anderen Dienstattribut, der von dem besagten Nutzergerät (11, 31) angefordert wird, sofern vorhanden, in dem Falle, dass ein Wert, der in dem teilnehmerspezifischen Profil (15) für das besagte Dienstattribut gespeichert ist, für die angeforderte Übermittlung nicht geeignet ist, wenn der Wert des besagten zumindest einen anderen Dienstattributs, der von dem besagten Nutzergerät (11, 31) angefordert wird, benutzt wird, oder in dem Falle, dass für das besagte Dienstattribut in dem teilnehmerspezifischen Profil (15) kein Wert gespeichert ist.
  13. Verfahren nach einem der vorherigen Ansprüche, wobei der besagte zumindest eine Wert von dem zumindest einen Dienstattribut, das von einem teilnehmerspezifischen Diensteprofil (15) definiert ist, in einem Speichermittel von einem ersten Netzwerkelement (13) eines Funkzugangsnetzwerks gespeichert ist, und wobei der besagte zumindest eine gemeinsame Wert von zumindest einem Dienstattribut in einem Speichermittel eines zweiten Netzwerkelements (12) des gleichen Funkzugangsnetzwerk gespeichert ist.
  14. Verfahren nach Anspruch 13, wobei in dem besagten zweiten Netzwerkelement (12) zusätzlich Regeln gespeichert sind, zur Bestimmung von Werten von Dienstattributen, die für die von dem besagten Nutzergerät (11) angeforderte Übermittlung zu benutzen sind.
  15. Verfahren nach einem der Ansprüche 1 bis 12, wobei der besagte zumindest eine Wert von zumindest einem Dienstattribut, der von einem teilnehmerspezifischen Diensteprofil (15) definiert ist, in einem Speichermittel eines Netzwerkelements (13) eines Funkzugangsnetzwerks gespeichert ist, und wobei der besagte zumindest eine gemeinsame Wert von zumindest einem Dienstattribut und/oder Regeln zur Bestimmung von Werten von Dienstattributen, die für die von dem Nutzergerät (11) angeforderten Übermittlung zu benutzen sind, von einem Betreiber des besagten Funkzugangsnetzwerk für jede angeforderte Übermittlung zur Verfügung gestellt werden.
  16. Verfahren nach einem der Ansprüche 13 bis 15, wobei das besagte Funkzugangsnetzwerk ein UMTS-Funkkommunikationsnetzwerk ist.
  17. Verfahren nach einem der Ansprüche 1 bis 12, wobei der besagte zumindest eine Wert von zumindest einem Dienstattribut, der von einem teilnehmerspezifischen Diensteprofil definiert ist, in einem Speichermittel eines ersten Funkzugangsnetzwerks (37) gespeichert ist, wobei der besagte zumindest eine gemeinsame Wert von zumindest einem Dienstattribut in einem zweiten Funkzugangsnetzwerk (32) verfügbar ist, wobei das besagte erste Funkzugangsnetzwerk (37) ein Netzwerk ist, für das ein Nutzergerät (31), welches eine Übermittlung anfordert, registriert ist, und wobei auf das besagte zweite Funkzugangsnetzwerk (32) von dem besagten Nutzergerät (31) zur Anforderung der Übermittlung zugegriffen wird.
  18. Verfahren nach Anspruch 17, wobei der besagte zumindest eine gemeinsame Wert von zumindest einem Dienstattribut in einem Speichermittel des besagten zweiten Funkzugangsnetzwerks (32) gespeichert ist.
  19. Verfahren nach Anspruch 17, wobei der besagte zumindest eine gemeinsame Wert von zumindest einem Dienstattribut von dem Betreiber des besagten zweiten Funkzugangsnetzwerks (37) für jede angeforderte Übermittlung zur Verfügung gestellt wird.
  20. Verfahren nach einem der Ansprüche 17 bis 19, welches ferner Folgendes umfasst: Die Übermittlung der Werte von Dienstattributen, die von einem teilnehmerspezifischen Profil definiert sind, das in dem ersten Speichermittel gespeichert ist, von dem besagten ersten Funkzugangsnetzwerk (37) zu dem besagten zweiten Funkzugangsnetzwerk (32), während der Authentifizierung des besagten Nutzergeräts (31), das auf das besagte zweite Funkzugangsnetzwerk (32) zugreift.
  21. Verfahren nach einem der Ansprüche 17 bis 20, wobei Werte von Dienstattributen, die für eine angeforderte Übermittlung in dem zweiten Funkzugangsnetzwerk (32) zu benutzen sind, bestimmt werden, indem Werte von Dienstattributen, die basierend auf Werten von Dienstattributen, soweit wie sie von einem Nutzergerät (31) für eine angeforderte Übermittlung angefordert werden, auf teilnehmerspezifischen Werten von Dienstattributen und auf gemeinsamen Werten von Dienstattributen bestimmt werden, wobei diese Dienstattribute in dem ersten Funkzugangsnetzwerk (37) definiert sind, auf Werte von Dienstattributen, die in dem zweiten Funkzugangsnetzwerk (32) definiert sind, gemappt werden.
  22. Verfahren nach einem der Ansprüche 17 bis 21, wobei das besagte zweite Funkzugangsnetzwerk (32) ein drahtloses lokales Netzwerk (WLAN = Wireless Local Area Network) ist.
  23. Verfahren nach einem der vorherigen Ansprüche, welches in dem Falle, dass das besagte Nutzergerät (11, 31) eine Übermittlung mit einer Angabe, dass die besagte angeforderte Übermittlung für spezifischen Verkehr benutzt wird, anfordert, die Auswahl von Werten von Dienstattributen, die von einem gespeicherten dedizierten Diensteprofil definiert werden, als Werte von Dienstattributen, die für die besagte Übermittlung zu benutzen sind, umfasst.
  24. Verfahren nach Anspruch 23, wobei die besagte angeforderte Übermittlung ein signalisierender Kontext ist.
  25. Verfahren nach Anspruch 23 oder 24, wobei das besagte gespeicherte dedizierte Diensteprofil ein teilnehmerspezifisches dediziertes Diensteprofil ist, das in einem Home Location Register (HLR) (13) eines jeweiligen Nutzergeräts (11, 31) gespeichert ist.
  26. Verfahren nach einem der Ansprüche 23 bis 25, wobei zumindest einer der besagten Werte von Dienstattributen, die von dem besagten gespeicherten dedizierten Diensteprofil definiert werden, in einem Serving Gateway Support Node (SGSN) (12) eines UMTS-Netzwerks gespeichert ist.
  27. Verfahren nach Anspruch 26, wobei ein anderer der besagten Werte von Dienstattributen, die von dem besagten dedizierten Diensteprofil definiert werden, in einer Funknetz-Steuereinrichtung (RNC = Radio Network Controller) eines UMTS-Netzwerks gespeichert ist
  28. Netzwerkelement (12, 34) eines Funkzugangsnetzwerks (32), das Folgendes umfasst: Verarbeitungsmittel zur Bestimmung von Werten oder eines Hinweises auf solche Werte von Dienstattributen, die die Dienstgüte einer Übermittlung definieren, die für eine Übermittlung zu benutzen ist, die von einem Nutzergerät (11, 31) eines Teilnehmers, der bei einem Funkzugangsnetzwerk (37) registriert ist, angefordert wird, dadurch gekennzeichnet, dass das besagte Verarbeitungsmittel dazu angepasst ist, die besagten Werte oder den besagten Hinweis auf solche Werte zu definieren, basierend auf zumindest einem zur Verfügung gestellten gemeinsamen Wert von zumindest einem Dienstattribut für alle Teilnehmer, der zumindest einer Übermittlungsart zugewiesen werden kann, und basierend auf zur Verfügung gestellten Werten von Dienstattributen, die von einem teilnehmerspezifischen Diensteprofil (15) definiert werden.
  29. Netzwerkelement (12) nach Anspruch 28, wobei das besagte Nutzergerät (11) bei dem besagten Funkzugangsnetzwerk registriert ist, zu dem das besagte Netzwerkelement (12) gehört.
  30. Netzwerkelement (12) nach Anspruch 29, wobei die besagten Verarbeitungsmittel für eine von dem besagten Nutzergerät (11) angeforderte Übermittlung mit einer Angabe, dass die besagte Übermittlung für spezifischen Verkehr genutzt wird, zur Verfügung gestellte Werte von zumindest einem. Dienstattribut, die durch ein dediziertes Diensteprofil definiert werden, auswählen.
  31. Netzwerkelement (12) nach Anspruch 30, wobei die besagte Übermittlung ein signalisierender Kontext ist.
  32. Netzwerkelement (34) nach Anspruch 28, wobei es bei dem besagten Funkzugangsnetzwerk (32), zu dem das besagte Netzwerkelement (34) gehört, einem Nutzergerät (31) eines Teilnehmers, der bei einem anderen Funkzugangsnetzwerk (37) registriert ist, gestattet ist, eine Übermittlung anzufordern, und wobei die besagten Verarbeitungsmittel dazu angepasst sind, Werte oder einen Hinweis auf solche Werte von Dienstattributen, die für eine von dem besagten Nutzergerät (31) angeforderte Übermittlung zu benutzen sind, zu bestimmen, basierend auf Werten von Dienstattributen, die von einem teilnehmerspezifischen Diensteprofil definiert werden, das von dem anderen Funkzugangsnetzwerk (37) empfangen wird, und basierend auf dem besagten zumindest einen gemeinsamen Wert von zumindest einem Dienstattribut.
  33. Funkzugangsnetzwerk, das Folgendes umfasst: Ein Netzwerkelement (12) gemäß einem der Ansprüche 29 bis 31 und Speichermittel zur Speicherung von teilnehmerspezifischen Diensteprofilen (15), die Werte von zumindest einem Dienstattribut definieren, die zumindest einer Übermittlungsart zugewiesen werden können.
  34. Funkzugangsnetzwerk nach Anspruch 33, wobei das besagte Funkzugangsnetzwerk ein Mobilfunknetzwerk ist, wobei die besagten Speichermittel in einem Home Location Register oder einem Home Subscriber Server (HLR/HSS) (13) des besagten Mobilfunknetzwerks integriert sind, und wobei das besagte Netzwerkelement (12) ein Serving Gateway Support Node (SGSN) (12) des besagten Mobilfunknetzwerks ist.
  35. Funkzugangsnetzwerk nach Anspruch 33 oder 34, das Speichermittel zur Speicherung eines dedizierten Diensteprofils umfasst, das Werte von zumindest einem Dienstattribut definiert, wobei die Werte von den besagten Verarbeitungsmitteln für eine Übermittlung ausgewählt werden, die von einem Nutzergerät (11) angefordert wird, mit einer Angabe, dass die besagte Übermittlung für spezifischen Verkehr benutzt wird.
  36. Funkzugangsnetzwerk (32), bei dem es einem Nutzergerät (31) eines Teilnehmers, der bei einem anderen Funkzugangsnetzwerk (37) registriert ist, gestattet ist, eine Übermittlung anzufordern, wobei das besagte Funkzugangsnetzwerk (32) ein Netzwerkelement (34) nach Anspruch 32 umfasst.
  37. Funkzugangsnetzwerk (32) nach Anspruch 36, wobei die Verarbeitungsmittel dazu ausgelegt sind, Werte von Dienstattributen, die basierend auf Werten von Dienstattributen, soweit wie sie von einem Nutzergerät (31) für eine angeforderte Übermittlung angefordert werden, auf teilnehmerspezifischen Werten von Dienstattributen und auf gemeinsamen Werten von Dienstattributen bestimmt werden, wobei die Dienstattribute in dem anderen Funkzugangsnetzwerk (37) definiert sind, zu Werten von Dienstattributen, die in dem Funkzugangsnetzwerk nach Anspruch 36 definiert sind, zu mappen.
  38. Funkzugangsnetzwerk (32) nach Anspruch 36 oder 37, wobei das besagte Funkzugangsnetzwerk (32) ein drahtloses lokales Netzwerk (WLAN = Wireless Local Area Network) ist, und wobei die Speichermittel des besagten Funkzugangsnetzwerks (32) die besagten zur Verfügung gestellten gemeinsamen Werte von zumindest einem Dienstattribut speichern und wobei zumindest ein Teil der besagten Speichermittel in einem Public Access Controller (PAC) (34) des besagten drahtlosen lokalen Netzwerks integriert sind.
DE60127869T 2001-03-14 2001-10-22 Verfahren zum zuteilen von dienstparameterwerten an übertragungen, funkzugangsnetze und netzwerkelemente Expired - Fee Related DE60127869T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US09/808,616 US7010305B2 (en) 2001-03-14 2001-03-14 Method for assigning values of service attributes to transmissions, radio access networks and network elements
US808616 2001-03-14
PCT/EP2001/012180 WO2002073998A2 (en) 2001-03-14 2001-10-22 Method for assigning values of service attributes to transmissions, radio access networks and network elements

Publications (2)

Publication Number Publication Date
DE60127869D1 DE60127869D1 (de) 2007-05-24
DE60127869T2 true DE60127869T2 (de) 2007-12-13

Family

ID=25199272

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60127869T Expired - Fee Related DE60127869T2 (de) 2001-03-14 2001-10-22 Verfahren zum zuteilen von dienstparameterwerten an übertragungen, funkzugangsnetze und netzwerkelemente

Country Status (5)

Country Link
US (1) US7010305B2 (de)
EP (1) EP1368980B1 (de)
AT (1) ATE359684T1 (de)
DE (1) DE60127869T2 (de)
WO (1) WO2002073998A2 (de)

Families Citing this family (80)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0011058D0 (en) * 2000-05-08 2000-06-28 Nokia Networks Oy Data bearers in a communication system
DE10112699C2 (de) * 2001-03-16 2003-06-18 Daimler Chrysler Ag Autorisierungsverfahren für die Kommunikation mit einem Datenbus
US7058387B2 (en) * 2001-11-01 2006-06-06 Intel Corporation System and method for providing cost of quality of service levels in a wireless communication device
CA2365685A1 (en) * 2001-12-19 2003-06-19 Alcatel Canada Inc. System and method of provisioning subscriber services in a communication network
US6842621B2 (en) * 2001-12-21 2005-01-11 Motorola, Inc. Method and apparatus for splitting control and media content from a cellular network connection
US7301950B1 (en) * 2002-02-14 2007-11-27 Nortel Networks Limited Adaptive state transition control
US7647389B2 (en) * 2002-02-28 2010-01-12 Alcatel-Lucent Usa Inc. Method for configuration negotiation in a data communication system
EP1486036B1 (de) * 2002-03-08 2012-12-12 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Kompatibilität zwischen verschiedenen w-lan standards
US6965775B2 (en) * 2002-05-15 2005-11-15 Nokia Corporation Service-oriented protection scheme for a radio access network
CA2393373A1 (en) * 2002-07-15 2004-01-15 Anthony Gerkis Apparatus, system and method for the transmission of data with different qos attributes.
US7035242B2 (en) * 2002-07-29 2006-04-25 Interdigital Technology Corporation Method and apparatus for delivery of universal mobile telecommunications system (UMTS) based unidirectional services over a wireless local area network (WLAN)
US20040037264A1 (en) * 2002-08-23 2004-02-26 Charbel Khawand Pre-negotiated quality of service
US20040073674A1 (en) * 2002-09-05 2004-04-15 Alcatel Method and a server for allocating local area network resources to a terminal according to the type of terminal
US8161158B2 (en) * 2002-09-25 2012-04-17 Nokia Corporation Method in a communication system, a communication system and a communication device
EP1906694A1 (de) 2002-10-08 2008-04-02 Interdigital Technology Corporation Dienstqualitätsabbildung zwischen verschiedenen Typen von drahtlosen Kommunikationssystemen
US20040121778A1 (en) * 2002-10-08 2004-06-24 Interdigital Technology Corporation Quality of service mapping between various types of wireless communication systems
JP4058326B2 (ja) * 2002-10-17 2008-03-05 株式会社エヌ・ティ・ティ・ドコモ 無線基地局、制御装置、無線通信システム及び通信方法
US20040127200A1 (en) * 2002-12-31 2004-07-01 Shaw Venson M. Delivery of network services
KR100510669B1 (ko) * 2002-12-31 2005-08-31 엘지전자 주식회사 패킷 무선 서비스 네트워크에서 착신 호를 설정하는 방법 및 이를 위한 시스템
JP4520705B2 (ja) * 2003-04-11 2010-08-11 パナソニック株式会社 通信システム及び通信方法
US7272496B2 (en) * 2003-06-12 2007-09-18 Temic Automotive Of North America, Inc. Vehicle network and method of communicating data packets in a vehicle network
US7392055B2 (en) * 2003-06-23 2008-06-24 Lucent Technologies Inc. Method for allocating resources in a wireless data system based on system loading
US20050101313A1 (en) * 2003-08-11 2005-05-12 Stanco Bart D. Method and apparatus for communicating phone with radio services and the like
FR2859862A1 (fr) * 2003-09-11 2005-03-18 France Telecom Procede de differenciation de la qualite de service dans les reseaux de communication mobile en mode paquets
EP1719355B1 (de) * 2003-11-26 2010-09-29 Lenovo (Singapore) Pte. Ltd. Verfahren und vorrichtung zur bereitstellung von dienstqualität für voip über drahtlose 802.11-lans
GB0329221D0 (en) * 2003-12-17 2004-01-21 Nokia Corp Session control in a communication system
FI20031922A0 (fi) * 2003-12-30 2003-12-30 Nokia Corp Menetelmä, järjestelmä ja tietokoneohjelma resurssien kontrolloimiseksi langattomassa viestintäjärjestelmässä
US7477632B1 (en) * 2004-01-16 2009-01-13 Qualcomm, Inc. Subscriber management and service profiles
US8630225B2 (en) * 2004-04-16 2014-01-14 Broadcom Corporation Over the air programming via a broadband access gateway
WO2005112371A1 (en) * 2004-05-19 2005-11-24 Telefonaktiebolaget Lm Ericsson (Publ) Bit rate mapping
AU2005254265B2 (en) * 2004-06-21 2010-07-29 Sika Technology Ag Cement grinding aid
US7339913B2 (en) * 2004-08-17 2008-03-04 Intel Corporation Method and system of network management and service provisioning for broadband wireless networks
JP4438946B2 (ja) * 2004-09-08 2010-03-24 日本電気株式会社 付加機能制御システムおよび通信端末
DE602004012336T2 (de) * 2004-10-05 2009-03-19 Telefonaktiebolaget Lm Ericsson (Publ) Anordnung und verfahren in bezug auf die dienstbereitstellungssteuerung
US20060092963A1 (en) * 2004-10-28 2006-05-04 Ajay Bakre Architecture and method for efficient application of QoS in a WLAN
US8488612B2 (en) * 2004-11-01 2013-07-16 At&T Intellectual Property Ii, L.P. System and method for method for providing quality-of service in a local loop
US7346340B2 (en) 2004-12-23 2008-03-18 Spyder Navigations L.L.C. Provision of user policy to terminal
US8856359B2 (en) 2005-06-29 2014-10-07 Qualcomm Connected Experiences, Inc. Caller-callee association of a plurality of networked devices
US8756328B2 (en) * 2005-01-19 2014-06-17 Qualcomm Connected Experiences, Inc. Caller-callee association of a plurality of networked devices with direct dial through thin client
US8351419B2 (en) * 2005-01-19 2013-01-08 Qualcomm Iskoot, Inc. Local access to a mobile network
JP4498973B2 (ja) * 2005-05-11 2010-07-07 株式会社日立製作所 無線通信装置、無線通信装置の制御方法、およびプログラム
US20070002868A1 (en) * 2005-06-29 2007-01-04 Haibo Qian Location based quality of service (QoS) control
EP1964426B1 (de) 2005-12-12 2010-07-28 Telefonaktiebolaget LM Ericsson (publ) Verfahren und einrichtungen zum spezifizieren der dienstgüte bei einer übertragung von datenpaketen
US9479604B2 (en) * 2006-01-30 2016-10-25 Qualcomm Incorporated System and method for dynamic phone book and network content links in a mobile device
DE602006010910D1 (de) * 2006-02-05 2010-01-14 Ericsson Telefon Ab L M Verfahren und einrichtungen zum installieren von paketfiltern bei einer datenübertragung
CN1859306A (zh) * 2006-02-21 2006-11-08 华为技术有限公司 一种提供QoS服务的方法和系统
CN100518191C (zh) * 2006-03-21 2009-07-22 华为技术有限公司 通讯网络中对服务质量进行保障的方法及系统
US20090299836A1 (en) * 2006-04-04 2009-12-03 Joachim Sachs Radio access system attachment
US7907970B2 (en) * 2006-04-14 2011-03-15 Qualcomm Incorporated Providing quality of service for various traffic flows in a communications environment
US8170572B2 (en) * 2006-04-14 2012-05-01 Qualcomm Incorporated Methods and apparatus for supporting quality of service in communication systems
WO2007119012A1 (fr) * 2006-04-18 2007-10-25 Trusteed Sas Procede et dispositif de securisation de transferts de donnees
FI118714B (fi) * 2006-05-18 2008-02-15 Teliasonera Ab Palvelun laatu -profiilien hallinta viestintäjärjestelmässä
US8254253B2 (en) * 2006-07-05 2012-08-28 Nokia Corporation Conditional utilization of private short-range wireless networks for service provision and mobility
US9148823B2 (en) 2006-07-05 2015-09-29 Nokia Technologies Oy Ensuring quality of service for private short-range wireless networks
US8126474B2 (en) * 2006-08-15 2012-02-28 Nokia Corporation Streaming quality optimization
US8098639B2 (en) * 2007-01-02 2012-01-17 Motorola Solutions, Inc. System and method for managing communication channel assignments for different types of communication units in a communication system
US8050230B2 (en) * 2007-07-07 2011-11-01 Wipro Limited VoWLAN roaming controller with station pre-authentication
WO2009024188A1 (en) * 2007-08-22 2009-02-26 Telefonaktiebolaget Lm Ericsson (Publ) Data transmission control
US9584564B2 (en) 2007-12-21 2017-02-28 Brighttalk Ltd. Systems and methods for integrating live audio communication in a live web event
US10015729B2 (en) * 2008-11-17 2018-07-03 Telefonaktiebolaget L M Ericsson (Publ) Providing access to a GPRS network
BRPI0823198A8 (pt) 2008-11-17 2015-09-22 Ericsson Telefon Ab L M método para fornecer acesso a dispositivo a uma rede do serviço de rádio por pacote geral, nó de controle, programa de computador e produto de meio legível por computador .
US8331225B2 (en) * 2009-12-07 2012-12-11 At&T Mobility Ii, Llc Quality of service based upon location
CA2696037A1 (en) 2010-03-15 2011-09-15 Research In Motion Limited Advertisement and dynamic configuration of wlan prioritization states
EP2556684A1 (de) * 2010-04-08 2013-02-13 Nokia Siemens Networks OY Verfahren zur übertragung von daten in einem kommunikationsnetz
US8612526B2 (en) * 2010-07-21 2013-12-17 At&T Intellectual Property I, L.P. System and method for prioritizing message transcriptions
US8879695B2 (en) 2010-08-06 2014-11-04 At&T Intellectual Property I, L.P. System and method for selective voicemail transcription
CN102143479A (zh) * 2010-11-26 2011-08-03 华为技术有限公司 管理服务质量的方法、设备及系统
US9420030B2 (en) 2010-12-15 2016-08-16 Brighttalk Ltd. System and method for distributing web events via distribution channels
US8346241B2 (en) * 2011-03-22 2013-01-01 King Abdulaziz City For Science And Technology Controlled mobile communication in a socially sensitive environment
EP2695422A1 (de) * 2011-04-04 2014-02-12 Telefonaktiebolaget LM Ericsson (PUBL) Verfahren anhand von gn/gp mit maximal erlaubter dienstgüte
US9099956B2 (en) 2011-04-26 2015-08-04 King Abdulaziz City For Science And Technology Injection locking based power amplifier
US8750180B2 (en) 2011-09-16 2014-06-10 Blackberry Limited Discovering network information available via wireless networks
US8942221B2 (en) 2011-11-10 2015-01-27 Blackberry Limited Caching network discovery responses in wireless networks
EP2837248A1 (de) * 2012-04-12 2015-02-18 Telefonaktiebolaget LM Ericsson (Publ) Benutzervorrichtung, funkbasisstation und entsprechendes verfahren zur verwalten von uplink-ressourcen in einem funkversorgungsbereich der funkbasisstation
US9204299B2 (en) 2012-05-11 2015-12-01 Blackberry Limited Extended service set transitions in wireless networks
US10812964B2 (en) 2012-07-12 2020-10-20 Blackberry Limited Address assignment for initial authentication
US9137621B2 (en) 2012-07-13 2015-09-15 Blackberry Limited Wireless network service transaction protocol
US9301127B2 (en) 2013-02-06 2016-03-29 Blackberry Limited Persistent network negotiation for peer to peer devices
WO2015143693A1 (en) * 2014-03-28 2015-10-01 Qualcomm Incorporated Methods and apparatus for validating reconfiguration messages based on sdu lifetime
CN109716742A (zh) * 2016-08-02 2019-05-03 诺基亚通信公司 在网络中提供语音呼叫支持

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5638412A (en) 1994-06-15 1997-06-10 Qualcomm Incorporated Method for providing service and rate negotiation in a mobile communication system
US6201971B1 (en) 1998-03-26 2001-03-13 Nokia Mobile Phones Ltd. Apparatus, and associated method for controlling service degradation performance of communications in a radio communication system
US6169898B1 (en) 1998-07-16 2001-01-02 Nokia Mobile Phones Ltd Apparatus, and associated method, for maintaining a selected quality of service level in a radio communication system
SE522068C2 (sv) * 1999-07-15 2004-01-13 Ericsson Telefon Ab L M Metod och anordning för att åstadkomma radioaccessbärartjänster
WO2001028160A2 (en) 1999-10-14 2001-04-19 Nortel Networks Limited Establishing a communications session having a quality of service in a communications system
US20020077097A1 (en) * 2000-12-19 2002-06-20 Jerry Mizell Method and apparatus in a GPRS ready mobile terminal for providing differentiated quality of service

Also Published As

Publication number Publication date
WO2002073998A3 (en) 2002-11-21
DE60127869D1 (de) 2007-05-24
US7010305B2 (en) 2006-03-07
ATE359684T1 (de) 2007-05-15
WO2002073998A2 (en) 2002-09-19
US20020132611A1 (en) 2002-09-19
EP1368980B1 (de) 2007-04-11
EP1368980A2 (de) 2003-12-10

Similar Documents

Publication Publication Date Title
DE60127869T2 (de) Verfahren zum zuteilen von dienstparameterwerten an übertragungen, funkzugangsnetze und netzwerkelemente
DE60003525T2 (de) Übertragung von dienstqualitätsabbildungsinformation in einem paketfunknetz
DE60130911T2 (de) Verfahren und gerät für die koordinierte verrechnung von diensten in einer multimedia-sitzung
DE69921831T2 (de) Kontrolle der dienstqualitäten in einem mobilkommunikationssystem
DE60130114T2 (de) Anwendungsbeeinflusste richtlinie
DE60115030T2 (de) Kommunikationen unter verwendung von adaptiven mehrraten kodierern/dekodierern
DE60120354T2 (de) Rsvp-verarbeitung in 3g-netzwerken
DE602004005604T2 (de) Verfahren zur dienstqualitätsdifferenzierung in paketmodus-mobilkommunikationsnetzen
DE602004012336T2 (de) Anordnung und verfahren in bezug auf die dienstbereitstellungssteuerung
DE602004009913T2 (de) Verfahren, system und netzwerkelement zur autorisierung einer datenübertragung
DE60211881T2 (de) Bindungsinformation für ip mediendatenströmen
DE60225278T2 (de) Technik zur verbesserung von ansagen in anrufen mit mobilursprung
EP1316230B1 (de) Generische wlan-architektur
DE69935397T3 (de) Verfahren und Vorrichtung zur Echtzeitdatenübertragung in einem Paketfunknetz
DE60304117T2 (de) Drahtlose Kommunikationskostenvorhersage für ein drahtloses Gerät
DE60112480T2 (de) Dienstqualität (QoS) für ein Universales Mobiltelekommunikationssystem (UMTS) mit Unterstützung einer Verhandlung einer einstellbaren Dienstqualität
DE60108765T2 (de) Basis-qos-mechanismen zur drahtlosen übertragung von ip-verkehr
DE69834188T2 (de) Dynamische dienstqualitätreservierung in einem mobilen kommunikationsnetz
DE10302788B4 (de) Einrichtung und Verfahren zum Umordnen von TFTs in einem Mobilkommunikationssystem
DE60030858T2 (de) Verfahren und anordnung zur anzeige der speziellen verwendung eines pdp kontexts
DE60125422T2 (de) Abbildung von paketen auf pdp-kontexte bei vielfach-verbindungen
DE60215026T2 (de) Verfahren für Verkehrslastmanagement basierend auf dem Austausch von dienstspezifischen Informationselementen für freie Kapazität zwischen Funkzugangsnetz-Steuerungseinheiten
DE60206894T2 (de) Verfahren und vorrichtung zur herstellung eines protokoll-proxy für ein mobiles host-endgerät in einer multimediasitzung
DE69829764T2 (de) Auswahl zwischen paketvermittelte und leitungsvermittelte dienste in einem mobilen kommunikationssystem
DE60310667T2 (de) Netzarchitektur für mobile Kommunikationssysteme und entsprechendes Kommunikationsverfahren

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee