DE10208432A1

DE10208432A1 - Verfahren zur servergestützten Datenverarbeitung für eine Mehrzahl von Clients

Info

Publication number: DE10208432A1
Application number: DE10208432A
Authority: DE
Inventors: Claudia Oltmanns; Gerald Oltmanns
Original assignee: Siemens AG
Current assignee: Nokia Solutions and Networks GmbH and Co KG
Priority date: 2002-02-22
Filing date: 2002-02-22
Publication date: 2003-09-18
Anticipated expiration: 2022-02-23
Also published as: US20030233406A1; US7145995B2; DE10208432B4

Abstract

Verfahren zur servergestützten Datenverarbeitung einer Mehrzahl von mit einem Server mindestens temporär verbundener Clients, wobei der Server eine definierte Menge an Verarbeitungs-Ressourcen verwaltet, die Clients jeweils eine Teilmenge der Verarbeitungs-Ressource für einen Reservierungszeitraum reservieren und der Server die Reservierungen der Clients verwaltet und diesen die reservierten Teilmengen der Verarbeitungs-Ressource für den Reservierungszeitraum bereitstellt, wobei ein Bestätigungs-Zeitraum definiert wird, in dem der Server zum Empfang einer Reservierungsbestätigung bereit ist.

Description

Die Erfindung betrifft ein Verfahren zur servergestützten Datenverarbeitung für eine Mehrzahl von mit einem Server mindestens temporär verbundenen Clients nach dem Oberbegriff des Anspruchs 1.
Derartige Verfahren sind auf verschiedenen technischen Gebieten und in vielfältigen Anwendungs-Kontexten bekannt geworden. Grundsätzlich werden Verfahren dieser Art sowohl in Rechnersystemen mit verteilten Ressourcen zur Lösung komplexer Verarbeitungsaufgaben als auch beispielsweise in Kommunikationsnetzen mit einer Vielzahl von Teilnehmern sowie einem zentralen elektronischen Vergebührungssystem angewandt. Große wirtschaftliche Bedeutung haben sie perspektivisch bei der Entwicklung und dem Betrieb von IN-Diensten mit Gebührenabbuchung von einem vorausbezahlten Guthaben (Prepaid- Guthaben).
Bei der Entwicklung eines IN-Dienstes (Prepaid-Service) ist es möglich, Teilbeträge bzw. Portionen des Guthabens eines Dienstnutzers und Kontoinhabers (Subscribers) zu reservieren. Der Abzug des vertelefonierten Geldes erfolgt normalerweise am Ende des Rufes. Erst hierbei werden die Reservierungen des Rufes zurückgenommen.
Es muß sichergestellt werden, daß bei abgebrochenen Rufen auch ohne diese Endbehandlung deren Reservierungen wieder freigegeben werden. Ansonsten wäre das "Abtelefonieren" des gesamten Guthabens nicht mehr möglich.
Aktuell wird das dadurch gelöst, daß beim Zugriff eines beliebigen Rufes (Calls) auf den Account überprüft wird, wie lange auf diesen Account nicht mehr zugegriffen wurde. Bei Überschreiten einer vorgebbaren (Recovery-)Zeit werden sämtliche Reservierungen gelöscht. Beim Zurücksetzen muß sichergestellt sein, daß kein "lebender" Call eine Reservierung hält.
Bei Mobilfunkverbindungen nach dem GPRS-Standard wird für always-on-Szenarien jedoch kontinuierlich auf den Account zugegriffen, d. h. es ist zu jeder Zeit wenigstens die (Gebühren-)Portion des GPRS-Calls bis zum nächsten ACR reserviert. Daher können nach der jetzigen Methode niemals die Reservierungen zurückgesetzt werden. Die Reservierungen von u. U. abgebrochenen parallelen Rufen stehen dem Subscriber nicht mehr zur Verfügung.
Das Hauptproblem birgt der Recovery-Mechanismus in sich: Die beim RESERVE übergebene RecoveryTime bezieht sich nicht auf die einzelne Reservierung, sondern im Falle, daß die übergebene Zeit seit dem letzten reservierenden Zugriff abgelaufen ist, werden alle Reservierungen auf Null zurückgesetzt. Daraus ergibt sich, daß "hängende" Reservierungen nur dann aufgehoben werden, wenn zwischen zwei Rufen mindestens eine Pause in Länge der Recovery-Zeit ist. Bei "normalen" Rufen ist dieses Verhalten nicht so kritisch, da

- die Recovery-Zeit hier in der Regel relativ klein gehalten werden kann (vergebührung nach Zeit) und
- die Rufe nicht ewig andauern, so daß die Chance für eine baldige Pause sehr hoch ist.

Bei GPRS hat man das Problem, daß die Rufe beliebig lange andauern können (volumenbasierte Vergebührung). "Hängende" Reservierungen haben kaum eine oder u. U. keine Chance, aufgehoben zu werden.
Bei langlebigen Calls (GPRS-Calls oder auch anderen) oder kurz aufeinanderfolgenden Calls kann es aus demselben Grund dazu kommen, daß Reservierungen von parallelen bzw. vorangegangenen Rufen, die abgebrochen wurden, aus Sicht des Teilnehmers zu spät wieder freigegeben werden.
Der Erfindung liegt daher die Aufgabe der Bereitstellung eines verbesserten Verfahrens der gattungsgemäßen Art zugrunde, welches insbesondere eine korrekte Handhabung der Ressourcen- bzw. Guthaben-Reservierung bei modernen Kommunikationssystemen - speziell bei Mobilfunkverkehr nach dem GPRS-Standard - erlaubt.
Diese Aufgabe wird durch ein Verfahren mit den Merkmalen des Anspruchs 1 gelöst.
Es wird eine Lösung beschrieben, die eine zweite Reservierungssumme verwendet, in der ständig die aktuell "lebenden" Calls ihre gesamten Reservierungen bestätigen. Zu den Recovery-Zeitpunkten wird dann nicht mehr wie bisher die Summe der Reservierungen auf Null gesetzt, sondern durch den Wert der zweiten Reservierungssumme ersetzt. Jede Call- Instanz muß sich innerhalb einer gewissen Zeit (RecoveryTime) beim Account mindestens einmal zurückmelden und damit ihre Reservierung bestätigen. Nicht mehr aktive Rufe werden sich nicht mehr melden können, um ihre Reservierung zu bestätigen. Deren Reservierungen werden dann beim ersten Zugriff auf den Account nach Ablauf der Recovery-Zeit wieder freigegeben.
Zu diesem Zwecke führt der Account-Manager für jeden Account neben dem normalen Reservierungszähler (der, wie gehabt, für die RESERVE/CHARGE-Funktionalität verwendet wird) einen weiteren, in dem alle innerhalb des aktuell laufenden Recovery-Intervalls bestätigten Reservierungen nochmals summiert werden. Stimmt nach Ablauf der Recovery-Zeit diese Summe nicht mit der des tatsächlichen Reservierungszählers überein, so existier(t)en Call-Instanzen, die sich offenbar nicht mehr zurückgemeldet haben und deren Reservierungen hinfällig sind. Daher kann die Differenz zwischen den Zählerständen der beiden Reservierungszähler von dem des tatsächlichen Reservierungszählers abgezogen werden.
In einer bevorzugten Verfahrensführung wird ein Maximal- Reservierungszeitraum bestimmt und festgelegt, daß die Länge eines für die Clients erhältlichen Reservierungszeitraumes höchstens gleich dem Maximal-Reservierungszeitraum ist.
Weiterhin wird bevorzugt vorab vor Beginn des Verfahrens eine generelle Anforderung von Reservierungsbestätigungen an die Clients übermittelt, die für sämtliche Reservierungszeiträume während der Verfahrensdurchführung gilt.
Für die Festlegung der Länge des Maximal-Reservierungszeitraumes sowie des Bestätigungs-Zeitraumes in Abhängigkeit von diesem gibt es mehrere alternative Möglichkeiten: In einer ersten Variante wird vorab vor Verfahrensbeginn der Maximal- Reservierungszeitraum und in Abhängigkeit davon der Bestätigungs-Zeitraum fest definiert. Eine zweite Variante sieht vor, daß während der Verfahrensdurchführung die Reservierungszeiträume erfaßt werden und hieraus der Maximal-Reservierungszeitraum bestimmt wird, wobei der Bestätigungs-Zeitraum als fester Wert, bezogen auf den Maximal-Reservierungszeitraum, definiert wird. In einer dritten Variante schließlich wird der Bestätigungs-Zeitraum als Verhältniswert, bezogen auf den Maximal-Reservierungszeitraum, in Abhängigkeit von der Verfahrensdurchführung dynamisch definiert.
Wie weiter oben bereits angesprochen, wird insbesondere am Ende des Bestätigungs-Zeitraumes die Menge der vorliegenden Reservierungen mit der Menge der bestätigten Reservierungen verglichen, und es erfolgt eine Freigabe nicht bestätigter Teilmengen der Verarbeitungs-Ressource durch Gleichsetzung der Summe aller Reservierungen mit der Summe der bestätigten Reservierungen.
Bei der oben erwähnten Zukunfts-Anwendung der Bereitstellung von Netzressourcen eines Mobilfunknetzes für GPRS-Calls aufgrund eines Prepaid-Guthabens geht es neben der Reservierung von Verarbeitungs-Ressourcen in Gestalt von Rechner- bzw. Übertragungskapazitäten insbesondere auch um die Handhabung virtueller Geldbeträge, speziell die Abbuchung von virtuellen Guthaben. Mit den nachfolgenden Ausführungen werden vorteilhafte Realisierungsaspekte eines entsprechenden Verfahrens unter Bezugnahme auf die Figuren näher erläutert. Diese zeigen beispielhaft in symbolischen Darstellungen verschiedene Rufszenarien, nämlich
Fig. 1 eine Situation, bei der drei Rufe (Calls) auf einen Account zugreifen und Reservierungen vorgenommen haben, welche für ein erstes Recovery-Intervall als bestätigt gelten,
Fig. 2 die Situation, daß nach Ende des ersten Recovery- Intervalls ein erster Ruf wieder auf den Account zugreift,
Fig. 3 die Situation, daß nach Ende des ersten Recovery- Intervalls ein zweiter Ruf auf den Account zugreift und
Fig. 4 die Situation, daß nach Ende eines zweiten Recovery- Intervalls wiederum ein Ruf auf den Account zugreift.
Bei dem in Fig. 1 bis 4 skizzierten System handelt es sich um ein Verfahren für online-vergebührte IN-Rufe, wobei die zu verwaltende Ressource ein Prepaid-Guthaben Account, der Server ein sogenannter Account-Manager und die Clients parallele IN-Rufe Call 1 bis Call n sind, welche über denselben Account vergebührt werden.
Aus Platz-/Performance-Gründen kann für einen Account keine Call-spezifische Information im Account-Manager gehalten werden. Daher muß die aufrufende Instanz die jeweils notwendige Kontext-Information (siehe unten) jedesmal mitliefern.

Account-Daten

Inhaltlich werden folgende Felder benötigt:

Abgleich wenn reservation_account_1 größer reservation_account_2, dann

- reservation_account_1 = reservation_account_2
- reservation_account_2 = 0

Recovery-Zeit

Unter Verwendung des timestamps (nächster Abgleich) und der Recovery-Zeit wird der Start des Abgleichs der beiden Reservierungszähler gesteuert (Die folgende Bedingung wird bei jedem RESERVE/CHARGE-Aufruf überprüft):
wenn aktuelle Zeit größer timestamp (nächster Abgleich), dann

- erhöhe timestamp (nächster Abgleich) um RTstat (statische Recovery-Zeit)
- starte Abgleich

Es wird vorausgesetzt, daß die Recovery-Zeit einmal statisch für einen Account festgelegt wird. Sollte es notwendig sein, die Recovery-Zeit dynamisch einzustellen, so ist auch dies unter folgenden Voraussetzungen denkbar:

a) extra Datenfeld im Account zum Halten der aktuellen Recovery-Zeit (RTmax). Aus Platzgründen sollte der Wert der Recovery-Zeit MAXSHORT nicht überschreiten.
b) die Recovery-Zeit kann nur vergrößert werden
c) für alle aufrufenden Instanzen gilt die maximale Recovery- Zeit.

Behandlung beim RESERVE-Aufruf

- erhöhe timestamp (nächster Abgleich) um Delta (RTneu, RTmax)
- RTmax = RTneu

Behandlung beim Abgleich

- erhöhe timestamp (nächster Abgleich) um RTmax
- starte Abgleich

Die Einschränkung b) kann auf Kosten eines weiteren Account- Feldes (RTlastmax) auf das aktuell laufende Recovery-Intevall beschränkt bleiben. Dazu müßte in diesem zusätzlichen Feld die letzte Recovery-Zeit vermerkt werden, die beim Abgleich zur Bildung des neuen timestamps (nächster Abgleich) verwendet wurde: Die Behandlung beim RESERVE-Aufruf müßte dann wie folgt erfolgen:
wenn RTneu größer RTlastmax, dann

- erhöhe timestamp (nächster Abgleich) um Delta(RTneu, RTlastmax)

- RTmax = RTneu

Behandlung beim Abgleich

- erhöhe timestamp um RTmax
- RTlastmax = RTmax
- RTmax = 0

Behandlung der Kontext-Information bei RESERVE

Diese Kontext-Information ist bei jedem RESERVE-Aufruf zu übergeben und wird wie folgt ausgewertet:

- Abgleich-Funktion (siehe oben)
- aktPortion = Reservierungs-Funktion mit Update reservation_account_1 (wie gehabt)
- last_reservation_time kleiner/gleich
(timestamp (nächster Abgleich) - RT (RTlastmax/RTmax/RTstat je nach Variante)), dann
- Der Call meldet sich gerade das erstemal im aktuellen Recovery-Intervall zurück. Alle Reservierungen aus den letzten Intervallen und die aktuelle Reservierung müssen bestätigt werden:
erhöhe reservation_account_2 um aktPortion und sum_reserved_portions
wenn
last_reservation_time größer
(timestamp (nächster Abgleich) - RT (RTlastmax/RTmax/RTstat je nach Variante)), dann
- Der Call hatte sich bereits im aktuellen Recovery-Intervall zurückgemeldet und beim erstenmal alle Reservierungen aus den letzten Intervallen bestätigt. Daher muß nur noch die aktuelle Reservierung bestätigt werden.:
erhöhe reservation_account_2 um aktPortion

Eine einfache COMMIT_RESERVATION-Operation kann eingeführt werden, die dann analog zu RESERVE mit aktPortion = 0 abläuft. Behandlung der Kontext-Information bei CHARGE
Diese Kontext-Information ist bei jedem CHARGE-Aufruf zu übergeben und wird wie folgt ausgewertet:

- Abgleich-Funktion (siehe oben)
- Charge-Funktion mit Update account und
reservation_account_1 (wie gehabt)
wenn last_reservation_time kleiner/gleich
(timestamp (nächster Abgleich) - RT (RTlastmax/RTmax/RTstat je nach Variante)), dann
- Der Call meldet sich gerade das erste mal im aktuellen Recovery-Intervall zurück. Alle Reservierungen aus den letzten Intervallen müßten bestätigt werden. Da die CHARGE- Funktion ohnehin alle angesagten Vergebührungen zurücknimmt, ist in diesem Falle nichts mehr zu tun.
- wenn last_reservation_time größer
(timestamp (nächster Abgleich) - RT (RTlastmax/RTmax/RTstat je nach Variante)), dann
- Der Call hatte sich bereits im aktuellen Recovery-Intervall zurückgemeldet und beim ersten mal alle Reservierungen aus den letzten Intervallen bestätigt. Daher muß noch die Summe aller Reservierungen abgezogen werden: verringere reservation_account_2 um charged_money

COMMIT_RESERVATION

Im oben beschriebenen Verfahren wurde der Einfachheit halber die RESERVE-Funktion zur Bestätigung der Reservierungen verwendet.
Es kann zu diesem Zwecke aber auch eine einfache COMMIT_RESERVATION-Operation eingeführt werden, die dann analog zu RESERVE mit aktPortion = 0 abläuft und regelmäßig (wenigstens einmal im recovery-Intervall) aufgerufen werden muß.
Die Figuren sind im Hinblick auf die obigen Erläuterungen zu den verwendeten Begriffen und angenommenen Abläufen im wesentlichen selbsterklärend. Die dargestellten Situationen sind wie folgt:
In Fig. 1 haben drei IN-Rufe Call 1, Call 2 und Call n auf das Prepaid-Guthaben Account zugegriffen und Reservierungen vorgenommen. Alle diese Reservierungen gelten für das erste Recovery-Intervall als bestätigt. In Fig. 2 greift der erste Ruf Call 1 nach Ablauf der Recovery-Zeit als erster wieder auf den Account zu. Es erfolgt ein Abgleich der Reservierungen mit den Bestätigungen. Da keine Differenzen vorliegen, bleibt reservation_account_1 unberührt, während reservation_account_2 zurückgesetzt wird. Call 1 bestätigt seine ursprüngliche Reservierung und reserviert einen weiteren Guthabenbetrag.
In Fig. 3 wird durch einen weiteren Ruf Call 3 die ursprüngliche Reservierung bestätigt und ein weiterer Guthabenanteil (Portion) reserviert. Der zweite Ruf Call 2 wurde abgebrochen, ohne daß der Account-Manager eine entsprechende Information erhält. In Fig. 4 greift Call 3 nach Ablauf der Recovery-Zeit als erster wieder auf das Guthaben zu. Es erfolgt ein Abgleich zwischen Reservierungen und bestätigten Reservierungen, und diesmal sind infolge der unterbliebenen Rückmeldung von Call 2 Abweichungen entstanden. Daraufhin übernimmt reservation_account_1 Werte aus reservation_account_2, und reservation_account_2 wird zurückgesetzt. Call 3 bestätigt nochmals seine bisherigen Reservierungen und reserviert eine weitere Portion.
Die Ausführung der Erfindung ist nicht auf das beschriebene Beispiel und die oben hervorgehobenen Verfahrensaspekte beschränkt, sondern ebenso in einer Vielzahl von Abwandlungen möglich, die im Rahmen fachgemäßen Handelns liegen.

Claims

1. Verfahren zur servergestützten Datenverarbeitung einer Mehrzahl von mit einem Server mindestens temporär verbundener Clients, wobei der Server eine definierte Menge an Verarbeitungs-Ressource verwaltet, die Clients jeweils eine Teilmenge der Verarbeitungs-Ressource für einen Reservierungszeitraum reservieren und der Server die Reservierungen der Clients verwaltet und diesen die reservierten Teilmengen der Verarbeitungs-Ressource für den Reservierungszeitraum bereitstellt, dadurch gekennzeichnet, daß
einzelne Reservierungen nicht als solche vom Server verwaltet werden, sondern nur als Summen: tatsächliche Reservierungssumme und Summe der bestätigten Reservierungen,
ein Bestätigungs-Zeitraum definiert wird, in dem der Server zum Empfang einer Reservierungsbestätigung bereit ist,
an alle Clients die Anforderung einer Reservierungsbestätigung und eine Information über den definierten Bestätigungs-Zeitraum gesandt wird,
die Clients im Bestätigungs-Zeitraum für ihre tatsächlich benötigten Reservierungen eine Reservierungsbestätigung an den Server senden,
der Server die empfangenen Reservierungsbestätigungen registriert und verwaltet und
der Server am Ende des Bestätigungs-Zeitraumes die reservierten Teilmengen der Verarbeitungs-Ressource freigibt, für die keine Reservierungsbestätigung vorliegt.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß
ein Maximal-Reservierungszeitraum bestimmt und festgelegt wird, daß die Länge eines für die Clients erhältlichen Reservierungszeitraumes höchstens gleich dem Maximal- Reservierungszeitraum ist, und
die Länge des Bestätigungs-Zeitraumes in Abhängigkeit von derjenigen des Maximal-Reservierungszeitraumes festgelegt wird.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß vorab vor Beginn des Verfahrens eine generelle Anforderung von Reservierungsbestätigungen an die Clients übermittelt wird, die für sämtliche Reservierungszeiträume während der Verfahrensdurchführung gilt.

4. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß vorab vor Verfahrensbeginn der Maximal-Reservierungszeitraum und in Abhängigkeit davon der Bestätigungs-Zeitraum fest definiert wird.

5. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß während der Verfahrensdurchführung die Reservierungszeiträume erfaßt werden und hieraus der Maximal-Reservierungszeitraum bestimmt wird, wobei der Bestätigungs-Zeitraum als fester Wert, bezogen auf den Maximal-Reservierungszeitraum, definiert wird.

6. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß der Bestätigungs-Zeitraum als Verhältniswert, bezogen auf den Maximal-Reservierungszeitraum, in Abhängigkeit von der Verfahrensdurchführung dynamisch definiert wird.

7. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß am Ende des Bestätigungs-Zeitraumes die Menge der vorliegenden Reservierungen mit der Menge der bestätigten Reservierungen verglichen wird und eine Freigabe nicht bestätigter Teilmengen der Verarbeitungs-Ressource durch Gleichsetzung der Summe aller Reservierungen mit der Summe der bestätigten Reservierungen erfolgt.

8. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß die Verarbeitungs-Ressource ein virtueller Geldbetrag ist und die Datenverarbeitung eine elektronische Abbuchung hiervon umfaßt.

9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, daß ein Kontodatensatz zur Verarbeitung des virtuellen Geldbetrages die Felder "account" für den vorhandenen Geldbetrag, "timestamp" für den Endzeitpunkt des Bestätigungs-Zeitraumes, "reservation_account_1" für den Zähler aller Reservierungen und "reservation_account_2" für den Zähler aller im Bestätigungs-Zeitraum bestätigten Reservierungen umfaßt.

10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, daß der Kontodatensatz zusätzlich die Felder "Rtmax" für den aktuellen Maximal-Reservierungszeitraum und "Rtlastmax" für den zuletzt gültigen, zur Bestimmung des Bestätigungs- Zeitraumes herangezogenen Maximal-Reservierungszeitraum umfaßt.

11. Verfahren nach einem der Ansprüche 8 bis 10, dadurch gekennzeichnet, daß jede Reservierungsanforderung eines Client eine Kontextinformation umfaßt, welche die Kontextelemente "new_portion" für die zu reservierende Teilmenge der Verarbeitungs-Ressource, "sum_reserved_portions" für die Summe der aktuell in einem Verarbeitungsvorgang reservierten Teilmengen, ohne die neu zu reservierende Teilmenge, und "last_reservation_time" für den Zeitpunkt der letzten vorherigen Reservierung umfaßt.

12. Verfahren nach Anspruch 11, dadurch gekennzeichnet, daß eine Reservierungsbestätigung eine Kontextinformation mit gleichem Aufbau wie eine Reservierung umfaßt, wobei das Kontextelement "new_portion" gleich Null gesetzt ist.

13. Verfahren nach einem der Ansprüche 8 bis 12, dadurch gekennzeichnet, daß ein die Beendigung eines Verarbeitungsvorganges signalisierendes Abbuchungssignal eine Kontextinformation umfaßt, welche die Kontextelemente "charged_money" über die Höhe des abzubuchenden virtuellen Geldbetrages, "sum_reserved_portions" über die Summe aller bisher im Verarbeitungsvorgang reservierten Teilmengen und "last_reservation_time" zum Zeitpunkt der letzten Reservierung umfaßt.