GB2427331A

GB2427331A - Re-establishing connection between a mobile radio communications device and a socket of a SIM card web server

Info

Publication number: GB2427331A
Application number: GB0512199A
Authority: GB
Inventors: Hubert Helaine; Fabrice Zappula
Original assignee: NEC Technologies UK Ltd
Current assignee: NEC Technologies UK Ltd
Priority date: 2005-06-15
Filing date: 2005-06-15
Publication date: 2006-12-20
Anticipated expiration: 2025-06-15
Also published as: GB2427331B; GB0512199D0

Abstract

The present invention provides for a method of re-establishing connection between a mobile radio communications device and a socket of a server card provided therein and subsequent to disconnection between the device and the server card, such that the mobile radio communications device manages creation of the said socket for the server card and on behalf of the said server card and for use in re-establishing the said connection. Thus there is no need to close and re-open the BIP channel to the server, so avoiding delays. The handset automatically accepts a new socket each time the current server socket is closed without experiencing delays.

Description

Connect ivity Method Within A Mobile Radio Communications Device And

Related Mobile Radio Communications Device Arranged To Employ Such A Method The increased functionality offered by a mobile radio communications device such as a cellular phone handset has arisen, at least in part, from technical developments relating to the various circuit elements of the handset, the operating and application software and also from improvements relating to network operation and characteristics.

One recent development has focused upon the Subscriber Identification Module (SIM) card employed within a mobile phone handset and, in particular, relates to the adoption of internet-related technology within a SIM card device. One such advancement relates to the provision of a web server running in the S[M card and which allows for the provision of SIMbased services whilst taking advantage of the multimedia capability already present in the handset and relating, for example, to data display and/or information processing. That is, the provision of such a smartcard web server allows for internet-related design characteristics to be incorporated into SIM card applications and this can lead to advantages such as enhanced and unified Graphical User Interface (GUI) for SIM-based services, the storage of static pages such as a browser's homepage and also the use of dynamic web pages. Such pages can prove attractive to network operators as a means for increasing on-line revenue.

Further, control of a SlIM-based services menu can readily be profiled so as to match the end-user's preferences and common requirements.

Connectivity within the handset to the smartcard web server is achieved by way of a Bearer Independent Protocol (BIP) channel and so use of such a BIP server allows support within the handset of the local smartcard web server which is then readily accessible by the handset browser.

However, limitations have been identified in relation to the support of such a BlIP-related server insofar as Hypertext Transfer Protocol (HTTP) is employed within the handset for the transfer of hypertext-based files between the browser and the smartcard server and also in view of the effect of HTTP server application behaviour in relation to a Transfer Control Protocol (TCP) connection. In accordance with the HTTP and HTTP server application behaviour, the TCP connection used for sending a HTTP request is currently closed after each request has been completed.

Further, and with regard to the B1P protocol specification, it is found that BIP channel-life is linked to the life of the TCP connection such that closure of the TCP connection will likewise lead to closure of the BIP channel. That is, in accordance with the BIP specification, when the BIP channel, and thus the related socket in the smartcard web server, has become closed, the handset identifier then sends a "line drop" control command such that the smartcard web server closes the BIP channel and then initialises the opening of a new BIP channel so as to connect to a new socket of the smartcard web server.

That is, in current arrangements, and with the server card presenting an open socket for connection of the handset thereto, an internal or external client associated with the handset can request a TCP connection to the server card, which request is handled by the handset to permit the required data exchange. When, for any reason, the TCP connection fails or is broken, the handset serves to close the server socket and to notify the server card, which card then serves to close the connection between the handset and server card prior to the establishment of a new connection.

Thus, as will be appreciated, the service offered by the server is effectively closed after each request, and related data transfer has been completed. The smartcard web server is then required to formally close the B1P channel and, as noted above, initialise the opening of a new channel and the BIP connection to a new server socket, after each HTTP request has been processed in the TCP connection link.

This closure and reopening of the B[P channel as controlled by the smartcard web server has been found to lead to disadvantages particularly in view of the speed of the link between the smartcard web server and the handset, and also in view of the smartcard server CPU computing power. It has been identified that there is a high risk that BIP connection requests will be lost particularly, for example, if a page is divided into several parts. The browser within the handset will then be required to send several HTTP requests within a short time and at least one of which may be lost due to the disconnectjopjreconnectjon scenario controlled by the smartcard web server and as outlined above.

The present invention seeks to provide for a method of achieving connectivity within a mobile radio communications device, and to a related mobile radio communications device employing the same, and which exhibit advantages over known such methods and devices.

In particular, the present invention seeks to provide for a mode of achieving reconnection between a device browser and a server card within the device and which does not exhibit the delays, and associated limitations and disadvantages, discussed above.

According to a first aspect of the present invention there is provided a method of re-establishing connection between a mobile radio communications device and a socket of a server device provided therein and subsequent to disconnection between the mobile device and the server device, characterjsed in that the mobile radio communications device manages creation of the said socket for the server device and for use in re-establishing the said connection.

In the present invention, and with the server device again presenting an open socket but with the "automatic re-establishment" mode set, the initial data exchange between the elements proceeds as noted above for the current arrangement. However, upon TCP connection failure, the handset reactivates the new socket connection automatically without waiting for a request to arise from the server.

Then, advantageously, the handset/server device connection status is now * quite independent of the TCP/IP client server status connection.

The present invention is advantageous insofar as it provides for the creation of the new server socket to be managed by the handset itself effectively on behalf of the server and so the delays otherwise experienced within the prior-art can advantageously be avoided. The connection status for the handset server device does not therefore now depend upon the TCP/IP client/server connection status.

If required the mobile device can manage the creation of the said socket without impact on the channel Connecting to the said server device.

Thus, since the handset itself manages the creation and use of the socket effectively on behalf of the server device and without reference to the channel connecting to the server device, there is no need for the closure, and subsequent reopening, of the channel as arises in the prior-art and so the delays arising within the prior-art are not experienced, and the above-mentioned independence from the TCP/IP connection status is achieved.

Of course, the server device can comprise a server card.

Preferably, it should be appreciated that the connection to the server device is achieved by way of a BIP channel.

According to another aspect of the present invention, there is provided a method of achieving automated reconnection within a mobile radio communications device to a smartcard device operating in server mode within the mobile radio communications device and including the method of re-establishing connection as outlined above.

Such operation is provided on a request originating from the smartcard device.

According to a further aspect of the present invention, there is provided a mobile radio communications device having a server device provided therein, the mobile device being arranged such that, subsequent to disconnection of the server device within the mobile device, the mobile device manages creation of a socket for the server device and to which reconnection is to be established.

As noted above, the invention advantageously renders the handset/server device connection status independent of the TCP/IP client/server status connection The device can further be arranged to manage creation of the said socket without impact on the channel connecting to the said server device.

As will be appreciated, the device employs a BIP channel for connectivity to the server card.

In particular, the aforementioned server card advantageously comprises a smartcard web server.

As will be appreciated from the above, the present invention provides for the creation of a new server socket, and related general connection, and which, unlike the prior-art, does not require awaiting the closure of a current channel and the subsequent opening of a new channel and server socket.

Operation of the device subsequent to the disconnection can therefore be established in a far quicker manner than in the current art and this greatly reduces the likelihood of loss of data.

Also, through advantageously avoiding the identification of a reconnection failure, there is no need for the browser to initiate its timer-lapse. This is currently in the order often seconds and occurs prior to an attempted re-connection. Thus, the speed of operation is likewise enhanced, and the likelihood of the loss of data greatly reduced. Also, through the avoidance of the initial re-connection failure, the tensecond timer-lapse is not initiated.

The invention is described further hereinafter, by way of example only, with reference to the accompanying drawings in which: Fig. I is a timing diagram illustrating the connection, and re-connection arising within a cellular phone handset between a browser and smartcard web server within a cellular phone handset according to the state of the art: and Fig. 2 is a similar timing diagram illustrating operation within a cellular phone handset embodying one aspect of the present invention.

Turning first to Fig. 1, the timing diagram illustrates the connectivity and data transfer that occurs within a cellular phone handset and between a browser and smartcard web server in the form of a Universal Mobile Telecommunication System Integrated Circuit Card (UICC) 12.

Such connectivity is achieved by way of a TCP internet protocol clientsewer pair 14, 16, the server 16 of which is arranged for communication via a BIP S1M application tool kit 18 with the circuit card 12 by way of a BIP channel.

The employment of the TCP protocol in relation to a BIP channel allows for the smartcard device to act in a server mode over the TCP connection and not merely as a TCP Internet protocol client as previously.

The timing diagram illustrates initially that the BIP channel between the application 18 and the circuit card 12 is opened by way of a command originating from the circuit card 12. Communication between the application tool kit 18 and the TCP Internet protocol server 16 serves to prepare for connection of the browser to a particular socket of the circuit card 12. At the point indicated by arrow 20 in the timing diagram, the browser 10 sends a first request for connection to the circuit card 12 and, as illustrated by arrow 22, this first request serves to establish connection between the TCP internet protocol client-server pair 14, 16 and which subsequently leads to a connected state within the BIP channel connecting to the circuit card 12.

As indicated at 24, the browser 10 and circuit card 12 comprising the smartcard web server are then able to exchange data as required.

However, once such data exchange has completed, the connection between the TCP internet protocol client-server pair 14, 16 is cut in accordance with the HTTP version employed and the HTTP server application behaviour as discussed above.

In view of the previously mentioned link between the BIP channel life and the TCP connection between the TCP Internet protocol client server pair 14, 16, the channel status 28 of the BIP channel is likewise changed to indicate a connection-cut status.

A subsequent attempt by the browser 10 to send a second request to the circuit card 12 as indicated by arrow 30 will not be successfiully processed in view of the connection failure indicated by arrow 32 that will be experienced in the connection between the TCP internet protocol client-server pair 14, 16.

In view of the connectioncut channel status 28 of the BIP channel identified by the circuit card 12, the circuit card then initiates a chain of message exchanges via the application tool kit 18 as indicated by data exchanges 34 which seek first to offer a command to formally close the BIP channel and then, issue an open channel command so as to open a new channel and achieve connectivity for the browser to a new socket of the circuit card 12.

The identification of the circuit failure 32 and the initial failure of the second request 30 from the browser 10 leads the TCP internet protocol client 14 to enter a 10 second timer-lapse period before re-connection will be attempted again.

While, within this 10 second period indicated initially at 36, a new server socket will be set up as indicated by arrow 38 under the control of the circuit card 12 and the related message exchanges 34, there has however nevertheless been a disadvantageous delay in dealing with the initial connection failure 32 between the TCP client-server pair 14, 16 and subsequent successful re-connection subsequent to the establishment of the new server socket as indicated by arrow 38 50 as to eventually achieve connection success 40 between the TCP internet protocol client- server pair 14, 16.

Such delay arising in relation to the closing of the current channel, and the creation of a new BIP channel for connection to a new server socket by way of signalling originating from the circuit card 12 comprise disadvantageous delays which, in accordance with a principal disadvantage of the current art, can lead to a loss of connection requests from the browser. Also, the aforementioned ten second timer-lapse itself, and which originates from an initial connection failure, likewise leads to disadvantageous delays in operation and in achieving the required reconnection of the browser to the circuit card.

One embodiment of the present invention is illustrated by reference to Fig. 2 which is a similar timing diagram to that of Fig. I and so again, illustrates the connectivity and message exchanges between a browser 10 and a UICC smartcard web server 12 and a TCP Internet protocol clientserver pair 14, 16 and related BIP application toolkit 18.

As discussed in relation to Fig. I, communication between the circuit card 12, the BIP application toolkit 18 and the TCP internet protocol server 16 serves to establish and confirm a new identity of the open socket at the circuit card 12 and related BlIP channel. Then, when at arrow 40 the browser 10 issues its first request, the connectivity that is achieved as indicated by arrow 44 between the TCP internet protocol client-server pair 14, 16 leads to a connected BIP channel status between the BIP application toolkit 18 and circuit card 12 such that, as illustrated at 46, the browser 10 and circuit card 12 can then exchange data as required.

As before however, and in accordance with the HTTP version employed and HTTP server application behaviour, subsequent to the exchange of data between the browser 10 and the circuit card 12 as illustrated at 46, the connection between the TCP internet protocol client server pair 14, 16 is cut as indicated at arrow 48.

However, unlike the prior-art, and under automated management control of the handset itself, the BIP channel status between the BIP application toolkit 18 and circuit card 12 is maintained as indicated at arrow 50. Then, when the browser 10 sends a second request as indicated by arrow 52, successful connection can be completed for the browser 10 through the TCP internet protocol client-server pair 14, 16 and the BIP channel 56 as illustrated by arrows 54, 56 respectfully, leads to connection between the browser 10 and the circuit card 12 such that the browser 10 and card 12 can then conduct new exchange data as required.

Thus, as will be appreciated, there is no initial connection failure experienced subsequent to the second browser request 52 and, further, signalling between the circuit card 12 so as to command channel closure and subsequent channel opening and identification of new server socket by means of the circuit card 12 is not required in view of the management of the creation of the new server socket conducted by the handset itself.

The present invention therefore advantageously decreases the number of messages arising within the handset and transmitted at, or from, the circuit card 12 and the handset, it being noted that a time period in the order of 200ms is required for requesting the opening/closure of a BIP channel.

Under control of the handset, the same channel can be shared for all of the application protocol requests even if the transport connection is actually closed for each such request. This can advantageously expedite the setting up of the transport protocol between two successive application requests and therefore, as illustrated, avoids the rejection of the attempted first request required for establishing a new connection. Yet further, it avoids the need for triggering the transport protocol retry- timer which, as discussed in relation to Fig. I leads to a "time-out" delay of in the order often seconds.

The loading of a page from the circuit card 12 by the local browser 10 can then advantageously be speeded up and user-acceptance is greatly improved. As an example, testing page loading time can be decreased by in the order of a factor of four.

Thus, as will be appreciated, the present invention provides for protocol optimisation of the management of a BIP channel between a mobile radio communications device such as a cell phone handset and a universal mobile telecommunication system integrated circuit smartcard arranged to operate in a server mode.

The present invention provides for an arrangement of the BJP channel for automatic reconnection when the smartcard is operating in server mode and such that, when automatic mode is selected, and the handset is arranged automatically to accept a new socket each time the current server socket is closed but without experiencing the disadvantageous limitations and delays that are inherent in the prior-art.

As will be appreciated, the invention can be extended for use in relation to a variety of peripheral devices for use, for example, in relation to a handset such as for example a domotic device, memory cards in the form a SD cards or JVIMC cards, camera devices or indeed any peripheral device offering a server feature employing a mobile TCP/IP stack.

Claims

Claims 1. A method of re-establishing connectivity between a mobile radio

communications device and a socket of a server device associated therewith and subsequent to disconnection between the mobile device and the server device, characterised in that the mobile radio communications device manages creation of the said socket for the server device and for use in re-establishing the said connection.
2. A method as claimed in Claim 1 wherein the server device comprises a JO server card.
3. A method as claimed in Claim 1 or 2, wherein the device is arranged to manage the creation of the said socket without impact on the channel connecting to the said server device.
4. A method as claimed in Claim 1, 2 or 3, wherein the connection to the server card is achieved by way of a B1P channel.
5. A method of achieving automated reconnection within a mobile radio communication device to a smartcard device operating in the server mode within the mobile radio communications device and including the method of establishing connection as defined in any one or more of Claims I to 4.
6. A mobile radio communications device having a server device associated therewith, the mobile device being arranged such that, subsequent to a disconnection between the mobile device and the server device, the device manages creation of a socket for the server device and to which reconnection is to be established.
7. A device as claimed in Claim 6 wherein the server device comprises a server card.
8. A device as claimed in Claim 6 or 7 and arranged to manage creation of the said socket without impact on the channel connecting to the said server device.
9. A device as claimed in Claim 6, 7 or 8, and arranged to employ a BIP channel for connectivity to the server card.
10. A device as claimed in any one or more of Claims 6 to 9, wherein the server card comprises a smartcard web server.
ii. A method of establishing connection between a mobile communication device and a socket of a server card and subsequently as hereinbefore described with reference to, and as illustrated in Fig. 2 of the accompanying drawings.
12. A method of achieving automated reconnection within a mobile radio communications device to a smartcard device operating in server mode and substantially as hereinbefore described with reference to, and as illustrated in, Fig. 2 of the accompanying drawings.
13. A mobile radio communications device substantially as hereinbefore described with reference to Fig. 2 of the accompanying drawings.

13. A mobile radio communications device substantially as hereinbefore described with reference to Fig. 2 of the accompanying drawings.

Amendments to the claims have been filed as follows 1. A method of re-establishing connectivity between a TCP server stack socket of a mobile radio communications device and a remote application associated therewith and subsequent to discoimection between the mobile radio communications device and the remote application, characterised in that the mobile radio communications device manages reinstatement of the server socket for re-establishing the said connection and in the absence of acknowledgement from the remote application.

2. A method as claimed in C]aim 1 wherein the remote application employs a WEB smartcard.

3. A method as claimed in Claim 1 or 2, wherein the device is arranged to manage the creation of the said server socket without impact on the channel connecting to the remote application.

4. A method as claimed in Claim 1, 2 or 3, wherein the connection to the remote application is achieved by way of a BIP channel.

5. A method of achieving automated reconnection within a mobile radio communication device to a smartcard device operating in the server mode and including the method of establishing connection as defined in any one or more of Claims 1 to 4.

6. A mobile radio communications device arranged for communication with a remote application by way of a TCP server stack socket, the mobile radio communications device being arranged such that, subsequent to a disconnection between the mobile radio communications device and the remote application, the device manages reinstatement of a server socket and to which reconnection is established in the absence of acknowledgement from the remote application.

7. A device as claimed in Claim 6 wherein the remote application employs a server card.

8. A device as claimed in Claim 6 or 7 and arranged to manage creation of the said server socket without impact on the channel connecting to the remote application.

9. A device as claimed in Claim 6, 7 or 8, and arranged to employ a BIP channel for connectivity to the remote application.

10. A device as claimed in any one or more of Claims 6 to 9, wherein the remote application employs a smartcard web server.

11. A method of establishing connection between a mobile communication device and a socket of a server card and subsequently as hereinbefore described with reference to, and as illustrated in Fig. 2 of the accompanying drawings.

12. A method of achieving automated reconnection within a mobile radio cornmuni cat ions device to a smartcard device operating in server mode and substantially as hereinbefore described with reference to, and as illustrated in, Fig. 2 of the accompanying drawings.