PACKET BASED CLIENT/SERVER PROTOCOL

Abstract: A method and system for client/server data exchange. The transmission and reception of Protocol Data Units (PDU's) over a data communications network comprises the steps of receiving a PDU for transmission, encoding the PDU into a number of alphanumeric data packets, such that each data packet is less than a predetermined size, associating an address frame with the or each data packet, the address frame including the destination of the or each data packet and, transmitting the or each data packet. The data packets are preferably transmitted by SMS or Cell Broadcast.

Description: PACKET BASED CLIENT/SERVER PROTOCOL The present invention relates to a compact packet-based data communication protocol particularly suitable for use with GSM-type mobile phones. The internet, and indeed most data communications networks, is based on a packet based data communications protocol. The most commonly used protocol is the Internet Protocol (IP) and this is the primary protocol upon which the Internet is based. Packet based protocols divide transmission data into a number of packets, each transmitted over the network as a separate protocol data unit (PDU). Packets are routed over the network by routing nodes which maintain routing tables indicating the routes between themselves and other nodes and adapt the routes they forward traffic by according to network traffic and other factors. Each packet is numbered as it is transmitted so that the data can be re-ordered upon receipt and missing packets can be requested for re-transmission. Where a fixed line connection is not available, remote access to data networks is normally made by some form of mobile telephony system. The most common systems are GSM (Groupe Special Mobile) systems in which data networks are accessed via mobile telephone systems offering a limited bandwidth and variable connection reliability. Unfortunately, the limited bandwidth typically restricts data transmission and reception rates to 9600 bps. This restriction, combined with the variable connection reliability, conflicts with packet based protocols which assume data links to be of high bandwidth and to have little or no packet loss. In addition, the minimum size of some packets can, in some cases, be too large for GSM systems. According to a first aspect of the present invention, a method of transmitting Protocol Data Units (PDU's) over a data communications network comprises the steps of: receiving a PDU for transmission; encoding the PDU into a number of alphanumeric data packets, such that each data packet is less than a predetermined size; associating an address frame with the or each data packet, the address frame including the destination of the or each data packet; and, transmitting the or each data packet. A particular advantage of the present invention is that Internet access can be provided to mobile telephones without adapting the GSM protocol or infrastructure the phone is currently running on. By re-packetising data into data packets less than a predetermined size, the probability of each packet being successfully transmitted over the limited data communications link is dramatically increased. Additionally, the loss of a single, or a number of packets, does not incur large overheads as the packet(s) can be quickly retransmitted. By re-packetising PDU's irrespective of their content, overheads from protocols which reassemble data from constituent PDU's prior to re-packetising them are avoided. Encoding, compression and error correction are extensions available without further overheads or protocol layers. The step of encoding the PDU may comprise the step of applying an alphanumeric encoding scheme if the PDU is not wholly alphanumeric. The alphanumeric encoding scheme is preferably uuencoding. Uuencoding enables data to be sent over existing text-based links which have reserved characters without modification. The step of encoding the PDU may comprise the steps of: determining the length of the PDU; generating a data packet from the PDU, wherein if the PDU is greater than a predetermined size, it is divided up into a sequence of data packets. The step of generating a data packet may further comprise the step of associating a packet identifier with the generated data packet, wherein if a PDU is divided up into a sequence of data packets, the packet identifier for each data packet identifies it as part of a divided PDU and identifies the relative position of the data packet in the sequence. Preferably, the address frame may include a Short Message Service (SMS) address and the or each data packet is transmitted by SMS. The Short Message Service (SMS) is a feature available to all GSM service users. SMS is a bi-directional service for short alphanumeric messages. Normally, SMS messages are limited to 160 bytes consisting strictly of letters and numbers which has restricted their use to personal messages and services such as traffic and news updates. Normally, the reserved characters (such as control characters), which SMS prohibits messages from using, conflict with such characters in the data to be transmitted. By use of uuencoding, such conflicts are easily and simply resolved. Piggy-backing WWW data onto existing SMS service links does not commonly affect the SMS system's performance as they are normally underutilised. However, the use of the existing link and underlying protocols greatly reduces the complexity of the data transmission as handshaking and the like need not be catered for. This reduction in complexity in turn reduces the overheads of data required in header frames because handshaking etc is handled elsewhere. The present invention therefore offers a powerful communication mechanism without the complexity of providing an entirely new mechanism from basics. In an alternative to SMS, the address frame may include a Cell Broadcast address and the or each data packet is transmitted by Cell Broadcast. Cell Broadcasts offer a simple and effective way of getting World Wide Web type data to a number of users without fixed Internet links. The step of encoding the PDU into a number of alphanumeric data packets may include the step of compressing the PDU. A method of receiving Protocol Data Units (PDU's) transmitted over a data communications network according to the above method may comprise the steps of receiving a number of alphanumeric data packets, removing the address frame associated with each data packet and regenerating a PDU from the number of received alphanumeric data packets. The step of regenerating a PDU may include uudecoding the number of received alphanumeric data packets. The step of regenerating a PDU may include the steps of ordering the received alphanumeric data packets in dependence on a packet identifier associated with each data packet, removing the packet identifier associated with each data packet and rejoining the data packets. The step of ordering the received alphanumeric data packets may include the step of detecting non- received data packets and requesting their retransmission. According to another aspect of the present invention, a system for transmitting Protocol Data Units (PDU's) over a data communications network comprises a receiver for receiving a PDU for transmission, an encoder for encoding the PDU into a number of alphanumeric data packets, such that each data packet is less than a predetermined size, an addressing system for associating an address frame with the or each data packet, the address frame including the destination of the or each data packet and a transmitter for transmitting the or each data packet. The encoder may apply an alphanumeric encoding scheme if the PDU is not wholly alphanumeric. The transmitter preferably comprises a Short Message Service (SMS) system for addressing and transmitting the or each data packet. The system may further include a receiver for receiving Protocol Data Units (PDU's) transmitted over a data communications network by the transmission elements of the above system, the receiver including a receiver system for receiving a number of alphanumeric data packets, a processor for removing the address frame associated with each data packet and for regenerating a PDU from the number of received alphanumeric data packets. The processor may be configured to uudecode the number of received alphanumeric data packets. The processor may be configured to order the received alphanumeric data packets in dependence on a packet identifier associated with each data packet, to remove the packet identifier associated with each data packet and to rejoin the data packets. Preferably, the processor is configured to detect non-received data packets and to request their retransmission. The receiver is preferably an SMS receiver, such as a GSM mobile telephone, and the alphanumeric data packets are received by SMS. Alternatively, the receiver may be a Cell Broadcast receiver and the alphanumeric data packets are received by Cell Broadcast. The transmitter may also be a GSM mobile telephone. The PDU's may comprise data resulting from browsing of, and/or interaction with, the World Wide Web, wherein the system may further comprise a World Wide Web server for acting as a gateway for PDU's for transmission to, and for reception from, the World Wide Web. In a preferred aspect of the present invention, the PDU's comprise data resulting from browsing of, and/or interaction with, the World Wide Web, wherein the SMS system is hosted by a World Wide Web server which also acts as a gateway for PDU's for transmission to and for reception from the World Wide Web. In the context of SMS, alphanumeric characters comprise the following set: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqr stuvwxyzo Embodiments of the present invention will now be described, by way of example only, and with reference to the accompanying drawings, in which: Figure 1 is a schematic diagram of a data communications network for use in the present invention; Figures 2a and 2b are representations of data packet formats transmitted and received in a data communications session according to the present invention; and, Figures 3a-3e and 4a-4e are examples of data packets transmitted and received in a data communications session according to the formats defined with reference to Figure 2. Figure 1 is a schematic diagram of a data communications network for use in or with the present invention. A GSM service provider has a mobile telephone network comprising a number of transmission cells 10. The network is linked to an SMS system 20 which is in turn linked to a World Wide Web (WWW) server 30 which is connected to the WWW 40. A user of a mobile telephone 50 in the transmission area of one of the cells 10 browses the WWW using a micro-browser installed on his mobile telephone 50. Due to the user's interaction with the micro-browser, requests for data from the WWW are issued by the micro-browser. The requests are encoded and transmitted by the mobile telephone as SMS messages addressed to the WWW server 30. The messages are treated as a normal SMS message and are forwarded by the cells 10 to the SMS system 20. The SMS system 20 passes the messages on to the WWW server 30. Upon receiving an SMS message, the WWW server 30 decodes it into an appropriate HTTP (HyperText Transport Protocol) request which it then processes. Data received by the WWW server 30 via the WWW 40 in response to the HTTP request is encoded as an SMS message addressed to the micro- browser of the mobile telephone 50. The WWW server 30 passes the message to the SMS system 20 which transmits it to the mobile telephone 50 via the cells 10. The mobile telephone receives the message, decodes it and passes it to the micro-browser for the appropriate action such as displaying a WWW page to the user. Figures 2a and b are representations of the formats of data packets generated in accordance with the present invention. The transport protocol used by the mobile telephone 50 and WWW server 30 to generate SMS messages due to requests and decode received messages is divided into two layers: a session layer responsible for encoding and decoding data and requests into SMS format messages, and a transport layer responsible for preparing and addressing the SMS messages and error checking received messages. Due to the size limit for SMS messages, a request or a response that exceeds this limit must be divided into a number of discrete packets. The transport layer divides such messages into a number of packets, each transmitted as a separate SMS message. Received packetised messages are reassembled by the transport layer. SMS allows messages of 160 7-bit characters which must be uuencoded or 140 8-bit characters which do not need to be uuencoded. The remainder of the description relates to 160 7-bit character messages but the skilled reader will understand that the present invention is applicable to either type. Figure 2a is a representation of a message prepared by a session layer. Each message includes a CommandlD field 100 indicating the type of command the message relates to (open, close, request, send or rerequest), a MsgSize field 110 indicating the length in characters of the particular message (this is encoded into loendian using 7-bit values i.e. size=byte1+byte2 * 2 7 ), a header field 120 (discussed below), a data field 130 containing the data (URI, data sent from server or packet number of rerequested message) and an end field 140 indicating the next CommandlD or NULL if it is the last message. The contents of the header field relate to optional data. Each header field includes a value followed by a NULL terminated string. A header may be formed of the following: The content type field may include, for example, one of the following type identifiers: An encoding field may specify a value corresponding to an encoding or compression scheme such as Huffman encoding or run length encoding. The type of alert field may specify the data field to relate to an alert of one of the following types: The agent profile is used to adapt the data type and/or content transmitted by a service or server depending on the type of device accessing the data. Due to the diversity of supported features by different browsers (particularly in mobile phones), identifying the browser by name is not enough. A profile identifies the main features of the browser such as support of HTML/HDML/WML, image types it can display, screen size, etc. The service or server can then adapt the data returned to the browser using this information. Figure 2b is a representation of a message prepared by the transport layer. A session layer message is processed and, if necessary divided into a number of packets having a maximum length of 157 bytes, shown as data field 200. For each packet, a header is attached including a MessagelD field 210, packet number field 220, error check field 230 and packet total field 240. The messagelD 210 identifies the message the packet is associated with. If the message is divided into more than one packet, each packet's header contains the same messagelD so that, upon receipt, the packets can be identified and merged together to reform the message. The packet number and packet total fields (220, 240) are also used in this respect as packets may be received in any order and packets may be missing. The number and total fields allow the receiver to re-order the packets and request re-transmission of missing packets. The error check field 230 indicates the type of error checking used on the accompanying data. Figures 3a-3e are representations of data packets transmitted and received in a data communication session using a protocol according to the present invention. Figure 3a is a representation of a data packet prepared by a session layer in response to a request by a mobile telephone's micro-browser for the URI (Universal Resource Indicator) "http://hdmlhost/home.hdml". The session layer determines the message is for a request (commandlD=3), the MsgSize is 29 (headers 4 + URI String 25), and no header field required. The message of Figure 3a is therefore passed to the transport layer. Upon receipt, the transport layer determines that only 1 SMS message is required and therefore allocates the messagelD 1 , packet number 0, error check level 0 (no error checking) and packet total 0. This information is concatenated to the session message to produce the SMS packet of Figure 3b, which is then transmitted. Having received and decoded the SMS message, a server requests the URI via HTTP and receives 200 bytes of data in response. Processing the data, the session level of the server takes the data and allocates a commandlD 4 (send), and a message size 207 (headers 6 + data 200 + terminator 1 ) which is encoded into 79+1 * 2 7 . A header field of content type 1 (HDML) is added, followed by the data (200 bytes) and the next commandlD 0 (no more messages). The assembled message, as shown in Figure 3c is passed to the server's transport layer. The transport layer builds the first SMS packet having a MsglD of 1 , packet number 0, error check 0 and packet total 1. The resultant SMS message, as shown in Figure 3d cannot hold all of the session layer's message and therefore only contains the first 151 bytes with the 9 bytes of headers. A second SMS packet having the same transport layer data as the first with the exception of packet number being 1 is generated to take the last 49 bytes of data, as is shown in Figure 3e. Both SMS packets are transmitted to the mobile telephone and are decoded, reconstituting the data for display by the micro-browser. Figures 4a-4d are representations of data packets transmitted and received in a data communication session using a protocol according to the present invention. Figure 4a is a representation of a data packet prepared by a session layer in response to a request by a mobile telephone's micro-browser for the URI (Universal Resource Indicator) "http://hdmlhost/home.hdml". The session layer determines the message is for a request (commandID=3), the MsgSize is 29 (headers 4 + URI String 25), and no header field is required. The message of Figure 4a is therefore passed to the transport layer. Upon receipt, the transport layer determines that only 1 SMS message is required and therefore allocates the messagelD 1 , packet number 0, error check level 0 (no error checking) and packet total 0. This information is concatenated to the session message to produce the SMS packet of Figure 4b, which is then transmitted. Having received and decoded the SMS message, a server requests the URI via HTTP and receives 200 bytes of data in response. As both the server and client support Huffman encoded data compression, the 200 bytes are compressed by the server to 87 bytes. Processing the data, the session level of the server takes the compressed data and allocates a commandlD 4 (send), and a message size 96 (headers 8 + data 87 + terminator 1) which is encoded into 96+0 * 2 7 . Header fields of content type 1 , 2 (HDMLc) and Huffman encoding (6, 1 , 0) are added, followed by the data (87 bytes) and the next commandlD 0 (no more messages). The assembled message, as shown in Figure 4c is passed to the server's transport layer. The transport layer builds the first SMS packet having a MsglD of 1 , packet number 0, error check 0 and packet total 0. The SMS packet is transmitted to the mobile telephone, decoded and then decompresed, reconstituting the data for display by the micro-browser. Preferably, a uuencoding scheme is applied to received data packets in order to avoid attempts to transmit non-alphanumeric characters which SMS does not support. Whilst the above description has been concerned with the transmission of data by packetising it and using SMS, it will be apparent that the present invention is applicable to many transmission protocols and mechanisms, for example Cell Broadcast. In Cell Broadcasts and SMS alerts no initial request is made from the phone for data. A URI is created at a WWW server and transmitted to the phone according to some criteria such as a previous request to receive certain data or a decision by a service provider to notify some/all users of an event. As the maximum size of a Cell Broadcast packet is 88 bytes, the transport layer modifies message length accordingly. A Cell Broadcast message utilises the alert field, described previously, to identify the type of data transmitted and whether/how the user should be notified when the broadcast arrives. Although cell broadcast is only a one-way transmission mechanism from the server to any recipients in the respective cell, the protocol of the present invention could be used, for example, to broadcast pages with local information (e.g. where a local branch of a well-known store is).

Claims: Claims 1. A method of transmitting Protocol Data Units (PDU's) over a data communications network comprising the steps of: receiving a PDU for transmission; encoding the PDU into a number of alphanumeric data packets, such that each data packet is less than a predetermined size; associating an address frame with the or each data packet, the address frame including the destination of the or each data packet; and, transmitting the or each data packet. 2. A method according to claim 1 , in which the step of encoding the PDU comprises the step of applying an alphanumeric encoding scheme if the PDU is not wholly alphanumeric. 3. A method according to claim 2, in which the step of encoding the PDU comprises the steps of: determining the length of the PDU; generating a data packet from the PDU, wherein if the PDU is greater than a predetermined size, it is divided up into a sequence of data packets. 4. A method according to claim 3, in which the step of generating a data packet further comprises the step of associating a packet identifier with the generated data packet, wherein if a PDU is divided up into a sequence of data packets, the packet identifier for each data packet identifies it as part of a divided PDU and identifies the relative position of the data packet in the sequence. 5. A method according to any preceding ciaim, in which the step of encoding the PDU into a number of alphanumeric data packets includes the step of compressing the PDU. 6. A method of receiving Protocol Data Units (PDU's) transmitted over a data communications network according to the method of any one of the preceding claims comprising the steps of: receiving a number of alphanumeric data packets; removing the address frame associated with each data packet; and, regenerating a PDU from the number of received alphanumeric data packets. 7. A method according to claim 6, in which the step of regenerating a PDU includes the steps of ordering the received alphanumeric data packets in dependence on a packet identifier associated with each data packet, removing the packet identifier associated with each data packet and rejoining the data packets. 8. A system for transmitting Protocol Data Units (PDU's) over a data communications network comprising: a receiver for receiving a PDU for transmission; an encoder for encoding the PDU into a number of alphanumeric data packets, such that each data packet is less than a predetermined size; an addressing system for associating an address frame with the or each data packet, the address frame including the destination of the or each data packet; and, a transmitter for transmitting the or each data packet. 9. A system according to claim 8, in which the encoder applies an alphanumeric encoding scheme if the PDU is not wholly alphanumeric. 10. A system according to claim 9, in which encoder is configured to determine the length of the PDU, and to generate a data packet from the PDU, wherein if the PDU is greater than a predetermined size, the encoder is configured to divide it up into a sequence of data packets. 11. A system according to claim 10, in which the encoder is configured to associate a packet identifier with the generated data packet, wherein if a PDU is divided up into a sequence of data packets, the packet identifier for each data packet identifies it as part of a divided PDU and identifies the relative position of the data packet in the sequence. 12. A system according to any of claims 8 to 11 , in which the encoder is configured to compress the PDU. 13. A system for receiving Protocol Data Units (PDU's) transmitted over a data communications network by the system of any one of claims 8 to 12 comprising a receiver for receiving a number of alphanumeric data packets, a processor for removing the address frame associated with each data packet and for regenerating a PDU from the number of received alphanumeric data packets. 14. A system according to claim 13, in which the processor is configured to order the received alphanumeric data packets in dependence on a packet identifier associated with each data packet, to remove the packet identifier associated with each data packet and to rejoin the data packets. 15. A system according to any of claims 8 to 14, in which the PDU's comprise data resulting from browsing of, and/or interaction with, the World Wide Web, wherein the system further comprises a World Wide Web server for acting as a gateway for PDU's for transmission to and for reception from the World Wide Web. 16. A program storage device readable by a machine and encoding a program of instructions for executing the method of any of claims 1 to 7. 17. A program storage device readable by a machine and encoding a program of instructions for executing the system of any one of claims 8 to 15. 18. A computer data signal embodied in a carrier wave encoding a program of instructions for executing the method of any one of claims 1 to 7. 19. A computer data signal embodied in a carrier wave encoding a program of instructions for executing the system of any one of claims 8 to 15.

Inventors: SIMONS PAUL R, YULE DAVID C, SIMONS, PAUL, R., YULE, DAVID, C.
Applicants: KONINKL PHILIPS ELECTRONICS NV, KONINKLIJKE PHILIPS ELECTRONICS N.V.
Application year: 2000
Main classification: H04L29
IPC codes: H04L12, H04L29, H04W4, H04W80