Methods and arrangements for providing efficient information transfer over a limited speed communications link TECHNOLOGICAL FIELD The invention concerns generally the field of transferring information over a limited speed communications link, which typically involves a wireless network connec- tion. Especially the invention aims at providing efficiency to such information transfer. Efficiency is construed to have a manifestation in relatively short delays observed by a user, as well as in the possibility of distributing the transmission re- sources of a communications link among a relatively large number of simultaneous connections.

BACKGROUND OF THE INVENTION At the priority date of this patent application information transfer between com- puters over wired or optically coupled networks has become a vital part of everyday life. A vast majority of such information transfer takes place according to or at least takes some partial advantage of various versions of the TCP/IP (Transmission Con- trol Protocol/Internet Protocol), as is illustrated in fig. 1. In a simple case there are two communicating parties, known as the client 101 and the server 102. The former is the device or arrangement that a user utilizes to download and use information and store it locally, while the latter is a kind of central data storage from which in- formation is to be downloaded. Both the client 101 and the server 102 set up a so- called protocol stack where information is exchanged in the conceptually vertical direction. Layers that are on the same level in the client and the server constitute the so-called peer entities that communicate with each other through all lower layers in the protocol stacks. On top of the pairs of IP layers 103 and TCP layers 104 there may be further higher layers. An example of a protocol layer that is widely used di- rectly above the TCP layer is the HTTP (HyperText Transfer Protocol) that is meant for the transmission of files written in markup languages like HTML (HyperText Markup Language). Other examples of widely used higher protocol layers that in the layer hiearchy are level with HTTP are FTP (File Transfer Protocol), Telnet and SMTP (Simple Mail Transfer Protocol; not shown). The layers that are below the IP layer 103 are not specifically shown in fig. 1 ; the person skilled in the art is well aware of those possible lower layers that are used in various communication solu- tions.

The basic model of two-party communications shown in fig. 1 contains an inherent assumption that the transmission capacity of all stretches of the communication connection is essentially the same. However, in many real life communication con- nections there is a certain passage over which only a limited transmission capacity is available. In this patent application we will refer to such a capacity-restricted pas- sage as the limited speed communications link. The transmission capacity that is available for communications over the limited speed communications link deter- mines the overall maximum bit speed that can be obtained in the communication connection between the endpoints of the connection.

Extending the techniques known from wired information transfer into a connection that includes a wireless link, such as a radio connection between a base station and a portable terminal, introduces new aspects that a user is likely to encounter in the form of lower bit rates and increased delays. These are mainly related to two inter- connected features of the wireless link in comparison with wired or optically cou- pled links : inherently lower reliability (i. e. higher susceptibility to transmission er- rors), which leads to frequent retransmissions, and radio link congestion because a base station can only maintain a limited number of simultaneous connections. These factors together cause the wireless passage often to be the limited speed commun- cations link of a communication connection. In the following we will mainly de- scribe the properties and characteristics of wireless links; the invention has, how- ever, also wider applicability in all kinds of communication connections where a certain passage between two devices limits the overall achievable performance in a connection extending further than just these two devices.

The TCP/IP-based technique of transferring information is not particularly well suited for wireless information transfer. As an example we may consider a typical case of web browsing, where HTTP is used over TCP/IP in a communication con- nection that goes over a wireless link. Factors that cause the wireless link resources to be wasted to a relatively great extent are: - sending the bulk of the contents from web servers (HTML pages) as plain text ; - the multitude of requests: at least in HTTP 1.0 a separate request is issued for every item (e. g. a picture) that exists on a page, so that because TCP in turn estab- lishes a separate connection for every request, there may easily be as many requests as there are items to be downloaded; - the 3-way handshake procedure, i. e. a pair of non-payload messages exchanged between the client and the server, involved in each TCP connection; and - sending the HTML page most often in several packets so that TCP sends an ac- knowledgement for every one of them.

A solution that has become reality around the priority date of this patent application is WAP (Wireless Application Protocol). It is a bandwidth-optimized alternative to protocols that are not, such as the TCP/IP. Optimization involves measures like omitting redundant messages and replacing repeatedly occurring well-known tags with shortened codes. Optimization in this sense aims at the highest possible band- width efficiency, which itself has a definition as the ratio of the information trans- mission rate (the number of information bits transmitted per second) and the band- width in Hertz that is allocated for transmitting said information. Bandwidth effi- ciency measures (not surprisingly) how efficiently the communications system uses the available bandwidth.

The WAP protocol stacks are illustrated in fig. 2, where the actual WAP layers are, from top to down, the application layer 201 (WAE, Wireless Application Environ- ment), the session layer 202 (WSP, Wireless Session Protocol), the transaction layer 203 (WTP, Wireless Transaction Protocol), the security layer 204 (WTLS, Wireless Transport Layer Security Protocol) and the transport layer 205 (WDP, Wireless Datagram Protocol). In place of the WDP layer an UDP (User Datagram Protocol) layer must be used for IP bearers. Beneath the transport layer 205 there are further lower layers like IP 206 and physical layers 207; together these are also commonly referred to as the bearer layers.

WAP was developed to enable access to networked information from devices that have the typical features of wireless terminals, i. e. limited CPU (Central Processing Unit) capacity, limited memory size, battery-powered operation and simple user in- terface. The commercial applications of WAP that exist at the priority date of this patent application are the so-called WAP phones that combine the features of a mo- bile telephone with certain limited functionality of a web browser. In practice we have seen that the small number of WAP users compared to that of wired Internet users is a major drawback that reduces the commercial interest in setting up WAP services, especially at the advent of third generation digital cellular networks.

Moreover, already due to the introduction of the first phase of packet-switched cel- lular data networks using GPRS (General Packet Radio Service) the need of wire- less access for full-fledged mobile clients is expected to grow considerably. WAP is not suitable for providing that, so there have been devised various proprietary solu- tions for wireless data transfer.

As an example of the last-mentioned Fig. 3 illustrates the so-called MOWGLI con- cept (Mobile Office Workstations using GSM Links) where a mobile workstation 301 utilises a wireless link between a GSM (Global System for Mobile telecommu- nications) cellular phone 302 and a GSM base station 303 to communicate with what is called a mobile-connection host 304. In the mobile workstation 301 old ap- plications 311 and 312 communicate with agent programs 313,314 and 315 through an application programming interface known as the Mowgli Socket API 316. From the agents there is a connection to a Mowgli Data Channel Service API 317 and the associated Mowgli Data Channel Service 318 either directly or through a Mowgli Data Transfer Service API 319 and the associated Mowgli Data Transfer Service 320. New mobile applications 321 may have been designed to communicate directly (through the appropriate API) with either the Mowgli Data Transfer Service 320 or the Mowgli Data Channel Service 318. A control tool 322 is included for control- ling the operation of the other program components. A wireless interface block 323 constitutes the connection from the mobile workstation 301 to the cellular phone 302.

In the mobile-connection host 304 there are counterparts for certain entities imple- mented in the mobile workstation 301: a wireless interface block 331, a Mowgli Data Channel Service 332 with its associated API 333 as well as a Mowgli Data Transfer Service 334 with its associated API 335. A number of proxies 336,337, 338 and 339 may act in the mobile-connection host 304 as counterparts to the agent programs 313, 314 and 315 in the mobile workstation 301. An arrangement of a socket API 341, a TCP/UDP layer 342 and an IP or mobile IP layer 343 constitute, together with a network interface 344, a connection from the mobile-connection host 304 further to a LAN 345 or a similar network. Under the IP or mobile IP layer 343 there may also be a virtual network interface 346.

The division of the MOWGLI architecture into Agent/Proxy-, Data Transfer-and Data Transport layers is shown with heavy dotted lines in fig. 3. Of the protocols used therein, between an agent and a proxy (like the master agent 314 at the mobile workstation 301 and the master proxy 338 at the mobile-connection host 304) there is a Mowgli Socket protocol, between the mutually corresponding MDTS entities 320 and 334 there is a Mowgli Data Transfer protocol and between the mutually corresponding MDCS entities 318 and 332 there is a Mowgli Data Channel proto- col.

SUMMARY OF THE INVENTION As a consequence of the existence of a multitude of protocols described above, the problem of providing efficient and widely usable information transfer over a wire- less network connection remains unsolved at the priority date of this patent applica- tion. It is therefore an object of the invention to provide a method and an arrange- ment for providing efficient and widely usable information transfer over a wireless network connection. It is also an object of the invention to provide a method and an arrangement for enhancing the level of service that a human user of a wireless net- work connection experiences. It is a further object of the invention to provide ex- tendability to a wireless network link so that minimal software and hardware addi- tions would be needed to widen the selection of transmission protocols that can be used for wireless network access.

The objects of the invention are achieved by setting up a pair of functional entities that comprise protocol converters and additional modules. These functional entities are placed at each end of a wireless communication connection. They make a trans- parent conversion to a bandwidth-optimized wireless protocol for information to be transmitted wirelessly and a corresponding reverse conversion for information that has been received wirelessly.

The invention applies to a method the characteristic features of which are recited in the characterising portion of the independent patent claim directed to a method. The invention applies also to an arrangement the characteristic features of which are re- cited in the characterising portion of the independent patent claim directed to an ar- rangement. The characteristic features of other aspects of the invention are recited in the characterising portions of the respective independent patent claims.

The present invention has its roots in the contradictory situation where those proto- cols that have been most widely used for transferring data over network connections are not bandwidth-optimized while some other protocols that are were only devel- oped for a narrow application area or have not gained too much popularity. In a method and arrangement according to the invention there is a bandwidth-optimized link portion located at that point of a wireless network connection that covers the radio interface. Both the user's application at the client end of the connection and the server application may be designed for a different protocol, and indeed they may remain completely unaware about the fact that a different (bandwidth-optimized) protocol is used for a part of the network connection. A protocol converter at the client end and another at the network end of the bandwidth-optimized link portion perform the necessary protocol conversions to and from the bandwidth-optimized protocol. The protocol for which the user's application and the server application have been designed is typically some widely used network communication protocol.

At the priority date of this patent application such widely used network communia- tion protocol is typically TCP/IP, while the bandwidth-optimized protocol is typi- cally WAP.

Various advantageous features can be used in the additional modules to enhance the efficiency of the arrangement from that of a simple protocol conversion. Most ad- vantageously the client proxy, which is the device and/or process that is responsible for the connection and protocol conversions at the client side, has a cache memory where it stores a copy of data that has been requested and downloaded from the server side. If the same data is then needed again, it suffices to check whether there have been any changes to it since it was last downloaded. No changes means that a new downloading operation over the radio interface is completely avoided. Even if there have been changes it suffices to download only the changed data instead of the whole contents of a requested data entity. The client proxy may even have a back- ground connection to the server side over which changes and updates to recently downloaded and cached data are transmitted automatically in preparation for the po- tentially occurring need for an updated version at the client side.

A further development to the idea of simple caching is predictive caching, which means that the client proxy follows either certain regularities in the behaviour of the user or certain preprogrammed instructions (or both) and proactively downloads data that the user is likely to need during a certain time period to come. Similarly as in the difference caching referred to above, the predictive caching arrangement may have a background connection to the server side so that while the user is doing something else, the client proxy may prepare for the predicted need of certain data by downloading it from the network. Predictive caching is easily combined with dif- ference caching so that in preparation for the potential need of certain predictively downloaded data the client proxy receives changes and updates to said data accord- ing to certain updating rules.

An effective way of achieving efficiency is to enable the functional entities at the ends of the wireless communication connection to multiplex separate logical con- nections into one connection. The multiplexed logical connections may include representatives from both those established by the mobile client software and those related to the above-described caching processes.

BRIEF DESCRIPTION OF DRAWINGS The novel features which are considered as characteristic of the invention are set forth in particular in the appended claims. The invention itself, however, both as to its construction and its method of operation, together with additional objects and advantages thereof, will be best understood from the following description of spe- cific embodiments when read in connection with the accompanying drawings.

Fig. 1 illustrates the known use of TCP/IP in a client/server connection, Fig. 2 illustrates the known use of WAP in a wireless network connection, Fig. 3 illustrates the known Mowgli architecture, Fig. 4 illustrates the principle of transparent intermediate protocol conversion, Fig. 5 illustrates an advantageous architecture for the client proxy, Fig. 6 illustrates an advantageous modular structure for the application layer of a client proxy, Fig. 7 illustrates the handling of a request at the client proxy according to an embodiment of the invention, Fig. 8 illustrates the multiplexing of connections in a schematic state machine, Fig. 9 illustrates an advantageous modular structure for the application layer of an access gateway and Fig. 10 illustrates the handling of a request at the access gateway according to an embodiment of the invention.

Figs. 1,2 and 3 were described above within the description of prior art, so the fol- lowing description of the invention and its advantageous embodiments will focus on figs. 4 to 10.

DETAILED DESCRIPTION OF THE INVENTION The exemplary embodiments of the invention presented in this patent application are not to be interpreted to pose limitations to the applicability of the appended claims. The verb"to comprise"is used in this patent application as an open limita- tion that does not exclude the existence of also unrecited features. The features re- cited in depending claims are mutually freely combinable unless otherwise explic- itly stated.

Fig. 4 illustrates the principle of a method and an arrangement where a first com- municating party 401, designated here as the client side, has a wireless network connection to a second communicating party 402, which is here designated as the server side. It should be easy to appreciate the fact that the designations"client"and "server"are used for the sake of example only and do not limit the applicability of the invention regarding communication connections between different kinds of de- vices. Especially both the client side and the server side may comprise any number of mutually coupled individual devices.

At the client side there is an application 411 that has been designed to use a first communications protocol stack, which is shown as 412. A characteristic feature of the first communications protocol stack is that it is not bandwidth-optimized and therefore not optimal for communications over a wireless link. For this reason there is at the client side a client-side proxy 413 where the first communications protocol stack 414 is linked, at a certain relatively high level, to a second communications protocol stack 415. Contrary to the first communications protocol stack the second communications protocol stack is bandwidth-optimized. The link between the stacks 414 and 415 constitutes another application layer 416 that should not be con- fused with the application 411 that is the actual user of information transferred over the network connection. Note that the invention does not place limitations to the number of physically separate devices that are used to set up the client side: it is possible to run the application 411 and the client-side proxy 413 in one and only device, while it is just as possible to have at least two physically separate devices to implement these functions.

On the server side 402 there is an access gateway 421 where the part that faces the client side 401 comprises a peer entity stack 422 for the second communications protocol stack 415 at the client side. On top of said peer entity stack 422 there is a server side applications layer 423 from which there are couplings further into one or more fixed networks. As an example there is shown in fig. 4 a pair of protocol stacks 424 and 425 as well as a network application 426 that complete the server side as a mirror image of the client side: the stacks 424 and 425 conform to the first communications protocol introduced above. If the application 411 at the client side would be running in an ordinary terminal of a wired network, it would use directly and exclusively the first communications protocol stack to communicate with the network application 426. We will describe later certain alternative forms of further couplings from the server side applications layer 423.

In order to take full advantage of the invention, the client-side proxy 413 and the access gateway 421 should not be just unintelligent protocol converters. According to the invention the application layers 416 and 423 contain a set of modules, which can greatly improve the efficiency of information transfer.

Fig. 5 is a more detailed exemplary embodiment of the principle shown above in fig. 4. Here the client side 401 consists of a client application 501 and a client proxy 511, and the server side 402 consists of an access gateway 551 and a WWW-server 571. In the embodiment of fig. 5 the first and second communications protocol stacks have been selected according to high prevalence in use at the priority date of this patent application: the first communications protocol stack is a combination of HTTP over TCP/IP, and the second communications protocol stack is WAP. Con- sequently the client application 501 has, from top to down, an application layer 502, an HTTP layer 503, a TCP layer 504 and an IP layer 505. At the top in the layer hi- erarchy of the client proxy 511 there is an application layer 512. Under it there are, from top to down on the side facing the client application, the HTTP 513, TCP 514 and IP 515 layers that constitute the peer entities for the similarly named layers in the protocol stack of the client application 501. In order to facilitate the establishing and maintaining of a physical communication connection between the client appli- cation 501 and the client proxy 511 there may be further lower layers below the pair of IP layers 505 and 515.

Under the client proxy's application layer 512 on the other side there are, from top to down, the WSP 521, WTP 522, WTLS 523, UDP 524 and IP 525 layers. Under the IP layer 525 there are further lower (radio link) layers 526 that have been dedi- cated to the physical implementation of a wireless network connection.

At the top in the layer hierarchy of the access gateway 551 there is another applica- tion layer 552. Under it on the side facing the client proxy there are, from top to down, the WSP 553, WTP 554, WTLS 555, UDP 556 and IP 557 layers as well as the schematically shown further lower layers'entity 558. These are easily recog- nized as the peer entities of the similarly named layers at the client proxy 511. On the other side under the access gateway's application layer 552 there are, from top to down, the HTTP 559, TCP 560 and IP 561 layers. The protocol stack of the network server 571 has once again an application layer 572 and under it the HTTP 573, TCP 574 and IP 575 layers that constitute the peer entities for the similarly named layers at the access gateway 551. In order to facilitate the establishing and maintaining of a physical communication connection between the access gateway 551 and the net- work server 571 there may be further lower layers below the pair of IP layers 561 and 575.

One of the tasks of the client proxy 511 is to make it completely transparent to the client application 501 that the network connection comprises a stretch where a completely different communications protocol stack is used. This has the advanta- geous consequence that the client application 501 can be of an off-the-shelf type known already at the priority date of this patent application. Thus the wide selection of already available client-side application programs can be used without making changes. When one"looks"at the client proxy 511 from the viewpoint of the client application 501, the client proxy 511 appears to function exactly like a network server. Next we will analyse an advantageous implementation architecture for the client proxy that aims at fulfilling this task.

STRUCTURE AND OPERATION OF THE CLIENT PROXY Fig. 6 illustrates a schematical structure of an advantageous embodiment of the ap- plication layer 512 at the client proxy 511 of fig. 5. The left-hand side of fig. 6 illus- trates the coupling (s) to the highest layer (s) of the first communications protocol stack: HTTP 601 and FTP 602 are examples. On the right-hand side there is the coupling to the second communications protocol stack, schematically shown as the WAP stack 603. Note that depending on the first communications protocol stack the coupling to the right from the application layer 512 does not need to concern only the highest WAP layer, i. e. the WSP layer. For example, if the left-hand coupling is with FTP the right-hand coupling can take place directly with the WTP layer, while a left-hand coupling with an HTTP client necessitates a right-hand coupling with the WSP layer.

The central functional module 604 in fig. 6 is called the CH or Connection Handler.

It has a bidirectional coupling with at least one PH (Protocol Handler); PHs 605 to 609 are shown in fig. 6. The CH 604 has also bidirectional couplings with a CCH (Content Cache Handler) 610. The tasks of the CH 604 can be summarized as fol- lows: - it receives requests from the client application through the first communications protocol stack, - it recognizes the protocol that application 411 uses, - it decides, whether the received requests can be satisfied by just reading previ- ously stored data from the CCH 610 or whether a request must be forwarded over the wireless network connection to the access gateway, - it calls, according to the recognized protocol, appropriate PHs 605-609 when nec- essary, and - it controls the setting up, maintaining and tearing down of connections to the ac- cess gateway.

The CCH 610 is a local cache memory the primary task of which is to locally store certain information that according to a certain algorithm is likely to be requested by client applications. A simple strategy is to store previously requested information so that there is a maximum amount of memory allocated for caching : after the allo- cated memory becomes full, the content of the cache is discarded according to the chosen cache replacement policy. More elaborate strategies will be described in more details later.

Each PH 605-609 is associated with a client application protocol of its own. A PH contains protocol-specific instructions about how should a request associated with the appropriate client application protocol be processed before forwarding it over to the second communications protocol stack (the WAP stack 603 in the example of fig. 6). The PH is also equipped to perform the corresponding actions as well as similar procedures that are to be applied to responses received from the WAP stack). Examples of above said actions are the following: - binary encoding of uplink commands, headers and all other standard elements for all text based protocols, except when such binary encoding is already a part of the appropriate client application protocol or second communications protocol, and cor- responding decoding for downlink data - binary encoding of uplink tags of markup languages like HTML or XML (ex- tended markup language), except when such binary encoding is already a part of the appropriate client application protocol or second communications protocol, and cor- responding decoding for downlink data, and - compression (for uplink) and decompression (for downlink) with appropriate algo- rithms for all kinds of payload information.

All PHs have couplings to the MU (Multiplexing Unit) 611, which has two main tasks: - multiplexing and demultiplexing of logical connections so that the number of separate connections to the access gateway is minimized, and - uplink connections prioritizing according to priorities set by the CH.

Fig. 7 illustrates the exchange of calls and messages within and between the entities shown in fig. 6 in an exemplary case where a client application requests information that is to be downloaded from the network. At step 701 there comes a request from a client application through a first protocol stack. At step 702 the CH receives the request and analyzes it in order to at least recognize, through which one of the pos- sibly several parallel first protocols it came.

At step 703 the CH sends an inquiry to the CCH in the hope that the requested in- formation would already exist there as a previously stored copy. In fig. 7 we assume that this is not the case, so the CCH responds at step 704 with a negative. Thereafter the CH uses its knowledge about the first protocol that was recognized at step 702 and calls the appropriate PH at step 705. The called PH processes the request at step 706 by performing operations, examples of which were given above, and forwards the request to the MU at step 707.

At step 708 the MU checks the priority of the request (priorities are assigned to every request by the CH). The MU communicates the processed request to the ap- propriate level in the second protocol stack at step 709.

Note that the processed request does not always go to the top layer of the second protocol stack: for example if the request came from the client application through HTTP, WSP must be used while an FTP request from the client application allows the WTP layer to be contacted directly.

Step 710 represents generally the phase in which the communication is carried out with the access gateway through the second protocol stack. At step 711 there arrives a response from the access gateway to the MU. The response must be subjected to reverse processing in the same PH that processed the request at step 706, so the MU decides at step 712 to which particular PH the response should be passed, and passes the request to that PH at step 713. At step 714 the response is processed by the PH, and at step 715 it arrives to the CH in a form that is ready to be passed on to the client application through the first communications protocol stack. We assume that the CH wants the information contained in the response to be stored into the CCH, so at step 716 the CH commands the CCH to store the response information.

There may be an acknowledgement from the CCH at step 717. At step 718 the same information is forwarded towards the client application.

One efficient way for reducing overheads and performing bandwidth-optimization is the multiplexing of connections at the MU. Multiplexing concerns both requests from client applications and client proxy's internally originated requests, e. g. that for"active"caching. Fig. 8 is a state diagram that illustrates the aspects of connec- tion multiplexing. When there are no active communications connections to the ac- cess gateway, the MU is in state 801. A request causes a transition to state 802, where the MU sets up a connection to the access gateway. Successfully setting up the connection is followed by an immediate transition to state 803, where the con- nection is maintained. If, during the period when the connection to the access gate- way is active, there comes another request for another connection, a transition to state 804 occurs where the newly requested connection is added to a multiplexing scheme that the MU uses to multiplex all separately requested first protocol connec- tions to a single second protocol connection. After the addition step 804 the MU re- turns to the steady state connection maintaining step 803. Similarly if during the pe- riod when the connection to the access gateway is active some first protocol connec- tion is not needed any more, there occurs a transition to state 805 where the ending connection is removed from the multiplexing scheme, with immediate return to state 803. Only when even the last remaining first protocol connection is found to be ending there occurs a transition to state 806 where the connection to the access gateway is ended. A natural consequence of such ending is a return to the com- pletely idle state 801.

STRUCTURE AND OPERATION OF THE ACCESS GATEWAY The most important part of the access gateway regarding operation according to the invention is the application layer 552 seen in fig. 5. The other parts of the access gateway are basically just means for implementing protocol stacks that are known as such. Fig. 9 is a schematic block diagram of an access gateway's application layer 552. On the left in fig. 9 there is the coupling to the bandwidth-optimized commu- nications protocol stack, meaning here the WAP stack 901. A central part of the ap- plication layer 552 is again a CH (Communications Handler) 902, from which there are couplings to the representatives of other communications protocols on the right: the HTTP and FTP examples 903 and 904 have been already discussed previously.

As another alternative there is a coupling from the CH 902 to a WAP Applications Environment 905. We will describe later the meaning and importance of this alter- native. We may refer generally to the protocols on the right in fig. 9 as the network protocols, because they are used for communications into the direction of various (fixed) networks.

Similarly as in the application layer of the client proxy, there are an MU and various PHs (Protocol Handlers) that are specific to those network protocols through which the CH 902 wishes to be able to communicate. PHs 911 to 915 and the MU 931 are shown in fig. 9. Also the CCH concept is used in the access gateway, but instead of a single CCH there are multiple CCHs, four of which are shown as examples in fig.

9 as 921-924. The reasoning behind using several parallel CCHs is that there may be a separate CCH for each individual client proxy that has registered itself at a cer- tain access gateway, or group-specific CCHs each of which corresponds to a group of registered client proxies. The invention does not require several CCHs to be used at the access gateway, but having individual CCHs makes it easier to implement the (background) routines that aim at keeping the client proxies'CCHs up to date dur- ing active caching. Moreover, the difference between individual CCHs may be purely logical (they can all be stored in one physical database).

The application layer also contains a DNSP (Domain Name Server Proxy) 930, which is a local database that is used to map domain names to network addresses.

Its purpose is to improve efficiency by avoiding requests to a remote DNS, in case when locally available information is sufficient for name resolving.

Fig. 10, which consists of figs. 10a and 10b together, illustrates the handling of an exemplary request 1001 that an access gateway receives from a client proxy through the second protocol (WAP) stack. At step 1002 the MU recognizes the request pro- tocol and calls a corresponding PH at step 1004 to process the request, i. e. to re- verse the processing that was made at a PH of the client proxy that is the originator of the request. The result of the processing 1005 at the PH is a processed request that is forwarded to the CH at step 1006.

Note that the MU is able of receiving requests not only from the top layer of the second protocol stack, but from inner layers, as well. For example, an FTP request from the client application will be passed to the MU immediately from WTP layer, but not via WSP layer. It should also be noted, that the MU is capable of recogniz- ing"true"WAP requests. They are forwarded directly to the CH (shown by dashed line as step 1003).

At step 1007 the CH recognizes the processed request and the protocol that is to be used to forward it to a content provider's server. The CH also monitors the priority of every particular request and performs actions, which guarantee that the priority of the corresponding response is the same, as for the request.

It would be most expedient if the requested contents could be read locally from a CCH instead of forwarding the request to any other server through a network, so at step 1008 the CH sends an inquiry to the appropriate CCH. Here we assume that the CCH did not have the requested contents in store, as is illustrated by the negative response at step 1009. If the request contains a domain name or network location that necessitates a call to the local DNSP of the access gateway, this is made at step 1010 with the response of the DNSP shown as 1011.

At step 1012 the CH transmits the processed request to the selected protocol (HTTP, FTP,...). Above said"true"WAP requests are directly forwarded to the WAE level without any further processing.

Step 1013 represents generally the actual communication with the content provider's server. A response is received through the first protocol (HTTP/TCP) stack at step 1014. At step 1015 the CH identifies, what request caused the received response, and assigns the response priority according to that of request.

In order to be able to send the response to the client proxy through the second pro- tocol (WAP) stack, the CH must call again the appropriate PH at step 1016. The se- lected PH processes the response at step 1017 and forwards it to the MU at step 1018.

At step 1019 the MU performs actions needed for prioritizing of connections, and then communicates the processed response to the appropriate level in the second protocol stack at step 1020. So the response is finally transmitted to the client proxy through the wireless communication connection. At step 1021 the CH commands the appropriate CCH to store the received contents according to the principle of caching, and at step 1022 the CH receives the acknowledgement.

It should be noted that the access gateway has by default a fixed high-capacity con- nection to at least one communications network, so exchanging information be- tween it and content sources at various locations throughout the world is much eas- ier and simpler and much less limited by bandwidth restrictions than transferring in- formation over the wireless link to the client proxy. Also memory space is less scarce a resource at the access gateway than at the client proxy. This underlines the significance of active caching at the access gateway. After the strategy has been chosen that is to be adhered to in active caching, the access gateway follows the changes of content in the selected content sources that are subject to active caching and updates regularly the client proxy specific (or client proxy group specific) cache databases. Keeping the latters at the access gateway as up to date as possible gives maximal freedom for choosing the time and way in which low-priority (back- ground) connections over the wireless link are established for updating correspond- ing cache databases at the client proxies.

PRIORITIZING CONNECTIONS Above it was explained how one of the advantageous functions of the client proxy is the multiplexing of several simultaneously active client application connections to a single wireless connection. As a first assumption each client application con- nection has equal priority regarding the multiplexing procedure, which means that every connection gets an equal share of the communications resources that the wire- less connection represents. However, it may be advantageous to define, and store in association with the CH, various levels of priority so that as a part of the multiplex- ing procedure the CH evaluates the urgency of each client application request; so that a larger proportional portion of the available communications resources will be allocated to those connections, that serve the most urgent requests.

Handling the background processes that serve active caching is typically an ultimate example of prioritizing. The active caching requests from the CCH have so low pri- ority that if there are any other requests that necessitate downloading information over the wireless connection, these are served first before any capacity is allocated to active caching.

The selection of priorities may follow a predetermined and fixed strategy that take into account e. g. the real-time nature of certain requests and the non-real-time na- ture of others. It is also possible to let a user set the priorities himself so that she can determine, what kind of connections should be served first.

CACHING STRATEGIES Next we will analyze certain ways of achieving savings in the number of time- critical requests that must be forwarded from the CH to the wireless network con- nection. A time-critical request is, in a wide sense, a request for such information the most prompt arrival of which would be appreciated by the requesting client ap- plication. For example if a human user wants to examine a web page on a display, the faster the correct page appears the better. This wide sense of time-criticality covers also narrow interpretations according to which only requests concerning real time data are time-critical. Achieving said savings means that a certain number of time-critical requests may be satisfied by reading information locally from the CCH.

It might be assumed that a substantial number of users of network connections have a rather limited selection of frequented network locations. Additionally we may as- sume that the content that can be downloaded from these"favourite"locations changes only gradually. The"enhanced"caching strategy that is proposed to be used by the CCH comprises three main aspects: difference-, active-and predictive caching. In the structure of the access gateway it was mentioned that the access gateway maintains personalised caches of each registered client: any of said aspects as well as any combinations of them can be applied in maintaining such caches.

Similarly any of said aspects as well as any combinations of them can be applied in maintaining a cache at the client proxy, or even a number of user-specific caches at the client proxy if there are multiple users using the same client proxy.

Difference caching means that the whole changed contents of a network location subject to caching are not reloaded from the network but only those parts of it where changes have occurred. Difference caching is mainly applicable in maintaining the cache (s) at the client proxy. The cache (s) at the access gateway downloads contents from the network in the way defined by the network server; at the priority date of this patent application it is not regarded as possible to ask for only a difference be- tween a newest version and the one that the requester already has. However, accord- ing to the invention it is possible to influence the transfer between the access gate- way and the client proxy, so it is feasible to perform difference caching by compar- ing both caches and sending only the difference between the version cached in the client proxy and the version cached in the access gateway. If needed, the latter will be (re) loaded to the access gateway from a content server prior to perfoming the comparison.

Active caching means that the CCH makes requests for downloading information from the access gateway without any client application directly requiring the infor- mation. An example of use of active caching can be a situation where the user specifies in the client proxy that he wants the latest version of a certain network re- source to be always available on the client device at once.

Predictive caching differs from active caching in that the CCH additionally tries to predict at least a part of the network locations from which contents should be downloaded and forwarded to client applications in the near future. Predicting may be based on a variety of factors, such as observed frequency of use (the contents of a certain network location have been requested at least N times, where N is a posi- tive integer), observed regularity in use (the contents of a certain network location have been requested at certain regularly repeated times), observed focus of interest (the relative portion of requests that concern contents of a certain type is large) and observed following of trends (the requests follow generally documented popularity statistics; the user wants to always check the entries on a latest"best of the web" list). The CCH implements predictive caching by either just storing the latest re- quested copy of the contents which it assumes to be requested again, or by regularly updating the predictively cached contents so that if and when a new request comes regarding a certain network location, the version that can be read directly from the CCH is never older than the length of the updating interval. Regular updating is most advantageously used when the predictions are based on observed regularity in use, so that the contents stored in the CCH are updated when the next occurrence of the observed regular use is approaching.

Generally caching could also be divided into two basic types: push and pull. In the present invention push type caching is a procedure where the CCH has subscribed as an active caching client of the access gateway regarding certain network loca- tions, and every time when the access gateway becomes aware of a change of con- tents in one of these locations it automatically forwards the changed information to the client proxy's CCH. Pull type caching means that the CCH must always ask for the changed information. Pull type can be further classified into"regular"or"ac- cording to need", where the former becomes actually predictive caching because the CCH asks for the changed information even if no client application has recently re- quested it. Pull type caching according to need means that when a request comes from a client application, the CCH asks for the latest changed information from the access gateway so that the latest changes are combined with the unchanged infor- mation read from the CCH itself.

It is common to all active-and predictive caching requests that these are most advantageously performed as background processes so that the user does not need to know that they are taking place. Similarly they are most advantageously performed at times when ample bandwidth is available, e. g. during the night or when the communications capabilities of the client side are not currently used for something else like an ongoing telephone call.

The mobility of the client side also suggests that active-and predictive caching should take into account the current location of the user: e. g. when the user is at a location where a local high-speed network connection is available, cache can be up- dated. Another example is when a user is entering a cell that covers a shopping mall; in this case information regarding the products and services available in the mall could be predictively stored into the CCH.

Enhanced caching also implies that means are available for optimizing said caching strategies, in terms of e. g. communication connection cost or communication traffic volume. It is considered to be within the capability of a person skilled in the art to present methods of optimization once the prerequisites like taxing policies are known.

Caching may also follow a number of strategies regarding the grouping of clients and client proxies, or even individual users, to their respective caches. The most elaborate grouping alternative is to have a personalized cache and its corresponding caching strategy for each individual, identified user so that even if a number of us- ers appear to use the same client proxy, they all have their personalized"cache ac- counts"at the access gateway. A slightly less complicated approach delegates the task of user-specific caching to the client proxy (which then in turn must have sev- eral logically separate cache memories instead of the single one referred to above) so that the access gateway only keeps a logically separate cache for each client proxy. Moving towards even simpler implementations, there comes the grouping of client proxies so that the access gateway does not perform logically separate cach- ing for individual client proxies but only for client proxy groups. The simplest, triv- ial grouping alternative is the limiting case of the last-mentioned where all client proxies constitute a single group.

In all grouping alternatives except the simplest (trivial) one the search for certain requested contents may follow an expansive pattern: for example if user-specific caches have been defined but the cache reserved for a certain user does not contain the requested contents, the caches reserved for other users of the same client proxy are searched next, taking user access rights into account. If still no match is found, the search proceeds to the caches of other client groups and so on. The expansive searching strategy can be used in a smaller scale in the cache of the client proxy, if user-specific caches have been defined therein.

COUPLING OTHER KINDS OF (WAP) WIRELESS CLIENTS TO THE SAME ACCESS GATEWAY In the description above we have assumed that the client side that is to communicate with an access gateway has the overall structure shown in figs. 4 and 5, i. e. that there is a client side application that is designed for a non-bandwidth-optimized pro- tocol stack and necessitates a protocol conversion according to the invention. How- ever, it should be noted that the invention has an inherent advantage regarding ser- vice that can be given also to other kinds of clients. At the priority date of the inven- tion there are numerous users of WAP phones and other WAP-based portable ter- minals: because the access gateway uses WAP as the protocol that constitutes the interface towards wireless terminals, it is actually irrelevant whether the client is of the type shown in figs. 4 and 5 or just a conventional"true"WAP client.

Extending the service of the access gateway to true WAP clients is the reason for having a direct coupling from the CH 902 to a WAE entity 905. If the request from the client side turns out to relate to true WAP functionality, the CH 902 just for- wards it to the WAE entity 905 that takes care of the rest of the processing accord- ing to the known and documented practices of WAP.

Another feature of multi-service readiness is related to the fact that in the previous description we left it completely open what constitutes the lower layers 526 and 558 of fig. 5. Depending on the wireless bearer technology that is to be used (e. g. GPRS, HSCSD or CSD) there may be different lower layer entities below the transport layer (the IP layer 525,557) that can all be used by the same upper layers (without any changes in them) through appropriate inter-layer connections.

RATE ADAPTATION AND PORTAL FUNCTIONALITY AT OR WITHIN REACH OF THE ACCESS GATEWAY The access gateway is well aware of the fact that the requested contents will be transmitted to the client proxies over a bandwidth-restricted wireless link. Therefore it may implement various processing methods on the requested contents before transmitting them towards the client proxies. Above we have already referred to mainly protocol-specific measures like binary coding of headers. Additionally the access gateway may perform content-dependent processing such as deliberately sac- rificing picture or sound quality by reducing the amount of picture or sound data, stripping bandwidth-intensive elements such as pictures or animations from the transmitted contents altogether, or removing redundancy if a higher level of trans- mission errors is accepted. These measures may be taken automatically or user- specifically only at an explicit consent of each user. Such processing may also be made dependent on predicted and/or measured link quality: when the current link data rate is high, the contents would be transmitted more or less in their original form, otherwise various degrees of stripping and/or compressing should be used.

Preparing or optimizing certain contents according to the capabilities of a user end device and/or according to link characteristics is often referred to as portal function- ality. The access gateway may have this functionality as its own feature for example in one or several PHs, or it may communicate with a certain specific external portal device that is capable of producing optimized content pages. Requests from the ac- cess gateway to such an external portal device should indicate the requested amount and type of portal functionality, for example by citing the current wireless link data rate, referring to maximal or optimal content page sizes, or announcing the type of client side device that is to use the requested content page.

If the access gateway has obtained an identification of a user that is behind a certain request, it may apply portal functionality according to certain selections that the user has explicitly made previously. The access gateway may also automatically adapt its portal functionality according to certain identified user activity or user profile, so that changes are done into the content which is transmitted over the lim- ited speed communications link.

FURTHER CONSIDERATIONS Because of the typically wireless nature of the limited speed communications link, the client proxy can never be sure beforehand without trying, whether the commu- nications connection to the acees gateway is functioning properly or not. In addition to link failures there is also the uncertainty factor of the access gateway or a certain content-providing server possibly being temporarily in a state where it is simply not responding. The client proxy may be arranged to send occasional queries to the ac- cess gateway just to make sure that an active communication connection can be set up quickly if there comes a request that necessitated downloading of information from the access gateway.

The priorization of connections over the limited speed communications link may be made dependent on certain telltale observations made at the client side. For exam- ple, if a browser program that a user uses to utilize network connections is run in a window, and this window is closed or reduced in size or otherwise found to be inac- tive, priorities of all connections that relate to that particular browser can automati- cally be lowered. Correspondingly observed increase in user activity (e. g. a reduced window being expanded again) may automatically cause priorities to be raised in order to prepare for potentially coming urgent requests.

The bandwidth-optimized protocol stack may be used for encrypting, authentication and/or similar add-on functions that add value to a communications connection. The invention allows encryption and/or authentication to be used between a variety of devices: encryption between the client proxy and the access gateway in either or both directions, encryption between the client proxy and a network server in either or both directions, encryption between the access gateway and a network server in either or both directions, authenticating the client proxy to the access gateway and/or vice versa, authenticating the client proxy to a network server and/or vice versa, authenticating the access gateway to a network server and/or vice versa.

In a situation where a client proxy has the possibility of communicating with several access gateways simultaneously, the selection of the access gateway that would most probably offer the service that matches best the needs of the user of the client proxy is possible; either manually by the user before establishing a network connec- tion, or automatically by the client proxy during the process of establishing a con- nection. In establishing a network connection the client proxy may query for the ad- dress of the access gateway to be used either from the user or from a predetermined source within the network.

It may also happen that there are no access gateways available at all. Since a user would most probably appreciate even a slow wireless connection more than no wireless connection at all, the client side may go into a"non-AG"mode where the requests from client applications according to the first, non-bandwidth-optimized protocol stack are passed transparently on over the wireless connection to a the server application and responses are received from said server application as well according to the non-bandwidth-optimized protocol stack and passed on transpar- ently to the appropriate client applications; in both actions the access gateway is by- passed. During the"non-AG"mode the client proxy should be regularly polling for active, available access gateways so that once one becomes available, bandwidth- optimized operation is resumed.