CN111526554B

CN111526554B - Method and system for switching advanced association preparation support

Info

Publication number: CN111526554B
Application number: CN201911347440.3A
Authority: CN
Inventors: 西格拉姆·申德勒
Original assignee: Sigram Schindler Beteiligungs GmbH
Current assignee: Sigram Schindler Beteiligungs GmbH
Priority date: 2012-11-27
Filing date: 2012-11-27
Publication date: 2023-04-28
Anticipated expiration: 2032-11-27
Also published as: EP2926595A1; WO2014082658A1; CN111526554A; CN104969617A; CN104969617B

Abstract

A handover pre-association preparation support method and system are disclosed. A method of provisioning at least one internet application service to a mobile communication terminal prior to a handoff of the mobile communication terminal from one communication network access device to another communication network access device comprising: receiving a signal indicating that the mobile communication terminal can be handed over to a communication network access device other than the communication network access device currently providing a service to the mobile communication terminal within a given time t1> 0; in response to receiving the signal and prior to initiating the handover operation, preparing an association of the at least one internet application service with the mobile communication terminal at the communication network access device to which the mobile communication terminal may be handed over, such that the at least one internet application service is immediately available to the mobile communication terminal at the communication network access device to which the mobile communication terminal is handed over after the handover operation is completed.

Description

Method and system for switching advanced association preparation support

The present application is a divisional application of chinese invention patent application with the application date 2012, 11, 27, international application number PCT/EP2012/073721, chinese application number 201280077304.7, and the name of "handover advanced association preparation support method and system".

Technical Field

The present invention relates to a handover advanced association provisioning support (Handover Proactive Association Provisioning Support, HOPA-profs) method and system.

Background

EP2027747 ("HOBIS" patent) discloses a web surfing method for an end system A0 having a real or virtual A0-homeIAD0 and an A0 connection to a second end system Z0 for a Managed Handover (MHO) of the end system A0 to a real IADx in wlan x or a virtual IADx to a mobile network x. The Managed Handover (MHO) is supported by A0-homeIAD 0. The A0 connection is often relayed through an MHO module (MHOM) controlled by the MHO Specification (MHOs) in A0-homeIAD 0.

Disclosure of Invention

A.Problems solved by HQPA-ProvS method/apparatus

"Handover (HO) advanced association preparation support (HO Proactive Association Provisioning Support), HOPA-profs" method/system, for any HO-based Handover technique, is supported by free Handover to Sxyzjkm-association of shared ldx (complex representation ("s") omitted) prior to HO preparation (otherwise known as setup): the HO time for switching to shared IADx for a web surfing smartphone Ayz controlled by a local IADz (home Internet access device z, local internet access device z) (see EP2027747, "HOBIS", the entire contents of which are incorporated herein by reference) is minimized and the revenue from these shared IADx is optimized. That is, the shared ldx service Sxyzjkm is prepared for Ayz substantially at the time of its HO. Sxyzjkm comprises services of at least one internet application with a specific network quality of service, given by a service level agreement (Service Level Agreements) SLAxyzjkm between users of Ayz corresponding to the management of their local iadz or the management of shared IADx, potentially constrained by a given HOPA preparation system PSxyzjkm (designed to optimize the usual benefits of the system from shared IADx, for example), x, y, z, j, k, m=0, 1,2, ….

This enables a second innovation of the HOPA-profs method/system: for any shared-IADx, pre-HO (and/or post-HO) automatic auctions for its service capabilities-if Ayz requires services beyond its capabilities-are controlled by, for example, PSxyzjkm and/or a suitable scavenging system that is not part of the present invention.

The third HOPA-profs innovation has completely different properties. The innovation can enable shared IADx to automatically generate profitable clicks on services of location-based internet applications published by Ayz across the reach of shared IADx. Examples are clicking on a website: 1. ) It directly affects the actual location of Ayz (e.g., its nearest coffee shop), or 2.) indirectly affects the actual location of Ayz (e.g., the user of Ayz calls a public transportation system or is near a particular company), or 3.) it also affects the earlier location of Ayz (e.g., for tracking the route he takes to reach his actual location).

The fourth HOPA-profs innovation in turn has completely different properties: this innovation greatly promotes the vital daily and very competitive market demand for internet applications, as it enables several such provisioning (and scavenging) systems to be run simultaneously even for arbitrary shared ldx-thus, high flexibility is achieved with respect to instant and local/regional system reconfiguration, e.g. representing pricing strategy adaptations and/or version control.

HOPA-ProvS method/system solves the problem of managing shared lADx by its pre-HO activity

■ The HO-time to switch a given set of Ayz to shared ldx is reduced to essentially zero, and

■ The HOPA provisioning system of various internet-applied services can flexibly optimize revenue from the shared ldx's that offer these services, where it facilitates even local/regional, immediate and seamless changes in system version as required by dynamic marketing activities, for example.

That is, as seen after HO, most of such pre-HO activities of the HOPA-ProvS method/system are useless, being currently overcompensated economically by their just-described advantages.

The application of the HOPA-profs method/system does not need to change networks between which the above pre-HO supporting its HO/MHO should be performed, i.e. the HOPA-profs method/system may work for all networks between which HO or MHO may be performed, but the HOPA-profs method/system may be integrated into the network and/or the HO mechanism of the network.

B.Novelty and non-obvious of the HOPA-profs method/system

The novelty of the HOBIS invention has been established by the HOBIS patent. Since the HOPA-profs method/apparatus is built on top of the HOBIS invention, there is absolutely no prior art for it-no inventor so far has considered this direction and disclosed a technique capable of guiding the solution of the above-mentioned problems. This makes it self-evident not only in its novelty but also in its non-obvious nature.

Drawings

FIG. 1 is a block diagram of a web surfing arrangement suitable for use with the present invention;

FIGS. 2a and 2b are schematic and block diagrams, respectively, of a business region having overlapping wireless network cells;

fig. 3a and 3b are block diagrams illustrating different specific handover situations of a user according to the present invention; and

fig. 4 is a diagram illustrating a handoff look-ahead provisioning and support data structure in accordance with the present invention.

Detailed Description

C.Description of HOPA-ProvS methods/systems and embodiments thereof

Since the novelty of the web surfing and MHO methods of the HOBIS invention-the HOBIS invention is particularly important for HOPA-profs methods/systems and thus it is particularly important-their basic characteristics are first outlined. This simplifies the subsequent description of the HOPA-profs method/system.

First note that: this HOPA-profs patent application includes the functionality of the pre-HO preparation policy of "Sxyzjkm-association" without limitation (see section D) -thus the HOPA-profs method/system is inherent in all pre-HO association preparation policies.

As known from the HOBIS patent, we start the web surfing system A0 by local IAD0 and by A0 to MHO sharing IADx. The HOPA-profs method/apparatus handles unmanaged HO, in particular managed or unmanaged "service-HO" (see section D), in the same way as it is now explained with the help of MHO.

Each MHO of the web surfing system A0 is supported by its local IAD0 (see HOBIS patent). Any OSI-connection of A0 is relayed via the MHO-module MHO-M, which is controlled in the local IAD0 by the MHO-specification MHO-S or even executed there. MHO-S may be local IAD 0-management-private, A0-type-specific or even A0-individual. HOPA-profs-S/-M is peer to peer with MHO-S/-M, but is very functionally different.

Figure 1 shows the simplest web surfing configuration. It is assumed that MHO-S/-M and HOPA-profs-S/-M are integrated in local IAD0 (fig. 6-8 in the HOBIS patent show their distributed implementation and therefore need not be reiterated here). It illustrates (see, for example, section D, the user's smartphone A0 and the existing OSI-connected OC 0) a surfing A0 from its local WLAN0 (simply referred to as W0 of the local IAD 0) along route 1 or route 2, respectively, into an MHO of W1 (W1 intersects W0) and W2 (W2 does not intersect W0). The existing OC0 between A0 and Z0 is not in contact with these MHOs along line 1 or path 2. However, after A0 has completed its HO into W1 or W2, one L3-connection/association in this OC0 is relayed from IAD1 or IAD2 (here shared IADI and shared IAD2, respectively) via A0-MHO-M in local IAD0, respectively. Technical details and variants (e.g. "tunnelling"/"multiplexing"/"compression") are known from mobile internet technology.

Regarding small or large local/shared IADs, their local/shared (W) LANs, respectively, are the same as described in the HOBIS patent: its LAN/WLAN is considered as an internet access LAN/WLAN (otherwise known as IAW) and for the present invention may comprise one or more cells and thus IADs of any wireless technology, such as RFI/WiFi/BlueTooth/Femtocell/DECT/Wimax/GSM/CDMA/UMTS/GPRS/HSPDA/LTE/… technology. However, as managed in the present invention, this IAW must be managed (by some "overlay network function") so that IAW is functionally a single end system representing a single local/shared IAD. It is possible to roam seamlessly between its cells, especially without interrupting any of its existing OSI-connections OC. Thus, IAW may be area distributed and e.g. comprise IADs and/or such BSs (bs=base stations of mobile networks) connected via a fixed line PSN (psn=packet switched network (Packet Switch Network)) extending only to parts of their technology access area and comprising geographically even separate areas with holes therein. The HOPA-profs method/apparatus is applicable to HO between all such "network configurations" (i.e., between IAW cells and between lAW).

As mentioned above, the HOPA-profs method/system achieves its innovation by acting at the point in time, i.e. before HO, which is not considered by the prior art in HO technology and by the HOBIS patent. These pre-HO operations of the HOPA-profs method/system-for a set of shared IADx, a set of web surfing mobile terminal systems Ayz with local IADz, a set of service Sxyzjkm based on a set of service level agreements, SLAxyzjkm, and a set of HOPA preparation systems, PSxyzjkm, x, y, z, j, k, m = 0,1,2,3, … -determine a set of all constraints of the preparation Sxyzjkm-association requested or possibly requested by Ayz. Since Ayz should obtain service Sxyzjkm immediately upon its Handover (HO) to shared IADx, these pre-HO operations of the HOPA-profs method/system have previously fully established all web surfing x/yz-associations (where only one association is needed) and at least substantially established all x/u-associations (see second sentence and part D of the next paragraph), which may be required to provide Sxyzjkm to the users of Ayz. That is, the "web surfing" service in Sxyzjkm-association is fully established prior to HO and wherein the "non-web surfing" service (none of which need to exist) is at least substantially established.

In the previous paragraph, it

■ The first sentence shows how the HOPA-profs method/system provides an architecture for arbitrarily optimizing the expected revenue from this set of shared ldx: that is, it identifies and describes the limitations on all current contractual relationships that can be used for revenue optimization, i.e., shows its offered/needed services and its short-term potential contribution to revenue optimization for any < shared ldx/Ayz > pair based on its SLAxyzjkmu. In addition, this HOPA-profs information, which the person skilled in the art knows will store in the "HOPA-profs data structure", which provides the basis for any optimization of revenue achieved by selling Sxyzjkmu via shared ldx, and also provides the basis for any optimization of user support for Aye users, either alone or in parallel or globally.

■ The second sentence shows how the HOPA-profs method/system may actually ignore the HO-time encountered by the Ayz user and how it does ignore (and the situation described above may be caused if the Ayz has to reconnect after HO to the Sxyzjkm service(s) used before HO unless the pre-HO network and the post-HO network cooperate between the two networks during processing of the service, but this situation is not assumed in the present patent application and therefore means that the Sxyzjkm-association has to be established again after HO), the HOPA-profs method/system first establishes it before HO. Thus, the HOBIS method/system ensures that the x/yz-association(s) are fully established, although the establishment of the x/u-association (which need not exist at all) may not be accomplished immediately before HO, for example, due to the design or implementation of the communication application underlying the x/u-association. This is called "basic set-up" of the communication connection, and the implicit corresponding HO-time is then reduced to "substantially zero".

The actual implementation of the HOPA-profs system-where the implementation of HOPA-profs-S controls the implementation of HOPA-profs-M-typically includes physical HW and SW components, just like all working computers. Thus, these HW components need not be dedicated to their HOPA-ProvS-SW, but may be used by SW components of any other system as well. The implementation of the HOPA-profs data structure and its management system(s) may thus be distributed, such as on the respective local IADz or shared IADx, or concentrated on a certain server, or a mixture of both. In addition, the system design is aware of techniques that can efficiently and completely maintain parallel access to this data structure for flexibly and instantaneously updating/changing the data structure by properly synchronizing all read and write accesses to the data structure. Thus, those skilled in the art are aware of various embodiments of HOPA-profs methods/systems.

The HOPA-profs method/system (local IADz and shared IADx for web surfing Ayz) is subject to the following basic constraints: ayz may use the shared IADx alone as a router that connects only to Ayz-local IADz or its Ayz-MHO_S with a fixed IP address unless the services of the communication application are privately provided by the shared IADx. Both the correctness of the IP address and the compatibility of such private services with the implementation of HOPA-profs (and HOBIS, …) methods/systems require explicit approval by management of the shared IADx before the completion of the respective HO (handover) to Ayz-local IADz or the shared IADx of Ayz. That is, ayz may also use this shared IADx to use other services than those provided via the web surfing x/yz-association, i.e., services that are privately provided by the shared IADx and bypass the Ayz-local IADz. Thus, the shared IADx ensures in real time that its management is always possible, identifying the management of Ayz and PSxyzjkm responsible for sharing IADx (such as by their approval) with respect to communications relayed via the shared IADx and even before starting the application system of the shared IADx.

Fig. 2a schematically shows a business area where in any building there are several shared IADx cells overlapping and independent from each other (e.g. WiFi-based, as enlarged in fig. 2 b), which in turn overlap several GSM networks-where the respective accessible areas of the shared IADx are represented by "virtual" borderlines. In addition, two different smartphone systems Ayz (visualized by their two different shapes) are schematically shown in this context, since they belong to two different local iadzs and their Ayz-mho_s. If the handset Ayz moves along the street in fig. 2a, for example, ayz generates a very new potential and/or actual HO requirement related to a series of shared IADx along the road of Ayz. Proper inspection of potential HO with respect to its optimality is done by a suitable scavenging system (which is not part of the present invention) and its actual execution is expedited by the HO-advance HOPA-profs method/system.

In this context, for example, due to an unacceptably reduced SLA of the quality/cost ratio of L3-services provided to Ayz by the currently used shared IADx of Ayz, or due to an increase in the required L3-quality of service by Ayz because the user of Ayz starts another broadband streaming application, or due to the cooperation of the HOPA provisioning system with another system, such as a suitable scavenging system, some circumstances may change, causing a question as to whether the HO of Ayz is suitable, even if Ayz is not moving.

Fig. 3a shows for Ay1 its local IAD1, its currently used shared IADx, and its 2 OCy i.e. OCy1, OCy2 and 4 BCy i.e. BCy1-4. The HOPA-profs method/system can identify which Sxyzjkmu-association to first establish the corresponding rebroadcast before HO. Fig. 3b additionally shows that the shared IADx has the ability to also provide Ay1 on its own BCy and BCy with things approved/supported by the HOPA-ProvS method/system, e.g. as required by Ay 1's security and/or market and/or logistics and/or billing and/or pricing requirements. Figures 3a and 3b are enriched here by the web surfing system of Ay 2-but a single shared IADx can route both Ay at any point in time, i.e. a single shared IADx can cooperate with several different HOPA provisioning systems.

Figure 4 schematically shows HOPA-profs data structure entries accessed from the following locations,

■ For managing the HOPA-profs module side sharing IADx and corresponding local IADz of at least one HOPA preparation system and their Ayz, and

■ For example, to manage the appropriate cleaning module side of the respective local iadzs and their Ayz sharing the IADx and at least one appropriate cleaning system.

These figures should ultimately be retrieved: telephone, IP-TV, video clip, security assessment, medical monitoring, guidance, … require different types of L3-services and L3-L7 resources in the end system.

The HOPA-profs method/system may also support identifying/negotiating-while on all currently possible Sxyzjkm-associated its upper pre-HO decisions-all contentions of Ayz related to shared IADx services and potentially disclosing to them, either completely or in part (through e.g. protocols between competitors), which contentions exist on which shared IADx for which Sxyzjkm. Such agreements and/or decisions regarding negotiations may

■ For example, upon purchase or lease of Ayz, by an initial operation or at any time as required by its user, either globally or regionally or statically according to address, … and/or,

■ For example, according to the level of actual importance in which these services are located (e.g., in an area), or dynamically according to the degree of use of the Internet or Sxyzjkm (e.g., in an area), or …

And (3) generating.

Some other cues regarding the limitations of the HOPA-profs method/system appear to be appropriate:

■ There is no limitation regarding the generation and/or examination and/or detection of the signal SIGxyz. Specifically, as described above, the signal may be generated by a suitable purging system as described above.

■ Any internet application service Sxyzjkm may be provided by a collection of alternative and/or collaborative and/or concurrent or sequential communication applications and may involve several internet end systems.

■ The parameter may be constant or varying (predictable or unpredictable) over time and/or the same for several Ayz or shared IADx or local IADz and/or (not) dependent on another parameter which is valid in at least one geographical area and/or for at least one time period.

■ There is no limitation regarding additional pre-HO preparation activities for the HO, such as communication with the appropriate scavenging system and/or additional given systems described above.

■ The HOPA-profs method/system can generate a given alert upon the occurrence of certain events, for example, when attempting to route data outside of an approved route.

■ The auction of the HOPA-profs method/system may be fully automated or interact with at least one user and/or take place under its own control or under the control of the HOPA preparation system or some separate system.

Finally, it is clear to the person skilled in the art that:

■ The communication architecture of the HOPA-profs method/system discussed above with the HOPA-profs-S module in the local IAD of the end system is independent of whether the local IAD of the end system additionally includes MHO-S and/or a suitable purge module-i.e., the HOPA-profs method/system may also be used to support "unmanaged" and/or "uncleaned" HO; and this holds true for "vertical" HO as with "horizontal" HO (see HOBIS patent) and any mix of all the HO types mentioned above.

■ The HOPA-profs method/system can be integrated in any XYZ function, unlike the functions previously disclosed in any conceivable way, i.e. the use of the HOPA-profs method/system is not presented at all in a separate way. However, this holds true in the following cases: insofar as this XYZ function includes the above disclosed functions of the HOPA-profs method/system, this XYZ function relates to the scope of patent protection of the HOPA-profs method, provided that it is to be granted.

■ The same holds for any system of any parameters of the HOPA-profs method/system described in the preceding paragraph.

D.HOPA-ProvS method/apparatusPut terms and concepts

The telecommunication technology terms and their meaning as used in this patent application are defined by The international standard "ISO7498-1,Information Technology-Open Systems Interconnection-Basic Reference Model: the basic Model (ISO 7498-1, information technology-development system interconnection-basic Reference Model: basic Model)" which is called "ISO/OSI-Reference Model" based on The fact that they have only recently become present, i.e. that they do not exist at that time. For a person skilled in the art, this international standard is also an absolute mandatory basis for the interpretation, i.e. the assignment of meaning, of all communication technology terms which only appear after the OSI reference model has been adopted by all relevant international and national consensus forming communities worldwide, such as ISO, IEEE, ITU, ANSI, ETSI, DIN, BSI, AFNOR, …. This also holds true for the innovative terms introduced herein capable of describing the present patent application based on the communication technology.

With respect to this "OSI-RM", there is (i.e., exists) an "OSI connection" for any interactive communication application, i.e., for each communication between two end systems (e.g., A0 and Z0) hosting respective interactive communication application systems that cause the communication. Thus, the "presence" of an OSI connection for an interactive communication application (system) begins at the very beginning of its first interaction. This OSI connection then exists in particular between the two end systems hosting the interactive communication application.

OSI connections are generally referred to here by the acronyms OCj (=osi connection j) or BCj (= "business connection j") as shorthand. The only reason for having BCj is that BCj sometimes helps to retrieve a communication application Sj (which may be a particular business application) -then also referred to herein as "business communication j", j=0, 1,2,3 …, and OSI connections are similarly commonly denoted as "communication connections".

A refinement of the following concepts is required with respect to the above OSI connection. OSI-RM defines the meaning of any "connection" as "association" of its two endpoints-i.e. not only the meaning of an entire OSI connection, but also the meaning of any one of its Li-connections (see below). The end system or transmission system includes these endpoints. One example of an end system is the "web surfing system Ayz", while one example of a transmission system is the "shared IADx" used by Ayz when roaming (for providing services Sj to its users). Thus, the shared IADx is also the end system that the roaming communication application system is partially comprised of. For each layer i, each OSI connection defined by the OSI-RM includes at least one "Li-connection" individually referred to as "Li-association", 1< i <7 (without the need to clear their end/transport system, see below). Thus, any Li-connection is "present" in common with its Li-association-as both terms have the same meaning-as long as one of its endpoint systems knows the second endpoint system, i.e., knows the address of the other endpoint system.

Thus, as long as the association in one of a or Z for interaction between their communication applications has become known, e.g., as long as the address of Z in a and the communication application are available for this interconnection, an OSI connection exists between end systems a and Z. Namely: the availability of a communication application for enabling this interaction requires that this communication application is first "prepared" for at least a. At least one communication application is already prepared for at least the first interconnected system starting this application when an OSI association/connection starts to exist.

In any Li-connection of an existing/existing OC or BC, the transfer of data between its two endpoints and thus between the end systems, i.e. the transfer of this interaction via any one of the Li-connections of the OC/BC, can initiate/start to perform its "set-up", implementing any necessary "set-up" of the resources required for this Li-connection in a and Z and/or of the protocol between the two endpoints regarding what technical parameters should be used in the connection. All Li-connections/associations of OC/BC must be established (at least temporarily) before "user data" is transferred between the parts of the communication application system a and Z that the OC/BC is serving.

There is an association/connection that is prepared a priori, i.e., from the time the system (or subsystem thereof) that should contain its respective endpoint is started. And an association/connection is established as soon as the system exists (both are implemented by a priori protocols related to this association/connection). This is generally true, in particular, for all L3-associations (= "network connections") on the internet, i.e. for any L3-association of two internet end systems a and Z, once a processes (for interaction between a and Z) the IP address of Z. Namely: the prepared association/connection does not mean its establishment.

For the HOPA-profs method/apparatus, the terms "x/yz-association", "web surfing-x/yz-association", and "Sxyzjkm-association" are taken to mean the sharing of Li-associations between IADx and Ayz in all three cases for providing services to Ayz, or between IADx and local IADz, respectively, or between IADx or Ayz and at least one other end system hosting a part of a communication application, respectively.

Surfing-x/yz-associations typically connects the shared IADx with the local IADz, and Sxyzjkm-associations may be partially or fully relayed through the local IADz. As already defined above, a "preparation" of either of the two HOPA-profs associations means that the associated end systems are made available for the corresponding communication application. The "clean-up" is performed before HO in a manner outside the scope of HOPA-profs methods/apparatus. Then the HOPA-profs association as explained above starts to exist but has not been established under normal circumstances.

The establishment of such existing HOPA-profs association may then also be performed "substantially before HO". Namely: if the system and network implementing the embodiment of the HOPA-profs cleaning system is fast enough, possibly before HO,

■ (by having the shared IADx and Ayz run a corresponding web surfing protocol between the shared IADx and Ayz, see HOBIS patent above), to fully establish any web surfing-x/yz-association, and

■ As will be appreciated by those skilled in the art, any Sxyzjkm-association (depending on the shared IADx) is fully established by having the shared IADx and the other end system(s) involved run the respective communication application protocols implemented between the shared IADx and the other end system(s) involved, thereby enabling the end system to support endpoints of multiple such associations. He also knows that some communication applications will not tolerate such a complete pre-establishment of a connection with them for reasons not relevant here-which means that in these cases this connection establishment has to be deferred until the HO is complete. The phrase "substantially" is therefore used in this context.

A "handover HO" occurs within an OSI-connection that exists if at least one of its Li-connection's functional or non-functional characteristics changes. Accordingly: "Ayz performs a HO connected to the shared IADx" or abbreviated "Ayz HO to the shared IADx" if at least one Li-connection of the existing OSI-connection of at least one Ayz changes. Whereby the L3-association frequently changes its quality and/or is replaced by another and/or added/removed from the OSI-connection. Note that: this concept of HO also includes: once the Sxyzjkm provided to Ayz and/or its users by the shared IADx is changed (e.g., a change to one of its L3-connections and/or one of its L7-connections), a "service HO" occurs for Ayz. Such changes may also occur only within the Ayz and/or may be supported by communications of at least one given other system and/or network outside of that/those systems or networks of the Ayz that share the IADx.

Furthermore, the present invention also includes the following configurations.

1. A method called a "handover look ahead association preparation support HOPA-profs" method for managing a set of shared IADx, a set of web surfing systems with local IADs Ayz, a set of internet application services Sxyzjkmu (abbreviated Sj) provided by Ayz to Ayz users, a set of service level protocols saxyzjkm (abbreviated SLAk) and a set of HOPA preparation systems PSxyzm (abbreviated PSm), x, y, z, j, k, m = 0,1,2,3, …, any such given set together with a given set of management and time constraints of its elements is called a "parameter" of this method, wherein the services Sj

■ Is invoked by an Ayz user according to the SLAk of the user, and

■ In contrast to this call, it may be constrained by PSm,

wherein for a given set of these parameters, the execution of the method comprises the steps of, for at least one pair < shared IADx, ayz >:

(a) Checking a signal SIGxyzjkm indicating that Ayz can perform a handover to HO to one of shared IADx and/or Sxyzj/m, at least one of shared IADx and/or Sxyzj/m being different from the one just used by Ayz, within a given time t1>0,

(b) Once SIGxyzjkma is detected before HO, if SIGxyzj/m indicates that one of x/yz-association, web surfing x/yz-association and Sxyzj/m-association is required after HO and if the one association has not been established then the one association is basically established,

(c) After the basic establishment is completed, a signal SIG' xyzjkm indicating that the basic establishment is completed is generated.

2. The method according to 1 is limited, alone and/or in any combination, to:

■ Sj is any internet application, and/or

■ Assuming that x, y, z, j, k, m is only a value of "1", and/or

■ SLAk and/or PSm may be represented as a finite set of linked or independent automation and/or its characteristics may be described as and/or consist of a logical sum of attributes that predominate a finite set of given concepts, any of which are Boolean-type or whose value ranges are governed by the general order with which they are associated, and/or

■ A parameter or element thereof may be changed without interrupting the execution or OSI connection, and/or

■ Several executions of overlapping and/or disjoint parameters occur simultaneously, and/or

■ In step (b) at least one Sxyzjkm-association is fully or substantially established.

3. The method according to claim 1, comprising starting up directly or indirectly e.g. via signals and/or messages and/or procedure calls and/or by a given HOPA preparation system representative of the shared IADx,

■ Management and/or click-generating capabilities related to auction or tariff negotiating activities with Ayz's users or service provision of this shared lADx to Ayz's local IADz and using it, and/or

■ Sales activities for Sxyzjkm or for products or services not offered by this sharing IADx.

4. The method according to claim 1, wherein,

■ At least one of the IADs is a cell phone or even a surfing system, and/or

■ At least one of the web surfing systems is stationary/fixed, and/or

■ For at least one shared IADz and one Ayz,

known geographic location or distance between them, and/or

The latter to former HO time is known, and/or

At least a portion of the HOPA-ProvS data structure is stored in the WLANz, which shares the IADz.

5. The method of claim 1, wherein pre-HO activity in step (b) may be after and/or overlapping with at least one communication between management of this respective shared IADx of the Ayz in relation to at least one post-HO quality of service.

6. The method of claim 1, wherein at least one element of a parameter communicates with another element of the same or another parameter and/or uses another network other than the internet.

7. The method according to claim 1, wherein if one of a series of given events occurs, at least one given notification, e.g. signal SIGxyz, is performed or received by at least one element of at least one parameter.

8. The method according to claim 1, wherein for at least one pair < shared IADx, ayz >, the generation of at least one given notification, e.g. signal SIGxyz, depends on the location of at least one shared IADx and/or Ayz and/or on the distance from some other given location to one of these devices, in particular the distance between the two devices of at least one such pair.

9. A system called a "handover-advanced association preparation support HOPA-profs" system for managing a set of shared IADx, a set of web surfing systems Ayz with local IADz, a set of internet application services Sxyzjkmu (abbreviated Sj) provided by Ayz to Ayz users, a set of service level protocols saxyzjkm (abbreviated SLAk) and a set of HOPA preparation systems PSxyzm (abbreviated PSm), x, y, z, j, k, m=0, 1,2,3, …, any such given set together with a given set of management and time constraints of its elements is called a "parameter" of this method, wherein the services Sj

■ Is invoked by Ayz's user according to SLAk of said user, and

■ In contrast to this call, it may be constrained by PSm,

wherein for a given set of these parameters, the execution of the method comprises the steps of, for at least one pair < shared ldx, ayz >:

(a) Checking a signal SIGxyzjkm, said signal indicating that Ayz can perform HO to another service than shared ldx or currently provided to Ayz and/or its users within a given time t1>0,

(b) Once SIGxyzjkm is detected, if x/yz-associations have not been established, then the web surfing x/yz-associations required after HO are established,

(c) After the establishment is completed, a signal SIG' xyzjkm to be used by another given system is generated.

10. The system according to 9 is limited, alone and/or in any combination, to:

■ Sj is any internet application, and/or

■ Assuming that x, y, z, j, k, m is only a value of "1", and/or

11. A system according to claim 9, comprising a direct or indirect initiation of sharing IADx, e.g. via signals and/or messages and/or procedure calls and/or by a given HOPA preparation system representative,

■ Management and/or click-generation capabilities related to auction or tariff negotiating activities with Ayz's users or service provision of Ayz's local IADz in connection with this sharing of IADx and using it, and/or

12. The system according to claim 9, wherein,

■ At least one of the IADs is a cell phone or even a surfing system, and/or

■ At least one of the web surfing systems is stationary/fixed, and/or

■ For at least one shared IADz and one Ayz,

known geographic location or distance between them, and/or

The latter to former HO time is known, and/or

13. The system of claim 9, wherein the pre-HO activity in step (b) may be after and/or overlap with at least one communication between management of this respective shared IADx of the Ayz in relation to at least one post-HO quality of service.

14. The system of claim 9, wherein at least one element of a parameter communicates with another element of the same or another parameter and/or uses another network other than the internet.

15. The system of claim 9, wherein if one of a series of given events occurs, at least one given notification, e.g., signal SIGxyz, is performed or received by at least one element of at least one parameter.

16. The system according to claim 9, wherein for at least one pair < shared IADx, ayz >, the generation of at least one given notification, e.g. signal SIGxyz, depends on the location of at least one shared IADx and/or Ayz and/or on the distance from some other given location to one of these devices, in particular the distance between the two devices of at least one such pair.

Claims

1. A method of provisioning at least one internet application service to a mobile communication terminal prior to a handoff of the mobile communication terminal from one communication network access device to another communication network access device, the method comprising:

receiving a signal indicating that the mobile communication terminal can switch to a communication network access device other than a communication network access device currently providing a service to the mobile communication terminal within a given time t1> 0;

preparing, at a communication network access device to which the mobile communication terminal can be handed over, an association of the at least one internet application service with the mobile communication terminal in response to receiving the signal and before initiating a handover operation;

so that the at least one internet application service is immediately available to the mobile communication terminal at the communication network access device to which the mobile communication terminal is handed over after the handover operation is completed.

2. A method for managing a set of shared integrated access devices, IADs, a set of web surfing communication devices each having a local IAD, a set of internet application services provided to a user by the web surfing communication devices, a set of service level agreements for the user, and a set of handover preparation systems whereby internet application services invoked by a user of a web surfing communication device according to their service level agreements may be limited by the user's handover preparation systems, the method comprising: for at least one pair of shared IAD and web surfing communication devices,

checking a switching signal indicating that the web surfing communication device may perform a switch to a shared IAD or to an internet application service other than the internet application service currently being provided to the user within a given time t1> 0;

in response to detecting the signal and prior to initiating a handover operation, establishing any post-handover web surfing associations that are required; and

upon completion of establishing the desired post-handoff web surfing association, a handoff signal is generated to be used by a given other pair of IAD-web surfing communication devices.

3. The method of claim 2, further comprising: focusing on the following, an auction or tariff negotiation with the user is initiated on behalf of the sharing IAD: at least one of the services provided by the shared IAD, a sales activity for the service provided by the shared IAD, a sales activity for a product, or a sales activity for another service not provided by the shared IAD.

4. The method of claim 2, wherein at least one IAD is a mobile device.

5. The method of claim 2, wherein at least one web surfing communication device is a stationary device.

6. The method of claim 2, wherein the generation of the switching signal for the pair of shared IAD and web surfing communication devices is dependent on at least one of:

the location of the shared IAD is referred to,

the location of the web surfing communication device,

the distance of the shared IAD from a given location,

the distance of the web surfing communication device from a given location

The distance between the shared IAD and the web surfing communication device.

7. A system for managing a set of shared integrated access devices, IADs, a set of web surfing communication devices each having a local IAD, a set of internet application services provided to a user by the web surfing communication devices, a set of service level agreements for the user, and a set of handover preparation systems whereby internet application services invoked by a user of a web surfing communication device according to their service level agreements may be limited by the user's handover preparation systems, the system comprising: for at least one pair of shared IAD and web surfing communication devices,

a module configured to check a switching signal indicating that the web surfing communication device may perform a switch to a shared IAD or to an internet application service other than the internet application service currently being provided to the user within a given time t1> 0;

a module configured to prepare any post-handover web surfing associations required in response to detecting the signal and prior to initiating a handover operation; and

the apparatus further includes means for generating a handoff signal to be used by a given other pair of IAD-web surfing communication devices after completing a post-handoff web surfing association of the provisioning requirement.

8. The system of claim 7, wherein the system further comprises a module configured to initiate an auction or tariff negotiation with the user on behalf of the sharing IAD, focusing on: at least one of the services provided by the shared IAD, a sales activity for the service provided by the shared IAD, a sales activity for a product, or a sales activity for another service not provided by the shared IAD.

9. The system of claim 7, wherein at least one IAD is a mobile device.

10. The system of claim 7, wherein at least one web surfing communication device is a stationary device.

11. The system of claim 7, wherein the generation of the handoff signal for the pair of shared IAD and web surfing communication devices is dependent on at least one of:

the location of the shared IAD is referred to,

the location of the web surfing communication device,

the distance of the shared IAD from a given location,

the distance of the web surfing communication device from a given location

The distance between the shared IAD and the web surfing communication device.

12. A system for preparing at least one internet application service to a user of a web surfing communication device prior to switching the web surfing communication device from one communication web access device to another communication web access device, the system comprising:

a module configured to check a signal indicating that the web surfing communication device may switch to a communication network access device other than a communication network access device currently providing a service to the web surfing communication device within a given time t1> 0;

a module configured to prepare an association of the at least one internet application service with the web surfing communication device at a communication web access device to which the web surfing communication device may be handed over in response to receiving the signal and before initiating a handover operation;

whereby the at least one internet application service is immediately available to the web surfing communication device at the communication network access device to which the web surfing communication device is handed over after the handover operation is completed.

13. The system of claim 12, wherein the communication network access device to which the web surfing communication device switches is a shared Integrated Access Device (IAD).

14. The system of claim 12, wherein the system further comprises: and means for establishing an association of at least one internet application service with the web surfing communication device between a communication web access device to which the web surfing communication device can be handed over and the web surfing communication device in response to receiving the signal.

15. The system of claim 14, wherein the at least one internet application service is defined by at least one service level agreement of a user of the web surfing communication device.

16. The system of claim 13, wherein the system further comprises: a module configured to focus on services provided by a communication network access device to which the web surfing communication network may be switched, initiate auction or tariff negotiating activities with a user of the web surfing communication device, or initiate management of an associated local network access device.

17. The system of claim 13, wherein the services provided by the communication network access device to which the web surfing communication device can switch include sales activities for internet application services or sales activities for products or services that the communication network access device cannot provide.

18. The system of claim 13, wherein the IAD is a mobile web surfing communication device.

19. The system of claim 12, wherein the establishment of the association is performed in connection with a communication related to at least one post-handover quality of service.

20. The system of claim 12, wherein the signal is generated based on a location of the web surfing communication device relative to a communication web access device.

21. The system of claim 12, wherein the system further comprises: and means for generating another signal indicative of a handover of the web surfing communication device after the association is established.