Title:
Festlegen von auf Anwendungen basierenden Routing-Richtlinien in Multimodus-Benutzergeräten
Kind Code:
U1


Abstract:

Multimodus-Benutzergerät bzw. UE, umfassend:
eine Empfangskomponente, die dafür ausgelegt ist, von einem ANDSF-Server (Access Network Discovery and Selection Function), der in einem Evolved Packet Core eines auf Trägern basierenden Zugangsnetzes unterhalten wird, ein ANDSF-Verwaltungsobjekt zu empfangen, wobei das ANDSF-Verwaltungsobjekt eine Intersystem-Routingrichtlinie bzw. ISRP auf der Basis einer Betriebssystemkennung bzw. OSId für ein Betriebssystem des UE umfasst, wobei die ISRP eine Anwendungsnetzwerk-Routingregel zum Offloading von Daten einer für Betrieb auf dem UE ausgelegten Softwareanwendung umfasst, und
eine Routingkomponente, die dafür ausgelegt ist, Offloading von Daten, die von der Softwareanwendung erzeugt werden, auf ein sekundäres Zugangsnetz gemäß der ISRP durchzuführen.




Application Number:
DE202013012469U
Publication Date:
01/12/2017
Filing Date:
06/06/2013
Assignee:
Intel Corporation (Calif., Santa Clara, US)
International Classes:



Other References:
IEEE-802.11-Standard
IEEE-802.16-Standard
IEEE-802.11-Standardfamilie
Richtlinie in der Intersystem-
Attorney, Agent or Firm:
BOEHMERT & BOEHMERT Anwaltspartnerschaft mbB - Patentanwälte Rechtsanwälte, 28209, Bremen, DE
Claims:
1. Multimodus-Benutzergerät bzw. UE, umfassend:
eine Empfangskomponente, die dafür ausgelegt ist, von einem ANDSF-Server (Access Network Discovery and Selection Function), der in einem Evolved Packet Core eines auf Trägern basierenden Zugangsnetzes unterhalten wird, ein ANDSF-Verwaltungsobjekt zu empfangen, wobei das ANDSF-Verwaltungsobjekt eine Intersystem-Routingrichtlinie bzw. ISRP auf der Basis einer Betriebssystemkennung bzw. OSId für ein Betriebssystem des UE umfasst, wobei die ISRP eine Anwendungsnetzwerk-Routingregel zum Offloading von Daten einer für Betrieb auf dem UE ausgelegten Softwareanwendung umfasst, und
eine Routingkomponente, die dafür ausgelegt ist, Offloading von Daten, die von der Softwareanwendung erzeugt werden, auf ein sekundäres Zugangsnetz gemäß der ISRP durchzuführen.

2. Multimodus-UE nach Anspruch 1, das eine Sendekomponente umfasst, die dafür ausgelegt ist, ein zweites ANDSF-Verwaltungsobjekt zu senden, wobei das zweite ANDSF-Verwaltungsobjekt UE-Profilinformationen umfasst und die UE-Profilinformationen die OSId umfassen.

3. Multimodus-UE nach Anspruch 2, wobei die UE-Profilinformationen Informationen über einen oder mehrere Aspekte des UE, einschließlich einer Softwareversion, einer Hardwareversion oder einer Hardwarearchitektur, umfassen.

4. Multimodus-UE nach Anspruch 1, wobei die ISRP eine auf nicht nahtlosem Offload basierende Regel umfasst.

5. Multimodus-UE nach Anspruch 4, wobei die auf nicht nahtlosem Offload basierende Regel einen Knoten für die Softwareanwendung einschließlich einer auf nicht nahtlosem Offload basierenden Routingregel für die Softwareanwendung umfasst.

6. Multimodus-UE nach Anspruch 1, wobei die ISRP eine auf Fluss basierende Regel umfasst.

7. Multimodus-UE nach Anspruch 6, wobei die auf Fluss basierende Regel einen Knoten für die Softwareanwendung einschließlich einer auf Fluss basierenden Routingregel für die Softwareanwendung umfasst.

8. Multimodus-UE nach Anspruch 1, wobei das auf Trägern basierende Zugangsnetz gemäß einem Standard aus einer 3GPP-LTE/LTE-A-Standardfamilie (Long Term Evolution oder Long Term Evolution-Advanced) arbeitet und wobei das sekundäre Zugangsnetz gemäß einem Standard aus einer IEEE-802.11-Standardfamilie arbeitet.

9. Multimodus-UE nach Anspruch 1, das einen Beschleunigungsmesser umfasst.

10. Multimodus-UE nach Anspruch 1, umfassend:
einen ersten Sendeempfänger, ausgelegt zum Kommunizieren mit dem auf Trägern basierenden Zugangsnetz; und
einen zweiten Sendeempfänger, ausgelegt zum Kommunizieren mit dem sekundären Zugangsnetz.

11. Maschinenlesbares Medium, auf dem Anweisungen gespeichert sind, die, wenn sie von einem Prozessor eines ANDSF-Servers ausgeführt werden, den ANDSF-Server veranlassen, eine auf Anwendungen basierenden Netzwerk-Routingrichtlinie festzulegen, durch:
Erhalten einer Betriebssystemkennung bzw. OSId für ein Betriebssystem des Benutzergeräts bzw. UE von einem UE-Profilknoten in einem ersten ANDSF-Verwaltungsobjekt;
Bestimmen einer Anwendungsrichtlinie zum Offloading von Daten von einem primären Zugangsnetz zu einem sekundären Zugangsnetz für eine für Betrieb auf dem UE ausgelegte Softwareanwendung auf der Basis der OSId;
Definieren eines Anwendungsknotens in einem ISRP-Knoten (Intersystem-Routingrichtlinie) eines zweiten ANDSF-Verwaltungsobjekts, wobei der Anwendungsknoten die Anwendungsrichtlinie zum Offloading von Daten auf das sekundäre Zugangsnetz umfasst; und
Bereitstellen des zweiten ANDSF-Verwaltungsobjekts für das UE.

12. Maschinenlesbares Medium nach Anspruch 11, wobei der ISRP-Knoten eine auf Fluss basierende Regel umfasst.

13. Maschinenlesbares Medium nach Anspruch 11, wobei der ISRP-Knoten eine auf nicht nahtlosem Offload basierende Regel umfasst.

14. Maschinenlesbares Medium nach Anspruch 11, wobei Erhalten der OSId umfasst, das erste ANDSF-Verwaltungsobjekt von dem UE während eines OMA-DM-Austauschs (Open Mobile Alliance Device Management) zu erhalten.

15. Maschinenlesbares Medium nach Anspruch 11, wobei das erste ANDSF-Verwaltungsobjekt und das zweite ANDSF-Verwaltungsobjekt in einem XML-Format (eXtenxible Markup Language) strukturiert sind.

16. Maschinenlesbares Medium nach Anspruch 11, wobei für jede Anwendung des UE, die für Aufnahme in die Anwendungsrichtlinie zum Offloading von Daten auf das sekundäre Zugangsnetz identifiziert ist, ein distinkter Anwendungsknoten in dem ISRP-Knoten enthalten ist.

17. Maschinenlesbares Medium nach Anspruch 11, wobei der Anwendungsknoten eine Anwendungskennung umfasst, die die Softwareanwendung eindeutig identifiziert.

18. Maschinenlesbares Medium nach Anspruch 11, wobei der ANDSF-Server in einem Evolved Packet Core bereitgestellt ist, der gemäß einem Standard aus einer 3GPP-LTE/LTE-A-Standardfamilie (Long Term Evolution oder Long Term Evolution-Advanced) arbeitet, und wobei das sekundäre Zugangsnetz ein drahtloses lokales Netzwerk ist, das gemäß einem Standard aus einer IEEE-802.11-Standardfamilie arbeitet.

19. Maschinenlesbares Medium, das ein ANDSF-Verwaltungsobjekt (Access Network Discovery and Selection Function) umfasst, wobei das ANDSF-Verwaltungsobjekt Folgendes umfasst:
einen Benutzergeräte- bzw. UE-Profilknoten, der einen Betriebssystemkennungsbzw. OSId-Knoten umfasst; und
einen Intersystem-Routingrichtlinien- bzw. ISRP-Knoten, der eine Anwendungsregel zum UE-Datenoffload von einem primären Zugangsnetz auf ein sekundäres Zugangsnetz umfasst.

20. Maschinenlesbares Medium nach Anspruch 19, wobei der ISRP-Knoten einen Nicht-Nahtloses-Offload-Knoten umfasst.

21. Maschinenlesbares Medium nach Anspruch 20, wobei der Nicht-Nahtloses-Offload-Knoten einen OSId-Knoten umfasst.

22. Maschinenlesbares Medium nach Anspruch 19, wobei der ISRP-Knoten einen auf Fluss basierenden Knoten umfasst.

23. Maschinenlesbares Medium nach Anspruch 19, wobei der auf Fluss basierende Knoten einen OSId-Knoten umfasst.

24. Maschinenlesbares Medium nach Anspruch 19, wobei das ANDSF-Verwaltungsobjekt in einem XML-Format (eXtensible Markup Language) vorliegt.

Description:
PRIORITÄTSANSPRUCH

Die vorliegende Anmeldung beansprucht den Nutzen der Priorität der US-Patentanmeldung, laufende Nummer 13/711.338, eingereicht am 11.12.2012, die den Nutzen der Priorität der vorläufigen US-Patentanmeldung, laufende Nummer 61/679.627, eingereicht am 03.08.2012, beansprucht, die beide hiermit durch Bezugnahme vollständig aufgenommen werden.

TECHNISCHES GEBIET

Ausführungsformen betreffen Operationen und Kommunikation, die durch kommunizierende Vorrichtungen in drahtlosen Netzen ausgeführt werden. Einige Ausführungsformen betreffen Vorrichtungsinformationen und Routing-Richtlinien, die für durch ein drahtloses Netz ermöglichte Datenkommunikation festgelegt werden.

STAND DER TECHNIK

Auf Trägern basierende drahtlose Kommunikationsnetze, wie etwa Netze, die gemäß einem Standard aus der Standardfamilie LTE/LTE-A (3GPP Long Term Evolution/Long Term Evolution-Advanced) arbeiten, verwenden Mechanismen zur Hilfe bei der Entdeckung und Verwaltung von Netzrichtlinien. In LTE/LTE-A-Netzen werden bei einer solchen Technik Regeln und Richtlinien der ANDSF (Access Network Discovery Function) in einem EPC (Evolved Packet Core) der LTE/LTE-A-Systemarchitektur verwendet. Zum Beispiel können ANDSF-Regeln und -Richtlinien für Multimodus-Benutzergeräte (UE) spezifiziert werden, um nicht-3GPP-Zugangsnetze zu entdecken, und Multimodus-UE dabei zu helfen, eine Verbindung mit einem drahtlosen lokalen WiFi-Netzwerk (WLAN) (z. B. einem Netzwerk, das gemäß einem IEEE-802.11-Standard arbeitet) oder einem drahtlosen großflächigen WiMax-Netzwerk (z. B. einem Netzwerk, das gemäß einem IEEE-802.16-Standard arbeitet) herzustellen. Existierende Richtlinien wenden sich jedoch nicht an anwendungsspezifische Anforderungen oder vorrichtungsspezifische Fähigkeiten.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

1 zeigt eine Konfiguration einer Mischmodus-Kommunikationsnetzarchitektur gemäß einem weiter beschriebenen Beispiel.

2 zeigt Datenoperationen mit einer Mischmodus-Benutzergerätevorrichtung gemäß einem weiter beschriebenen Beispiel.

3 zeigt ein ANDSF-Verwaltungsobjekt mit einem Benutzerprofil-Konfigurationssubobjekt gemäß einem weiter beschriebenen Beispiel.

4A zeigt einen auf ISRP-Fluss basierenden Richtlinienknoten eines ANDSF-Verwaltungsobjekts mit einer anwendungsspezifischen Konfiguration gemäß einem weiter beschriebenen Beispiel.

4B zeigt einen Richtlinienknoten auf der Basis von nicht nahtlosem ISRP-Offload eines ANDSF-Verwaltungsobjekts mit einer anwendungsspezifischen Konfiguration gemäß einem weiter beschriebenen Beispiel.

5 zeigt einen Benutzerprofilknoten eines ANDSF-Verwaltungsobjekts gemäß einem weiter beschriebenen Beispiel.

6 zeigt ein Flussdiagramm eines beispielhaften Verfahrens zum Festlegen und Einsetzen einer anwendungsidentifizierenden ANDSF-Richtlinie gemäß einem weiter beschriebenen Beispiel.

7 zeigt eine beispielhafte mobile Vorrichtung, auf der die hier beschriebenen Konfigurationen und Techniken eingesetzt werden können.

8 zeigt ein beispielhaftes Computersystem, das als Datenverarbeitungsplattform für die hier beschriebenen Datenverarbeitungs- und Netzkommunikationsvorrichtungen verwendet werden kann.

AUSFÜHRLICHE BESCHREIBUNG

Die folgende Beschreibung und die Zeichnungen veranschaulichen ausreichend spezifische Ausführungsformen, um es Fachleuten zu ermöglichen, diese auszuüben. Andere Ausführungsformen können strukturelle, logische, elektrische, Prozess- und andere Änderungen enthalten. Teile und Merkmale einiger Ausführungsformen können in denen anderer Ausführungsformen enthalten sein oder diese ersetzen. In den Ansprüchen dargelegte Ausführungsformen schließen alle verfügbaren Äquivalente dieser Ansprüche ein.

Verschiedene hier beschriebene Techniken und Konfigurationen ermöglichen die Erstellung und den Betrieb von auf ANDSF basierenden Richtlinien, die eingesetzt werden können, um spezifische Vorrichtungs-/Netzimplementierungen und Offloading-Benutzungsfälle zu behandeln. Die in ANDSF-Richtlinien miteinbezogenen Informationen können anwendungs- und vorrichtungsspezifische Konfigurationen umfassen, darunter Vorrichtungstyp, Hardwareversion, Betriebssystemtyp und -version, Softwareanwendungstyp und -version und gleiche UE-Konfigurationsdetails. Mit diesen UE-Konfigurationsdetails kann eine spezifische Intersystem-Routingrichtlinie (ISRP) zur Steuerung des Verkehrsroutings und der Mobilität zwischen in dem UE installierten Anwendungen festgelegt und eingesetzt werden.

Bei einer LTE/LTE-A-Systemkonfiguration kann ein ANDSF-Server Folgendes bereitstellen: eine Intersystem-Mobilitätsrichtlinie, die zur Hilfe bei Handover-Entscheidungen verwendet wird; eine ISRP zum gleichzeitigen Routen von IP-Verkehr über mehrere Funkzugangsschnittstellen; und Entdeckungsinformationen zum Angeben von nicht-3GPP-Zugangsnetzen, die in der Umgebung des UE verfügbar sein können, um dem UE bei der Verbindung mit solchen Netzen zu helfen. Als Teil der ISRP für IP-Flowmobilitäts-Offloading-Techniken können mehrere verschiedene Richtlinien spezifiziert werden.

Als ein Beispiel für Verkehrsrouting und Mobilität können bestimmte Anwendungen mit der Fähigkeit zur Kommunikation über mehrere drahtlose Netzschnittstellen in einem Multimodus-Benutzergerät (wie etwa WLAN und Mobilfunk) wählen, allen Verkehr über eine Schnittstelle (WLAN), im Gegensatz zu einer anderen, zu routen. Auf ANDSF basierende Richtlinien werden durch einen Trägernetzbetreiber gesteuert und sollen solche Szenarien mit auf Regeln basierender Verwaltung des Netz-Offloading ergänzen. Mit ANDSF-Mechanismen kann man Richtlinien und Richtlinieninformationen im Namen von Betreiben aus vielfältigen Gründen und in vielfältigen Situationen an UE abliefern, wie etwa Verwaltung des Offloading und des Netzzugangs zu bestimmten Tageszeiten, in bestimmten Gebieten oder für bestimmte Flüsse.

Aktuelle auf ANDSF basierende Richtlinien stellen jedoch keine Mechanismen bereit, um anwendungsspezifische Präferenzen und Richtlinien angemessen zu behandeln. Zum Beispiel kann eine auf Video basierende Anwendung Verwendung einer WLAN-Verbindung wählen, während eine Sprachanwendung Verwendung einer Mobilfunkverbindung wählen kann. Ferner können die zum Durchführen von Offloading verwendeten Präferenzen und Richtlinien von der bestimmten Version oder Konfiguration des UE abhängen und davon, ob auf Fluss basierendes oder nicht nahtloses Offloading für bestimmte Anwendungen erwünscht oder erlaubt ist.

In einem Beispiel werden verschiedene Datenidentifikationsfelder zur Verwendung mit dem ANDSF-Verwaltungsobjekt (MO) vorgeschlagen, darunter der Zusatz verschiedener Anwendungskennungen im ANDSF-Server, um es einer ISRP zu erlauben, Verkehrsidentifikation auf der Basis einer Anwendungsidentität zu unterstützen. Aktuelle Aktualisierungen der ISRP ermöglichen erhöhte Verwendung und Behandlung einer Anwendungsidentität als Identifikation von IP-Verkehr. Zur Bestimmung der entsprechenden Anwendungsidentität verwendete relevante Informationen umfassen nicht nur die bestimmte Anwendungsversion oder Anwendungskonfiguration, sondern auch diesbezügliche Felder wie UE-Version, UE-Plattform und Hardwarekonfiguration, UE-Betriebssystem und dergleichen. Die vorliegend beschriebenen Datenkonfigurationen und Austauschmechanismen ermöglichen deshalb die Kommunikation einer detaillierten Anwendungsidentität und zugeordneter Datenbehandlungsrichtlinien und -prozeduren.

1 zeigt eine Darstellung einer beispielhaften Konfiguration einer Mischmodus-Kommunikationsnetzarchitektur 100. In er Netzarchitektur 100 wird ein auf Trägern basierendes Netz (z. B. ein LTE/LTE-A-Mobilnetz, das gemäß einem Standard aus einer 3GPP-Standardfamilie arbeitet) durch ein auf Trägern basierendes Netzsystem 102 (z. B. einem evolved NodeB (eNodeB), der ein Mobilfunknetz herstellt) hergestellt, das mit Multimodus-Mobilvorrichtungen (UE) 104A, 104B kommuniziert. Ein auf dem lokalen Bereich basierendes Netzsystem 106 (z. B. ein WiFi-Netzwerk, das gemäß einem Standard aus einer IEEE-802.11-Standardfamilie arbeitet) kann durch lokale Netzwerkgeräte, darunter ein WiFi-Router oder Zugangspunkt, hergestellt werden. Das auf Trägern basierende Netz umfasst Netzverbindungen 108A, 108B jeweils mit den mobilen Vorrichtungen 104A, 104B; und das auf dem lokalen Bereich basierende Netzwerk umfasst Netzwerkverbindungen 110A, 110B jeweils mit den mobilen Vorrichtungen 104A, 104B. Die mobilen Vorrichtungen 104A, 104B sind als verschiedenen Formfaktoren genügend dargestellt, darunter ein Smartphone (mobile Vorrichtung 104A) und ein Personal Computer (mobile Vorrichtung 104B) mit einer integrierten oder externen drahtlosen Netzkommunikationsvorrichtung, obwohl es sich versteht, dass derselbe oder andere Formfaktoren verwendet werden können.

Die drahtlosen Netzkommunikationsverbindungen 108A, 108B, 110A, 110B unter den verschiedenen mobilen Vorrichtungen 104A, 104B können entweder unter Verwendung des auf Trägern basierenden Netzsystems 102 oder des auf dem lokalen Bereich basierenden Netzsystems 106 in Verbindung mit dem Einsatz verschiedener Offloading-Richtlinien und Präferenzen ermöglicht werden. Die Offloading-Richtlinien und Präferenzen können unter Verwendung einer oder mehrerer ANDSF-Richtlinien 120 übermittelt und von einem ANDSF-Server 114 über das auf Trägern basierende Netzsystem 102 (und die Netzverbindungen 108A, 108B) übermittelt werden.

Der ANDSF-Server 114 kann in einem Dienstanbieternetz 112 des Trägernetzes ermöglicht werden. Das Dienstanbieternetz 112 kann verschiedene Komponenten eines EPC (Evolved Packet Core) und andere Komponenten des 3GPP-LTE/LTE-A-Netzes umfassen, darunter verschiedene Dienste 118 und ein P-GW (PDN-Gateway (Packet Data Network)) 116. Auf das auf dem lokalen Bereich basierende Netzsystem 106 abgeladener Datenverkehr kann mittels einer Verbindung mit dem P-GW 116 zurück zum Dienstanbieternetz 112 übermittelt werden. In einer anderen Netzarchitektur (drahtlose Netzverbindungen 110A, 110B) abgeladene drahtlose Netzübermittlungen können somit verwendet werden, um auf Funktionalität des Dienstanbieternetzes 112 zuzugreifen.

2 zeigt eine Darstellung beispielhafter Datenoperationen 200 mit einer Mischmodus-Benutzergerätevorrichtung (mobilen Vorrichtung 104C), die in Verbindung mit der Mischmodus-Kommunikationsnetzarchitektur 100 von 1 ausgeführt werden. Wie in 2 gezeigt, ist die mobile Vorrichtung 104C ausgelegt zum Durchführen von Übermittlungen von 3GPP-Netzdaten 206 mit dem auf Trägern basierenden Netzsystem 102 zu einem externen Netzwerk (wie etwa dem Internet) 122; und die mobile Vorrichtung 104C ist auch ausgelegt zum Durchführen von Übermittlungen von nicht-3GPP-Netzdaten 208 mit dem lokalen Netzwerksystem 106 zu dem externen Netzwerk 122.

Die mobile Vorrichtung 104C ist abgebildet als Daten mit einer ersten Softwareanwendung „App 1” in den 3GPP-Netzdaten 206 und mit einer zweiten Anwendung „App 2” in den nicht-3GPP-Netzdaten 208 übermittelnd. Der Einsatz von Daten von den verschiedenen Softwareanwendungen in dem entsprechenden Netz wird in Verbindung mit einer ISRP-Richtlinie 204 ermöglicht, die eine oder mehrere Anwendungsrichtlinien 204A umfasst, die vom ANDSF-Server 114 bereitgestellt werden. Die mobile Vorrichtung 104C ist konfiguriert zum Implementieren der ISRP-Richtlinie 204 zum Spezifizieren von IP-Flow(Fluss)-Mobilitätsanwendungen auf der Basis von Anwendungskennungen (wie etwa eine Angabe von App 1 im Gegensatz zu App 2).

Die bestimmten Anwendungskennungen und die bestimmte Menge von Anwendungsrichtlinien 204A in der ISRP-Richtlinie 204 werden in einem ANDSF-MO von dem ANDSF-Server 114, das über das nicht abgeladene Netz (z. B. 3GPP LTE/LTE-A) empfangen wird, zu der mobilen Vorrichtung 104C übermittelt. Das ANDSF-MO kann in einem XML-Format (eXtensible Markup Language) strukturiert sein und kann aus der mobilen Vorrichtung 104C gezogen oder in diese geschoben werden. Um die entsprechenden Anwendungsrichtlinien zum Einsatz in der ISRP-Richtlinie 204 zu bestimmen, können Informationen über das UE und entsprechende Anwendungen zum ANDSF-Server 114 übermittelt werden. In einem Beispiel wird auch ein UE-Profil 202 mit entsprechenden UE- und Anwendungsinformationen 202A in dem ANDSF-MO zum ANDSF-Server 114 übermittelt.

Die Verwendung der Anwendungsrichtlinien 204A in einer eingesetzten ISRP-Richtlinie 204 kann verwendet werden, um die Netzbenutzung einer Anwendung im UE zu behandeln. Die Anwendungsrichtlinien 204A können an vielfältige Netzbenutzungsfälle und -szenarien angepasst werden und umfassen Regeln zum Durchführen eines spezifischen Zugriffs oder einer Menge von Zugriffen von einer identifizierten Anwendung auf ein gewähltes Netz oder einen gewählten Netztyp. Man betrachtet zum Beispiel Video-Codec-Wiedergabe in einer Multimedia-Wiedergabeanwendung. In einigen Szenarien kann das UE ein qualitativ minderwertiges Video wiedergeben, das eine Präferenz aufweist, von einem 3GPP-Zugangsnetz heruntergeladen zu werden. Wenn qualitativ hochwertige Wiedergabe in einem hochauflösenden oder höher auflösenden Format erwünscht ist, kann die Präferenz darin bestehen, dass die Anwendung ein WiFi- oder anderes sekundäres drahtloses Netzwerk verwendet. Mit den Anwendungsrichtlinien 204A kann man die Anwendung eindeutig identifizieren und die Anwendung auf der Basis von Trägernetzanforderungen und Präferenzen mit Zugangstypregeln assoziieren.

3 zeigt eine beispielhafte Darstellung 300 eines formatierten strukturierten Knotenobjekts 302 des Typs ANDSF-MO mit einer Reihe von strukturierten Subobjekten, darunter ein Benutzerprofil-Konfigurationssubobjekt. Die strukturierten Subobjekte des strukturierten Knotenobjekts 302 können für Einhaltung einer bestimmten Spezifikation (z. B. einer 3GPP-LTE/LTE-A-Spezifikation) definiert werden und können Folgendes umfassen: ein Richtlinienknoten-Subobjekt 304, das einen Richtlinienknotenbaum 304A definiert; ein Entdeckungsinformationsknoten-Subobjekt 306, das einen Entdeckungsinformations-Knotenbaum 306A definiert; ein UE-Ortsknoten-Subobjekt 308, das einen Benutzergeräteort-Knotenbaum 308A definiert; ein ISRP-Knotensubobjekt 310, das einen ISRP-Knotenbaum 310A definiert; das UE_Profil-Knoten-Subobjekt 312, das einen UE_Profil-Knotenbaum 312A (in 5 weiter dargestellt) definiert; und ein Ext-Knoten-Subobjekt 314, das eine potenzielle Definition für anbieterspezifische Informationen bereitstellt.

Die Modifikation an dem ANDSF-MO zum Spezifizieren und Einsetzen von auf Anwendungen basierenden Routingrichtlinien kann in Verbindung mit zwei Aspekten bereitgestellt werden: erstens einer Definition des UE_Profil-Knotenbaums 312A, der die spezifische UE-Hardwarekonfiguration, das Betriebssystem, Betriebssystemversionsinformationen und andere UE-Betriebsinformationen enthält; und zweitens einer Definition eines AnwendungsID-Blatts, das für Einsatz in dem ISRP-Knotenbaum 310A definiert wird, wie hier weiter beschrieben (und in Knotenbäumen 400, 450 in 4A bzw. 4B dargestellt) wird.

Die Definition in dem UE_Profil-Knotenbaum 312A kann verwendet werden, um allgemeine UE- und Anwendungsoperationsinformationen über das ANDSF-MO, wie in dem in 2 übermittelten UE-Profil 202 dargestellt, zu übermitteln. Ein Knoten, der die AnwendungsID für spezifische Anwendungsrichtlinien spezifiziert, wird im ANDSF-MO verwendet und in einer ISRP sowohl für auf Flüssen basierende als auch für Nicht-Nahtlos-WLAN-Offload-Mechanismen eingesetzt.

4A und 4B zeigen beispielhafte Darstellungen von ISRP-Richtlinienknotenstrukturen für ein ANDSF-Verwaltungsobjekt, für einen auf Flüssen basierenden Richtlinienknotenbaum 400 bzw. einen Nicht-Nahtlos-Offload-Richtlinienknotenbaum 450. Eine ISRP-Regelmenge kann einen oder mehrere Flussverteilungsbehälter enthalten, darunter ein FürFlowBasis-Knoten 402 für einen IFOM-Dienst (IP Flow Mobility and Seamless Offload), wie in 4A gezeigt, und ein FürNichtNahtlosOffload-Knoten 452 für einen Nicht-Nahtlos-Offload-Dienst, wie in 4B gezeigt.

Die ISRP-Knotenverzweigungen spezifizieren einen Mechanismus zum Identifizieren des durch eine spezifische Anwendung erzeugten Verkehrs. Der Flussverteilungsbehälter kann eine oder mehrere Flussverteilungsregeln aufweisen. In einem FürFlowBasis-Knoten 402 für einen IFOM-Dienst, wie in 4A gezeigt, umfassen diese Verteilungsregeln Verkehrsverteilungsregeln für UE in Verbindung mit einem IFOM-Offloading-Mechanismus. In dem FürNichtNahtlosOffload-Knoten 452 für das nicht nahtlose Offload, wie in 4B gezeigt, umfassen diese Verteilungsregeln Verkehrsverteilung für UE in Verbindung mit einem Nicht-Nahtlos-Offloading-Mechanismus.

In einem Beispiel werden ISRP-Knoten zur Verwendung unter dem FürFlowBasis-Knoten 402 definiert, in Verbindung mit Definitionen für den App-ID-Knoten 404, den Plattformknoten 406, den PlattformApps-Knoten 408 und den Plattform_spezifischeAppID-Knoten 410. Die Definition dieser Knoten kann folgendermaßen angegeben werden:

Knoten: <X>/ISRP/<X>/FürFlowBasis/<X>/IPFlow/<X>/App-ID

Dieser Innenknoten wirkt als Platzhalter für einen IPFlow-Identifikationsmechanismus mittels einer Anwendungskennung. Mit der Abwesenheit dieses Knotens kann angegeben werden, dass die Anwendungskennung beim Vergleichen von Paketen mit der IP-Flowbeschreibung der Regel nicht untersucht wird.

  • – Auftreten: NullOderEins
  • – Format: Knoten
  • – Zugangstypen: Holen, Ersetzen

Knoten: <X>/ISRP/<X>/FürFlowBasis/<X>/IPFlow/<X>/App-ID/<X>/

Dieser Innenknoten wirkt als Platzhalter für eine oder mehrere Plattformkonfigurationen, die auf der Basis der in dem UE_Profil-Knoten enthaltenen Informationen durch das UE unterstützt werden.

  • – Auftreten: EinOderMehrere
  • – Format: Knoten
  • – Zugangstypen: Holen, Ersetzen

Knoten: <X>/ISRP/<X>/FürFlowBasis/<X>/IPFlow/<X>/App-ID/<X>/Plattform

Das Plattform-Blatt gibt die Plattform an, die der Anwendungskennung zugeordnet ist, die in dem entsprechenden Plattform_spezifischeAppID-Blatt enthalten ist.

  • – Auftreten: Ein
  • – Format: chr
  • – Zugangstypen: Holen, Ersetzen
  • – Werte: <Plattform>

Der Wert der Plattform-Kennung ist eine Zeichenkette, die das Betriebssystem oder die Ausführungsumgebung spezifiziert, zusammen mit den entsprechenden Versionsinformationen und der Hardwarearchitektur des UE. Eine weitere Definition kann für das Format und die Werte der Plattform-Kennung angegeben werden.

Knoten: <X>/ISRP/<X>/FürFlowBasis/<X>/IPFlow/<X>/App-ID/<X>/PlattformApps/

Dieser Innenknoten wirkt als Platzhalter für ein oder mehrere Plattform_spezifischeAppID-Blätter.

  • – Auftreten: Ein
  • – Format: Knoten
  • – Zugangstypen: Holen, Ersetzen

Knoten: <X>/ISRP/<X>/FürFlowBasis/<X>/IPFlow/<X>/App-ID/<X>/PlattformApps/<X>

Dieser Innenknoten wirkt als Platzhalter für ein oder mehrere Plattform_spezifischeAppID-Blätter.

  • – Auftreten: EinOderMehrere
  • – Format: Knoten
  • – Zugangstypen: Holen, Ersetzen

Knoten: <X>/ISRP/<X>/FürFlowBasis/<X>/IPFlow/<X>/App-ID/<X>/PlattformApps/<X>/Plattform_spezifischeAppID

Das Plattform_spezifischeAppID-Blatt gibt die plattformspezifische Anwendungskennung an, die der IP-Flow-Beschreibung zugeordnet ist.

  • – Auftreten: Ein
  • – Format: chr
  • – Zugangstypen: Holen, Ersetzen
  • – Werte: <AppID>

Der Wert der AppID ist eine Zeichenkette, die einer gegebenen Anwendung zugeordnet ist. Die plattformspezifische Anwendungskennung identifiziert eindeutig die Anwendung in dem UE für die gegebene Plattform. Beispielsweise kann die Anwendungskennung die Form com.organization.app-name annehmen.

In einem anderen Beispiel werden die ISRP-Knoten zur Verwendung unter dem FürNichtNahtlosOffload-Knoten 452 definiert, in Verbindung mit Definitionen für den App-ID-Knoten 454, den Plattformknoten 456, den PlattformApps-Knoten 458 und den Plattform_spezifischeAppID-Knoten 460. Die Definition dieser Knoten kann folgendermaßen angegeben werden:

Knoten: <X>/ISRP/<X>/FürNichtNahtlosOffload/<X>/IPFlow/<X>/App-ID

Dieser Innenknoten wirkt als Platzhalter für eine IPFlow-Identifikation auf der Basis mittels AnwendungsID. Mit der Abwesenheit dieses Blatts kann angegeben werden, dass die Anwendungskennung beim Vergleichen von Paketen mit der IP-Flow-Beschreibung der Regel nicht untersucht wird.

  • – Auftreten: NullOderEins
  • – Format: Knoten
  • – Zugangstypen: Holen, Ersetzen

Knoten: <X>/ISRP/<X>/FürNichtNahtlosOffload/<X>/IPFlow/<X>/App-ID/<X>/

Dieser Innenknoten wirkt als Platzhalter für eine oder mehrere Plattformkonfigurationen, die auf der Basis der in dem UE_Profil-Knoten enthaltenen Informationen durch das UE unterstützt werden.

  • – Auftreten: EinOderMehrere
  • – Format: Knoten
  • – Zugangstypen: Holen, Ersetzen

Knoten: <X>/ISRP/<X>/FürNichtNahtlosOffload/<X>/IPFlow/<X>/Plattform

Das Plattform-Blatt gibt die Plattform an, die der Anwendungskennung zugeordnet ist, die in dem entsprechenden Plattform_spezifischeAppID-Blatt enthalten ist.

  • – Auftreten: Ein
  • – Format: chr
  • – Zugangstypen: Holen, Ersetzen
  • – Werte: <Plattform>

Der Wert der Plattform-Kennung ist eine Zeichenkette, die das Betriebssystem oder die Ausführungsumgebung spezifiziert, zusammen mit den entsprechenden Versionsinformationen und der Hardwarearchitektur des UE. Eine weitere Definition kann für das Format und die Werte der Plattform-Kennung angegeben werden.

Knoten: <X>/ISRP/<X>/FürNichtNahtlosOffload/<X>/IPFlow/<X>/App-ID/<X>/PlattformApps/

Dieser Innenknoten wirkt als Platzhalter für ein oder mehrere Plattform_spezifischeAppID-Blätter.

  • – Auftreten: Ein
  • – Format: Knoten
  • – Zugangstypen: Holen, Ersetzen

Knoten: <X>/ISRP/<X>/FürNichtNahtlosOffload/<X>/IPFlow/<X>/PlattformApps/<X>

Dieser Innenknoten wirkt als Platzhalter für ein oder mehrere Plattform_spezifischeAppID-Blätter.

  • – Auftreten: EinOderMehrere
  • – Format: Knoten
  • – Zugangstypen: Holen, Ersetzen

Knoten: <X>/ISRP/<X>/FürNichtNahtlosOffload/<X>/IPFlow/<X>/PlattformApps/<X>/Plattform_spezifischeAppID

Das Plattform_spezifischeAppID-Blatt gibt die plattformspezifische Anwendungskennung an, die der IP-Flow-Beschreibung zugeordnet ist.

  • – Auftreten: Ein
  • – Format: chr
  • – Zugangstypen: Holen, Ersetzen
  • – Werte: <AppID>

Der Wert der AppID-Kennung kann als eine Zeichenkette definiert werden, die einer gegebenen Anwendung zugeordnet ist. Die plattformspezifische Anwendungskennung identifiziert eindeutig die Anwendung in dem UE für die gegebene Plattform. Beispielsweise kann die Anwendungskennung die Form com.organization.app-name annehmen.

5 zeigt eine beispielhafte Darstellung einer Benutzerprofil-Knotenstruktur 500 (z. B. UE_Profil-Knoten 312), die unter Verwendung eines ANDSF-MO zum ANDSF-Server 114 übermittelt wird. Die UE_Profil-Knotenstruktur 500 kann dafür ausgelegt werden, Informationen zu umfassen, die die Plattformkonfiguration des UE charakterisieren, die durch den ANDSF-Server 114 zur Informationsbereitstellung verwendet werden können. Die UE_Profil-Knotenstruktur 500 wird zu einem gegebenen Zeitpunkt durch das UE aktualisiert, zum Beispiel nach dem Herauffahren oder vor dem Herstellen einer Netzverbindung. Der ANDSF-Server 114 ist ausgelegt zum Abrufen von Informationen aus der UE_Profil-Knotenstruktur 500, nachdem das UE (z. B. die mobile Vorrichtung 104C) eine Verbindung mit dem ANDSF-Server 114 herstellt. Die Aktualisierung der in diesen Knoten enthaltenden Informationen bringt jedoch nicht unbedingt irgendeine Interaktion mit dem ANDSF-Server mit sich.

Die UE_Profil-Knotenstruktur 500 wird verwendet, um die UE-Konfiguration zu definieren und es dem UE zu ermöglichen, dem Netz seine Konfiguration anzugeben. Um mit der Anforderung der Unterstützung mehrerer Betriebssysteme umzugehen, stellt der ANDSF-Server 114 dem UE Richtlinien bereit, die die Anwendungs-ID für das entsprechende Betriebssystem, das auf dem UE läuft, und den Hardwareplattformtyp enthalten, um die Anwendungen ordnungsgemäß zu identifizieren. Mit der UE_Profil-Knotenstruktur 500 stellt das UE dem ANDSF Informationen des unterstützten Betriebssystems und der Hardwarekonfiguration bereit, um den ANDSF zu informieren, die Richtlinien mit der durch die unterstützte Plattform verwendeten Anwendungs-ID zu erhalten oder herunterzuladen und somit die Anwendung zu identifizieren, auf die sich die Richtlinie bezieht.

Das UE kann mehrere Plattformkonfigurationen unterstützen. Die mit dem ANDSF-Server 114 übermittelte Plattformkonfiguration kann das geltende Betriebssystem oder die geltende Ausführungsumgebung zusammen mit den entsprechenden Versionsinformationen angeben. In einem Beispiel verwendet der ANDSF-Server die Benutzerprofilinformationen aus der UE_Profil-Knotenstruktur 500, um eine bestimmte ISRP (z. B. eine an den auf Fluss basierenden Richtlinienknotenbaum 400 oder den Nicht-Nahtlos-Offload-Richtlinienknotenbaum 450 angepasste ISRP) zur Verwendung zum Klassifizieren von Anwendungsverkehr festzulegen und zu übermitteln. Die ISRP wird nur für die Anwendungen verwendet, die auf der Basis der in der UE_Profil-Knotenstruktur 500 spezifizierten Informationen durch die UE-Plattformkonfiguration unterstützt werden.

Das UE aktualisiert die Knoten in der UE_Profil-Knotenstruktur 500, so dass der ANDSF-Server 114 bei der Interaktion mit dem UE diese Informationen lesen kann. Die Informationen in der UE_Profil-Knotenstruktur 500 können durch den ANDSF-Server 114 während eines OMA-DM-Austauschs (Open Mobile Alliance Device Management) abgerufen werden, zum Beispiel wenn der Server das MO des UE liest.

Wie in 3 dargestellt, weist das MO einen Knoten (UE_Profil-Knoten 312) auf, der die Konfiguration des UE angibt und die UE_Profil-Knotenstruktur 500 umfasst. Die UE_Profil-Knotenstruktur 500 spezifiziert im Detail die Hardwareplattform des UE und das Betriebssystem oder die Ausführungsumgebung, das bzw. die von dem UE verwendet oder diesem verfügbar ist. Die Aktualisierung der in diesen Knoten enthaltenen Informationen bringt nicht unbedingt irgendeine Interaktion mit dem ANDSF-Server 114 mit sich. Das MO ermöglicht dem ANDSF-Server 114 jedoch, über die Hardwarekonfiguration des UE, das Betriebssystem und die Version des Betriebssystems, das bzw. die auf dem UE installiert ist, und andere relevante UE-Profilinformationen informiert zu sein. Auf der Basis dieser Informationen kann der ANDSF-Server 114 spezifische Anwendungskennungen entsprechend UE-Konfiguration erzeugen und bereitstellen (und somit bestimmte ISRP-Richtlinien an die spezifischen Anwendungskennungen anpassen).

Als ein spezifisches Implementierungsbeispiel können die folgenden Knoten und Blattobjekte des UE_Profil-Knotens 312 und des UE_Profil-Knotenbaums 312A unter dem formatierten strukturieren Knotenobjekt 302 des ANDSF MO bereitgestellt werden:

Knoten: <X>/UE_Profil/

Der UE_Profil-Knoten wirkt als Platzhalter zur Beschreibung der Plattformkonfigurationsinformationen des UE und hat Anwendungen und Anwendungsumgebungen für das spezifische UE identifiziert.

  • – Auftreten: NullOderEin
  • – Format: Knoten
  • – Zugangstypen: Holen

Knoten: <X>/UE_Profil/<X>

Dieser Innenknoten wirkt als Platzhalter für eine oder mehrere Plattformkonfigurationen des UE.

  • – Auftreten: EinOderMehrere
  • – Format: Knoten
  • – Zugangstypen: Holen

Knoten: <X>/UE_Profil/<X>/Plattform

Das Plattform-Blatt gibt die durch das UE unterstützte Plattformkonfiguration an.

  • – Auftreten: NullOderEin
  • – Format: chr
  • – Zugangstypen: Holen
  • – Werte: <Plattform>

Der Wert der Plattform-Kennung kann eine Zeichenkette umfassen, die das Betriebssystem oder die Ausführungsumgebung spezifiziert, zusammen mit den entsprechenden Versionsinformationen und der Hardwarearchitektur des UE. Es kann eine weitere Definition des Formats und der Werte der Plattform-Kennung bereitgestellt werden, um die Hardwarearchitektur und das Betriebssystem oder die Ausführungsumgebungsinformationen anzugeben, um geeignete Anwendungen auf dem UE eindeutig zu identifizieren.

Die weitere Spezifikation für das Format des UE_Profil-Knotens oder die Plattform-Kennung kann spezifische Hardware-, Betriebssystem- oder Softwarekonfigurationen miteinbeziehen. Als ein Beispiel kann die Plattform-Kennung einen der folgenden Werte spezifizieren:

  • – Android auf x86 auf Prozessoren auf x86-Basis
  • – Android auf ARM auf Prozessoren auf x86-Basis
  • – Windows, Version 8, auf Prozessoren auf x86-Basis
  • – Windows, Version 8, auf Prozessoren auf ARM-Basis
  • – iOS auf Prozessoren auf ARM-Basis

Obwohl die obigen Kennungsbeispielwerte für bestimmte Vorrichtungsimplementierungen spezifisch sind, werden diese Beispielwerte für Anschauungszwecke und nicht als Beschränkung bereitgestellt. Es können vielfältige andere Vorrichtungshardware-, Betriebssystem- und Softwareimplementierungswerte durch die Plattform-Kennung oder andere Informationen in der UE_Profil-Knotenstruktur 500 spezifiziert werden. Diese können Werte umfassen, die für konfigurierbare, anpassbare oder aufrüstbare Hardware- und Softwarekonfigurationen spezifisch sind.

In weiteren Beispielen kann die ISRP dafür ausgelegt sein, eine zum Bereitstellen einer Aktualisierung der Verteilungsregeln verwendete Aktualisierungsrichtlinie zu verwalten, einschließlich Aktualisierungen für Profilinformationen für verschiedene UE und UE-Anwendungen.

Knoten: <X>/ISRP/<X>/Aktualisierungsrichtlinie

Das Aktualisierungsrichtlinie-Blatt gibt die Aktualisierungsrichtlinie für die ISRP an. Das UE kann mit dem Aktualisierungsrichtlinie-Wert bestimmen, ob eine Aktualisierung seiner ISRP anzufordern ist oder nicht, wenn die Regel von dem UE nicht mehr als gültig betrachtet wird. Der Vorgabewert 0 gilt, wenn dieses Blatt nicht vorgesehen ist.

  • – Auftreten: NullOderEin
  • – Format: bool
  • – Zugangstypen: Holen, Ersetzen
  • – Werte: 0,1 (0 gibt an, dass das UE keine Aktualisierung der Regeln anfordern muss; 1 gibt an, dass das UE eine Aktualisierung der Regeln anfordern muss).

6 zeigt ein beispielhaftes Flussdiagramm 600 eines Verfahrens zum Festlegen und Einsetzen einer anwendungsidentifizierenden ANDSF-Richtlinie. Wie dargestellt, umfasst das Flussdiagramm 600 eine Kombination von Aktionen, die im ANDSF-Server und im UE ausgeführt werden. Es ist jedoch ersichtlich, dass Varianten des folgenden Übersichtsverfahrens entsprechende Aktionen und Techniken umfassen können, die ausschließlich im ANDSF-Server oder UE ausgeführt werden.

Das Flussdiagramm 600 zeigt Operationen zum Übermitteln und Erhalten der UE-Profilinformationen, darunter Bereitstellung der UE-Profilinformationen vom UE an den ANDSF-Server (Operation 602) und Bestimmen der Vorrichtungskonfigurationsinformationen im ANDSF-Server aus den UE-Profilinformationen (Operation 604). Die UE-Profilinformationen können in einem ANDSF-MO-Objekt oder in anderen Daten übermittelt werden, die dem ANDSF-Server bereitgestellt werden, bevor die ISRP-Richtlinie eingesetzt wird.

Als Nächstes umfassen Operationen zum Bestimmen der Werte der bestimmten ISRP-Richtlinie Aktualisieren der ISRP auf der Basis der Vorrichtungskonfigurationsinformationen (Operation 606) und Bereitstellen der ISRP von dem ANDSF-Server für das UE (Operation 608). Die ISRP kann als ein Knoten eines zum UE übermittelten ANDSF-MO-Objekts übermittelt werden. Die ISRP kann auf den ANDSF-Server oder einen anderen Dienst des EPC geschoben oder davon gezogen werden.

Die ISRP wird aktualisiert, um die Hardware- und Softwarekonfiguration des UE miteinzubeziehen, kann aber mehrere Arten von Offload-Richtlinienwerten zur Anwendung bereitstellen. Bestimmen der geeigneten Menge von Richtlinienwerten in der ISRP kann umfassen zu bestimmen, ob ein Verkehrsoffloading auf nahtloser oder nicht nahtloser Basis auftritt (Operation 610). Auf Auswahl der geeigneten Menge von Richtlinienwerten in der ISRP hin können die Anwendungsrichtlinienwerte zum Offloading aus der ISRP extrahiert werden (Operation 612) (z. B. aus dem APP-ID-Knoten in dem ISRP-Abschnitt, der für Offloading auf nahtloser oder nicht nahtloser Basis spezifisch ist).

Obwohl die vorhergehenden Beispiele mit Bezug auf einen spezifischen ANDSF-Server und Richtlinienbenutzung in einem 3GPP-Netz bereitgestellt wurden, versteht sich, dass Verwendung und Einsatz von identifizierenden Anwendungsinformationen zum Netz-Offloading in vielfältigen Netzen und unter Verwendung anderer Arten von Einsatzmechanismen bereitgestellt werden können. Zum Beispiel kann man die Richtlinieninformationen für spezifische Softwareanwendungen ganz oder teilweise mit Nicht-ANDSF-Strukturen übermitteln. Ferner können Multimodus-Benutzergeräte eine beliebige Vorrichtung umfassen, die zu Kommunikation auf dem Primärträgernetz und einem sekundären Offload-Netz fähig ist, darunter Personal Computer, Notebooks und Laptops, Smartphones, Tablets, mobile Notspots, Medienplayer und dergleichen.

Wie hier beschrieben können verschiedene Verfahren oder Techniken oder bestimmte Aspekte oder Teile davon die Form von Programmcode (d. h. Anweisungen) annehmen, der in greifbaren Medien realisiert ist, wie etwa Flash-Speicher, CD/DVD-ROM, Festplatten, tragbaren Speichervorrichtungen oder einem beliebigen maschinenlesbaren Speichermedium, wobei, wenn der Programmcode in eine Maschine, wie etwa einen Computer geladen und dadurch ausgeführt wird, die Maschine zu einer Vorrichtung zur Ausübung der verschiedenen Techniken wird. Im Fall von Programmcodeausführung auf programmierbaren Computern kann die Datenverarbeitungsvorrichtung einen Prozessor, ein durch den Prozessor lesbares Speichermedium (darunter flüchtige und nichtflüchtige Speicher- und/oder Speicherungselemente), mindestens eine Eingabevorrichtung und mindestens eine Ausgabevorrichtung umfassen. Ein oder mehrere Programme, die die verschiedenen hier beschriebenen Techniken implementieren oder benutzen können, können eine Anwendungsprogrammierschnittstelle (API), wiederverwendbare Steuerelemente und dergleichen verwenden. Solche Programme können in einer höheren prozedualen oder objektorientierten Programmiersprache zur Kommunikation mit einem Computersystem implementiert werden. Das Programm bzw. die Programme können jedoch gegebenenfalls auch in Assembler- oder Maschinensprache implementiert werden. In jedem Fall kann die Sprache eine kompalierte oder interpretierte Sprache sein und mit Hardwareimplementierungen kombiniert werden.

7 zeigt eine beispielhafte Darstellung einer mobilen Vorrichtung 700, wie etwa eines Benutzergeräts (UE), einer Mobilstation (MS), einer mobilen drahtlosen Vorrichtung, einer Mobilkommunikationsvorrichtung, eines Tablets, eines Handapparats oder einer beliebigen anderen Art von drahtloser mobiler Vorrichtung. Die mobile Vorrichtung 700 kann eine oder mehrere Antennen 708 umfassen, die dafür ausgelegt sind, mit einer Basisstation (BS), einem eNodeB oder einer anderen Art von Zugangspunkt des drahtlosen großflächigen Netzwerks (WWAN) zu kommunizieren. Die mobile Vorrichtung 700 kann dafür ausgelegt sein, unter Verwendung mindestens eines Standards der drahtlosen Kommunikation zu kommunizieren, darunter 3GPP LTE, WiMAX, HSPA (High Speed Packet Access), Bluetooth und WiFi. Die mobile Vorrichtung 700 kann unter Verwendung getrennter Antennen für jeden Standard der drahtlosen Kommunikation oder von geteilten Antennen für mehrere Standards der drahtlosen Kommunikation kommunizieren. Die mobile Vorrichtung 700 kann in einem WLAN, einem WPAN (Wireless Personal Area Network) und/oder einem WWAN kommunizieren.

7 zeigt außerdem eine Darstellung eines Mikrophons 720 und eines oder mehrerer Lautsprecher 712, die für Audioeingabe und -ausgabe von der mobilen Vorrichtung 700 verwendet werden können. Der Anzeigebildschirm 704 kann ein LCD-Bildschirm (Liquid Crystal Display) oder eine andere Art von Anzeigebildschirm sein, wie etwa eine OLED-Anzeige (Organic Light Emitting Diode). Der Anzeigebildschirm 704 kann als ein Berührungsschirm konfiguriert sein. Der Berührungsschirm kann kapazitive, resistive oder eine andere Art von Berührungsschirmtechnologie verwenden. Ein Anwendungsprozessor 714 und ein Grafikprozessor 718 können mit internem Speicher 716 gekoppelt sein, um Verarbeitungs- und Anzeigefähigkeiten bereitzustellen. Außerdem kann ein Port 710 nichtflüchtigen Speichers verwendet werden, um einem Benutzer Dateneingabe-/-ausgabemöglichkeiten bereitzustellen. Der Port 710 nichtflüchtigen Speichers kann auch verwendet werden, um die Speicherfähigkeiten der mobilen Vorrichtung 700 zu erweitern. Eine Tastatur 706 kann mit der mobilen Vorrichtung 700 integriert oder drahtlos mit der mobilen Vorrichtung 700 verbunden sein, um zusätzliche Benutzereingabe bereitzustellen. Außerdem kann unter Verwendung des Berührungsschirms eine virtuelle Tastatur bereitgestellt werden. Außerdem kann eine Kamera 722, die sich auf der Vorderseite (Anzeigeschirm) oder der Rückseite der mobilen Vorrichtung 700 befindet, in das Gehäuse der mobilen Vorrichtung 700 integriert sein.

8 ist eine Blockdarstellung einer beispielhaften Computersystemmaschine, auf der beliebige oder mehrere der hier besprochenen Methodologien laufengelassen werden können. Das Computersystem 800 kann als die mobilen Vorrichtungen 104A, 104B, die mobile Vorrichtung 700 (von 1 und 7) oder eine beliebige andere hier beschriebene oder erwähnte Datenverarbeitungsplattform realisiert werden. Bei alternativen Ausführungsformen arbeitet die Maschine als selbständige Vorrichtung oder kann mit anderen Maschinen verbunden (z. B. vernetzt) werden. Bei einem vernetzen Einsatz kann die Maschine in der Kapazität entweder eines Servers oder einer Client-Maschine in Server-Client-Netzumgebungen arbeiten oder kann in Peer-to-Peer-(oder verteilten)Netzumgebungen als eine Peer-Maschine wirken. Die Maschine kann ein PC (Personal Computer) sein, der tragbar (z. B. ein Notebook oder ein Netbook) sein kann oder nicht, ein Tablet, eine STB (Set-Top Box), eine Spielkonsole, ein PDA (Personal Digital Assistant), ein Mobiltelefon oder Smartphone, ein Web-Gerät, ein Netzwerkrouter, -switch oder -bridge oder eine beliebige Maschine mit der Fähigkeit zur Ausführung von Anweisungen (sequenziell oder anderweitig), die Aktionen, die durch diese Maschine zu unternehmen sind, spezifizieren, sein. Ferner soll der Ausdruck „Maschine”, obwohl nur eine einzige Maschine dargestellt ist, auch als eine beliebige Ansammlung von Maschinen aufgefasst werden, die einzeln oder zusammen eine Menge (oder mehrere Mengen) von Anweisungen ausführen, um eine beliebige oder beliebig mehrere der hier besprochenen Methodologien auszuführen.

Das beispielhafte Computersystem 800 umfasst einen Prozessor 802 (z. B. eine Zentralverarbeitungseinheit (CPU), eine Graphikverarbeitungseinheit (GPU) oder beides), einen Hauptspeicher 804 und einen statischen Speicher 806, die über ein Verbindungselement 808 (z. B. eine Verknüpfung, einen Bus usw.) miteinander kommunizieren. Das Computersystem 800 kann ferner eine Videoanzeigeeinheit 810, eine alphanumerische Eingabevorrichtung 812 (z. B. eine Tastatur) und eine Benutzeroberflächen- bzw. UI-Navigationsvorrichtung 814 (z. B. eine Maus) umfassen. Bei einer Ausführungsform sind die Videoanzeigeeinheit 810, die Eingabevorrichtung 812 und die UI-Navigationsvorrichtung 814 eine Berührungsschirmanzeige. Das Computersystem 800 kann zusätzlich eine Speicherungsvorrichtung 816 (z. B. eine Laufwerkeinheit), eine Signalerzeugungsvorrichtung 818 (z. B. einen Lautsprecher), eine Ausgangssteuerung 832, eine Power-Management-Steuerung 834 und eine Netzwerkschnittstellenvorrichtung 820 (die eine oder mehrere Antennen 830, Sendeempfänger oder andere drahtlose Kommunikationshardware umfassen oder wirksam damit kommunizieren kann) und einen oder mehrere Sensoren 828, wie etwa einen GPS-Sensor, Kompass, Ortssensor, Beschleunigungsmesser oder anderen Sensor, umfassen.

Die Speicherungsvorrichtung 816 umfasst ein maschinenlesbares Medium 822, auf dem eine oder mehrere Mengen von Datenstrukturen und Anweisungen 824 (z. B. Software) gespeichert sind, die eine beliebige oder mehrere der hier beschriebenen Methodologien oder Funktionen realisieren oder benutzen. Die Anweisungen 824 können auch ganz oder zumindest teilweise im Hauptspeicher 804, statischen Speicher 806 und/oder im Prozessor 802 während der Ausführung dieser durch das Computersystem 800 residieren, wobei der Hauptspeicher 804, der statische Speicher 806 und der Prozessor 802 auch maschinenlesbare Medien darstellen.

Obwohl das maschinenlesbare Medium 822 bei einer beispielhaften Ausführungsform als ein einziges Medium dargestellt ist, kann der Ausdruck „maschinenlesbares Medium” ein einziges Medium oder mehrere Medien (z. B. eine zentralisierte oder verteilte Datenbank und/oder zugeordnete Caches und Server) umfassen, die die eine oder die mehreren Anweisungen 824 speichern. Der Ausdruck „maschinenlesbares Medium” soll auch so aufgefasst werden, dass er ein beliebiges greifbares Medium umfasst, das Anweisungen zur Ausführung durch die Maschine, und die bewirken, dass die Maschine eine oder mehrere der Methodologien der vorliegenden Offenbarung ausführt, oder das durch solche Anweisungen benutzte oder damit assoziierte Datenstrukturen speichern, codieren oder tragen kann. Der Ausdruck „maschinenlesbares Medium” soll dementsprechend so aufgefasst werden, dass er, aber nicht beschränkt darauf, Halbleiterspeicher und optische und magnetische Medien umfasst. Spezifische Beispiele für maschinenlesbare Medien wären nichtflüchtiger Speicher, darunter zum Beispiel Halbleiterspeichervorrichtungen (z. B. EPROM (Electrically Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory)) und Flash-Speichervorrichtungen; magnetische Datenträger wie interne Festplatten und wechselbare Datenträger; magnetooptische Datenträger; und CD-ROM- und DVD-ROM-Disks.

Die Anweisungen 824 können ferner unter Verwendung eines Übertragungsmediums über die Netzwerkschnittstellenvorrichtung 820 unter Verwendung eines beliebigen einer Anzahl wohlbekannter Transferprotokolle (z. B. HTTP) über ein Kommunikationsnetz 826 übertragen oder empfangen werden. Beispiele für Kommunikationsnetze wären ein LAN (Local Area Network), ein WAN (Wide Area Network), das Internet, Mobiltelefonnetze, POTS-Netze (Plain Old Telephone) und drahtlose Datennetzwerke (z. B. WiFi, 3G- und 4G-LTE/LTE-A- oder -WiMAX-Netze). Der Ausdruck „Übertragungsmedium” soll so aufgefasst werden, dass er jedes nichtgreifbare Medium umfasst, das Anweisungen zur Ausführung durch die Maschine speichern, codieren oder tragen kann, und umfasst digitale oder analoge Kommunikationssignale oder ein anderes nichtgreifbares Medium zur Ermöglichung von Übermittlung solcher Software.

Es können andere anwendbare Netzkonfigurationen im Schutzumfang der vorliegend beschriebenen Kommunikationsnetze enthalten sein. Obwohl Beispiele mit Bezug auf eine Konfiguration eines lokalen drahtlosen Netzwerks und eine großflächige Internet-Netzwerkverbindung gegeben wurden, versteht sich, dass Kommunikation auch unter Verwendung einer beliebigen Anzahl von persönlichen Netzwerken, LANs und WANs unter Verwendung einer beliebigen Kombination von verdrahteten oder drahtlosen Übertragungsmedien ermöglicht werden kann.

Die oben beschriebenen Ausführungsformen können in Hardware, Firmware und Software oder einer Kombination daraus implementiert werden. Ausführungsformen können auch als Anweisungen implementiert werden, die auf einer computerlesbaren Speicherungsvorrichtung gespeichert sind, die durch mindestens einen Prozessor gelesen und ausgeführt werden können, um die hier beschriebenen Operationen auszuführen. Eine computerlesbare Speicherungsvorrichtung kann einen beliebigen nichttransitorischen Mechanismus zur Speicherung von Informationen in einer durch eine Maschine (z. B. einen Computer) lesbaren Form umfassen. Eine computerlesbare Speicherungsvorrichtung kann zum Beispiel Festwertspeichert (ROM), Direktzugriffsspeicher (RAM), magnetische Plattenspeichermedien, optische Speichermedien, Flash-Speichervorrichtungen und andere Speicherungsvorrichtungen und -medien umfassen.

Es versteht sich, dass die in der vorliegenden Beschreibung beschriebenen Funktionseinheiten oder Fähigkeiten als Komponenten oder Module erwähnt oder bezeichnet worden sein können, um ihre Implementierungsunabhängigkeit genauer zu betonen. Zum Beispiel kann eine Komponente oder ein Modul als eine Hardwareschaltung implementiert werden, die VLSI-Schaltungen (Very-Large-Scale Integration) oder Gatearrays, handelsübliche Halbleiter, wie Logikchips, Transistoren oder andere diskrete Komponenten, umfasst. Eine Komponente oder ein Modul kann auch in programmierbaren Hardwarevorrichtungen wie am Einsatzort programmierbaren Gatearrays, programmierbarer Arraylogik, programmierbaren Logikvorrichtungen oder dergleichen implementiert werden. Komponenten oder Module können auch in Software zur Ausführung durch verschiedene Arten von Prozessoren implementiert werden. Eine identifizierte Komponente oder ein identifiziertes Modul ausführbaren Codes kann zum Beispiel einen oder mehrere physische oder logische Blöcke von Computeranweisungen umfassen, die zum Beispiel als ein Objekt, eine Prozedur oder eine Funktion organisiert sein können. Dessen ungeachtet müssen die ausführbaren Dateien einer identifizierten Komponente oder eines identifizierten Moduls sich nicht physisch beieinander befinden, sondern können getrennte Anweisungen umfassen, die an verschiedenen Orten gespeichert werden, die, wenn sie logisch miteinander verbunden werden, die Komponente oder das Modul umfassen und den angegebenen Zweck für die Komponente oder das Modul erreichen.

Tatsächlich kann eine Komponente oder ein Modul ausführbaren Codes eine einzige Anweisung oder viele Anweisungen sein und kann sogar über mehrere verschiedene Codesegmente, über verschiedene Programme und über mehrere Speichervorrichtungen hinweg verteilt sein. Ähnlich können Operationsdaten hier in Komponenten oder Modulen identifiziert und dargestellt sein und können in einer beliebigen geeigneten Form und in einer beliebigen geeigneten Art von Datenstruktur organisiert realisiert sein. Die Operationsdaten können als eine einzige Datenmenge gesammelt oder über verschiedene Orte, einschließlich über verschiedene Speicherungsvorrichtungen, verteilt sein und können mindestens teilweise lediglich als elektronische Signale in einem System oder Netzwerk existieren. Die Komponenten oder Module können passiv oder aktiv sein, einschließlich Agenten mit der Fähigkeit zur Ausführung gewünschter Funktionen.

Zusätzliche Beispiele für das vorliegend beschriebene Verfahren, das vorliegend beschriebene System und die vorliegend beschriebenen Vorrichtungsausführungsformen umfassen die folgenden nichteinschränkenden Konfigurationen. Jedes der folgenden nicht einschränkenden Beispiele kann für sich selbst stehen oder in einer beliebigen Permutation oder Kombination mit einem beliebigen oder mehreren der nachfolgend beliebigen oder im Verlauf der vorliegenden Offenbarung bereitgestellten Beispiele kombiniert werden.

Beispiel 1 umfasst den Gegenstand, der durch ein Verfahren realisiert wird, das in einem ANDSF-Server (Access Network Discovery and Selection Function) ausgeführt wird, um auf Anwendungen basierende Netzwerkroutingrichtlinien festzulegen, wobei das Verfahren Folgendes umfasst: Erhalten von Benutzergeräte- bzw. UE-Profilinformationen von einem UE-Profilknoten in einem ANDSF-Verwaltungsobjekt, wobei die UE-Profilinformationen für eine Konfiguration eines UE spezifisch sind; Bestimmen einer Anwendungsrichtlinie zum Offloading von Daten auf ein sekundäres Netz für eine bestimmte Softwareanwendung, die in der Konfiguration des UE arbeitet; Definieren eines Anwendungsknotens in einem Intersystem-Routingrichtlinien- bzw. ISRP-Knoten des ANDSF-Verwaltungsobjekts, wobei der Anwendungsknoten die Anwendungsrichtlinie zum Offloading von Daten auf das sekundäre Netz bereitstellt; und Bereitstellen der ISRP für das UE zur Implementierung der Anwendungsrichtlinie zum Offloading von Daten auf das sekundäre Netz.

In Beispiel 2 kann der Gegenstand von Beispiel 1 gegebenenfalls Bereitstellen der ISRP für das UE zur Implementierung durch Senden des ANDSF-Verwaltungsobjekts von dem ANDSF-Server zum UE umfassen, wobei der Anwendungsknoten einen für eine auf Fluss basierende Richtlinie des ISRP-Knotens definierten ersten Anwendungsknoten und einen für eine auf nicht nahtlosem Offload basierende Richtlinie des ISRP-Knotens definierten zweiten Anwendungsknoten umfasst.

In Beispiel 3 kann der Gegenstand eines oder einer beliebigen Kombination der Beispiele 1–2 gegebenenfalls Erhalten von UE-Profilinformationen von einem UE-Profilknoten in dem ANDSF-Verwaltungsobjekt durch Erhalten des ANDSF-Verwaltungsobjekts von dem UE während eines OMA-DM-Austauschs (Open Mobile Alliance Device Management) und Lesen des UE-Profilknotens von dem ANDSF-Verwaltungsobjekt umfassen, wobei das ANDSF-Verwaltungsobjekt in einem XML-Format (eXtensible Markup Language) strukturiert ist.

In Beispiel 4 kann der Gegenstand eines oder einer beliebigen Kombination der Beispiele 1–3 gegebenenfalls einen neuen Anwendungsknoten umfassen, der in der ISRP für jede Anwendung des UE enthalten ist, die für Aufnahme in die Anwendungsrichtlinie zum Offloading von Daten auf das sekundäre Netz identifiziert ist.

In Beispiel 5 kann der Gegenstand eines oder einer beliebigen Kombination der Beispiele 1–4 gegebenenfalls umfassen, dass die UE-Profilinformationen, die für eine Konfiguration eines UE spezifisch sind, Informationen zum Identifizieren mehrerer für die Konfiguration des UE spezifischer Softwareanwendungen umfassen.

In Beispiel 6 kann der Gegenstand eines oder einer beliebigen Kombination der Beispiele 1–5 gegebenenfalls umfassen, dass die Informationen zum Identifizieren mehrerer Softwareanwendungen, die für die Konfiguration des UE spezifisch sind, eines oder mehrere von Softwareversion, Hardwareversion, Hardwarearchitektur oder Betriebssystem angeben.

In Beispiel 7 kann der Gegenstand eines oder einer beliebigen Kombination der Beispiele 1–6 gegebenenfalls umfassen, dass der Anwendungsknoten eine Anwendungskennung umfasst, wobei mit der Anwendungskennung die bestimmte Softwareanwendung, die in der Konfiguration des UE arbeitet, eindeutig identifiziert wird.

In Beispiel 8 kann der Gegenstand eines oder einer beliebigen Kombination der Beispiele 1–7 gegebenenfalls umfassen, dass der ANDSF-Server in einem Evolved Packet Core bereitgestellt ist, der gemäß einem Standard aus einer 3GPP-LTE/LTE-A-Standardfamilie (Long Term Evolution oder Long Term Evolution-Advanced) arbeitet, wobei das sekundäre Zugangsnetz ein drahtloses lokales Netzwerk ist, das gemäß einem Standard aus einer IEEE-802.11-Standardfamilie arbeitet.

Beispiel 9 kann den Gegenstand eines oder einer beliebigen Kombination der Beispiele 1–8 ganz oder teilweise umfassen oder kann gegebenenfalls damit kombiniert werden, um den Gegenstand zu umfassen, der durch eine Multimodus-Benutzergeräte- bzw. –UE-Vorrichtung realisiert wird, umfassend: einen Sendeempfänger, ausgelegt zum Durchführen von Kommunikation mit einem auf Trägern basierenden drahtlosen Netz und mit einem drahtlosen lokalen Netzwerk; und Verarbeitungsschaltkreise, ausgelegt zum Implementieren einer oder mehrerer auf Anwendungen basierenden Netzwerkroutingrichtlinien, die von einem ANDSF-Server (Access Network Discovery and Selection Function) bereitgestellt werden, der in einem Evolved Packet Core des auf Trägern basierenden drahtlosen Netzes unterhalten wird, wobei die Verarbeitungsschaltkreise dafür ausgelegt sind, eine oder mehrere Anweisungen für Folgendes auszuführen: Senden von UE-Profilinformationen, die eine Hardware- und Softwarekonfiguration des UE umfassen, zu dem ANDSF-Server; Empfangen einer Anwendungs-Netzwerkroutingrichtlinie zum Offloading von Daten einer für Betrieb auf dem UE ausgelegten Softwareanwendung von dem ANDSF-Server, wobei die Anwendungs-Netzwerkroutingrichtlinie in einer Intersystem-Routingrichtlinie bzw.

ISRP eines ANDSF-Verwaltungsobjekts enthalten ist; und Durchführen von Offloading der von der Softwareanwendung erzeugten Daten auf das drahtlose lokale Netzwerk in Verbindung mit der ISRP und der Anwendungs-Netzwerkroutingrichtlinie zum Offloading von Daten.

In Beispiel 10 kann der Gegenstand von Beispiel 9 gegebenenfalls umfassen, dass die UE-Profilinformationen Informationen für eines oder mehrere von Softwareversion, Hardwareversion, Hardwarearchitektur oder Betriebssystem umfassen.

In Beispiel 11 kann der Gegenstand eines oder einer beliebigen Kombination der Beispiele 9–10 gegebenenfalls umfassen, dass die Anwendungs-Netzwerkroutingrichtlinie mehrere Knoten für mehrere Softwareanwendungen umfasst, die für Betrieb auf dem UE ausgelegt sind, wobei die mehreren Softwareanwendungen die Softwareanwendung umfassen und wobei jede der mehreren Softwareanwendungen eine Kennung umfasst, die für die bestimmte Softwareanwendung und eine Betriebsumgebung für die bestimmte Softwareanwendung spezifisch ist.

In Beispiel 12 kann der Gegenstand eines oder einer beliebigen Kombination der Beispiele 9–11 gegebenenfalls umfassen, dass die Anwendungs-Netzwerkroutingrichtlinie eine für eine auf Fluss basierende Richtlinie der ISRP definierte erste Anwendungs-Netzwerkroutingrichtlinie und eine für auf nicht nahtlosem Offload basierende Richtlinie der ISRP definierte zweite Anwendungs-Netzwerkroutingrichtlinie umfasst.

In Beispiel 13 kann der Gegenstand eines oder einer beliebigen Kombination der Beispiele 9–12 gegebenenfalls umfassen, dass die erste Anwendungs-Netzwerkroutingrichtlinie und die zweite Anwendungs-Netzwerkroutingrichtlinie jeweils einen Knoten für die Softwareanwendung umfassen, einschließlich mehrerer unterschiedlicher Anwendungsrichtlinien auf der Basis der Hardware- und Softwarekonfiguration des UE.

In Beispiel 14 kann der Gegenstand eines oder einer beliebigen Kombination der Beispiele 9–13 gegebenenfalls umfassen, dass das auf Trägern basierende drahtlose Netz gemäß einem Standard aus einer 3GPP-LTE/LTE-A-Familie (Long Term Evolution oder Long Term Evolution-Advanced) arbeitet, wobei das drahtlose lokale Netzwert gemäß einem Standard aus einer IEEE-802.11-Standardfamilie arbeitet.

Beispiel 15 kann den Gegenstand eines oder einer beliebigen Kombination der Beispiele 1–14 ganz oder teilweise umfassen oder gegebenenfalls damit kombiniert werden, um den Gegenstand zu umfassen, der durch ein Verfahren realisiert wird, das durch ein Benutzergerät (UE) zur Implementierung einer auf Anwendungen basierenden Netzwerkroutingrichtlinie ausgeführt wird, wobei das Verfahren Folgendes umfasst: Einem ANDSF-Server werden UE-Profilinformationen für eine Hardware- und Softwarekonfiguration des UE bereitgestellt; Empfangen einer Anwendungsrichtlinie zum Offloading von Daten für eine für Betrieb auf dem UE ausgelegte Softwareanwendung von dem ANDSF-Server, wobei die Anwendungsrichtlinie in einem ANDSF-Verwaltungsobjekt enthalten ist und für die Hardware- und Softwarekonfiguration des UE spezifisch ist; und Betreiben der Softwareanwendung in Verbindung mit der Anwendungsrichtlinie zum Offloading von Daten durch Routen von Daten in der Softwareanwendung zu einem Offloading-Netz gemäß Spezifikationen der Anwendungsrichtlinie.

In Beispiel 16 kann der Gegenstand von Beispiel 15 gegebenenfalls umfassen, dass die Anwendungsrichtlinie zum Offloading von Daten eine für eine auf Fluss basierende Richtlinie in einer Intersystem-Routingrichtlinie definierte erste Anwendungsrichtlinie und eine für eine auf nicht nahtlosem Offload basierende Richtlinie in der Intersystem- Routingrichtlinie definierte zweite Anwendungsrichtlinie umfasst.

In Beispiel 17 kann der Gegenstand eines oder einer beliebigen Kombination der Beispiele 15–16 gegebenenfalls Folgendes umfassen: Bestimmen, ob ein Verkehrs-Offloading auf Flussbasis oder nicht nahtloser Basis in der Softwareanwendung verfügbar ist, und Auswählen der ersten Anwendungsrichtlinie oder der zweiten Anwendungsrichtlinie auf der Basis der Bestimmung.

In Beispiel 18 kann der Gegenstand eines oder einer beliebigen Kombination der Beispiele 15–17 gegebenenfalls Betreiben einer zweiten Softwareanwendung in Verbindung mit der Anwendungsrichtlinie zum Offloading von Daten durch Routen von Daten in der zweiten Softwareanwendung zu dem Offloading-Netz gemäß Spezifikationen der Anwendungsrichtlinie umfassen, wobei die Anwendungsrichtlinie eine zweite Anwendungsrichtlinie zum Offloading von Daten für die zweite Softwareanwendung umfasst.

In Beispiel 19 kann der Gegenstand eines oder einer beliebigen Kombination der Beispiele 15–18 gegebenenfalls umfassen, dass die UE-Profilinformationen bezüglich einer Hardware- und Softwarekonfiguration des UE in einem Verwaltungsobjekt von dem UE während eines OMA-DM-Austauschs (Open Mobile Alliance Device Management) bereitgestellt werden.

Beispiel 20 kann den Gegenstand eines oder einer beliebigen Kombination der Beispiele 1–19 ganz oder teilweise umfassen oder gegebenenfalls damit kombiniert werden, um den Gegenstand zu umfassen, der durch eine Evolved-Packet-Core- oder ähnliche Systemkonfiguration realisiert wird, die sich über ein durch einen eNodeB (Evolved Node B) hergestelltes primäres drahtloses Netz in drahtloser Kommunikation mit einem Benutzergerät (UE) befindet, umfassend: einen ANDSF-Server (Access Network Discovery and Selection Function) in wirksamer Kommunikation mit dem eNodeB und ausgelegt zum Verwalten eines ANDSF-Verwaltungsobjekts zum Steuern des Offloading von Datenverkehr von einer oder mehreren in dem UE arbeitenden Softwareanwendungen auf ein entferntes sekundäres drahtloses Netzwerk und zum Austauschen des ANDSF-Verwaltungsobjekts mit dem UE; ein Paketdatennetzwerk-Gateway in wirksamer Kommunikation mit dem eNodeB und dem entfernten sekundären drahtlosen Netzwerk und ausgelegt zum Ermöglichen des Offloading des Datenverkehrs auf das entfernte sekundäre drahtlose Netzwerk; wobei der ANDSF-Server ausgelegt ist zum Ausführen von Operationen zum Zugreifen auf in einem Benutzergeräte-Profilknoten des ANDSF-Verwaltungsobjekts enthaltene UE-Profilinformationen, wobei die UE-Profilinformationen für eine Betriebskonfiguration des UE spezifisch sind; Definieren eines Anwendungsknotens zur Aufnahme in einen ISRP-Knoten (Zwischensystem-Routingrichtlinie) des ANDSF-Verwaltungsobjekts, wobei der Anwendungsknoten eine oder mehrere anwendungsspezifische Richtlinien zum Offloading von Daten für die in dem UE arbeitenden Softwareanwendungen bereitstellt und die anwendungsspezifischen Richtlinien Offloading auf das entfernte sekundäre drahtlose Netzwerk für die in dem UE arbeitenden Softwareanwendungen steuern; und Bereitstellen des ANDSF-Verwaltungsobjekts einschließlich des ISRP-Knotens für das UE zur Implementierung der anwendungsspezifischen Richtlinien.

In Beispiel 21 kann der Gegenstand von Beispiel 20 gegebenenfalls umfassen, dass der ANDSF-Server ausgelegt ist zum Ausführen von Operationen zum Bestimmen der anwendungsspezifischen Richtlinien zum Offloading von Daten für eine bestimmte Softwareanwendung der Softwareanwendungen auf der Basis einer Hardware- und Software-Betriebskonfiguration der bestimmten Softwareanwendung, die durch die UE-Profilinformationen angegeben wird.

In Beispiel 22 kann der Gegenstand eines oder einer beliebigen Kombination der Beispiele 20–21 gegebenenfalls umfassen, dass die Hardware- und Software-Betriebskonfiguration der bestimmten Softwareanwendung, die durch die UE-Profilinformationen angegeben wird, Informationen umfasst, die die bestimmte Softwareanwendung unter Verwendung von Softwareversion und/oder Hardwareversion und/oder Hardwarearchitektur und/oder Betriebssystem identifizieren.

In Beispiel 23 kann der Gegenstand eines oder einer beliebigen Kombination der Beispiele 20–22 gegebenenfalls umfassen, dass der ISRP-Knoten Spezifikationen für Offloading auf Fluss-Basis und für Offloading auf nicht nahtloser Basis bereitstellt.

In Beispiel 24 kann der Gegenstand eines oder einer beliebigen Kombination der Beispiele 20–23 gegebenenfalls umfassen, dass der Anwendungsknoten eine Anwendungskennung umfasst, wobei die Anwendungskennung zum eindeutigen Identifizieren der in dem UE arbeitenden Softwareanwendungen verwendet wird, wobei das ANDSF-Verwaltungsobjekt in einem XML-Format (eXtensible Markup Language) strukturiert ist.

In Beispiel 25 kann der Gegenstand eines oder einer beliebigen Kombination der Beispiele 20–24 gegebenenfalls umfassen, dass der Evolved Packet Core Operationen gemäß einem Standard aus einer 3GPP-LTE/LTE-A-Standardfamilie (Long Term Evolution oder Long Term Evolution-Advanced) ausführt, wobei das entfernte sekundäre drahtlose Netzwerk ein drahtloses lokales Netzwerk ist, das gemäß einem Standard aus einer IEEE-802.11-Standardfamilie arbeitet.

Die Zusammenfassung wird bereitgestellt, um es dem Leser zu erlauben, die Beschaffenheit und das Wesentliche der technischen Offenbarung zu bestimmen. Sie wird mit dem Verständnis unterreicht, dass sie nicht zum Begrenzen oder Deuten des Schutzumfangs oder der Bedeutung der Ansprüche verwendet wird. Die folgenden Ansprüche werden hiermit in die ausführliche Beschreibung integriert, wobei jeder Anspruch für sich als separate Ausführungsform steht.

ZITATE ENTHALTEN IN DER BESCHREIBUNG

Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.

Zitierte Nicht-Patentliteratur

  • IEEE-802.11-Standard [0003]
  • IEEE-802.16-Standard [0003]
  • IEEE-802.11-Standardfamilie [0019]
  • IEEE-802.11-Standardfamilie [0088]
  • IEEE-802.11-Standardfamilie [0095]
  • Richtlinie in der Intersystem- [0097]
  • IEEE-802.11-Standardfamilie [0106]