DE60306754T2

DE60306754T2 - Verfahren zum Herunterladen von Software mit Unterstützung von mobilen Sitzungen in Mobilkommunikationssystemen

Info

Publication number: DE60306754T2
Application number: DE60306754T
Authority: DE
Inventors: Francesca Bossoli; Stefano Micocci; Gianluca Ravasio
Original assignee: Siemens SpA
Current assignee: Siemens AG
Priority date: 2003-05-21
Filing date: 2003-05-21
Publication date: 2007-07-12
Anticipated expiration: 2023-05-22
Also published as: ATE333182T1; EP1480408B1; DE60306754D1; US7346027B2; CN1574838A; US20040233866A1; CN1574838B; ES2268319T3; EP1480408A1

Description

Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich auf die Mobilkommunikation auf Basis des Internet-Protokolls (IP) und betrifft spezieller ein Verfahren zum Herunterladen von Software mit Unterstützung von mobilen Sitzungen in Mobilkommunikationssystemen, sowie auf ein Mobilkommunikationssystem, in dem dieses Verfahren zur Anwendung kommt.
Hintergrund der Erfindung
Mobilkommunikationssysteme der Zukunft über die dritte Generation (3G) hinaus werden gekennzeichnet sein durch ein Nebeneinander einer Mehrzahl von Zugangstechnologien wie etwa zellularer Mobilfunk (in verschiedenen Generationen, insbesondere zweite und dritte Generation), schnurlos, drahtlose Ortsnetze (WLAN, Wireless Local Area Network), Fernsehsysteme, drahtgebundene Systeme etc. Diese Systeme werden auf einer gemeinsamen Plattform integriert sein, so dass sie sich gegenseitig in optimaler Weise ergänzen können und die unterschiedlichsten Service-Anforderungen erfüllt werden. Die verschiedenen Zugangssysteme werden mit einem gemeinsamen, flexiblen und nahtlosen IP-Kernnetz („Core") verbunden sein.
Vor dem Hintergrund der zunehmenden Nutzung von Internetähnlichen mobilen Datenanwendungen in den bestehenden zellularen Mobilfunknetzen geht eine mögliche Weiterentwicklung dieser Netze in Richtung Definition einer gemeinsamen Transportschicht, die auf dem Internet-Protokoll IP basiert. Die Beweggründe für diese Option lassen sich in den folgenden Punkten kurz zusammenfassen:

– Das Kernnetz und das Funkzugangsnetz haben dieselbe Transportschicht;
– Basisstationen mit unterschiedlichen Funkzugangstechnologien (RAT, Radio Access Technologies) können mittels desselben Transportprotokolls (des IP) mit der Funknetzsteuerung verbunden werden;
– Das zellulare Mobilfunknetz und das Internet nutzen dasselbe Transportprotokoll, was die Integration von Netz- und Anwendungsdomänen erleichtert.

Folgt man diesem Ansatz, wird es erforderlich, den IP-Mechanismus auch für die Verwaltung der Mobilität des Endgeräts zu verwenden und so einen gemeinsamen Satz von Mobilitätsfunktionen zu haben, die in der Lage sind, die Endgerät-Mobilität unabhängig von der Funkzugangstechnologie sowie in Bezug auf das Kernnetz in einer integrierten Art und Weise zu verwalten. Dieser Ansatz kann mithilfe der Mobile IP- (MIP-) und Ipv6-Mechanismen verfolgt werden, jedoch scheinen diese nicht geeignet zu sein für Mikro- oder Piko-Mobilität. Es ist abzusehen, dass eine hierarchische Lösung (HMIP) und die Anwendung diverser Mechanismen integriert werden müssen, um eine Lösung für verschiedene Mobilitäts-Szenarien zu erhalten.
Aus Gründen der Klarheit werden hier einige der Definitionen verschiedener Mobilitätsarten in Erinnerung gerufen:

– Endgeräte-Mobilität: Die Fähigkeit des Endgeräts, den Standort zu verändern und dennoch weiter kommunizieren zu können. Endgeräte-Mobilität kann sein: – Diskrete Endgeräte-Mobilität: Die Fähigkeit des Endgeräts, diskrete Standortwechsel vorzunehmen, solange keine Anwenderdaten ausgetauscht werden, und dabei für kommende Anrufe erreichbar zu bleiben. Im Zusammenhang mit zellularem Mobilfunk bedeutet das Unterstützung von Roaming- und Paging-Prozeduren.
– Kontinuierliche Endgeräte-Mobilität: Die Fähigkeit, den Standort zu verändern, während gleichzeitig ein Austausch von Anwenderdaten läuft. Im Zusammenhang mit dem zellularen Mobilfunk bedeutet dies die Unterstützung der Handover-Prozedur. Diese wird als nahtlos bezeichnet, wenn die Dienstgüte (QoS, Quality of Service) nicht aufgrund von Verzögerungen oder Datenverlusten während des Handovers beeinträchtigt wird.
– Persönliche Mobilität: Die Fähigkeit des Endanwenders, an jedem beliebigen Endgerät an jedem beliebigen Standort (d. h. mithilfe unterschiedlicher Zugangstechnologien), das/der durch seinen Vertrag abgedeckt ist, Anrufe zu tätigen und zu empfangen. Das bedeutet, dass das Netz in der Lage ist, anhand der Registrierungsinformationen den Endanwender zu erreichen und Lokalisierungsfunktionen durchzuführen, statt auf Grundlage der Endgerät-Informationen.
– Sitzungs-Mobilität: Die Fähigkeit des Endanwenders, das Endgerät zu wechseln. Diese lässt sich in folgende Kategorien untergliedern: – Diskrete Sitzungs-Mobilität: Die Fähigkeit, das Endgerät zu wechseln, solange keine Anwenderdaten ausgetauscht werden, und dabei für kommende Anrufe erreichbar zu bleiben. Im Zusammenhang mit zellularem Mobilfunk bedeutet das, in der Lage zu sein, die Sitzung einem neuen Endgerät und einem neuen Standort im Netz zuzuweisen. – Kontinuierliche Sitzungs-Mobilität: Die Fähigkeit, das Endgerät zu wechseln, während gleichzeitig Anwenderdaten ausgetauscht werden.

Zur Vervollständigung des Bildes können wir außerdem definieren:

– Service-Mobilität: Die Fähigkeit eines Anwenders, die Dienste, für die er angemeldet ist, unabhängig von dem Standort des Anwenders und dem verwendeten Endgerät auszuführen.

Das neue zellulare Mobilfunknetz wird in der Lage sein, neue Mehrwertdienste bereitzustellen, die aller Wahrscheinlichkeit nach aus dem Internet-Bereich stammen und dem Anwender über eine Vielfalt unterschiedlicher Funkzugangstechnologien (beispielsweise 3G, WLAN etc.) bereitgestellt werden. Das Endgerät wird über die Fähigkeit verfügen, jedwede Art von Zugang zu unterstützen, d. h. es wird ein multimodales und, vorzugsweise, rekonfigurierbares Endgerät sein. In diesem Szenario werden im Netz alle diejenigen Funktionen implementiert sein, die zur Unterstützung der Rekonfiguration eines Endgeräts durch effiziente Nutzung der Funkressourcen benötigt werden. Es ist offensichtlich, dass sich bei dem Wechsel von einer Funkzugangstechnologie zu einer anderen (d. h. bei Ausführung eines so genannten „vertikalen Handover" oder „VHO") ein multimodales oder ein rekonfigurierbares Endgerät wie ein anderes Endgerät verhält, so dass das Problem, die für den Wechsel des Endgeräts relevanten Mobilitäts-Leistungsmerkmale zu unterstützen, durch das Netz sichergestellt werden muss.
Unter den neuen Diensten kann das Herunterladen von Software (Software-Download) erwähnt werden, wobei das Netz in der Lage sein muss, die optimale Strategie für seine Durchführung zu bestimmen und durchzuführen. Die Mobilfunkindustrie steht kurz davor, das Herunterladen von Medien-Objekten im Stile des Internet in großem Maßstab und unabhängig von dem Medientyp einzuführen. Einer der Bereiche für den Einsatz dieser Technologie ist der elektronische Handel, E-Commerce. Die wahrscheinlichsten Objekte in der Anfangsphase dieses Geschäfts werden Klingeltöne, Bildschirmschoner, Spiele und Java-Midlets sein.
In dem beschriebenen Szenario kann es vorkommen, dass ein Anwender mit einem multimodalen Endgerät das Herunterladen (Download) einer Software startet und während das Download noch läuft aus irgendeinem Grund (außerhalb des Funkversorgungsbereichs, Notwendigkeit zur Beschleunigung des Vorgangs etc.) ein vertikales Handover durchführen muss, beispielsweise von GPRS (General Packet Radio Service, allgemeiner Paketfunkdienst) zu UMTS (Universal Mobile Telecommunications Service, universeller mobiler Telekommunikationsdienst) oder von einem zellularen Mobilfunknetz zu einem WLAN.
Für das Herunterladen (Download) von Software besteht im Allgemeinen keine Echtzeiterfordernis. Im Fall eines vertikalen Handovers entsteht somit ein ernsthaftes Problem. Die Mobility-Management-Unterstützung während des Herunterladens der Software wird von dem Netzbetreiber mithilfe der klassischen SGSN- (Service GPRS Support Node) Standortwechsel-Prozedur sichergestellt, bei der die Informationen an den neuen Standort des Endgeräts umgeleitet werden. Allerdings unterstützt diese Prozedur die Sitzungs-Mobilität während horizontaler Handover, bei denen das Endgerät den Standort wechselt, aber im Bereich desselben Funkzugangsnetzes RAT bleibt. Für den Fall des vertikalen Handovers ist bislang noch kein Mechanismus implementiert, mit dem diese Art der Neuzuweisung bewältigt werden kann. In diesem Fall muss das Software-Download abgebrochen werden und es muss, nach Identifikation der neuen Position des Endgeräts, das Herunterladen der Software wieder ganz von Anfang gestartet werden.
Wenn die Software nur einen relativ geringen Umfang hat, wirkt sich dieser Vorgang nur geringfügig auf die Dienstgüte QoS und auf zusätzliche Belastung des Netzes aus (d. h. es werden mehr Netzressourcen für die Neuübertragung der Software in Anspruch genommen). Hat die herunterzuladende Software aber einen sehr großen Umfang, wird die Implementierung von Mechanismen, mit denen eine erneute Übertragung vermieden werden kann, unabdingbar, um Funknetzressourcen zu sparen und die Download-Prozedur zu beschleunigen. Ferner ist es möglich, dass eine Klasse von Software mit hoher Priorität heruntergeladen und installiert werden muss (beispielsweise neue Betriebssysteme, neue Funkübertragungsketten, neue Protokollstapel, ...). Für diese Klasse von Software ist es ebenfalls wichtig, erneute Übertragungen zu vermeiden.
Damit ist klar, dass in kurzer Zeit die Netzarchitektur alle Funktionalitäten umfassen muss, die in der Lage sind, die Rekonfiguration und das Herunterladen von Software in einem heterogenen Funkzugangszusammenhang effektiv zu unterstützen.
Für den Aufbau und die Verwaltung einer IMS- (IP-Multimedia-Subsystem-) Sitzung, die für paketorientierte Dienste vorgesehen ist, welche keine Echtzeitbeschränkungen aufweisen, hat die 3GPP (3rd Generation Project Partnership) das Session Initiation Protocol (SIP) als Referenzprotokoll vorgeschlagen (siehe etwa die 3GPP-Spezifikation TS 23.228). Das SIP-Protokoll ist ein (Signalisierungs-) Protokoll der Anwendungsschicht für den Aufbau, die Modifikation und den Abbau von Sitzungen mit einem oder mehreren Teilnehmer(n) sowohl für Unicast- als auch für Multicast-Sitzungen, das in der Internet Engineering Task Force standardisiert wurde (siehe beispielsweise den IETF-Standard RFC 3261, der Gegenstand des Dokuments „SIP: Session Initiation Protocol" von J. Rosenberg und H. Schulzrinne ist, das auf der Internet-Seite http://www.ietf.org/rfc.html zur Verfügung steht).
Der Einsatz eines solchen Protokolls zur Unterstützung der Anpassung von Anwendungen für IP-Anwendungen während eines vertikalen Handovers wurde bereits betrachtet, siehe beispielsweise das Papier „End-to-End SIP Based Real Time Application Adaptation During Unplanned Vertical Handovers" (Durchgängige Anpassung SIP-basierter Echtzeitanwendungen bei nicht geplanten vertikalen Handovers) von P. A. Pangalos et al., GLOBECOM '01, IEEE Global Telecommunications Conference, San Antonio (Texas, USA, 25.–29. November 2001), Bd. 6, S. 3488–3493. Dieses Papier beschreibt Praxistests und enthält eine Auswertung einer solchen Verwendung für vertikale Handovers von mobilen Endgeräten, die an einer Echtzeit-Audio-Verbindung beteiligt sind. Wie bekannt zeichnet sich Echtzeit-Verkehr durch sehr strenge Beschränkungen hinsichtlich zeitlicher Verzögerungen aus, erlaubt jedoch den Verlust einiger Datenpakete während des Handovers. Somit sind die in dem besagten Papier enthaltenen Vorschläge nicht geeignet für ein nicht in Echtzeit erfolgendes Herunterladen von Software, bei dem ein Verlust von Datenpaketen nicht toleriert werden kann und es unter Umständen notwendig macht, das gesamte heruntergeladene Softwarepaket erneut zu übertragen. Ferner beruhen die Vorschläge des Papiers auf der Verwendung der so genannten „Re-Invite"-Prozedur. Eine solche Prozedur zielt jedoch immer darauf ab, eine neue Sitzung aufzubauen, nachdem der Anwender das Handover abgeschlossen hat, und eignet sich daher nicht zur Lösung des hier interessierenden Problems.
Aufgaben der Erfindung
Die hauptsächliche Aufgabe der vorliegenden Erfindung ist es, die Nachteile des derzeitigen Standes der Technik zu überwinden und die Sitzungs-Mobilität während eines nicht echtzeitbasierten Prozesses zum Herunterladen von Software in einem heterogenen Funkzugangsschema sicherzustellen, insbesondere bei einem vertikalen Handover.
Zusammenfassung der Erfindung
Gemäß einem ersten Aspekt stellt die Erfindung ein Verfahren zum nicht echtzeitbasierten Herunterladen von Software in einem Internet-Protokoll- (IP-) basierten Mobilkommunikationssystem mit heterogenen Zugangstechnologien bereit, bei dem Software-Download-Sitzungen mithilfe des Session Initiation Protocol (SIP) aufgebaut und verwaltet werden. Für die Wiederaufnahme des Download-Vorgangs im Falle eines Handovers zwischen einem ersten und einem zweiten Funkzugangsnetz, die verschiedene Zugangstechnologien nutzen, während eine Software-Download-Sitzung noch läuft, sendet der SIP-User-Agent, der mit einem das Handover durchführenden Anwender-Endgerät verknüpft ist, ohne die laufende Sitzung auszulösen, bei Empfang einer neuen IP-Adresse und einer neuen URL in dem zweiten Funkzugangsnetz eine Nachricht mit einer Umleitungs-Anfrage („Refer"-Nachricht) an einen SIP-Proxy-Server, der die Download-Sitzung aufgebaut hat und derzeit verwaltet, wobei die besagte Nachricht Informationen zu der Adresse und der URL in dem ersten Funkzugangsnetz, der neuen URL, der Kennung der Sitzung und dem letzten Software-Datenpaket enthält, das erfolgreich empfangen wurde, wobei der besagte Proxy-Server auf diese Weise informiert wird, dass die Sitzung an den User-Agent an der neuen URL umzuleiten ist, und die notwendigen Schritte einleitet, um eine neue Sitzung mit dem User-Agent an der neuen URL aufzubauen, unter der Kontrolle eines Proxy-Servers, dessen Aufgabe es ist, die neue Sitzung zu verwalten und dafür zu sorgen, dass der Download-Vorgang beginnend bei dem besagten zuletzt empfangenen Datenpaket wieder aufgenommen wird.
Gemäß einem zweiten Aspekt stellt die Erfindung ein Internet-Protokoll- (IP-) basiertes Mobilkommunikationssystem mit heterogenen Zugangstechnologien zu einem Kernnetz bereit, das mindestens ein Serving and Gateway Mobile Switching Centre und GPRS Support Nodes (S-MSC/SGSN und G-MSC/GGSN) umfasst und in dem ein nicht echtzeitbasiertes Herunterladen von Software gemäß dem vorstehend beschriebenen Verfahren ausgeführt wird. In einem derartigen System hat zumindest ein Teil der Anwender Zugang zu Einrichtungen für das nicht echtzeitbasierte Herunterladen von Software und verfügt über die nötigen Endgeräte, um eine Verbindung zu dem System über eine Mehrzahl der besagten Zugangstechnologien herstellen zu können, wobei die besagten Endgeräte der Anwender sowie das Systemzugangs- und das Kernnetz mit Mitteln ausgestattet sind, unter anderen User-Agent-Anwendungen sowie Proxy- und Registrar-Servern, mit deren Hilfe Software-Download-Sitzungen über das Session Initiation Protocol (SIP) aufgebaut und verwaltet werden können. Für die Wiederaufnahme des Download-Vorgangs im Falle eines Handovers zwischen einem ersten und einem zweiten Funkzugangsnetz, die verschiedene Zugangstechnologien nutzen, während eine Software-Download-Sitzung noch läuft, ist der SIP-User-Agent, der mit einem das Handover durchführenden Anwender-Endgerät verknüpft ist, dafür ausgelegt, ohne die laufende Sitzung aufzulösen, bei Empfang einer neuen IP-Adresse und einer neuen URL in dem zweiten Funkzugangsnetz eine Nachricht mit einer Umleitungs-Anfrage („Refer"-Nachricht) an einen SIP-Proxy-Server zu senden, der die Download-Sitzung aufgebaut hat und derzeit verwaltet, wobei die besagte Umleitungs-Anfrage Informationen zu der Adresse und der URL in dem ersten Funkzugangsnetz, der neuen URL, der Kennung der Sitzung und dem letzten Software-Datenpaket enthält, das erfolgreich empfangen wurde, wobei der besagte Proxy-Server auf diese Weise informiert wird, dass die Sitzung an den User-Agent an der neuen URL umzuleiten ist, und dafür ausgelegt ist, die notwendigen Schritte einzuleiten, um eine neue Sitzung mit dem User-Agent an der neuen URL aufzubauen, und zwar unter der Kontrolle eines Proxy-Servers, dessen Aufgabe es ist, die besagte neue Sitzung zu verwalten, und der Download-Vorgang beginnend bei dem besagten zuletzt empfangenen Datenpaket wieder aufgenommen wird.
Kurze Beschreibung der Zeichnungen
Die Erfindung wird besser verständlich anhand der folgenden Beschreibung einer bevorzugten Ausführungsform, die beispielhaft und ohne jeden einschränkenden Charakter angeführt wird, unter Bezugnahme auf die beigefügten Zeichnungen, wobei:
1 ein Referenz-Szenario des Einsatzes der vorliegenden Erfindung zeigt;
2 ein Blockdiagramm ist, das die an der Rekonfiguration und der Verwaltung des Herunterladens der Software beteiligten Einheiten mehr ins Detail gehend zeigt;
3 ein vereinfachtes Blockdiagramm ist, das die Wege der SIP-Nachrichten für das Herunterladen von Software in einem ersten Beispiel des Einsatzes der Erfindung zeigt;
4 eine Grafik des Signalisierungsverlaufs für den in 3 dargestellten Download-Vorgang darstellt;
5 und 6 ein Blockdiagram bzw. eine Grafik ähnlich den 3 bzw. 4 sind, bezogen auf das Herunterladen von Software gemäß einem zweiten Beispiel des Einsatzes der Erfindung;
7 und 8 ein Blockdiagram bzw. eine Grafik ähnlich den 3 bzw. 4 sind und die Wiederaufnahme des Herunterladens von Software wie in den 3 und 4 betrachtet zeigen; und
9 und 10 ein Blockdiagram bzw. eine Grafik ähnlich den 7 bzw. 8 sind und die Wiederaufnahme des Herunterladens von Software wie in den 5 und 6 betrachtet zeigen.
Beschreibung der bevorzugten Ausführungsform
1 zeigt schematisch ein Mobilkommunikationssystem, in dem die vorliegende Erfindung zum Einsatz kommen kann. Ein Endgerät UE, bei dem es sich um ein multimodales Endgerät oder ein rekonfigurierbares Endgerät handeln kann, kann Zugang zu dem System über eine Mehrzahl von unterschiedlichen Funkzugangstechnologien und somit über verschiedene Funkzugangsnetze RATa, RATb, ... RATn haben. Der Teil des Systems, der von dem Zugangsverfahren unabhängig ist, wird gemäß der Terminologie der 3GPP als Kernnetz bezeichnet und wird hier mit CN (= Core Network) gekennzeichnet.
Die Abbildung zeigt beispielhaft die Funkzugangsnetze RATa, RATb zellularer Systeme der dritten bzw. der zweiten Generation sowie ein drahtloses Ortsnetz (WLAN oder Hotspot) RATn. In jedem Block RATi (i = a ... n) sind die konventionellen Einheiten des jeweiligen Mobilkommunikationssystems mit ihren gewöhnlichen Bezeichnungen oder Abkürzungen angegeben, nämlich Knoten B und Funknetzsteuerung RNC (= Radio Network Control) für das Netz der dritten Generation RATa, Funk-Basisstation BTS (= Base Transceiver Station) und Basisstationssteuerung BSC (= Base Station Controller) für das Netz der zweiten Generation RATb, Zugangspunkt AP (= Access Point) und Interworking-Einheit IWU (= Interworking Unit) für das drahtlose LAN RATn. Zu diesen Einheiten ist hier keine spezifische Beschreibung erforderlich. In dem Funkzugangsnetz RATa sind zwei Einheiten Knoten B dargestellt, NB1 und NB2. Analog hierzu sind die konventionelle Heimatdatei HLR (= Home Location Register) sowie die Serving and Gateway Mobile Switching Centres und GPRS Support Nodes S-MSC/SGSN bzw. G-MSC/GGSN im Kernnetz CN dargestellt. Aus Gründen der Übersichtlichkeit wird innerhalb des Kernnetzes CN lediglich eine einzige SGSN-Einheit betrachtet. Die Verbindung dieser Einheit mit anderen SGSN-Einheiten ist jedoch dargestellt, ebenso wie die Verbindungen des Kernnetzes CN zur festnetzbasierten Internet-Umgebung (über GGSN) und zu anderen Kernnetzen (über SGSN).
Das Endgerät UE wird angenommen als über den Knoten NB2 im Funkzugangsnetz RATa mit dem System verbunden, wie durch die durchgezogene Pfeillinie dargestellt, mit der Möglichkeit, sowohl horizontale Handover (zum Knoten NB1 in demselben Funkzugangsnetz RATa) als auch vertikale Handover (zum Funkzugangsnetz RATb, ... RATn, dargestellt durch die gestrichelten Pfeillinien) durchzuführen.
Um die Rekonfiguration der Endgeräte und das Herunterladen von Software unterstützen zu können, beinhalten die Funkzugangsnetze RATa ... RATn ferner Einheiten zur Verwaltung von Rekonfigurations- und Download-Vorgängen PRMa, PRMb ... PRMn (= Proxy Reconfiguration Manager), welche der Funknetzsteuerung RNC, der Basisstationssteuerung BSC bzw. der Interworking-Einheit IWU zugeordnet oder in diesen enthalten sein können.
Das Kernnetz CN (das Heimatnetz des Endgeräts UE, das in der Abbildung dargestellt ist) ist mit Einheiten SRM (Serving Reconfiguration Manager) und HRM (Home Reconfiguration Manager) einer höheren Ebene ausgestattet, welche den Einheiten S-MSC/SGSN bzw. HLR zugeordnet oder in diesen enthalten sein können. Mit „Rekonfiguration" wird im vorliegenden Fall die Gesamtheit der Funktionen angesprochen, die es einem Endgerät ermöglichen, von einem Funkzugangsverfahren zu einem andern zu wechseln, unabhängig davon, ob es sich um ein multimodales oder um ein rekonfigurierbares Endgerät handelt. Zu beachten ist, dass die Endgeräte gegebenenfalls die für die Rekonfiguration benötigte Software einschließlich der Funkzugangsverfahren aus dem Netz herunterladen können.
Die Einheiten PRMi (i = a ... n), SRM und HRM bilden eine verteilte, hierarchische Struktur mit drei Ebenen, die sich über verschiedene Netzdomänen erstrecken, wobei die HRM-Einheit (Home Reconfiguration Manager) die oberste und die PRMi-Einheit (Proxy Reconfiguration Manager) die unterste Ebene darstellt. Eine hierarchische verteilte Struktur minimiert die Netzbelastung und beschleunigt das Herunterladen von Software.
Die Funktionen der Einheiten PRM, SRM, HRM für die Rekonfiguration und das Herunterladen von Software in einem System der Art, wie es in 1 dargestellt ist, werden in den Dokumenten „Requirements on Network and Security Architecture and Traffic Management Schemes for Download Traffic based on IP Principles in Cellular and Ad Hoc Networks" (Anforderungen an die Netz- und Sicherheitsarchitektur und an Verkehrs-Management-Schemata auf Basis von IP-Prinzipien in zellularen und Ad-Hoc-Netzen; IST-Projekt „SCOUT", Dokument D4.1.1), die auf der Internet-Seite www.ist-scout.org zur Verfügung stehen, sowie in dem Dokument „Reconfigurable SDR Equipment and Supporting Networks Reference Models and Architectures" (Rekonfigurierbare SDR-Systeme und Unterstützungsnetz-Referenzmodelle und -Architekturen), White Paper der Arbeitsgruppe 3 des Wireless World Research Forum (WWRF) (2002). Für ein besseres Verständnis werden hier dennoch einige der Funktionen der Einheiten PRMi, SRM, HRM kurz beschrieben.
Für eine derartige Beschreibung wird auch Bezug genommen auf die 2. Dort werden der Einfachheit halber lediglich zwei Funkzugangsnetze betrachtet, beispielsweise ein UMTS-Netz RAT1 (auch als „Zellularnetz" bezeichnet) und ein WLAN RAT2 („Hotspot"). Die Rekonfigurationseinheiten sind hier in der Funknetzsteuerung RNC, der Interworking-Einheit IWU, der SGSN-Einheit (Service GPRS Support Node) bzw. der Heimatdatei HLR enthalten und sind geeigneten Speichereinheiten (Repositories) SP1, SP2, SS, SH1, SH2 zugeordnet, was im Folgenden noch ausführlicher behandelt wird. Zur Wahrung der Konsistenz mit 1 enthalten beide Netze RAT1, RAT2 einen jeweiligen Proxy Reconfiguration Manager PRM1, PRM2, auch wenn ein WLAN-artiges RAT2 mit dem Proxy Reconfiguration Manager des zellularen Mobilfunknetzes auskäme. Da PRM1, PRM2 mit derselben SRM-Einheit (Serving Reconfiguration Manager) im Kernnetz CN verbunden sind, gelten die Funkzugangsnetze RAT1 und RAT2 als zu demselben Terminal Reconfiguration Serving Area gehörig, gekennzeichnet durch den als gestrichelte Linie dargestellten Block TRSA. Die Beschreibung zu 2 setzt sich im Wesentlichen mit den Aspekten in Bezug auf das Herunterladen von Software auseinander.
Die Proxy Reconfiguration Manager-Einheiten PRMi (i = 1, 2) bilden die Kontaktpunkte für jedes Endgerät, das an die Funkzugangsnetze RATi angeschlossen ist. Diese Einheiten sind hauptsächlich an den Funktionen für Modus-Überwachung, Modus-Aushandlung, Modus-Umschaltung und das Herunterladen der Software beteiligt. Für die Aushandlungs- und Informationsprozesse wird Steuerungsverkehr von und zu den PRMi-Einheiten gesendet, wohingegen im Fall des Herunterladens von Software die entsprechenden Software-Datenpakete über die PRMi-Einheiten transportiert werden. Diese Einheiten können in zwei Teile unterteilt sein, die die Funktionen der Anwenderebene (Blöcke SPREi in 2, wobei SPRE die Abkürzung ist für Software Download and Profile Repository) und die Funktionen der Steuerungsebene (Block SDRC in 2, wobei SDRC die Abkürzung ist für Software Download and Reconfiguration Controller) repräsentieren. Die Blöcke SPREi erfassen alle Profile und sonstigen Informationen, die für die Durchführung der Rekonfiguration und für das Herunterladen von Software benötigt werden.
Ferner ist es Aufgabe dieser Blöcke, die Software-Module aus der entsprechenden Speichereinheit bzw. dem entsprechenden Repository SPi abzurufen und sie an das Endgerät weiterzuleiten. Allgemein ist das Repository SPi ein Cache-Speicher für häufig angeforderte Software (Rekonfigurations-Software für die Endgeräte des entsprechenden Funkzugangsnetzes RAT oder andere Software), die auf höheren Ebenen gespeichert ist, jedoch kann es auch einen Teil der Software enthalten, die an das Endgerät weitergeleitet werden kann. Dadurch, dass häufig angeforderte Software im PRMi (Proxy Reconfiguration Manager) enthalten ist, wird die für die Durchführung des Download-Vorgangs benötigte Zeit beträchtlich reduziert und wird auch das Netz von einem großen Teil des Verkehrs entlastet, so dass die Netzressourcen effizienter genutzt werden können. Der Block SDRC beherbergt, wie schon sein Name erkennen lässt, die Steuerungsfunktionen für die Rekonfiguration und das Download. Speziell steuert er die Bearbeitung der Anfrage zum Herunterladen von Software-Modulen, die in der zugehörigen Speichereinheit SPi enthalten sind, und leitet die Anfrage weiter an die höheren Ebenen, wenn die Software nicht in der SPi-Einheit enthalten ist.
Die Einheit SRM (Serving Reconfiguration Manager) ist mit allen PRMi-Einheiten in ihrem TRSA (Terminal Radar Serving Area) verbunden und ist mit einem Speichermittel SS verknüpft, in dem unter Anderem die Rekonfigurations-Software für alle Funkzugangsverfahren in dem besagten TRSA enthalten sind. Das Speichermittel SS beinhaltet eine aktuelle Software-Datenbank und kann unter Umständen auch einen Cache-Speicher für Software umfassen, die von einer höheren Ebene kommt. Wie die PRMi-Einheiten kann auch der Serving Reconfiguration Manager SRM in zwei Blöcke C-SRM und U-SRM untergliedert werden, die für die Funktionen der Steuerungs- bzw. der Anwenderebene zuständig sind.
Die Funktionalität der Steuerungsebene, C-SRM, hat im Wesentlichen zwei Aufgaben:

– Verwalten des entsprechenden Austauschs von Steuerungsnachrichten zwischen dem Endgerät (über den Proxy Reconfiguration Manager PRM sowie spezieller über den Software Download and Reconfiguration Controller SDRC) und den Einheiten, die AAA-Prozesse (Authentifizierung, Autorisierung und Abrechnung) im Betreibernetz verwalten, wenn der Anwender ein Handover ausführen oder eine Software-Komponente herunterladen will, für die eine Autorisierung erforderlich ist;
– Standortaktualisierung (oder Makro-Mobilitätsfunktion): Der Serving Reconfiguration Manager SRM speichert den Standort jedes kontrollierten Endgeräts in seinem TRSA: Wenn beispielsweise ein Massen-Upgrade ansteht, muss der SRM wissen, an welchen Proxy Reconfiguration Manager PRM das Software-Modul weitergeleitet werden muss.

Die Funktionalität der Anwenderebene, U-SRM, des SRM ist wiederum für die Funktion des Bereitstellens des Software-Downloads zuständig, indem sie Anfragen für Software empfängt, die weder in der Einheit PRMi des Funkzugangsnetzes RATi, das aktuell genutzt wird, noch in den benachbarten PRM-Einheiten enthalten ist. Die U-SRM-Funktionalität stellt dem Proxy Reconfiguration Manager PRM die angeforderte Software bereit, wenn sie im Speichermittel SS gespeichert ist; andernfalls leitet die U-SRM-Funktionalität die Anfrage ihrerseits weiter an den Home Reconfiguration Manager HRM, wobei die Software an den PRM übertragen wird, sobald sie beschafft wurde.
Die HRM-Einheit muss alle Software zur Verfügung stellen, die auf den unteren Ebenen nicht vorhanden ist, darunter auch neue Software-Upgrades, über die sie von den Anbietern informiert wird, und kann mit einer Mehrzahl von SRM-Einheiten (Serving Reconfiguration Manager) verbunden sein. Im Fall eines Upgrades benachrichtigt der HRM den SRM über die Verfügbarkeit neuer Software und leitet diese bei Bedarf an den SRM weiter. Geht bei dem HRM eine Anfrage zum Herunterladen von Software ein, ist er auch für die Autorisierung des Endgeräts zuständig, vorausgesetzt, dass die Software lizenziert ist, sowie für die Abrechnung des Software-Downloads mit dem Anwender. In diesem Fall verwendet der HRM ein Abrechnungs-Repository, das aktualisiert wird, wenn die betreffende Software heruntergeladen wird. Der Block SH1 zeigt die Gesamtheit der Software-Datenbanken, die für den HRM über die Server der jeweiligen Hersteller zugänglich sind, dargestellt im Ganzen durch den Block MS, und der Block SH2 stellt das Abrechnungs-Repository (bzw. den AAA-Server) dar. Der letztgenannte Server ist außerdem mit dem Steuerungsebenen-Teil C-SRM des SRM verbunden.
Gemäß der Erfindung werden die Software-Download-Sitzungen mithilfe des SIP-Protokolls derart verwaltet, dass mobile Sitzungen unterstützt werden. Das SIP ist ein textbasiertes Client-Server-Protokoll, das nach dem Simple Mail Transfer Protocol (SMTP) und dem HyperText Transfer Protocol (HTTP) entworfen wurde. Wie bei jedem anderen textbasierten Client-Server-Protokoll gibt der Client Anfragen aus und liefert der Server Antworten zurück. Um das Verständnis zu erleichtern, sind im Folgenden einige Definitionen von SIP-Komponenten und -Funktionen, die in der Erfindung zum Einsatz kommen, noch einmal aufgeführt:

– Der „User-Agent Client" (nachfolgend kurz einfach „SIP-Client" genannt) ist der rufende User-Agent, das heißt, eine Client-Anwendung, die eine SIP-Anfrage veranlasst;
– Der „Proxy" (oder „Proxy-Server") ist ein Zwischenprogramm, das sowohl als ein Server als auch als ein Client fungiert, mit dem Zweck, Anfragen im Namen anderer Clients zu veranlassen; Anfragen werden intern bearbeitet oder an andere Server weitergeleitet, möglicherweise nach einer vorherigen Übersetzung;
– Der „Registrar" ist ein Server, der Registrierungsanfragen annimmt und der üblicherweise zusammen mit einem Proxy-Server installiert ist;
– „Invite" ist die Prozedur, die zum Aufbauen einer Verbindung verwendet wird;
– „Register" ist die Prozedur, mit deren Hilfe ein Anwender Standortinformationen an einen Server übermitteln kann, damit der Server eine kommende Adresse einer gehenden Adresse zuordnen kann, unter der der Anwender erreichbar ist;
– „Bye" ist die Prozedur für den Abbau der Sitzung.

Um die Sitzungs-Mobilität sicherzustellen, verwendet die vorliegende Erfindung auch das „Refer"-Verfahren. Bei diesem verfahren handelt es sich um eine erst kürzlich standardisierte SIP-Erweiterung, die viele Anwendungen möglich macht, darunter beispielsweise auch die Anrufumleitung. Das „Refer"-Verfahren zeigt an, dass der Empfänger der Umleitungsnachricht, der durch den Anfrage-URI (Universal Resource Identifier) gekennzeichnet ist, anhand der in der Anfrage enthaltenen Kontaktinformationen einen Dritten kontaktieren soll. Das „Refer"-Verfahren ist in dem IETF-Standard RFC 2315 beschrieben, der Gegenstand des Dokuments „The SIP Refer Method" (Das SIP-Refer-Verfahren) von R. Sparks ist, welches auf der Internet-Seite http://www.ietf.org/rfc.html zur Verfügung steht.
Der Aufbau einer Sitzung für das Herunterladen von Software und die Wiederaufnahme im Fall eines vertikalen Handovers wird nun unter Bezugnahme auf die Blockdiagramme und Grafiken der 3 bis 10 beschrieben. von dem Endgerät UE wird angenommen, dass es mit dem Funkzugangsnetz RAT1 verbunden ist, wenn das Download gestartet wird, und dass es, während der Download-Vorgang läuft ein vertikales Handover zum Funkzugangsnetz RAT2 durchführt.
Die Blockdiagramme in den 3, 5, 7 und 9 zeigen die SIP-Komponenten, die von der Erfindung betroffen sind, sowie die Wege der SIP-Nachrichten, wobei letztere durch fett gedruckte Pfeillinien dargestellt sind. Im Einzelnen werden gestrichelte Linien für die „Register"-Nachrichten; durchgezogene Linien für die „Invite"- und „OK"-Nachrichten (in einem einzigen bidirektionalen Pfeil zusammengefasst); strichpunktierte Linien für die „Refer"-Nachrichten verwendet. Eine gepunktete Pfeillinie kennzeichnet das Download und eine gestrichelte Doppellinie bezeichnet die Überprüfungen in den Repositories. Einheiten, die auch in den 1 und 2 enthalten sind, werden mit denselben Bezugssymbolen dargestellt. Zugunsten der Einfachheit der Abbildungen wurden die standardmäßigen Einheiten des Mobilkommunikationssystems in den Blockdiagrammen weggelassen und werden nur die für die Verwaltung der Rekonfiguration und des Software-Downloads benötigten Einheiten dargestellt, da dies die Einheiten sind, die die SIP-Komponenten beherbergen. Andererseits ist die Anordnung dieser Verwaltungseinheiten in Bezug auf die Einheiten des Mobilkommunikationssystems unter Bezugnahme auf die 1 und 2 veranschaulicht. Auch die Speichereinheit SH2 und der Hersteller-Server MS wurden der besseren Übersichtlichkeit halber weggelassen.
Die Blockdiagramme zeigen klar, dass gemäß der Erfindung eine hierarchische Struktur der SIP-Proxies vorgeschlagen wird, um eine flexible und skalierbare Lösung zu entwickeln. Speziell:

– beherbergt das Endgerät UE einen SIP-Client (CL), der die Registrierungsphase und die Sitzung starten muss, wenn die Download-Anfrage von dem Endgerät selbst veranlasst wird;
– beherbergen die Einheiten PRM1, PRM2 und SRM jeweilige SIP-Proxy-Server PX1, PX2, PX3 (die den ersten Kontaktpunkt für den SIP-Client bilden und den Aufbau und die Verwaltung der Sitzung übernehmen) und Registrar-Server RG1, RG2 und RG3, welche die Registrierung des Endgeräts im Netz vornehmen.

Wie vorstehend bereits erwähnt, wird eine einzige Einheit SGSN (Service GPRS Support Node) betrachtet, die mit den Funkzugangsnetzen RAT1 und RAT2 verbunden ist, und wird beispielhaft der Fall des Herunterladens von Software beschrieben, die in der Speichereinheit SP1 (3, 4 und 7, 8) oder SS (5, 6 und 9, 10) vorliegt. Dementsprechend werden auch nur zwei Ebenen in der SIP-Struktur gezeigt. Die vorgeschlagene Lösung ist jedoch in jeder Hinsicht offen für eine erweiterte Architektur, beispielsweise den Fall, dass Funkzugangsnetze RAT mit verschiedenen SGSN-Einheiten verbunden werden. Tatsächlich ist das Verfahren skalierbar und erfolgreich auch auf komplexere Architekturen anwendbar.
In den Grafiken werden folgende Kennzeichner für die SIP-Komponenten verwendet:

– Ursprungsadresse des Endgeräts (SIP-Client): [email protected]
– SIP-Client-Adresse nach Standortwechsel: [email protected]
– PX1: [email protected]
– PX2: [email protected]
– PX3: [email protected].

Es wird nun Bezug genommen auf die 3, 4; der Prozess des Aufbauens einer Sitzung für das Herunterladen von Software vom Proxy Reconfiguration Manager PRM1 gestaltet sich wie folgt:

1. Der SIP-Client (das Endgerät UE) führt die Registrierung beim SIP-Proxy-Server PX1 im PRM1 durch;
2. Die REGISTER-Nachricht wird im Registrar-Server RG1 gespeichert und anschließend weitergeleitet an den Proxy-Server der höheren Ebene PX3 im SRM (Serving Reconfiguration Manager). Anschließend wird die Kennung des Endgeräts UE auf der SRM-Ebene in dem SIP-Register RG3 gespeichert.
3. Der SIP-Client sendet eine INVITE-Nachricht an den PRM1, um die SIP-Sitzung zu starten. Die Nachricht (soweit sie die für die vorliegende Erfindung interessierenden Informationen betrifft) könnte etwa folgendermaßen aussehen: INVITE [email protected] Via [[email protected]] From [email protected] To [email protected] Call ID xyz123
4. Der PRM1 prüft, ob die Software in seinem Repository SP1 enthalten ist. Die Antwort ist positiv.
5. Von dem Proxy-Server PX1 wird eine OK-Nachricht an das Endgerät UE zurückgesendet, so dass die Sitzung aufgebaut wird und das Herunterladen der Software an das Endgerät UE ordnungsgemäß gestartet wird.

Das Software-Download folgt den Regeln, die das SIP festlegt. Zu beachten ist, dass der Proxy-Server PX1 die heruntergeladene Software nicht speichert, selbst wenn ein gewisser Grad der Pufferung natürlich bereitgestellt wird, um den beim PX1 ankommenden und den von dort abgehenden Verkehr anzupassen. Der Pfeil „SW herunterladen" in dem Signalisierungsdiagramm erstreckt sich von dem Proxy zum Client, da er sich auf die Steuerungssignalisierung bezieht und nicht auf die eigentlichen Datenpakete.
In der obigen Nachricht sowie in den Nachrichten, die im Zusammenhang mit den 6, 8 und 10 erwähnt werden, wird nicht ausdrücklich Bezug genommen auf die Struktur der Nachricht (Abfragezeile, Kopfteil, Textteil), da die Struktur dieselbe ist wie durch die Standards des SIP-Protokolls definiert und von der vorliegenden Erfindung nicht berührt wird. Wir rufen hier lediglich in Erinnerung, dass der Textteil eine Anzahl von Parametern (bekannt als SDP-Parameter, wobei SDP für Session Description Protocol steht) umfasst, die Informationen enthalten, unter Anderem beispielsweise über die Sitzungsmerkmale, Zeitangaben und Angaben über die in der Sitzung verwendeten Medien. Eine Liste dieser Parameter an dieser Stelle einzufügen ist nicht notwendig, da sie im IETF-Standard RFC 2327 definiert sind, der auf der vorstehend bereits erwähnten Internet-Seite der IETF zu finden ist. Einer der Parameter, die die Sitzungsmerkmale beschreiben (beipielsweise der Parameter s = Name der Sitzung oder der Parameter i = Informationen zur Sitzung), zeigt an, dass es bei der Sitzung um das Herunterladen des gewünschten Software-Moduls geht. Ferner ist es, da die Erfindung darauf abzielt, einen Software-Download-Vorgang ab dem letzten empfangenen Datenpaket wieder aufzunehmen, wenn ein vertikales Handover erfolgt, notwendig, die fortlaufende Nummer pktn der heruntergeladenen Datenpakete nachzuverfolgen: Zu diesem Zweck können die optionalen Sitzungsattributzeilen (Parameter a) verwendet werden. Von den oben genannten beiden SDP-Parametern ist nur der Parameter „Paketnummer" ausdrücklich dargestellt (in den Nachrichten, die die Wiederherstellungsphase betreffen).
Wird die Software aus dem Serving Reconfiguration Manager SRM heruntergeladen (5, 6), startet der Anwender eine Sitzung mit dem PRM1, wie zuvor auch, und wiederholt die Schritte 1 bis 4 oben. Die „Register"-Nachrichten und die „Invite"-Nachricht an den Proxy-Server PX1 sind in 5 aus Gründen der Übersichtlichkeit der Zeichnung nicht mehr dargestellt. In diesem Fall liefert die Überprüfung in Schritt 4, ob die angefragte Software in dem Repository SP1 enthalten ist, ein negatives Ergebnis. Daraufhin werden die folgenden Schritte ausgeführt:

5. Wenn der PRM1 feststellt, dass die Software, die heruntergeladen werden soll, nicht im Repository SP1 enthalten ist, sendet er an das Endgerät UE eine „Refer"-Nachricht, um die bestehende Sitzung an den SIP-Proxy der höheren Ebene (d. h. den SRM) umzuleiten. Der PRM1 (Referred by, Umgeleitet von) teilt dem Endgerät UE (user1, Anwender1) mit, dass die bestehende Sitzung (Call ID, Anruf-ID) an den SRM (Refer to, Umleiten an) umgeleitet werden muss. Die „Refer"-Nachricht kann wie folgt aussehen: REFER [email protected] Via [[email protected]] From [email protected] To [email protected] Call ID xyz123 Refer to [email protected] Referred by [email protected]
6. Nach Empfang der „Refer"-Nachricht sendet das Endgerät UE eine neue INVITE-Nachricht an den Proxy-Server PX3 im Serving Reconfiguration Manager SRM. Die neue INVITE-Nachricht sieht folgendermaßen aus: INVITE [email protected] Via [[email protected]][[email protected]] From [email protected] To [email protected] Call ID xyz123
7. Angenommen, das Vorhandensein der Software in der Speichereinheit SS ist vorab bekannt, dann wird eine OK-Nachricht an das Endgerät UE zurückgesendet. Die Sitzung wird aufgebaut und das Software-Download wird gestartet. Ist das Vorhandensein der Software in der Speichereinheit SS nicht vorab bekannt, wird im Anschluss an die INVITE-Nachricht 6 eine Überprüfung ähnlich derjenigen in Schritt 4 durchgeführt (die Überprüfung ist in 5 dargestellt).

In beiden Fällen wird die Sitzung nach Abschluss des Download-Vorgangs abgebaut (durch die Nachricht BYE, in den Grafiken nicht dargestellt), sofern sich das Endgerät UE auch weiterhin im Funkversorgungsbereich von RAT1 befindet.
Es ist zu beachten, dass die „Register"-Nachricht, auch wenn das Download auf der PRM-Ebene erfolgt, an alle Registrars der höheren Ebenen weitergeleitet wird, so dass auch die höheren Ebenen den Standort des Endgeräts kennen. Dies ist vorteilhaft, wenn es um die Abwicklung der Wiederaufnahme eines Download-Vorgangs geht, wie nachfolgend deutlich wird.
Es wird nun der Fall beschrieben, dass das Endgerät UE während des Download-Vorgangs von einem Standort UE(1) im Funkversorgungsbereich von RAT1 an einen Standort UE(2) (strichpunktierte Linien) im Funkversorgungsbereich von RAT2 wechselt. Falls die Software aus dem Repository SP1 des Proxy Reconfiguration Managers PRM1 heruntergeladen wird (7 und 8), wird angenommen, dass diese Software auch im Repository SS des Serving Reconfiguration Manager SRM gespeichert ist. Die in 3 und 5 dargestellten Nachrichten sind in den 7 und 9 nicht mehr enthalten. Der im Funkzugangsnetz RAT1 eingeleitete Download-Vorgang ist weiterhin dargestellt, jedoch mit dünneren Linien.
In 8 werden in den Schritten 1, 2 der laufende Download-Vorgang und das vertikale Handover gezeigt. Im Funkversorgungsbereich von RAT2 erhält das Endgerät UE eine neue IP-Adresse und eine neue URL, in diesem Fall [email protected]. Die Mobilität der Endgeräte wird gemäß MIP- (IPv6-) Mechanismen gehandhabt. Dies sind konventionelle Mechanismen und müssen daher an dieser Stelle nicht noch einmal näher erläutert werden.
Nach Erhalt der neuen IP-Adresse ist das Endgerät UE darüber informiert, dass es sich in einem anderen Teilnetz befindet, und versucht, die Software-Download-Sitzung wiederaufzunehmen. Zusammen mit anderen SIP-Parametern hat das Endgerät UE die Kennung der zuvor bestehenden Sitzung (Call ID, Anruf-ID), die laufende Nummer des letzten ordnungsgemäß empfangenen Datenpakets (SDP-Parameter „pktn") und seine alte URL gespeichert. Das Endgerät UE sendet eine „Refer"-Nachricht an den Proxy-Server PX1 (Schritt 3 in 8), um die laufende Sitzung auf seine neue URL umzuleiten. Die Nachricht beinhaltet unter Anderem die alte URL (Feld „Referred by", Weitergeleitet durch) und kann folgendermaßen aussehen:
REFER [email protected]
Via [[email protected]][[email protected]]
From [email protected]
To [email protected]
Call ID xyz123
Refer to [email protected]
Referred by [email protected]
SDP Pktn: 1453
Der Proxy-Server PX1 ist dafür konfiguriert, nicht auf die „Refer"-Nachricht zu antworten; die Nachricht wird schlicht ignoriert, er erhält aber die neue URL des Endgeräts UE, die Anruf-ID und den Verweis auf das letzte ordnungsgemäß empfangene Datenpaket (Schritt 4 in 8).
Anschließend sendet der Proxy-Server PX1 eine weitere „Refer"-Nachricht („Refer"-Nachricht Nr. 5, ausgelöst durch „Refer"-Nachricht Nr. 3) an den Serving Reconfiguration Manager SRM, um die zuvor unter der alten URL aufgebaute Sitzung umzuleiten. Die neue „Refer"-Nachricht hat den Zweck, den SRM darüber zu informieren, dass eine durch den Parameter Call ID identifizierte Sitzung mit dem Endgerät UE unter dieser neuen URL veranlasst werden muss und dass der SRM dieselbe Software nochmals aus seinem Repository abrufen und das Download beginnend bei dem angegebenen Datenpaket starten muss. Diese zweite „Refer"-Nachricht sieht folgendermaßen aus:
REFER [email protected]
via [[email protected]]
From [email protected]
To [email protected]
Call ID xyz123
Refer to [email protected]
Referred by [email protected]
SDP Pktn: 1453
Der Serving Reconfiguration Manager SRM sendet eine INVITE-Nachricht an das Endgerät UE an dieser neuen URL ([email protected]):
INVITE [email protected]
Via [[email protected]]
From [email protected]
To [email protected]
Call ID xyz123
SDP Pktn: 1453
Das Endgerät UE akzeptiert die neue Sitzung, indem es eine OK-Nachricht zurücksendet (Schritt 7 in 8). Das Download der Software wird aus der Speichereinheit SS wieder aufgenommen und beginnt erneut bei dem Paket, bei dem der Download-Vorgang unterbrochen wurde (d. h. dem Paket 1453); nachdem die neue Sitzung ordnungsgemäß aufgebaut ist, wird die alte noch anhängige Sitzung abgebaut.
Die 7 und 8 zeigen, dass, auch wenn die Sitzung auf der PRM-Ebene gestartet wurde (durch PRM1), die Wiederaufnahme durch die nächsthöhere Ebene, also durch den Serving Reconfiguration Manager SRM, verwaltet wird, nicht auf der Peer-Ebene durch den PRM2 im Funkzugangsnetz RAT2. Diese Entscheidung wurde aus Gründen der Einfachheit der Signalisierung getroffen, wobei berücksichtigt wurde, dass ein sehr hohes Maß an Signalisierung erforderlich wäre, um die Verwaltung des Download-Vorgangs an den PRM2 zu übertragen. Auf der anderen Seite kommt es im Allgemeinen eher selten zu einem vertikalen Handover, so dass die Belastung des SRM nicht signifikant erhöht würde. Ferner ergibt sich aufgrund dieser Entscheidung auch eine Verbesserung der Laufzeiteigenschaften, auch wenn diese nicht von entscheidender Bedeutung ist, da es sich um nicht echtzeitbasierten Verkehr handelt.
Für den Fall, dass das Herunterladen der Software vom SRM wieder aufgenommen wird (9 und 10), ist die Vorgehensweise ähnlich: Selbstverständlich erfolgt während der Wiederaufnahme kein Eingreifen des PRM1. Speziell sendet das Endgerät UE nun eine „Refer"-Nachricht an den SRM, um die laufende Sitzung auf seine neue URL umzuleiten:
REFER [email protected]
Via [[email protected]]
From [email protected]
To [email protected]
Call ID xyz123
Refer to [email protected]
Referred by [email protected]
SDP Pktn: 1453
und sendet der SRM an das Endgerät UE eine INVITE-Nachricht wie vor. Der weitere Verlauf entspricht dem vorstehend beschriebenen Fall.
Wie bereits erwähnt basiert die Erfindung auf einer hierarchisch ausbaubaren Struktur der SIP-Server. Wenn daher die Endgeräte die Möglichkeit oder den Bedarf haben, Software-Module aus dem Repository SH1 herunterzuladen, wird der Home Reconfiguration Manager HRM auch einen Proxy- und einen Registrar-Server beherbergen; in diesem Fall wird, zumindest wenn der Speicherort der Software nicht vorab bekannt ist, die „Register"-Nachricht an den HRM weitergeleitet. Falls zur Abwicklung des Software-Downloads ein Eingreifen des HRM erforderlich ist, wird natürlich auch bei der Wiederaufnahme des Download-Vorgangs ein solches Eingreifen des HRM notwendig sein.
Im Allgemeinen lässt sich sagen, dass eine Software-Download-Sitzung, die von den Proxies der untersten Ebene aufgebaut wurde, durch einen Proxy der nächsthöheren Ebene (PX3) wiederaufgenommen wird, während eine Sitzung, die durch einen Proxy einer höheren Ebene aufgebaut wurde, von demselben Proxy wiederaufgenommen werden kann, von dem sie aufgebaut wurde.
In dem Fall, dass das Ziel-Funkzugangsnetz RAT2 mit einer anderen SGSN-Einheit (Service GPRS Support Node) verbunden ist als der SGSN-Einheit, die mit dem Funkzugangsnetz RAT1 verbunden ist, wird die hierarchische Struktur vorzugsweise dadurch ausgeschöpft, dass die Wiederherstellung von dem Home Reconfiguration Manager HRM verwaltet wird (d. h. durch die oberste Ebene der Hierarchie). In diesem Fall wird die „Refer"-Nachricht an den Serving Reconfiguration Manager SRM (3 oder 5, je nach dem, wie der Fall liegt) eine „Refer"-Nachricht an den HRM auslösen, wenn die Software von dem SRM oder dem PRM1 heruntergeladen wird, wohingegen die „Refer"-Nachricht von dem Client direkt an den HRM gesendet wird, wenn die Software vom HRM heruntergeladen wird. Der HRM sendet daraufhin die INVITE-Nachricht an den Client unter dessen neuer URL.
Die „alte" SGSN-Einheit könnte das Eingreifen der „neuen" SGSN-Einheit auch direkt anfordern, welche daraufhin die INVITE-Nachricht an den Client senden würde, wenngleich dies eine weniger bevorzugte Alternative ist.
Es ist offensichtlich, dass die vorstehende Beschreibung lediglich beispielhafter Natur ist und keinerlei einschränkenden Charakter hat und dass Veränderungen und Modifikationen möglich sind, ohne den Schutzbereich der Erfindung zu verlassen, wie er in den beigefügten Patentansprüchen definiert ist.
Daher kann die vorliegende Erfindung, selbst wenn sie hier unter Bezugnahme auf ein „konventionelles" Mobilkommunikationssystem beschrieben wurde, auch in Mobilkommunikationssystemen einer künftigen Generation profitabel eingesetzt werden. Da die Erfindung auf der Verwendung des SIP-Protokolls basiert, kann sie ebenso gut auch als Anwendung einer IMS-Plattform oder im Allgemeinen als ein Mittel zur Integration von rekonfigurierbaren Funktionalitäten in eine IMS-Architektur genutzt werden.

Claims

Verfahren zum nicht echtzeitbasierten Herunterladen (Download) von Software in einem auf dem Internet-Protokoll, IP, basierenden Mobilkommunikationssystem mit heterogenen Zugangstechnologien, in dem die Software-Download-Sitzungen mithilfe des Session Initiation Protocol, SIP, aufgebaut und verwaltet werden, wobei User-Agent-Anwendungen (CL) sowie Proxy- und Registrar-Server (PX1, RG1 ... PX3, RG3) am Endgerät des Anwenders (UE) bzw. in den Funkzugangs- und Kernnetzen (RAT1, RAT2, CN) zur Verfügung gestellt werden, um die SIP-Prozesse abzuwickeln, dadurch gekennzeichnet, dass für die Wiederaufnahme des Download-Vorgangs im Falle eines Handovers zwischen einem ersten (RAT1) und einem zweiten (RAT2) Funkzugangsnetz, die verschiedene Zugangstechnologien nutzen, während eine Software-Download-Sitzung noch läuft, der SIP-User-Agent (CL), der mit einem das Handover durchführenden Anwender-Endgerät (UE) verknüpft ist, ohne die laufende Sitzung auszulösen, bei Empfang einer neuen IP-Adresse und einer neuen URL in dem zweiten Funkzugangsnetz (RAT2) eine Nachricht mit einer Umleitungs-Anfrage, eine so genannte „Refer"-Nachricht, an einen SIP-Proxy-Server (PX1) sendet, der die Download-Sitzung aufgebaut hat und derzeit verwaltet, wobei die besagte „Refer"-Nachricht Informationen zu der Adresse und der URL in dem ersten Funkzugangsnetz (RAT1), der neuen URL, der Kennung der Sitzung und dem letzten Software-Datenpaket enthält, das erfolgreich empfangen wurde, wobei der besagte Proxy-Server (PX1) auf diese Weise informiert wird, dass die Sitzung an den User-Agent (CL) an der neuen URL umzuleiten ist und, die notwendigen Schritte einleitet, um eine neue Sitzung mit dem User-Agent (CL) an der neuen URL aufzubauen, unter der Kontrolle eines Proxy-Servers (PX3), dessen Aufgabe es ist, die neue Sitzung zu verwalten und dafür zu sorgen, dass der Download-Vorgang beginnend bei dem besagten zuletzt empfangenen Datenpaket wieder aufgenommen wird.
Verfahren gemäß Anspruch 1, dadurch gekennzeichnet, dass bei Annahme der besagten neuen Sitzung durch den User-Agent (CL) die Sitzung, die im Funkversorgungsbereich des ersten Funkzugangsnetzes (RAT1) aufgebaut wurde, ausgelöst wird.
Verfahren gemäß Anspruch 1 oder 2, wobei die Software von einer Mehrzahl von Software-Repositories (SP1, SP2, SS, SH1) heruntergeladen werden kann, die über Download-Management-Einheiten (PRM1, PRM2, SRM, HRM) auf verschiedenen Ebenen einer hierarchisch aufgebauten Download-Management-Struktur zugänglich sind, wobei die Download-Management-Einheiten auf einer Zwischenebene der besagten Struktur mit Mitteln (SGSN) verknüpft sind, die paketbasierte Dienste im System steuern, dadurch gekennzeichnet, dass das verfahren die folgenden Schritte umfasst: Aufbauen einer hierarchischen und modular skalierbaren Struktur aus den besagten SIP-Servern (PX1, RG1 ... PX3, RG3) und Hosting der Server auf jeder Ebene der besagten hierarchischen Server-Struktur (PX1, RG1 ... PX3, RG3) in den Download-Management-Einheiten (PRM1, PRM2, SRM, HRM) auf einer gegebenen Ebene der Download-Management-Struktur (PRM1, PRM2, SRM, HRM), wodurch eine Übereinstimmung zwischen den beiden hierarchischen Strukturen erzielt wird.
Verfahren gemäß Anspruch 3, welches eine Phase der Registrierung eines Anwenders (CL) beinhaltet, der eine Software-Download-Sitzung aufbauen will, dadurch gekennzeichnet, dass die Registrierung des entsprechenden User-Agent mithilfe von Registrar-Servern (RG1 ... RG3) auf allen hierarchischen Ebenen der Server-Struktur erfolgt, unabhängig von der Hierarchieebene, auf der die herunterzuladende Software zugänglich ist, wobei Informationen zum Standort des Anwenders auf allen Ebenen der hierarchischen Server-Struktur zur Verfügung stehen.
Verfahren gemäß Anspruch 3 oder 4, dadurch gekennzeichnet, dass Software-Download-Sitzungen von Servern (PX1 ... PX3) aufgebaut werden, die auf derselben hierarchischen Ebene liegen wie die Download-Management-Einheiten (PRM1, PRM2, SRM, HRM), über die die herunterzuladende Software zugänglich ist.
Verfahren gemäß einem der Ansprüche 3 bis 5, dadurch gekennzeichnet, dass der Aufbau einer Sitzung zunächst bei dem Proxy-Server auf der untersten Ebene (PX1, PX2) angefragt wird und dass, falls die herunterzuladende Software in dem Repository (SP1, SP2), das auf dieser untersten Ebene zugänglich ist, nicht enthalten ist, eine Anfrage zur Umleitung der Sitzung von dem besagten Proxy-Server der untersten Ebene (PX1, PX2) an den User-Agent (CL) gesendet wird, um diesen darüber zu informieren, dass die Sitzung zu einer höheren Ebene aufgebaut werden muss, wobei die Sitzungsaufbau-Anfrage und das Senden der Umleitungs-Anfrage bei jeder bzw. durch jede der aufeinander folgenden höheren Stufen wiederholt wird, bis die Sitzungsaufbau-Anfrage die Ebene erreicht, auf der die Software zur Verfügung steht.
Verfahren gemäß einem der Ansprüche 3 bis 6, dadurch gekennzeichnet, dass Software-Repositories (SS, SH1), die über die Download-Management-Einheiten (SRM, HRM) auf Ebenen oberhalb derjenigen, die mit der untersten Server-Ebene (PX1, PX2) verknüpft ist, zugänglich sind, ebenfalls Software speichern, die auch in den Repositories (SP1, SP2) enthalten ist, welche über die Download-Management-Einheiten (PRM1, PRM2) auf niedrigeren Ebenen zugänglich sind.
Verfahren gemäß einem der Ansprüche 3 bis 7, dadurch gekennzeichnet, dass der besagte Hosting-Schritt das Hosting von Proxy-Servern (PX3) umfasst, die auf einer Ebene unmittelbar oberhalb einer untersten Ebene in den Download-Management-Einheiten (SRM) liegen, welche den besagten Mitteln (SGSN) zur Steuerung von paketbasierten Diensten zugeordnet sind, sowie dadurch, dass die Umleitung einer Software-Download-Sitzung, die von einem Proxy-Server (PX1, PX2) der untersten Ebene in der Server-Struktur in dem ersten Funkzugangsnetz (RAT1) aufgebaut wurde, auf das zweite Funkzugangsnetz (RAT2) von einem Proxy-Server (PX3) auf einer nächsthöheren Ebene verwaltet wird, wenn die beiden Funkzugangsnetze mit demselben Mittel zur Steuerung von paketbasierten Diensten (SGSN) verbunden sind.
Verfahren gemäß den Ansprüchen 1 und 8, dadurch gekennzeichnet, dass die besagte Nachricht mit der Umleitungs-Anfrage, die von dem Client an den Proxy-Server (PX1, PX2) gesendet wird, auf dem besagten verwaltenden Proxy-Server (PX1, PX2) eine zweite Umleitungs-Anfrage an den Server (SRM) der nächsthöheren Ebene auslöst und dieser besagte Server auf der höheren Ebene (SRM) bei Empfang der besagten Umleitungs-Anfrage eine neue Sitzung aufbaut.
Verfahren gemäß einem der Ansprüche 3 bis 7, dadurch gekennzeichnet, dass die Umleitung einer Software-Download-Sitzung, die im ersten Funkzugangsnetz (RAT1) von einem Proxy-Server (PX3) einer Ebene in der Server-Struktur oberhalb der untersten Ebene aufgebaut wurde, auf das zweite Funkzugangsnetz (RAT2) übertragen wird, die von demselben Server verwaltet wird, der die Sitzung aufgebaut hat, wenn die beiden Funkzugangsnetze mit demselben Mittel zur Steuerung von paketbasierten Diensten (SGSN) verbunden sind.
Verfahren gemäß einem der Ansprüche 3 bis 7, dadurch gekennzeichnet, dass das erste und das zweite Funkzugangsnetz mit verschiedenen Mitteln (SGSN) zur Steuerung von paketbasierten Diensten verbunden sind, sowie dadurch, dass das Umleiten der Sitzung von einem Server auf einer der obersten Hierarchieebenen verwaltet wird, unabhängig von der Hierarchieebene des Servers, der die Sitzung in dem ersten Funkzugangsnetz (RAT1) aufgebaut hat.
Mobilkommunikationssystem, das auf dem Internet-Protokoll basiert und heterogene Zugangstechnologien zu einem Kernnetz zulässt, das mindestens ein Serving and Gateway Mobile Switching Centre und GPRS Support Nodes (S-MSC/SGSN und G-MSC/GGSN) umfasst und in dem zumindest ein Teil der Anwender Zugang zu Einrichtungen für das nicht echtzeitbasierte Herunterladen von Software hat und über die nötigen Endgeräte (UE) verfügt, um eine Verbindung zu einem Systemnetz über eine Mehrzahl der besagten Zugangstechnologien herstellen zu können, wobei die besagten Endgeräte der Anwender (UE) sowie das Systemnetz (RAT1, RAT2, CN) mit Mitteln (CL, PX1, RG1, ... PX3, RG3) ausgestattet sind, unter Anderem mit User-Agent-Anwendungen (CL) sowie Proxy- und Registrar-Servern (PX1, RG1, ... PX3, RG3), mit deren Hilfe Software-Download-Sitzungen über das Session Initiation Protocol (SIP) aufgebaut und verwaltet werden können, dadurch gekennzeichnet, dass für die Wiederaufnahme des Download-Vorganges im Falle eines Handovers zwischen einem ersten (RAT1) und einem zweiten (RAT2) Funkzugangsnetz, die verschiedene Zugangstechnologien nutzen, während eine Software-Download-Sitzung noch läuft, der SIP-User-Agent (CL), der mit einem das Handover durchführenden Anwender-Endgerät (UE) verknüpft ist, dafür ausgelegt ist, ohne die laufende Sitzung auszulösen, bei Empfang einer neuen IP-Adresse und einer neuen URL in dem zweiten Funkzugangsnetz (RAT2) eine Nachricht mit einer Umleitungs-Anfrage an einen SIP-Proxy-Server (PX1) zu senden, der die Download-Sitzung derzeit verwaltet, wobei die besagte Umleitungs-Anfrage Informationen zu der Adresse und der URL in dem ersten Funkzugangsnetz (RAT1), der neuen URL, der Kennung der Sitzung und dem letzten Software-Datenpaket enthält, das erfolgreich empfangen wurde, wobei der besagte Proxy-Server (PX1) auf diese Weise informiert wird, dass die Sitzung an den User-Agent (CL) an der neuen URL umzuleiten ist, und dafür ausgelegt ist, die notwendigen Schritte einzuleiten, um eine neue Sitzung mit dem User-Agent (CL) an der neuen URL aufzubauen, unter der Kontrolle eines Proxy-Servers (PX3), dessen Aufgabe es ist, die besagte neue Sitzung zu verwalten, und der Download-Vorgang beginnend bei dem besagten zuletzt empfangenen Datenpaket wieder aufgenommen wird.
System gemäß Anspruch 12, dadurch gekennzeichnet, dass der besagte Proxy-Server (PX3), dessen Aufgabe es ist, die besagte neue Sitzung zu verwalten, dafür ausgelegt ist, nach Annahme der neuen Sitzung durch den User-Agent (CL) für den Abbau der Sitzung zu sorgen, die in dem Funkversorgungsbereich des ersten Funkzugangsnetzes (RAT1) aufgebaut wurde.
System gemäß Anspruch 12 oder 13, welches eine hierarchische und verteilte Struktur aus Download-Management-Einheiten (PRM1, PRM2, SRM, HRM) sowie eine Mehrzahl von Software-Repositories (SP1, SP2, SS, SH1) umfasst, welche zwecks Herunterladen der Software über verschiedene Hierarchieebenen der besagten Struktur aus Download-Management-Einheiten (PRM1, PRM2, SRM, HRM) zugänglich sind, wobei die Download-Management-Einheiten auf einer der besagten Ebenen mit Mitteln (SGSN) zur Steuerung paketbasierter Dienste im System verknüpft sind, dadurch gekennzeichnet, dass die besagten SIP-Server (PX1, RG1, ... PX3, RG3) in einer hierarchischen Struktur angeordnet sind, bei der jede Ebene mit einer Ebene der Download-Management-Struktur (PRM1, PRM2, SRM, HRM) verknüpft ist, wodurch einander entsprechende Ebenen in den beiden Strukturen geschaffen werden, wobei jede der Download-Management-Einheiten (PRM1, PRM2, SRM, HRM) auf jeder der besagten einander entsprechenden Ebenen einen Proxy-Server (PX1 ... PX3) und einen Registrar-Server (RG1 ... RG3) beherbergt.
System gemäß Anspruch 14, dadurch gekennzeichnet, dass die Registrar-Server (RG1 ... RG3) auf allen Hierarchieebenen der Server-Struktur dafür ausgelegt sind, die Kennungen der User-Agents (CL) zu speichern, die sich für eine Software-Download-Sitzung registrieren, unabhängig von der Hierarchieebene, auf der die herunterzuladende Software zugänglich ist.
System gemäß Anspruch 14 oder 15, dadurch gekennzeichnet, dass die Proxy-Server (PX1 ... PX3) einer gegebenen Hierarchieebene der Server-Struktur dafür ausgelegt sind, Sitzungen zum Herunterladen einer Software aufzubauen, welche in Software-Repositories (SP1, SP2, SS, SH1) enthalten ist, die über Download-Management-Einheiten (PRM1, PRM2, SRM, HRM) zugänglich sind, welche die besagten Server beherbergen.
System, das mindestens ein Serving and Gateway Mobile Switching Centre und GPRS Support Nodes (S-MSC/SGSN und G-MSC/GGSN) umfasst, gemäß einem der Ansprüche 14 bis 16, dadurch gekennzeichnet, dass ein User-Agent (CL) so ausgelegt ist, dass der Aufbau einer Download-Sitzung zunächst bei dem Proxy-Server auf der untersten Ebene (PX1, PX2) angefragt wird und dass, falls die herunterzuladende Software in dem Repository (SP1, SP2), das über eine Download-Management-Einheit (PRM1, PRM2) auf der besagten untersten Ebene zugänglich ist, nicht enthalten ist, eine Anfrage zur Umleitung der Sitzung von dem besagten Proxy-Server der untersten Ebene (PX1, PX2) an den User-Agent (CL) gesendet wird, um diesen darüber zu informieren, dass die Sitzung zu einer höheren Ebene aufgebaut werden muss, wobei die Sitzungsaufbau-Anfrage und das Senden der Umleitungs-Anfrage bei jeder bzw. durch jede der aufeinander folgenden höheren Stufen wiederholt wird, bis die Sitzungsaufbau-Anfrage die Ebene erreicht, auf der die Software zur Verfügung steht.
System gemäß einem der Ansprüche 14 bis 17, dadurch gekennzeichnet, dass Software-Repositories (SS, SH1), die über die Download-Management-Einheiten (SRM, HRM) auf Ebenen oberhalb derjenigen, die mit der untersten Ebene (PX1, PX2) der Server-Struktur verknüpft ist, zugänglich sind, ebenfalls Software speichern, die in den Repositories (SP1, SP2) enthalten ist, welche über die Download-Management-Einheiten (PRM1, PRM2) auf niedrigeren Ebenen zugänglich sind.
System gemäß einem der Ansprüche 14 bis 18, dadurch gekennzeichnet, dass Proxy-Server (PX3), die auf einer Ebene unmittelbar oberhalb einer untersten Ebene liegen, in den Download-Management-Einheiten (SRM) enthalten sind, welche den besagten Mitteln (SGSN) zur Steuerung von paketbasierten Diensten zugeordnet sind, und dass im Falle eines Handovers zwischen Funkzugangsnetzen (RAT1, RAT2), die mit demselben Mittel zur Steuerung von paketbasierten Diensten (SGSN) verbunden sind, der besagte Proxy-Server (PX3) auf einer Ebene unmittelbar oberhalb der untersten Ebene dafür ausgelegt ist, die Umleitung einer Software-Download-Sitzung, die von einem Proxy-Server (PX1, PX2) der untersten Hierarchieebene in dem ersten Funkzugangsnetz (RAT1) aufgebaut wurde, auf das zweite Funkzugangsnetz (RAT2) zu verwalten.
System gemäß Anspruch 12 und 19, dadurch gekennzeichnet, dass der besagte Proxy-Server (PX1, PX2) auf der untersten Hierarchieebene dafür ausgelegt ist, auf den Empfang der Nachricht mit der Umleitungs-Anfrage damit zu reagieren, dass eine zweite Nachricht mit einer Umleitungs-Anfrage an den besagten Proxy-Server (PX3) der nächsthöheren Ebene gesendet wird, und dass der besagte Proxy-Server (PX3) der nächsthöheren Ebene dafür ausgelegt ist, die neue Sitzung in dem zweiten Funkzugangsnetz (RAT2) aufzubauen, sobald die besagte zweite Nachricht mit einer Umleitungs-Anfrage empfangen wird, und die alte Sitzung, die in dem ersten Funkzugangsnetz (RAT1) noch anhängig ist, auszulösen.
System gemäß einem der Ansprüche 14 bis 18, dadurch gekennzeichnet, dass Proxy-Server (PX3), die auf Ebenen oberhalb einer untersten Ebene liegen, dafür ausgelegt sind, im Falle eines Handovers zwischen Funkzugangsnetzen (RAT1, RAT2), die mit demselben Mittel zur Steuerung paketbasierter Dienste (SGSN) verbunden sind, die Umleitung von Software-Download-Sitzungen, die sie in dem ersten Funkzugangsnetz (RAT1) aufgebaut haben, an das zweite Funkzugangsnetz (RAT2) zu verwalten.
System gemäß einem der Ansprüche 14 bis 18, dadurch gekennzeichnet, dass ein Proxy-Server auf einer der obersten Hierarchieebenen dafür ausgelegt ist, im Falle eines Handovers zwischen Funkzugangsnetzen (RAT1, RAT2), die mit verschiedenen Mitteln zur Steuerung paketbasierter Dienste (SGSN) verbunden sind, die Wiederaufnahme des Download-Vorgangs zu verwalten, unabhängig von der Ebene des Proxy-Servers, der die Software-Download-Sitzung in dem ersten Funkzugangsnetz (RAT1) aufgebaut hat.