EP1668860A1 - Verfahren zur bereitstellung von leistungsmerkmalen bei bedarf - Google Patents

Verfahren zur bereitstellung von leistungsmerkmalen bei bedarf

Info

Publication number
EP1668860A1
EP1668860A1 EP04766434A EP04766434A EP1668860A1 EP 1668860 A1 EP1668860 A1 EP 1668860A1 EP 04766434 A EP04766434 A EP 04766434A EP 04766434 A EP04766434 A EP 04766434A EP 1668860 A1 EP1668860 A1 EP 1668860A1
Authority
EP
European Patent Office
Prior art keywords
bandwidth
server
feature
request
terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP04766434A
Other languages
English (en)
French (fr)
Inventor
Rainer Zimmermann
Bruno Bozionek
Dieter Hemkemeyer
Karl Klaghofer
Michael Tietsch
Rainer Uecker
Ralf Neuhaus
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Unify GmbH and Co KG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Publication of EP1668860A1 publication Critical patent/EP1668860A1/de
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • the invention relates to a method for transmitting software and / or data on request from a server to a terminal in a packet network.
  • the principle is often used to only reload certain software components from the network when necessary. This principle is referred to as software on demand.
  • the end device can use less storage capacity because the proportion of software and data in the end device that is not used anyway is reduced, on the other hand, it enables central management of the data and software and, in some cases, software savings -License fees.
  • This principle is also known in particular for IP-based (internet protocol-based) telecommunications networks, in which end devices only reload the software for certain performance features when the user needs the performance feature, i.e. if he uses it or activates it (feature-on-demand).
  • the features are stored on a central server, which is also called the "Feature Mall", and a feature is transferred to the terminal when it is activated and installed there.
  • the Feature Mall can also be a central or decentralized service ,
  • LAN local area networks
  • the bandwidths are normally sufficient to enable the feature to be transmitted almost in real time. In this case, the user cannot distinguish whether the feature is transmitted on-demand or whether it is already installed in his end device.
  • Bandwidths are managed in a packet network by a network resource manager.
  • network resource management is only used to carry out a call acceptance check. This does not prevent waiting times when reloading features on demand.
  • the object of the invention is to provide a method and a device with which a transfer of software and data on-demand under practical conditions is possible in a satisfactory manner.
  • the object is achieved with a method according to claim 1 and a server according to claim 14, with a terminal according to claim 21 and in a network arrangement according to claim 23.
  • the invention includes the essential idea of checking before transmission whether the available resources are sufficient to quickly make software or data available. The key question is whether a transfer can be carried out quickly enough upon a load request, which mainly depends on the bandwidth. If the currently available bandwidth is not sufficient, the load request is rejected.
  • the method according to the invention and the server use the bandwidth test to ensure that, at the time of transmission, there is sufficient bandwidth available for transmission within a time limit (which can be predetermined in view of user habits).
  • a satisfactory loading time can be guaranteed for the user via the bandwidth, and it reliably prevents software or data from being transmitted with unreasonable waiting times.
  • the terminal device makes transparent to the user which features are actually available to him in an acceptable time and not just nominally. Even if the available bandwidth is low, the user is not tempted to select a feature several times that is in his selection list, but at least cannot be transmitted at the moment.
  • the method is preferably used in IP-based telecommunication networks.
  • Terminal devices with fewer resources of their own, which are often used in telecommunications, benefit from on-demand transmission, and at the same time the acceptable waiting times are short.
  • the software to be transferred is a performance feature that is requested by the end device when required.
  • the method according to the invention ensures that the use of such performance is not made difficult by long charging times.
  • the bandwidth required is advantageously calculated on the basis of an upper limit for the loading time.
  • the parameter that is of greatest interest to the user is used as the criterion with the loading time. It does not use more bandwidth and ultimately expensive network resources than necessary.
  • the information about the required bandwidth is preferably part of the request and is thus made available by the terminal. This allows an individual and also configurable requirement for the available bandwidth, depending on the device. Alternatively or additionally, the information about the required bandwidth is associated with the requested data or the requested software and is therefore made available by the server.
  • the server has access to the respectively requested software or the requested data, with which a bandwidth requirement can be stored at the same time or from which the bandwidth requirement can be easily determined.
  • the information about the available bandwidth is made available by a network resource manager, this information being updated in particular regularly or at the request of the server. Current bandwidth data is therefore always available and network resource management that already exists for other tasks can be used.
  • the network resource management preferably manages priorities for all network resource requests and carries out the following steps in the event of a negative test result of the bandwidth test: - Determination of the difference in demand between required and existing network resources for the transmission,
  • This procedure enables network resources to be assigned to different users, end devices or requested data or software depending on their importance, and a loading request that initially failed could still be served with the required bandwidth if the importance was high.
  • a message is sent to the end device, which message can include one of the following two rejections:
  • the terminal receives the information as to whether another similar charging request could be successful immediately or at a later point in time. After a temporary rejection, a new loading request is advantageously generated automatically. Was the required bandwidth only temporarily not available, it can be used at a later time.
  • a permanent rejection can preferably be generated by one of the following steps:
  • the user of the terminal is preferably shown the message, in particular by marking the option for the request that led to the message with a warning or making it completely inaccessible.
  • a bandwidth requirement memory for storing the required bandwidth for a performance feature is advantageously additionally connected to the performance feature providing device so that the performance feature providing device can carry out the bandwidth test to determine which bandwidth a transmission of data and / or software according to a La - Required for a feature.
  • This bandwidth requirement memory enables the required bandwidth to be looked up quickly.
  • Preference has the performance feature - Most ready! 1 device access to a maximum bandwidth memory for storing the maximum available bandwidths for connections to terminal devices in order to provide an additional or alternative bandwidth perform the tentest based on the maximum available bandwidths.
  • the maximum bandwidths can therefore be easily looked up.
  • a network resource allocation device which is connected to the performance feature provision device and has access to the available bandwidth memory, the network resource allocation device being able to allocate or refuse network resources to the loading request and accordingly to the available bandwidths - Memory updated.
  • a network resource allocation device is usually part of a server and can be used in a simple manner for communication relating to the bandwidth with the performance feature provision device.
  • the network resource allocation device is connected to a network resource test device which has access to the available bandwidth memory and at least one connection to a terminal in order to keep up to date
  • the network resource test device can determine and store the currently available bandwidths so that current data is stored in the available bandwidth memory.
  • the network resource allocation device has access to a network resource distribution memory which stores data about bandwidths assigned to processes and priorities of these processes, the network resource allocation device being able to redistribute network resources depending on the priorities of the processes and the loading request in order to provide sufficient bandwidth for the loading request close.
  • a network resource distribution memory is a prerequisite for intelligent management of the existing network resources.
  • the network resource allocation device further preferably has access to a network resource request memory which stores data about requested bandwidths in order to manage processes to which no bandwidth is currently allocated. A storage for unprocessed or frozen
  • Table 1 shows an example of a network resource management table that is stored in a server according to the invention
  • Table 2 shows an example of an availability table of performance features that is stored in a server according to the invention.
  • 1 is a highly simplified schematic representation of a minimal network with a terminal according to the invention and a server according to the invention
  • 2 shows an example for the data exchange between a terminal and a server according to the inventive method
  • FIG. 3 shows a more detailed schematic representation of the functional units in a server according to the invention.
  • FIG. 4 shows a block diagram of a network arrangement according to the invention.
  • the network is a packet network and can be an IP-based telecommunication network, in which case the terminal 10 can also be a telecommunication terminal.
  • the terminal 10 offers the user via a user interface 11 access to various software or data which the user can select and which are then loaded on-demand by the server 20 if they are not available locally.
  • the software is often a feature that is requested by a feature loading device 12 connected to the user interface on-demand from the server 20 or a service running on this server. Therefore, in the following only the term performance feature is used, but also general software or data are included, which are processed in principle in the same way by the inventive method and the devices.
  • bandwidth is always used as a criterion for sufficient performance.
  • bandwidth translates directly into waiting time, ie it is the appropriate parameters, although sufficient bandwidth is of no immediate importance to the user. This means that the need for a real-time application can also be included if necessary, because real-time ultimately means nothing other than that the waiting times are very short and, depending on the requirements of the requesting application, can be neglected or lie in the area that is also required for activation local functions is required.
  • a loading request corresponding to the selected performance feature is sent from the performance feature loading device 12 to a performance feature management device 30 connected to it in the server 20 and processed there.
  • the performance feature management device 30 is connected to a network resource management device 40 which, among other things, provides information about network resources.
  • FIG. 2 shows an example of the data and message exchange between the terminal 10 and the server 20 using the method according to the invention.
  • a user selects a feature in the user interface 11, and the user interface 12 forwards a corresponding request to the feature loading device 12 (step S1).
  • the feature loading device normally forwards this loading request to the feature management device 30 in the server 20 (step S2).
  • it can also be tested beforehand whether a similar charging request has already been made or whether the request should not be forwarded due to network problems, for example.
  • the performance management device 20 generates a bandwidth status request to the network resource management device 40 after receiving the load request (Step S3).
  • This bandwidth status request is processed by the network resource management device 40 in a manner detailed in connection with FIG. 4 (step S4), and the bandwidth status is returned to the feature management device 30 (step S5).
  • the performance feature management device 30 evaluates the charging request (step S6). First, it is tested whether the available bandwidth is sufficient for a transmission of the requested performance. (This bandwidth test is also explained in more detail below in connection with FIG. 4.) It is pointed out that the bandwidth test can also be carried out without a network resource management device 40 and the associated method steps S3 to 35. Then the test is limited to information that is independent of the dynamic properties of the network connections. Examples of this could be, in principle, not to transfer any performance features via a bottleneck, such as an internet connection, or outside of your own local network (LAN), or to set a (possibly time-dependent) limit on the server side, i.e. in principle not to transmit any performance characteristics that exceed a maximum bandwidth requirement.
  • a bottleneck such as an internet connection, or outside of your own local network (LAN)
  • LAN local network
  • the bandwidth test delivers a positive test result, the requested feature, otherwise a message about the rejection to the feature loading device 12, is transmitted (step S7).
  • the feature loading device 12 can simply pass on the feature or the message to the user interface
  • Step S8 and thus end the process cycle.
  • it can also carry out its own processing steps. This includes caching, temporary storage of the performance feature in order to make it available to another connected user interface, or local storage of the performance feature for later inquiries on a permanent storage medium.
  • the performance feature loading device 12 automatically evaluates the rejection and, if necessary, generates a new loading request and sends it to the server.
  • the rejection is divided into at least two classes, namely temporary and permanent rejections.
  • a temporary rejection could mean that although not enough bandwidth is currently available, a transfer with the desired bandwidth would in principle be possible with a lower utilization by other processes.
  • a permanent rejection indicates that further charging requests will not result in the desired performance being transferred.
  • a temporary or repeated repeated rejection can lead to a permanent rejection. This decision can be made on the server side as well as on the end device. Another possible reason for a permanent rejection is if the maximum bandwidth is already smaller than the required one.
  • the user interface 11 installs the transmitted performance feature, which can be used by the user from this point in time. If the user's load request has not resulted in the transfer of the selected feature, the user interface indicates this to the user. This can be a simple message; However, it is clearer if the result of the current and previous charging requirements can be seen directly in the selection of possible performance features.
  • Each feature can e.g. be provided on a control panel of the corresponding end device with a (color) coding or an addition which indicates its status: local performance feature, already reloaded, (simple or x-fold) failed attempt to charge. In particular, a performance feature can no longer be displayed even after an associated attempt to charge has failed.
  • the user can also be shown why his request led to a rejection.
  • he has requested a feature that requires a bandwidth of 200 kbit / s, and the rejection includes the information that only 100 kbit / s are currently available.
  • the user interface can also offer him an option to send the load request again, which then includes information about the reduced bandwidth required.
  • FIG. 3 shows a more detailed schematic representation of the functional units in a server according to the invention.
  • Several functional units in the server 20 are connected to a network 50 with terminals 10.
  • the server has the main features of the feature management device 30 and the network resource management device 40.
  • the feature management device 30 has a feature providing device which is externally connected to the feature loading device 12 of a terminal 10 in the network 50. It also includes a feature memory 32, which stores the software or data for features, and a bandwidth requirement memory 33, which, in association with the features, stores the bandwidths required for transmission.
  • the feature providing device has access to these two memories 32 and 33 of the feature management device.
  • the central element of the network resource management device is a network resource allocation device 41, which is connected to terminals 10 of the network 50 and to the feature provision device 31, from which it can receive network resource requests and bandwidth status requests.
  • the network resource allocation device 41 points Processes and load requests bandwidth or denied them.
  • the network resource allocator 41 has access to an available bandwidth store 42, which holds a list of available bandwidths for the connection to the terminals 10, and a maximum bandwidth store 43, which a corresponding list of maximum available bandwidths for the Connection to terminals 10 holds.
  • the performance feature provision device also has direct access to the two bandwidth memories 42 and 43.
  • the network resource allocation device 41 has access to a network resource distribution memory 44, in which data about the allocation of the network resources to associated processes are stored, and a network resource request memory 45, in which data about requests for network resources or such processes are saved, to which no network resources are assigned in spite of need.
  • a network resource test device 46 is connected to terminals 10 of the network 50 in order to test which bandwidths are currently available for the connection to a terminal 10.
  • Network resource tester 46 has access to available bandwidth memory 42 to update the data stored therein and a connection to network resource allocator 41 to receive requests for such an update.
  • FIG. 4 is a block diagram of a network 150 according to the invention.
  • First to fourth terminals according to the invention are a block diagram of a network 150 according to the invention.
  • the feature server 120 is part of a main LAN 160, in which the typical tasks such as a proxy server, a name server, an Internet server, a firewall, etc. are combined in a main LAN server 161.
  • the feature server 160, the main LAN server 161 and a RAS server (Remote Access Service Server) 162 are connected to one another by the main LAN 160 via connections D. All of the described services of the main LAN 160 can of course be physically distributed to any number of computers or, in extreme cases, all run on the same computer.
  • a branch LAN server 171 is connected to the main LAN server 161 via a connection C1 that does not belong to one of the two LANs; otherwise the main and branch LAN 160 and 170 would only be one LAN.
  • the branch LAN server 171 in the branch LAN 171 has the same tasks as the main LAN server 161 in the main LAN 160.
  • a provider server 181 is indirectly connected to the main LAN server 161 via a stage server 151 via the connection paths B1 and B2.
  • connections shown are of course to be understood as examples. In a realistic network, each connection will have far more indications and will include any number of other stage servers and routers.
  • the terminals HOa-llOd illustrate different scenarios on which ways features can be requested and transmitted.
  • the first terminal 110a is connected to the RAS server 162 via a connection A, which can be an ISDN line, for example.
  • a teleworker could work on this terminal via a normal telephone connection.
  • the second terminal 110b is connected to the provider server 181 via a connection B3. This could be a teleworker on a VPN client (Virtual Private Network Client) via a DSL line or a user of a mobile telephone terminal.
  • the third terminal 110c is connected fertilized C2 connected to the branch LAN server 171.
  • the branch LAN 170 can be the LAN of a branch office, another branch office, a foreign agency or the like.
  • the fourth terminal 11Od is integrated directly into the main LAN 160 via a connection D.
  • Other, also wireless, connection types e.g. LAN or Blue Tooth are possible with the usual network connections.
  • step S4 The evaluation of the bandwidth status request (step S4) and the evaluation of the loading request (S6) are described in more detail below.
  • the method steps which have not been taken up again here can also be applied to the more complex network example 150 without further explanation.
  • step S4 the network resource allocator 41 receives a bandwidth status request.
  • This contains the information about which bandwidth is requested and for which end device.
  • the associated route can be identified, for example, via IP addresses, a terminal identification number, domain names or LINs (Location Identification Numbers).
  • the performance feature provision device 31 looks up the bandwidth information on the basis of the requested performance feature in the bandwidth requirement memory.
  • Table 1 the two thickly framed left columns show a corresponding list with an identification number for the feature and the associated required bandwidth.
  • the required bandwidth can also be part of the load request.
  • the network resource allocation device 41 uses the data of the available bandwidth memory 42 to check whether the bandwidth is available.
  • Table 1 an example of a table of such data is shown in the thickly outlined two headers, in which the available bandwidth is indicated for each terminal. If sufficient bandwidth is available, that is to say the required bandwidth is less than or equal to the available, the required bandwidth is assigned to the loading request and is subtracted from the available bandwidth of the corresponding connection in order to update the available bandwidth memory 42. The corresponding allocation of network resources is then the response to the feature provision device (step S5).
  • a rejection of the network resource allocation which may include a message about the available bandwidth, is sent only in response to the bandwidth status request.
  • the network resource allocation device 41 uses an optimization method in order to still be able to provide the requested bandwidth. It is conceivable here that assigned and requested network resources are assigned priorities and, if there are processes of lower priority than the load request, their network resources are reduced or completely withdrawn. Of course, this only makes sense if the sum of the bandwidth made accessible in this way and the already free bandwidth of the charging request are also sufficient, and it requires a consistent priority system that is based on the importance of tasks, but also on users or end devices can.
  • the performance feature provision device 31 can compile a table from the data about the available bandwidth, as is shown as an example in the 4x6 right and lower columns b7w. Rows of Table 1 is shown. This is simpler if the feature provision device 31 can also directly access the available bandwidth memory 42. In it is for each feature and for every possible connection to a terminal, whether the feature is available or temporary or permanently unavailable. Steps S3-S6 then coincide into a single look up in this table. It should also be mentioned that the performance
  • Provisioning device 31 can also refuse to transmit the feature at this point if the bandwidth has been sufficient, for example for security reasons.
  • the memory 42 In order to keep the available bandwidths in the memory 42 up-to-date, the memory 42 must be updated periodically or at the request of the performance feature provision device 31 or the resource allocation device 41.
  • the network resource test device 46 sends a bandwidth request to each terminal HOa-11Od. On the way to the terminal, the bandwidth of the associated partial connection is registered after each hop, and the collected data are sent back to the network resource test device 46 via partial connections.
  • Table 2 shows the result of this test procedure.
  • the terminal device 110b is connected to the feature server 120 via the provider server 181, the stage server 151 and the main LAN 160.
  • the bandwidths available in accordance with the test are entered for the corresponding sub-connections D, B1, B2 and B3.
  • the bandwidths within a LAN are assumed to be sufficient in any case and are accordingly set to infinity.
  • the column on the maximum bandwidth is taken from the maximum bandwidth memory 43, but can be initialized in a completely analogous manner to the available bandwidths. The same applies to the connection type.
  • the available bandwidth for the connection to a terminal can be seen in Table 2 according to the principle of bottle easily determine the neck.
  • this bottleneck is the DSL connection B3 between the terminal 110b and the provider server 181, and the available bandwidth to the terminal 110b is therefore 256 kbit / s according to Table 2.
  • Tables 1 and 2 show a clear and quick example of how the bandwidth test can be carried out.
  • the respective data can also be determined in individual cases and such tables can be dispensed with.
  • a service for locating the server 20 can also be used.
  • the latter can either determine a server 20 or a feature mall service that provides the performance feature, or one that is connected with the highest possible bandwidth.
  • the Feature Mall Service can optionally run decentrally on a terminal endpoint.
  • the feature management device 30 can be physically and logically separated from the network resource management device 40 or form a unit with it.
  • the performance feature management device 30 can be decentralized or central. It is also conceivable that these services are distributed, that is to say that depending on the performance feature, another server is responsible. In this case, the Feature Mall Service is distributed and / or decentralized. It is clear to the person skilled in the art that the server 20 only represents the localization of the required services.
  • the invention does not depend on the type of packet network and in particular for H.323, SIP (Session Initiation Protocol) or proprietary standards.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Verfahren zur Bereitstellung von Leistungsmerkmalen bei Bedarf Verfahren zur Übertragung von Software- und/oder Daten-auf-Anfrage von einem Server (20) auf ein Endgerät (10) in einem Paketnetzwerk (50), bei dem als Voraussetzung für die Übertragung ein Bandbreitentest ausgeführt wird, ob die gegenwärtig verfügbare Bandbreite für das Übertragen der angeforderten Software bzw. Daten ausreicht und ein negatives Testergebnis dieses Bandbreitentests dazu führt, dass der Server (20) die angefragte Software bzw. die angefragten Daten nicht überträgt.

Description

Beschreibung
Verfahren zur Bereitstellung von Leistungsmerkmalen bei Bedarf
Die Erfindung betrifft ein Verfahren zur Übertragung von Software und/oder Daten auf Anfrage von einem Server auf ein Endgerat in einem Paketnetzwerk.
Für Endgerate in einem Netzwerk findet häufig das Prinzip Anwendung, bestimmte Softwarekomponenten erst im Bedarfsfall aus dem Netzwerk nachzuladen. Dieses Prinzip wird als Soft- ware-on-Demand bzw. Software-auf-Anfrage bezeichnet. Damit kann zum einen das Endgerat mit weniger Speicherkapazitäten auskommen, weil der Anteil an Software und Daten im Endgerat reduziert ist, die ohnehin nicht zur Anwendung kommen, zum anderen ermöglicht es eine zentrale Verwaltung der Daten und Software sowie in manchen Fallen auch die Einsparung von Software-Lizenzgebuhren .
Dieses Prinzip ist insbesondere auch für IP-basierte (internet protocol basierte) Tel ekommumkatιonsnet7werke bekannt, in denen Endgerate die Software für gewisse Leistungsmerkmale erst dann nachladen, wenn der Anwender das Leistungsmerkmal braucht, d.h. wenn er es anwendet oder aktiviert (Feature-on- Demand bzw. Leistungsmerkmal-auf-Anforderung) . Dabei sind d e Leistungsmerkmale auf einem zentralen Server gespeichert, der auch "Feature Mall" genannt wird, und ein Leistungsmerkmal wird bei Aktivierung auf das Endgerat übertragen und dort in- stall ert. Der Feature Mall kann auch ein zentraler oder dezentraler Service bzw. Dienst sein.
Befriedigend für den Anwender ist dieses Vorgehen nur dann, wenn er von der Übertragung möglichst wem g merkt, also vor allem keine langen Wartezeiten in Kauf nehmen muss. Das hangt hauptsächlich davon ab, ob die für eine schnelle Übertragung notwendigen Bandbreiten zum Anfragezeitpunkt zur Verfügung stehen .
Innerhalb von lokalen Netzen (LAN) reichen die Bandbreiten im Normalfall aus, um eine Übertragung des Features nahezu in Echtzeit zu ermöglichen. Der Anwender kann in diesem Fall also gar nicht unterscheiden, ob das Leistungsmerkmal on-Demand übertragen wird oder ob es bereits in seinem Endgerät installiert ist.
Bei anderen Netzwerkkonfigurationen, wie etwa bei einem Tele- arbeiter oder einem Netzwerk mit mehreren untereinander nur über Internet verbundenen lokalen Netzwerken sind dagegen oft Engpässe mit geringeren Bandbreiten vorhanden. Hier kann das Prinzip der Übertragung eines Leistungsmerkmals on-Demand leicht zu inakzeptablen Wartezeiten und damit zu großer Unzufriedenheit des Anwenders führen. Das gilt natürlich in erhöhtem Maße für komplexe und damit umfangreiche Leistungsmerkmale .
Bandbreiten werden in einem Paketnetz von einer Netzressourcenverwaltung (Network Ressource Manager) verwaltet. Die Netzressourcenverwaltung wird dabei allerdings nur eingesetzt, um eine Rufannahmekontrolle durchzuführen. Wartezeiten beim Nachladen von Leistungsmerkmalen on-Demand werden dadurch nicht verhindert .
Aufgabe der Erfindung ist es, ein Verfahren und eine Vorrichtung anzugeben, mit dem eine Übertragung von Software und Da- ten on-Demand unter Praxisbedingungen in befriedigender Weise möglich sind.
Die Aufgabe wird mit einem Verfahren nach Anspruch 1 und einem Server nach Anspruch 14, mit einem Endgerät nach Anspruch 21 sowie in einer Netzwerkanordnung nach Anspruch 23 gelöst. Die Erfindung schließt den wesentlichen Gedanken ein, vor der Übertragung zu prüfen, ob die vorhandenen Ressourcen genügen, um die Verfügbarmachung von Software bzw. Daten schnell zu realisieren. Die Kernfrage dabei ist, ob eine Übertragung auf eine Ladeanforderung hin rasch genug durchgeführt werden kann, was hauptsächlich von der Bandbreite abhängt. Reicht also die gegenwärtig verfügbare Bandbreite nicht aus, so wird die Ladeanforderung abgewiesen.
Das erfindungsgemäße Verfahren und der Server stellen durch den Bandbreitentest sicher, dass zum Zeitpunkt der Übertragung genügend Bandbreite für eine Übertragung innerhalb eines (in Anbetracht der Benutzergewohnheiten vorgebbaren) Zeitlimits zur Verfügung steht. Über die Bandbreite kann für den Anwender eine zufriedenstellende Ladezeit garantiert werden, und es wird zuverlässig verhindert, dass Software bzw. Daten mit unzumutbaren Wartezeiten übertragen werden.
Darüber hinaus macht das erfindungsgemäße Endgerät für den Anwender transparent, welche Leistungsmerkmale ihm tatsächlich in akzeptabler Zeit und nicht nur nominell zur Verfügung stehen. Auch bei geringer verfügbarer Bandbreite ist der Anwender nicht verleitet, ein Leistungsmerkmal mehrmals anzuwählen, das zwar in seiner Auswahlliste steht, zumindest der- zeit aber gar nicht übertragen werden kann.
Das Verfahren ist bevorzugt in IP-basierten Telekommunikationsnetzen einzusetzen. Gerade Endgeräte mit geringeren eigenen Ressourcen, die in der Telekommunikation häufig Verwen- düng finden, profitieren von einer Übertragung on-Demand, und zugleich sind hierbei die akzeptablen Wartezeiten gering.
In der aus derzeitiger Sicht wichtigsten Anwendung ist die zu übertragende Software ein Leistungsmerkmal, das von dem End- gerät bei Bedarf angefordert wird. Hierbei sichert das erfindungsgemäße Verfahren, dass die Verwendung solcher ausgela- gerter Leistungsmerkmale nicht durch lange Ladezeiten erschwert wird.
Vorteilhafterweise wird die benötigte Bandbreite anhand einer Obergrenze für die Ladezeit berechnet. Damit wird als Kriterium mit der Ladezeit der Parameter herangezogen, der für den Anwender von größtem Interesse ist. Es werden dabei nicht mehr Bandbreite und damit letztlich teure Netzressourcen genutzt als notwendig.
Bevorzugt ist die Information über die benötigte Bandbreite Teil der Anfrage und wird somit vom Endgerät zur Verfügung gestellt. Das erlaubt eine vom Endgerät abhängige individuelle und auch konfigurierbare Anforderung an die verfügbare Bandbreite. Alternativ oder ergänzend sind die Informationen über die benötigte Bandbreite den angeforderten Daten bzw. der angeforderten Software zugehörig und werden somit vom Server zur Verfügung gestellt. Der Server hat Zugriff auf die jeweils angeforderte Software oder die angeforderten Daten, mit denen zugleich ein Bandbreitenbedarf gespeichert sein kann oder aus denen sich der Bandbreitenbedarf leicht ermitteln lässt.
In einer weiteren bevorzugten Ausführungsform wird die Infor- mation über die vorhandene Bandbreite von einer Netzressourcenverwaltung zur Verfügung gestellt, wobei diese Information insbesondere regelmäßig oder auf Anfrage des Servers aktualisiert wird. Es stehen somit immer aktuelle Bandbreitendaten zur Verfügung, und es kann eine für andere Aufgaben bereits existierende Netzressourcenverwaltung genutzt werden.
Bevorzugt verwaltet die Netzressourcenverwaltung Prioritäten für alle Netzressourcenanforderungen und führt bei einem negativen Testergebnis des Bandbreitentests folgende Schritte aus: - Ermittlung der Bedarfsdifferenz zwischen benötigten und vorhandenen Netzwerkressourcen für die Übertragung,
- Aufsuchen eines oder mehrerer Prozesse mit geringerer Priorität als die Anforderung, deren aufaddierte Netzwerkressour- cen der Bedarfsdifferenz entsprechen oder sie übersteigen und
- falls das Aufsuchen erfolgreich ist, Verteilung von Beschrankungen der Netzwerkressourcen an die aufgesuchten Prozesse bis hin zum vollständigen Einfrieren, so dass die aufaddierten Beschrankungen zumindest der Bedarfsdifferenz ent- sprechen.
Dieses Vorgehen ermöglicht, Netzressourcen verschiedenen Anwendern, Endgeraten oder angeforderte Daten bzw. Software je nach Wichtigkeit zuzuordnen und eine Ladeanforderung, die zu- nächst scheitern wurde, bei entsprechender Wichtigkeit dennoch mit der geforderten Bandbreite zu bedienen.
In einer weiteren bevorzugten Ausfuhrungsform wird bei einem negativen Testergebnis des Bandbreitentests eine Meldung an das Endgerat gesendet, wobei die Meldung eine der beiden folgenden Ablehnungen umfassen kann:
- eine temporare Ablehnung der Anforderung, wobei nachfolgende gleichartige Anforderungen erzeugt und erfolgreich beant- wortet werden können,
- eine permanente Ablehnung der Anforderung, wobei nachfolgende gleichartige Anforderungen nicht erzeugt werden können oder ohne weitere Verarbeitungsschritte sofort mit einer weiteren permanenten Ablehnung beantwortet werden.
Wenn also wegen zu geringer verfugbarer Bandbreite keine Übertragung der angeforderten Daten bzw. Software stattfindet, erhalt das Endgerät die Information, ob eine weitere gleichartige Ladeanforderung unmittelbar oder zu einem spate- ren Zeitpunkt erfolgreich sein könnte. Vorteilhafterweise wird nach einer temporaren Ablehnung automatisch eine erneute Ladeanforderung erzeugt. War die geforderte Bandbreite nur vorübergehend nicht vorhanden, so kann sie somit zu einem späteren Zeitpunkt bedient werden.
Andererseits können nachfolgende Ladeanforderungen, die ohne- hin nicht bedient werden, von vorneherein unterdrückt werden. Bevorzugt kann eine permanente Ablehnung durch einen der folgenden Schritte erzeugt werden:
- einfach oder mehrfach wiederholte temporäre Ablehnung - Vergleich der benötigten mit der maximal verfügbaren Bandbreite .
In beiden Fällen ist es wahrscheinlich oder sicher, dass auch weitere Ladeanforderungen nicht bedient werden, und diese In- formation steht dem Endgerät auf die beschriebene Weise zur Verfügung .
Bevorzugt wird dem Anwender des Endgerätes die Meldung angezeigt, insbesondere indem die Option zur Anforderung, die zu der Meldung geführt hat, mit einem Warnhinweis markiert oder gänzlich unzugänglich gemacht wird.
Mit dem erfindungsgemäßen Server ist vorteilhafterweise zusätzlich ein Bandbreitenbedarfsspeicher zur Speicherung der benötigten Bandbreite für ein Leistungsmerkmal mit der Leistungsmerkmal-Bereitstellungseinrichtung verbunden, damit die Leistungsmerkmal-Bereitstellungseinrichtung für die Durchführung des Bandbreitentests ermitteln kann, welche Bandbreite eine Übertragung der Daten und/oder Software gemäß einer La- deanforderung für ein Leistungsmerkmal benotigt. Dieser Bandbreitenbedarfsspeicher ermöglicht ein rasches Nachschlagen der benötigten Bandbreite.
Bevorzugt hat die Lei stungsmerkmal -Bereitste! 1 ungseinrichtung Zugriff auf einen Maximale-Bandbreiten-Speicher zur Speicherung der maximal verfügbaren Bandbreiten für Verbindungen zu Endgeräten, um einen zusätzlichen oder alternativen Bandbrei- tentest anhand der maximal verfügbaren Bandbreiten durchzuführen. Die maximalen Bandbreiten können also leicht nachgeschlagen werden.
In einer bevorzugten Ausführungsform ist eine Netzressourcen- Zuteilungseinrichtung vorgesehen, die mit der Leistungsmerkmal-Bereitstellungseinrichtung verbunden ist und Zugriff auf den Verfügbare-Bandbreiten-Speicher hat, wobei die Netzressourcen-Zuteilungseinrichtung der Ladeanforderung Netzres- sourcen zuweisen oder verweigern kann und dementsprechend den Verfügbare-Bandbreiten-Speicher aktualisiert. Eine solche Netzressourcen-Zuteilungseinrichtung ist üblicherweise Teil eines Servers und kann auf einfache Weise für eine die Bandbreiten betreffende Kommunikation mit der Leistungsmerkmal- Bereitstellungseinrichtung verwendet werden.
Vorteilhafterweise ist die Netzressourcen-Zuteilungseinrichtung mit einer Netzressourcen-Testeinrichtung verbunden, welche Zugriff auf den Verfügbare-Bandbreiten-Speicher sowie zu- mindest eine Verbindung zu einem Endgerät hat, um aktuelle
Bandbreitendaten zu ermitteln und zu speichern. Über die Verbindung zu dem Endgerät kann die Netzressourcen-Testeinrichtung die aktuell verfügbaren Bandbreiten ermitteln und abspeichern, damit im Verfügbare-Bandbreiten-Speicher aktuelle Daten gespeichert sind.
Weiter vorteilhafterweise hat die Netzressourcen-Zuteilungseinrichtung Zugriff auf einen Netzressourcen-Verteilungsspeicher, der Daten über Prozessen zugeordnete Bandbreiten sowie Prioritäten dieser Prozesse speichert, wobei die Netzressourcen-Zuteilungseinrichtung abhängig von den Prioritäten der Prozesse und der Ladeanforderung Netzressourcen umverteilen kann, um der Ladeanforderung genügend Bandbreite verfügbar zu machen. Ein solcher Netzressourcen-Verteilungsspeicher ist Voraussetzung für eine intelligente Verwaltung der vorhandenen Netzressourcen. Weiter bevorzugt hat die Netzressourcen-Zuteilungseinrichtung Zugriff auf einen Netzressourcen-Anfragen-Speicher, der Daten über angeforderte Bandbreiten speichert, um Prozesse zu verwalten, denen gegenwartig keine Bandbreite zugeordnet ist. Ein Speicher für noch nicht bearbeitete oder eingefrorene
Prozesse ermöglicht mehr Flexibilität bei einer intelligenten Verwaltung der vorhandenen Netzressourcen.
In dem erfindungsgemaßen Endgerat ist bei der Aktualisierung der Darstellung ein Leistungsmerkmal nach einer temporären
Ablehnung durch den Server hervorgehoben und nach einer permanenten Ablehnung nicht dargestellt. Damit erhalt der Anwender eine leicht aufzunehmende Ruckmeldung über derzeit nicht verfugbare Leistungsmerkmale bzw. kann solche Leistungsmerk- male, die ohnehin wegen mangelnder Bandbreite in der bestehenden Netzkonfiguration und Netzauslastung gar nicht erst anwählen.
Die Erfindung wird nachstehend, auch hinsichtlich weiterer Merkmale und Vorteile, anhand von Ausführungsbeispielen und unter Bezugnahme auf die beigefugten Tabellen und Zeichnungen beschri eben .
Die Tabellen stellen folgendes dar:
Tabelle 1 ein Beispiel für eine Netzressourcen-Verwaltungstabelle, die in einem erfindungsgemaßen Server abgelegt st und Tabelle 2 ein Beispiel für eine Verfugbarkeitstabelle von Leistungsmerkmalen, die in einem erfindungsgemaßen Server ab- gelegt st.
Die Zeichnungen zeigen in:
Fig. 1 eine stark vereinfachte schematische Darstellung eines minimalen Netzwerken mit einem erfindungsgemaßem Endgerat und einem erfindungsgemaßem Server, Fig. 2 ein Beispiel für den Datenaustausch zwischen einem Endgerät und einem Server nach dem erfindungsgemäßen Verfahren,
Fig. 3 eine detailliertere schematische Darstellung der Funktionseinheiten in einem erfindungsgemäßen Server und
Fig. 4 eine Blockdarstellung einer erfindungsgemäßen Netzwerkanordnung .
Fig. 1 zeigt ein stark vereinfacht dargestelltes Netzwerk mit einem erfindungsgemäßen Endgerät 10 und einem er indungsgemäßen Server 20. Das Netzwerk ist ein Paketnetzwerk und kann ein IP-basiertes Telekommunikationsnetzwerk sein, wobei dann auch das Endgerät 10 ein Telekommunikations-Endgerät sein kann .
Das Endgerät 10 bietet dem Anwender über eine Benutzerschnittstelle 11 Zugriff auf verschiedene Software bzw. Daten an, die der Anwender auswählen kann und die dann, wenn sie lokal nicht verfügbar sind, von dem Server 20 on-Demand geladen werden .
Häufig handelt es sich bei der Software um ein Leistungsmerk- mal, das von einer mit der Benutzerschnittstelle verbundenen Leistungsmerkmal-Ladeeinrichtung 12 on-Demand vom Server 20 bzw. einem auf diesem Server ablaufenden Dienst angefordert wird. Deshalb wird im folgenden nur noch der Begriff Leistungsmerkmal verwendet, wobei aber auch allgemeine Software bzw. Daten eingeschlossen sind, welche in prinzipiell gleicher Weise von dem erfindungsgemäßen Verfahren und den Vorrichtungen verarbeitet werden.
Als weitere Vorbemerkung sei angemerkt, dass im folgenden i - mer die Bandbreite als Kriterium für eine hinreichende Leistungsfähigkeit herangezogen wird. Für den Anwender rechnet sich Bandbreite unmittelbar in Wartezeit um, d.h. sie ist der angemessene Parameter, obwohl ausreichende Bandbreite unmittelbar für den Anwender keine Rolle spielt. Damit kann auch im Bedarfsfall das Erfordernis einer Echtzeitanwendung eingeschlossen werden, denn Echtzeit bedeutet letztlich nichts an- deres, als dass die Wartezeiten sehr klein sind und je nach Bedarf der anfordernden Applikation vernachlässigt werden können bzw. in dem Bereich liegen, der auch für die Aktivierung lokaler Funktionen benötigt wird.
Eine dem angewählten Leistungsmerkmal entsprechende Ladeanforderung wird von der Leistungsmerkmal-Ladeeinrichtung 12 an eine mit ihr verbundene Leistungsmerkmal- Verwaltungseinrichtung 30 im Server 20 gesendet und dort bearbeitet. Die Leistungsmerkmal-Verwaltungseinrichtung 30 ist mit einer Netzressourcen-Verwaltungseinrichtung 40 verbunden, die unter anderem Informationen über Netzressourcen bereitstellt. Eine genauere Funktionsbeschreibung der aufgeführten Einrichtungen wird unten im Zusammenhang mit den Figuren 3 und 4 erfolgen.
Fig. 2 zeigt beispielhaft den Daten- und Nachrichtenaustausch zwischen dem Endgerät 10 und dem Server 20 nach dem erfindungsgemäßen Verfahren. Ein Anwender wählt in der Benutzerschnittstelle 11 ein Leistungsmerkmal aus, und die Benutzer- Schnittstelle 12 gibt eine entsprechende Anfrage an die Leistungsmerkmal-Ladeeinrichtung 12 weiter (Schritt Sl) . Die Leistungsmerkmal-Ladeeinrichtung gibt diese Ladeanfrage im Normalfall an die Leistungsmerkmal-Verwaltungseinrichtung 30 im Server 20 weiter (Schritt S2) . Es kann aber auch zuvor ge- testet werden, ob eine gleichartige Ladeanforderung bereits gestellt worden ist oder ob beispielsweise aufgrund von Netzproblemen eine Weiterleitung der Anfrage nicht vorgenommen werden sollte oder kann.
Die Leistungsmerkmal-Verwaltungseinrichtung 20 erzeugt nach dem Empfang der Ladeanforderung eine Bandbreiten- Statusanfrage an die Netzressourcen-Verwaltungseinrichtung 40 (Schritt S3) . Diese Bandbreiten-Statusanfrage wird von der Netzressourcen-Verwaltungseinrichtung 40 in einer im Zusammenhang mit Fig. 4 naher ausgeführten Weise bearbeitet (Schritt S4) und der Bandbreitenstatus an die Leistungsmerk- mal-Verwaltungseinrichtung 30 zurückgegeben (Schritt S5) .
Die Leistungsmerkmal-Verwaltungseinrichtung 30 wertet die Ladeanforderung aus (Schritt S6) . Zunächst wird getestet, ob die verfugbare Bandbreite für eine Übertragung des angefor- derten Leistungsmerkmals ausreicht. (Auch dieser Bandbreiten- test wird unten im Zusammenhang mit Fig. 4 naher erläutert.) Es wird darauf hingewiesen, dass der Bandbreitentest auch ohne eine Netzressourcen-Verwaltungseinrichtung 40 und die zugehörigen Verfahrensschritte S3 bis 35 durchgeführt werden kann. Dann beschrankt sich der Test auf Informationen, die von den dynamischen Eigenschaften der Netzverbindungen unabhängig sind. Beispiele hierfür konnten sein, prinzipiell keine Leistungsmerkmale über einen Engpass, etwa eine Internetverbindung, oder nach außerhalb des eigenen lokalen Netzes (LAN) zu übertragen, oder sich bereits serverseitig ein (möglicherweise zeitabhängiges) Limit zu setzen, also prinzipiell keine ei stungsme kmale zu übertragen, die eine Höchstgrenze an benötigter Bandbreite überschreiten.
Falls der Bandbreitentest ein positives Testergebnis liefert, wird das angeforderte Leistungsmerkmal, anderenfalls eine Nachricht über die Ablehnung an d e Leistungsmerkmal-Ladeein- πchtung 12 übertragen (Schritt S7) . Die Leistungsmerkmal- Ladeeinrichtung 12 kann das Leistungsmerkmal bzw. die Nach- rieht einfach an die Benutzerschnittstelle weitergeben
(Schritt S8) und damit den Verfahrenszyklus beenden. Alternativ oder ergänzend kann sie aber auch eigene Verarbeitungsschritte durchfuhren. Dazu gehört ein Caching, ein vorübergehendes Ablegen des Leα stungsmerkmals, um es einer weiteren verbundenen Benutzerschnittstelle verfugbar machen zu könne, oder ein lokales Speichern des Leistungsmerkmal für spatere Anfragen auf einem dauerhaften Speichermedium. Auch kann bei einer Ablehnung die Leistungsmerkmal-Ladeeinrichtung 12 selbsttätig die Ablehnung auswerten und gegebenenfalls eine erneute Ladeanforderung erzeugen und an den Server senden. Dazu ist es vorteilhaft, wenn die Ablehnung zumindest in zwei Klassen eingeteilt ist, nämlich temporäre und permanente Ablehnungen. Eine temporäre Ablehnung könnte beinhalten, dass zwar derzeit nicht genug Bandbreite verfügbar ist, bei einer geringeren Auslastung durch andere Prozesse prinzipiell aber eine Übertragung mit der gewünschten Bandbreite möglich wäre. Eine permanente Ablehnung dagegen zeigt an, dass auch weitere Ladeanforderungen nicht zu einer Übertragung des gewünschten Leistungsmerkmals führen werden. Dabei kann eine einfach oder mehrfach wiederholte temporäre Ablehnung zu einer permanenten Ablehnung führen. Diese Entscheidung kann sowohl Server- wie auch endgerätseitig getroffen werden. Ein weiterer möglicher Grund für eine permanente Ablehnung ist, wenn schon die maximale Bandbreite geringer ist als die geforderte.
Die Benutzerschnittstelle 11 installiert das übertragene Leistungsmerkmal, das von diesem Zeitpunkt an für den Anwender nutzbar ist. Wenn die Ladeanforderung des Benutzers nicht zu einer Übertragung des gewählten Leistungsmerkmals geführt hat, zeigt die Benutzerschnittstelle dies dem Benutzer an. Das kann eine einfache Meldung sein; übersichtlicher ist es aber, wenn unmittelbar in der Auswahl möglicher Leistungsmerkmale das Ergebnis der gegenwärtigen sowie früherer Ladeanforderungen ersichtlich ist. Jedes Leistungsmerkmal kann z.B. auf einer Bedientafel des entsprechenden Endgerätes mit einer (Färb) Kodierung oder einem Zusatz versehen sein, das seinen Status anzeigt: lokales Leistungsmerkmal, bereits nachgeladen, (einfach oder x-fach) gescheiterter Ladeversuch. Insbesondere kann ein Leistungsmerkmal auch gar nicht mehr dargestellt werden, nachdem ein zugehöriger Ladeversuch gescheitert ist.
Darüber hinaus kann dem Anwender auch dargestellt werden, warum seine Anforderung zu einer Ablehnung geführt hat. Bei- spielsweise hat er ein Leistungsmerkmal angefordert, dass eine Bandbreite von 200 kbit/s erfordert, und die Ablehnung um- fasst die Information, dass derzeit nur 100 kbit/s verfügbar sind. Dann sieht der Benutzer zum einen, wie groß der Netz- ressourcenmangel ist, zum anderen kann ihm die Benutzerschnittstelle auch eine Option anbieten, die Ladeanforderung erneut abzusenden, die dann eine Information über die reduzierte benötigte Bandbreite umfasst.
Fig. 3 zeigt eine detailliertere schematische Darstellung der Funktionseinheiten in einem erfindungsgemäßen Server. Mehrere Funktionseinheiten in dem Server 20 sind mit einem Netz 50 mit Endgeräten 10 verbunden. Der Server weist wie in der stark vereinfachten Abstraktionsebene der Fig. 1 als Haupt- komponenten die Leistungsmerkmal-Verwaltungseinrichtung 30 und die Netzressourcen-Verwaltungseinrichtung 40 auf.
Die Leistungsmerkmal-Verwaltungseinrichtung 30 weist eine Leistungsmerkmal-Bereitstellungseinrichtung auf, die nach au- ßen mit der Leistungsmerkmal-Ladeeinrichtung 12 eines Endgerätes 10 im Netzwerk 50 verbunden ist. Zudem umfasst sie einen Leistungsmerkmalspeicher 32, der die Software bzw. Daten für Leistungsmerkmale speichert, und einen Bandbreitenbedarfsspeicher 33, der zugehörig zu den Leistungsmerkmalen die erforderlichen Bandbreiten für eine Übertragung speichert. Die Leistungsmerkmal-Bereitstellungseinrichtung hat Zugriff auf diese beiden Speicher 32 und 33 der Leistungsmerkmal- Verwaltungseinrichtung .
Das zentrale Element der Netzressourcen- Verwaltungseinrichtung ist eine Netzressourcen- Zuteilungseinrichtung 41, die mit Endgeräten 10 des Netzwerkes 50 sowie mit der Leistungsmerkmal- Bereitstellungseinrichtung 31 verbunden ist, von der sie Netzressourcenanfragen und Bandbreiten-Statusabfragen empfangen kann. Die Netzressourcen-Zuteilungseinrichtung 41 weist Prozessen und Ladeanforderungen Bandbreiten zu oder verweigert sie.
Die Netzressourcen-Zuteilungseinrichtung 41 hat Zugriff auf einen Verfügbare-Bandbreiten-Speicher 42, der eine Liste von verfügbaren Bandbreiten für die Verbindung zu den Endgeräten 10 hält, und einen Maximale-Bandbreiten-Speicher 43, der eine entsprechende Liste von maximal verfügbaren Bandbreiten für die Verbindung zu Endgeräten 10 hält. Auf die beiden Band- breitenspeicher 42 und 43 hat auch die Leistungsmerkmal- Bereitstellungseinrichtung unmittelbaren Zugriff. Weiterhin hat die Netzressourcen-Zuteilungseinrichtung 41 Zugriff auf einen Netzressourcen-Verteilungsspeicher 44, in dem Daten ü- ber die Zuweisungen der Netzressourcen an zugehörige Prozesse gespeichert sind, sowie einen Netzressourcen-Anfragen- Speicher 45, in dem Daten über Anfragen nach Netzressourcen oder solche Prozesse gespeichert sind, denen trotz Bedarf keine Netzressourcen zugeordnet sind.
Eine Netzressourcen-Testeinrichtung 46 ist mit Endgeräten 10 des Netzwerkes 50 verbunden, um zu testen, welche Bandbreiten für die Verbindung zu einem Endgerät 10 gegenwärtig zur Verfügung steht. Die Netzressourcen-Testeinrichtung 46 hat Zugriff auf den Verfügbare-Bandbreiten-Speicher 42, um die dort gespeicherten Daten zu aktualisieren, sowie eine Verbindung zu der Netzressourcen-Zuteilungseinrichtung 41, um Anforderungen für eine solche Aktualisierung zu empfangen.
Fig. 4 ist eine Blockdarstellung eines erfindungsgemäßen Netzwerk 150. Erste bis vierte erfindungsgemäße Endgeräte
110a, 110b, 110c und llOd sind über verschiedenartige Verbindungsarten mit einem erfindungsgemäßen Leistungsmerkmal- Server 120 verbunden. Dabei ist der Leistungsmerkmal-Server 120 Teil eines Haupt-LANs 160, in dem die typischen Aufgaben wie die eines Proxyservers, eines Nameservers, eines Internetservers, eines Firewalls etc. in einem Haupt-LAN-Server 161 zusammengefasst sind. Der Leistungsmerkmal-Server 160, der Haupt-LAN-Server 161 und ein RAS-Server (Remote Access Service Server) 162 sind untereinander durch das Haupt-LAN 160 über Verbindungen D verbunden. Sämtliche beschriebene Dienste des Haupt-LANs 160 können dabei selbstverständlich physikalisch auf eine beliebige Zahl von Rechnern verteilt sein oder im Extremfall auch alle auf demselben Rechner ablaufen .
In einem Zweig-LAN 170 ist ein Zweig-LAN-Server 171 mit dem Haupt-LAN-Server 161 über eine Verbindung Cl verbunden, die nicht zu einem der beiden LANs gehört; ansonsten wären auch Haupt- und Zweig-LAN 160 und 170 nur ein LAN. Dabei hat der Zweig-LAN-Server 171 im Zweig-LAN 171 die analogen Aufgaben wie der Haupt-LAN-Server 161 im Haupt-LAN 160.
In einem Providernetzwerk 180 ist ein Provider-Server 181 mittelbar über einen Etappenserver 151 über die Verbindungswege Bl und B2 mit dem Haupt-LAN-Server 161 verbunden.
Die dargestellten Verbindungen sind natürlich als Beispiel aufzufassen. In einem realistischen Netz wird jede Verbindung weitaus mehr Indirektionen aufweisen und eine beliebige Zahl weiterer Etappenserver und Router umfassen.
Die Endgeräte HOa-llOd illustrieren verschiedene Szenarien, auf welchen Wegen Leistungsmerkmale angefordert und übertragen werden können.
Das erste Endgerät 110a ist über eine Verbindung A, die bei- spielsweise eine ISDN-Leitung sein kann, mit dem RAS-Server 162 verbunden. An diesem Endgerät könnte beispielsweise ein Teleworker über einen gewöhnlichen Telefonanschluss arbeiten. Das zweite Endgerät 110b ist über eine Verbindung B3 mit dem Provider-Server 181 verbunden. Dies könnte ein Teleworker an einem VPN-Client (Virtual Private Network Client) über eine DSL-Leitung sein oder auch ein Anwender eines mobilen Telefonendgerätes. Das dritte Endgerät 110c ist über eine Verbin- düng C2 mit dem Zweig-LAN-Server 171 verbunden. Das Zweig-LAN 170 kann das LAN einer Zweigstelle, einer weiteren Niederlassung, einer Auslandsvertretung o.a. sein. Schließlich ist das vierte Endgerät llOd direkt in das Haupt-LAN 160 über eine Verbindung D integriert. Weitere, auch drahtlose, Verbindungsarten (z.B. LAN oder Blue Tooth) sind mit den üblichen Netzwerkverbindungen möglich.
Nachfolgend werden die Auswertung der Bandbreiten- Statusanfrage (Schritt S4) und die Auswertung der Ladeanforderung (S6) genauer beschrieben. Die hier nicht erneut aufgegriffenen Verfahrensschritte sind ohne weitere Erläuterungen auch auf das komplexere Netzwerkbeispiel 150 zu übertragen.
Im Schritt S4 empfängt die Netzressourcen-Zuteilungseinrichtung 41 eine Bandbreiten-Statusanfrage. Darin ist die Information enthalten, welche Bandbreite angefordert wird, und für welches Endgerät. Die zugehörige Route kann dabei beispielsweise über IP-Adressen, eine Endgeräte-Identifikationsnummer, Domainnamen oder LINs (Location Identification Numbers) identifiziert werden.
Die Bandbreiteninformationen schlägt die Leistungsmerkmal- Bereitstellungseinrichtung 31 anhand des angeforderten Leis- tungsmerkmals im Bandbreitenbedarfsspeicher nach. In Tabelle 1 zeigen die beiden dick umrandeten linken Spalten eine entsprechende Liste mit einer Identifizierungsnummer für das Leistungsmerkmal und der zugehörigen erforderlichen Bandbreite. Alternativ kann die erforderliche Bandbreite auch Teil der Ladeanforderung sein.
Im einfachsten Fall überprüft dann die Netzressourcen-Zuteilungseinrichtung 41 anhand der Daten des Verfügbare-Bandbrei- ten-Speichers 42, ob die Bandbreite verfügbar ist. Tn Tabelle 1 ist ein Beispiel für eine Tabelle solcher Daten in den dick umrandeten beiden Kopfzeilen dargestellt, in denen für jedes Endgerät die verfügbare Bandbreite angegeben ist. Ist genug Bandbreite verfugbar, also die erforderliche Bandbreite kleiner oder gleich der verfugbaren, so wird die erforderliche Bandbreite der Ladeanfrage zugewiesen und zur Aktualisierung des Verfugbare-Bandbreiten-Speichers 42 von der verfugbaren Bandbreite der entsprechenden Verbindung abgezogen. Die entsprechende Zuweisung der Netzressourcen ist dann die Antwort an die Leistungsmerkmal-Bereistellungsemrichtung (Schritt S5) .
Ist nicht genug Bandbreite vorhanden, so wird im einfachsten Fall lediglich als Antwort auf die Bandbreiten-Statusanfrage eine Zurückweisung der Netzressourcenzuteilung gesendet, die eine Nachricht über die verfugbare Bandbreite beinhalten kann.
Es ist aber auch denkbar, dass die Netzressourcen-Zuteilungs- einπchtung 41 ein Optimierungsverfahren verwendet, um dennoch die angeforderte Bandbreite bereitstellen zu können. Denkbar ist hier, dass vergebenen und angeforderten Netzressourcen Prioritäten zugeordnet sind und, falls es Prozesse von geringerer Priorität als die Ladeanforderung gibt, deren Netzressourcen verringert oder gänzlich entzogen werden. Das ist natürlich nur sinnvoll, wenn die Summe an in dieser Weise zuganglich gemachter Bandbreite und die ohnehin freie Bandbreite der Ladeanforderung auch ausreicht, und es setzt ein durchgangiges Prioritatensystem voraus, das sich an der Wichtigkeit von Aufgaben, aber auch Anwendern oder Endgeraten o- rientieren kann.
Die Leistungsmerkmal-Bereitstellungseinrichtung 31 kann aus den Daten über die verfugbare Bandbreite eine Tabelle zusammensetzen, wie sie als Beispiel in den 4x6 rechten und unteren Spalten b7w. Zeilen der Tabelle 1 gezeigt ist. Einfacher ist das, wenn die Leistungsmerkmal-Bereitstellungseinrichtung 31 auch unmittelbar auf den Verfugbare-Bandbreiten-Speicher 42 zugreifen kann. Darin ist für jedes Leistungsmerkmal und für jede mögliche Verbindung zu einem Endgerat eingetragen, ob das Leistungsmerkmal verfugbar oder temporar bzw. permanent nicht verf gbar ist. Die Schritte S3-S6 fallen dann zu einem einzigen Nachschlagen in dieser Tabelle zusammen. Es sei noch angefugt, dass die Leistungsmerkmal-
Bereitstellungseinr chtung 31 die Übertragung des Leistungsmerkmals an dieser Stelle auch verweigern kann, wenn die Bandbreite ausreichen wurde, zum Beispie aus Sicherheitsgründen .
Um die verfugbaren Bandbreiten im Speicher 42 aktuell zu halten, muss der Speicher 42 periodisch oder auf Anfrage der Leistungsmerkmal-Bereitstellungseinrichtung 31 oder der Res- sourcen-Zuteilungseinrichtung 41 aktualisiert werden.
Dazu schickt die Netzressourcen-Testeinrichtung 46 an jedes Endgerat HOa-llOd eine Bandbreitenanfrage. Auf dem Weg zu dem Endgerat wird nach jedem Hop die Bandbreite der zugehörigen Teilverbindung registriert, und die gesammelten Daten werden über Teilverbindungen an die Netzressourcen- Testeinrichtung 46 zurückgeschickt.
In Tabelle 2 ist das Ergebnis dieses Testverfahrens dargestellt. Beispielsweise ist das Endgerat 110b über den Provi- der-Server 181, den Etappenserver 151 und das Haupt-LAN 160 mit dem Leistungsmerkmal-Server 120 verbunden. Für die entsprechenden Teilverbindungen D, Bl, B2 und B3 sind d e gemäß dem Test verfugbaren Bandbreiten eingetragen. Dabei werden die Bandbreiten innerhalb eines LAN als in jedem Fall ausrei- chend angenommen und entsprechend auf unendlich gesetzt. Die Spalte über die maximale Bandbreite ist dem Maximale- Bandbreiten-Speicher 43 entnommen, kann aber auf völlig analoge Weise initialisiert werden wie die verfugbaren Bandbreiten. Das gleiche gilt für die Verbindungsart.
Die verfugbare Bandbreite für die Verbindung zu einem Endgerat lasst sich aus Tabelle 2 nach dem Prinzip des Flaschen- halses leicht ermitteln. Für die Verbindung zu dem Endgerät 110b ist dieser Flaschenhals die DSL-Verbindung B3 zwischen dem Endgerät 110b und dem Provider-Server 181, und die verfügbare Bandbreite zum Endgerät 110b beträgt also gemäß Ta- belle 2 256 kbit/s.
Die Tabellen 1 und 2 zeigen ein übersichtliches und schnelles Beispiel, wie der Bandbreitentest vorgenommen werden kann. Selbstverständlich können die jeweiligen Daten auch im Ein- zelfall ermittelt und auf derartige Tabellen verzichtet werden .
Als Weiterentwicklung der Erfindung kann zusätzlich ein Dienst zum Aufsuchen des Servers 20 (Feature Location Servi- ce) anhand des ausgewählten Leistungsmerkmals Verwendung finden. Dieser kann entweder überhaupt einen Server 20 bzw. einen Feature Mall Service ermitteln, der das Leistungsmerkmal bereitstellt, oder einen solchen, der mit möglichst hoher Bandbreite verbunden ist.
Der Feature Mall Service kann optional auch dezentral auf einem Term nalendpoint ablaufen.
Weiterhin kann die Leistungsmerkmal-Verwaltungseinrichtung 30 von der Netzressourcen-Verwaltungseinrichtung 40 physikalisch und logisch getrennt sein oder mit dieser eine Einheit bilden. Ebenso kann die Leistungsmerkmal-Verwaltungseinrichtung 30 dezentral oder zentral sein. Es ist auch denkbar, dass diese Dienste verteilt sind, dass also etwa je nach Leis- tungsmerkmal ein anderer Server zustandig ist. In diesem Fall ist der Feature Mall Service verteilt und/oder dezentral. Für den Fachmann ist klar, dass der Server 20 nur stellvertretend für die Lokalisierung der benötigten Dienste steht.
Schließlich wird noch darauf hingewiesen, dass die Erfindung nicht von der Art des Paketnetzes abhangt und insbesondere für H.323, SIP (Session Initiation Protocol) oder proprietäre Standards einsetzbar ist.
Obwohl die Erfindung anhand von Ausführungsbeispielen be- schrieben ist, umfasst sie auch weitere denkbare Kombinationen der beschriebenen Merkmale, wie sie insbesondere, aber nicht abschließend in den Unteransprüchen angegeben sind.
α CD

Claims

Patentansprüche
1. Verfahren zur Übertragung von So tware- und/oder Datenauf-Anfrage von einem Server (20) auf ein Endgerät (10) in einem Paketnetz (50) , d a d u r c h g e k e n n z e i c h n e t, d a s s als Voraussetzung für die Übertragung ein Bandbreitentest ausgeführt wird, ob die gegenwartig verfugbare Bandbreite für das Übertragen der angeforderten Software bzw. Daten aus- reicht, und im Ansprechen auf ein negatives Testergebnis dieses Bandbreitentests der Server (20) die angefragte Software bzw. die angefragten Daten nicht übertragt.
2. Verfahren nach Anspruch 1, d a d u r c h g e k e n n z e i c h n e t, d a s s das Paketnetz (50) ein IP-basiertes Teleko munikationsnetz ist .
3. Verfahren nach Anspruch 1 oder 2, d a d u r c h g e k e n n z e i c h n e t, d a s s die Software ein Leistungsmerkmal ist, das von dem Endgerat (10) bei Bedarf angefordert wird.
4. Verfahren nach einem der Ansprüche 1 bis 3, d a d u r c h g e k e n n z e i c h n e t, d a s s eine benötigte Bandbreite anhand einer vorgegebenen Obergrenze für die Ladezeit der Software bzw. Daten berechnet wird.
5. Verfahren nach einem der Ansprüche 1 b s 4, d a d u r c h g e k e n n z e i c h n e t, d a s s Informationen über die benötigte Bandbreite TeiJ der Anfrage sind und somit vom Endgerat (10) zu Verfugung gestellt werden .
6. Verfahren nach einem der Ansprüche 1 bis 5, d a d u r c h g e k e n n z e i c h n e t, d a s s Informationen über die benotigte Bandbreite den angeforderten Daten bzw. der angeforderten Software zugehoren und somit vom Server (20) zur Verfugung gestellt werden.
7. Verfahren nach einem der Ansprüche 1 bis 6, d a d u r c h g e k e n n z e i c h n e t, d a s s der Bandbreitentest ein positives Testergebnis nur dann liefert, wenn die Bandbreite für eine Echtzeit- oder Quasi- Echtzeit-Anwendung ausreicht.
8. Verfahren nach einem der Ansprüche 1 bis 7, d a d u r c h g e k e n n z e i c h n e t, d a s s die Information über die vorhandene Bandbreite von einer Netzressourcenverwaltung (40) zur Verfugung gestellt wird, wobei diese Information insbesondere periodisch oder auf Anfrage des Servers (20) aktualisiert wird.
9. Verfahren nach Anspruch 8, d a d u r c h g e k e n n z e i c h n e t, d a s s d e Netzressourcenverwaltung (40) Prioritäten für alle Netzressourcenan orderungen verwaltet und bei einem negativen Testergebrus des Bandbreitentests folgende Schritte ausfuhrt:
- Ermittlung der Bedarfsdifferenz zwischen benotigten und vorhandenen Netzwerkressourcen f r die Übertragung, - Aufsuchen eines oder mehrerer Prozesse mit geringerer Priorität als d e Anforderung, deren aufaddierte Netzwerkressourcen der Bedarfsdifferenz entsprechen oder sie übersteigen und
- falls das Aufsuchen erfolgreich ist, Verteilung von Beschrankungen der Netzwerkressourcen an die aufgesuchten Pro- zesse bis hin zum vollständigen Einfrieren, so dass die aufaddierten Beschrankungen zumindest der Bedarfsdifferenz entsprechen.
30. Verfahren nach einem der Ansprüche ] bis 9, d a d u r c h g e k e n n z e i c h n e t, d a s s bei einem negativen Testergebnis des Bandbreitentests eine Meldung an das Endgerät (10) gesendet wird, wobei die Meldung eine der beiden folgenden Ablehnungen umfassen kann:
- eine temporäre Ablehnung der Anforderung, wobei nachfolgen- de gleichartige Anforderungen erzeugt und erfolgreich beantwortet werden können,
- eine permanente Ablehnung der Anforderung, wobei nachfolgende gleichartige Anforderungen nicht erzeugt werden können oder ohne weitere Verarbeitungsschritte sofort mit einer wei- teren permanenten Ablehnung beantwortet werden.
11. Verfahren nach Anspruch 10, d a d u r c h g e k e n n z e i c h n e t, d a s s dem Anwender des Endgerätes (10) die Meldung angezeigt wird, insbesondere indem die Option zur Anforderung, die zu der
Meldung geführt hat, markiert oder unzugänglich gemacht wird.
12. Verfahren nach Anspruch 10 oder 11, d a d u r c h g e k e n n z e i c h n e t, d a s s im Ansprechen auf eine temporäre Ablehnung automatisch eine erneute Ladeanforderung erzeugt wird.
13. Verfahren nach einem der Ansprüche 10 bis 12, d a d u r c h g e k e n n z e i c h n e t, d a s s eine permanente Ablehnung durch einen der folgenden Schritte erzeugt wird:
- einfach oder mehrfach wiederholte temporäre Ablehnung
- Vergleich der benötigten mit der maximal verfügbaren Bandbreite .
14. Server (20), der eine Leistungsmerkmal-Bereitstellungseinrichtung (31) zum Zugriff auf einen Leistungsmerkmalspeicher (32) zur Speicherung von Software und/oder Daten sowie einen Verfügbare-Bandbreiten-Speicher (42) zur Speicherung von Bandbreitendaten für Verbindungen zu Endgeräten (10) aufweist, wobei die Leistungsmerkmal-Bereitstellungseinrichtung (31) eine Schnittstelle zu mindestens einem Endgerät (10) hat, über die Software und/oder Daten zum Endgerat übertragen werden können, d a d u r c h g e k e n n z e i c h n e t, d a s s die Leistungsmerkmal-Bereitstellungseinrichtung (31) zumin- dest mittelbaren Zugriff auf den Verfugbare-Bandbreiten-
Speicher (42) hat und somit auf eine Ladeanforderung an der Schnittstelle hin einen Bandbreitentest ausfuhren kann, um entweder bei positivem Testergebnis des Bandbreitentests die Daten und/oder Software gemäß der Ladeanforderung oder bei negativen Testergebnis eine Meldung mit einer Ablehnung der Ladeanforderung zu übertragen.
15. Server (20) nach Anspruch 14, d a d u r c h g e k e n n z e i c h n e , d a s s zusätzlich ein Bandbreitenbedarfsspeicher (33) zur Speicherung der benotigten Bandbreite für ein Leistungsmerkmal mit der Leistungsmerkmal-Bereitstellungseinπchtung (31) verbunden ist derart, dass die Leistungsmerkmal- Bereitstellungseinrichtung (31) für die Durchfuhrung des Bandbreitentests ermitteln kann, welche Bandbreite eine Übertragung der Daten und/oder Software gemäß einer Ladeanforderung für ein Lei stungsmerkmal benotigt.
16. Server (20) nach Anspruch 14 oder 15, d a d u r c h g e k e n n z e i c h n e t, d a s s die Leistungsmerkmal-Bereitstellungseinrichtung (31) Zugriff auf einen Maximale-Bandbreiten-Speicher (43) zur Speicherung der maximal verfugbaren Bandbreiten für Verbindungen zu Endgeraten (10) hat, um einen zusätzlichen oder alternativen Bandbreitentest anhand der maximal verfugbaren Bandbreiten durchzufuhren .
17. Server (20) nach einem der Ansprüche 14 bis 16, g e k e n n 7 e c h n e t d u r c h eine Netzressourcen-Zuteilungseinrichtung (41), die mit der Leistungsmerkmal-Bereitstellungseinr chtung (31) verbunden ist und Zugriff auf den Verfugbare-Bandbreiten-Speicher (42) hat, wobei die Netzressourcen-Zuteilungseinrichtung (41) der Ladeanforderung Netzressourcen zuweisen oder verweigern kann und dementsprechend den Verfügbare-Bandbreiten-Speicher (42) aktualisiert .
18. Server (20) nach Anspruch 17, d a d u r c h g e k e n n z e i c h n e , d a s s die Netzressourcen-Zuteilungseinrichtung (41) mit einer Netzressourcen-Testeinrichtung (46) verbunden ist, welche Zugriff auf den Verfügbare-Bandbreiten-Speicher (42) sowie zumindest eine Verbindung zu einem Endgerät (10) hat, um aktuelle Bandbreitendaten zu ermitteln und zu speichern.
19. Server (20) nach Anspruch 17 oder 18, d a d u r c h g e k e n n z e i c h n e t, d a s s die Netzressourcen-Zuteilungseinrichtung (41) Zugriff auf einen Netzressourcen-Verteilungsspeicher (44) hat, der Daten über Prozessen zugeordnete Bandbreiten sowie Prioritäten dieser Prozesse speichert, wobei die Netzressourcen-Zuteilungs- einrichtung (41) abhängig von den Prioritäten der Prozesse und der Ladeanforderung Netzressourcen umverteilen kann, um der Ladeanforderung genügend Bandbreite verfügbar zu machen.
20. Server (20) nach einem der Ansprüche 14 bis 19, d a d u r c h g e k e n n z e i c h n e t, d a s s die Netzressourcen-Zuteilungseinrichtung Zugriff auf einen Netzressourcen-Anfragen-Speicher hat, der Daten über angeforderte Bandbreiten speichert, um Prozesse zu verwalten, denen gegenwärtig keine Bandbreite zugeordnet ist.
21. Endgerät (10) für Datenverarbeitung in einem Paketnetzwerk (50) mit einem Server (20) nach einem der Ansprüche 14 bis 20, das eine Benutzerschnittstelle (11), die eine Auswahl von Leistungsmerkmalen darstellt, und eine Leistungsmerkma.l - Ladeeinrichtung (12) aufweist, die zumindest mittelbar über das Netzwerk (50) mit dem Server (20) verbunden ist, d a d u r c h g e k e n n z e i c h n e , d a s s die Benutzerschnittstelle (11) zur aktuellen Darstellung der Auswahl von Leistungsmerkmalen nach einer Ablehnung einer Ladeanforderung eines Leistungsmerkmals durch den Server (20) derart ausgebildet ist, dass das angeforderte Leistungsmerk- mal hervorgehoben oder ausgelassen ist.
22. Endgerat (10) nach Anspruch 21, d a d u r c h g e k e n n z e i c h n e t, d a s s in der Darstellung ein Leistungsmerkmal nach einer temporaren Ablehnung durch den Server (20) hervorgehoben und nach einer permanenten Ablehnung nicht dargestellt ist.
23. Netzwerkanordnung (150) mit mindestens einem Server (120) nach einem der Ansprüche 14 bis 20 und mindestens einem End- gerat (HOa-llOd) nach Anspruch 21 oder 22.
EP04766434A 2003-09-29 2004-08-05 Verfahren zur bereitstellung von leistungsmerkmalen bei bedarf Ceased EP1668860A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10345184 2003-09-29
PCT/EP2004/051729 WO2005034463A1 (de) 2003-09-29 2004-08-05 Verfahren zur bereitstellung von leistungsmerkmalen bei bedarf

Publications (1)

Publication Number Publication Date
EP1668860A1 true EP1668860A1 (de) 2006-06-14

Family

ID=34399030

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04766434A Ceased EP1668860A1 (de) 2003-09-29 2004-08-05 Verfahren zur bereitstellung von leistungsmerkmalen bei bedarf

Country Status (4)

Country Link
US (1) US8656005B2 (de)
EP (1) EP1668860A1 (de)
CN (1) CN1860762B (de)
WO (1) WO2005034463A1 (de)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100242048A1 (en) * 2006-04-19 2010-09-23 Farney James C Resource allocation system
US20080259810A1 (en) * 2007-04-23 2008-10-23 At&T Knowledge Ventures, Lp Broadband Service Applications Test Tool
US8184538B2 (en) * 2007-06-22 2012-05-22 At&T Intellectual Property I, L.P. Regulating network service levels provided to communication terminals through a LAN access point
US8174974B2 (en) * 2009-11-12 2012-05-08 Yahoo! Inc. Voluntary admission control for traffic yield management
US20130013666A1 (en) * 2011-07-07 2013-01-10 International Business Machines Corporation Monitoring data access requests to optimize data transfer
US10896432B1 (en) * 2014-09-22 2021-01-19 Amazon Technologies, Inc. Bandwidth cost assignment for multi-tenant networks
US9923965B2 (en) 2015-06-05 2018-03-20 International Business Machines Corporation Storage mirroring over wide area network circuits with dynamic on-demand capacity
US10057327B2 (en) 2015-11-25 2018-08-21 International Business Machines Corporation Controlled transfer of data over an elastic network
US9923839B2 (en) 2015-11-25 2018-03-20 International Business Machines Corporation Configuring resources to exploit elastic network capability
US10581680B2 (en) 2015-11-25 2020-03-03 International Business Machines Corporation Dynamic configuration of network features
US10177993B2 (en) 2015-11-25 2019-01-08 International Business Machines Corporation Event-based data transfer scheduling using elastic network optimization criteria
US9923784B2 (en) 2015-11-25 2018-03-20 International Business Machines Corporation Data transfer using flexible dynamic elastic network service provider relationships
US10216441B2 (en) 2015-11-25 2019-02-26 International Business Machines Corporation Dynamic quality of service for storage I/O port allocation
CN108400888B (zh) * 2018-01-29 2021-07-23 深圳壹账通智能科技有限公司 一种日志处理方法、存储介质及终端设备
US10868853B2 (en) * 2018-06-08 2020-12-15 Verizon Patent And Licensing Inc. System and method for image file generation and management
US11018960B2 (en) * 2019-03-06 2021-05-25 Cisco Technology, Inc. Accelerated time series analysis in a network

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4891805A (en) * 1988-06-13 1990-01-02 Racal Data Communications Inc. Multiplexer with dynamic bandwidth allocation
CA2130395C (en) * 1993-12-09 1999-01-19 David G. Greenwood Multimedia distribution over wide area networks
US6222856B1 (en) * 1996-07-02 2001-04-24 Murali R. Krishnan Adaptive bandwidth throttling for individual virtual services supported on a network server
US6968379B2 (en) * 1997-05-30 2005-11-22 Sun Microsystems, Inc. Latency-reducing bandwidth-prioritization for network servers and clients
US6075772A (en) * 1997-08-29 2000-06-13 International Business Machines Corporation Methods, systems and computer program products for controlling data flow for guaranteed bandwidth connections on a per connection basis
US6529499B1 (en) * 1998-09-22 2003-03-04 Lucent Technologies Inc. Method for providing quality of service for delay sensitive traffic over IP networks
EP0996264A1 (de) * 1998-09-24 2000-04-26 Bowne Global Solutions Germany GmbH Verfahren und Vorrichtung zur Dateienübertragung
US6459681B1 (en) * 1998-11-13 2002-10-01 Sprint Communications Company L.P. Method and system for connection admission control
US7225264B2 (en) * 1998-11-16 2007-05-29 Softricity, Inc. Systems and methods for delivering content over a computer network
US6850965B2 (en) * 1998-11-17 2005-02-01 Arthur Douglas Allen Method for connection acceptance and rapid determination of optimal multi-media content delivery over network
US6411601B1 (en) * 1998-12-15 2002-06-25 Siemens Information And Communication Networks, Inc. System and method for securing available communications network resources
EP1022883A3 (de) * 1999-01-25 2004-01-28 Siemens Aktiengesellschaft Verfahren zum Realisieren einer Leistungsmerkmalsteuerung in einem Kommunikationsdatennetz
US6826612B1 (en) * 1999-12-21 2004-11-30 Alcatel Canada Inc. Method and apparatus for an improved internet group management protocol
AU2001238419A1 (en) * 2000-02-16 2001-08-27 Microsoft Corporation System and method for transferring data over a network
US6920110B2 (en) * 2001-02-14 2005-07-19 Microsoft Corporation System and method for transferring data over a network
US6795445B1 (en) * 2000-10-27 2004-09-21 Nortel Networks Limited Hierarchical bandwidth management in multiservice networks
US6941380B2 (en) * 2000-12-28 2005-09-06 Nortel Networks Limited Bandwidth allocation in ethernet networks
US6636482B2 (en) * 2001-03-08 2003-10-21 Arris International, Inc. Method and apparatus for controlling traffic loading of different service levels in a cable data system
US6584017B2 (en) * 2001-04-05 2003-06-24 Saifun Semiconductors Ltd. Method for programming a reference cell
US6754230B2 (en) * 2001-08-31 2004-06-22 The Boeing Company User bandwidth monitor and control management system and method
US6956857B2 (en) * 2001-09-24 2005-10-18 Lucent Technologies Inc. Guaranteed admission and incremental bandwidth allocation in a packet network
US20030097443A1 (en) * 2001-11-21 2003-05-22 Richard Gillett Systems and methods for delivering content over a network
US7039712B2 (en) * 2002-10-16 2006-05-02 Microsoft Corporation Network connection setup procedure for traffic admission control and implicit network bandwidth reservation
US20040158644A1 (en) * 2003-02-11 2004-08-12 Magis Networks, Inc. Method and apparatus for distributed admission control

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2005034463A1 *

Also Published As

Publication number Publication date
WO2005034463A1 (de) 2005-04-14
US20070198627A1 (en) 2007-08-23
CN1860762B (zh) 2013-03-27
US8656005B2 (en) 2014-02-18
CN1860762A (zh) 2006-11-08

Similar Documents

Publication Publication Date Title
DE60217253T2 (de) Centrale und regelbasierte Verkehrsverwaltung
EP1668860A1 (de) Verfahren zur bereitstellung von leistungsmerkmalen bei bedarf
DE69933852T2 (de) Hausnetz- autokonfigurierung
DE19842673B4 (de) Verfahren und Vorrichtung zur Vermittlung bei der Datenkommunikation
DE69731965T2 (de) Zugriff auf rechnerbetriebsmittel von aussen durch eine firewall
EP1488611B1 (de) Aaa serversystem zur effizienten zugangskontrolle und adresszuordnung
DE69934451T2 (de) Internetteilnehmerprofil
DE69735426T2 (de) Nachrichtenübertragung in netzwerken bestehend aus unternetzwerken mit verschiedenen namensraümen
DE602004004321T2 (de) Vorrichtung und Verfahren zur Echtzeitbeurteilung einer Netzverwaltungsregel
DE69933312T2 (de) Auswahlsteuerung eines gateway-unterstützungsknotens
DE602004008415T2 (de) System und Verfahren zum Aufrechterhalten der Netzwerkverbindung
DE102005053688A1 (de) Verfahren und Mechanismus zum Identifizieren eines nicht-verwalteten Schalters in einem Netz
EP1123622A1 (de) Verfahren zur steuerung von netzelementen
WO2010025759A1 (de) Verfahren zur übertragung und aushandlung von netzwerk kontrollierten funktionsdaten zwischen einem client und einem server
DE60205501T2 (de) Verwaltung von informationen über subskriptionen der dienstleistungen von dritten
WO2007087804A1 (de) Änderungsverfahren der arbeitsweise einer technischen-kommunikationsgruppen-plattform (tkgp) eines telekommunikations-netzes (tk-netzes)
DE60038171T2 (de) Verfahren zur Auswahl von Übertragungsentitäten
DE10314597A1 (de) Verfahren und Anordnungen in einem Telekommunikationsnetz
DE102011080676A1 (de) Konfiguration eines Kommunikationsnetzwerks
EP1942633A2 (de) Verfahren und System für ein Erreichbarkeitsmanagement
EP1195945B1 (de) Client, System und Verfahren zum Netzmanagement in einem Multiserver-Kommunikationsnetz
DE60107433T2 (de) Verfahren und Vorrichtung zur Koordinierung von Telekommunikationsdiensten
DE60100685T2 (de) Verwaltungsverfahren vor einem telekommunikationsnetzwerk und vorrichtung zur durchführung des Verfahrens
WO2007118891A1 (de) Verfahren zum beschränken des zugriffs auf daten von gruppenmitgliedern und gruppenverwaltungsrechner
WO2008006889A2 (de) Verfahren und anordnung zur realisierung von zugangsnetzwerken zu einem öffentlichen netzwerk

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060221

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): DE FR GB IT SE

17Q First examination report despatched

Effective date: 20061025

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE FR GB IT SE

APBN Date of receipt of notice of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA2E

APBR Date of receipt of statement of grounds of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA3E

APAV Appeal reference deleted

Free format text: ORIGINAL CODE: EPIDOSDREFNE

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIEMENS ENTERPRISE COMMUNICATIONS GMBH & CO. KG

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

APBT Appeal procedure closed

Free format text: ORIGINAL CODE: EPIDOSNNOA9E

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20120621