US 20060106932 A9
A wireless communication system allows mobile users to access a resource from a content server. The wireless communication system includes a browser that allows mobile users to access resources through a wireless application protocol (WAP) compliant server. The (WAP) compliant server connects the browser to a content server. This connection allows resources to be passed between the browser and the (WAP) compliant server. The browser is further configured to transmit a request that includes an address for a resource, a protocol to be used, and one or more textual parameters encoded into a binary data packet. The wireless communication method includes generating a request for a resource; translating a textual portion of that request into binary data at the browser; transmitting the request to a wireless gateway; and converting the request into a format that is compatible with a protocol used by a receiving network.
1. A wireless communication system that allows mobile users to access a resource from a content server through a network comprising:
a browser that allows mobile users to access resources; and
a wireless application protocol compliant server programmed to couple the browser to a content provider server so that a resource may be passed between the browser and the wireless application protocol compliant server;
where the browser is configured to transmit a request that comprises an address for the resource, a protocol to be used, and one or more textual parameters encoded into a single binary data packet.
2. A communication system having a browser capability, comprising
a wireless application protocol compliant server; and
a client coupled the server and adapted to transmit a request for a resource;
where the request comprises a single encoded parameter that includes an identification code that comprises a binary data packet.
3. The communication system according to
4. The communication system according to
5. The communication system according to the claims 2 where the request is not more than 256 characters long.
6. The communication system according to claims 2 where the request is transmitted to the server after a handshake process.
7. The communication system according to
8. The communication system according to
9. The communication system according to
10. The communication system according to
Identification code of the service (Service ID);
Length of the serial number;
Serial number, further reserved area for future applications;
Number of packets (last-section-number);
Number of the package just sent (section number); and
11. The communication system according to
12. The communication system according to claims 7 where the identification code is variable in length and generated by the server.
13. The communication system according to
14. The communication system according to claims 13 where the requested service comprises a query of the client's current location.
15. The communication system according to
16. The communication system according to
17. The communication system according to
18. The communication system according to
19. The communication system according to
20. A wireless communication protocol method comprising:
generating a request for an publicly accessible resource;
translating a textual portion of the request into a binary data through a wireless browser;
transmitting the request to a wireless gateway; and
converting the request at the gateway into a format that is compatible with a protocol used by a receiving network.
This application is a continuation-in-part and claims the benefit of priority under 35 U.S.C. §§ 120, 365, and 371 to Patent Cooperation Treaty Patent Application No. PCT/EP02/13609, filed on Dec. 2, 2002, which was published in German under Publication No. WO 03/047201. This application further claims the benefit of priority to German Application No. DE 10158739.2, filed Nov. 30, 2001. The disclosures of the above applications are incorporated herein by reference.
1. Technical Field
The invention relates to an exchange of information, and more particularly, to a mobile communication system.
2. Related Art
Wireless Application Protocol (WAP) enables delivery of information and services to mobile users. Both high end and low end devices including handheld wireless phones and pagers may rely on a WAP communication protocol to connect to the Internet. WAP may be based on Internet standards such as Hypertext Markup Language (HTML) and Extensible Markup Language (XML) that use tags to organize and present information.
To access information, software allows users to view Wireless Markup Language (WML) documents and access files related to those documents. WML primarily transports text because tags related to large resources such as large tables and images may slow down the communication exchange. A WAP compliant browser may also interpret some Wireless Markup Language Script (WMLScript) to create customized responses to requesting clients.
A request, such as a Uniform Resource Locator (URL), may ask for resources through the Internet. In a simple format string, a URL request may specify the protocol to be used, the server to be accessed, the path to the resource, and multiple parameters that may be related to the resource. At a high level, the URL is simply a formatted string such as “. . ./testappl.cgi?navdest=DEUTSCHLAND,, HILDESHEI M,, DAIML RRING” where the parameters are positioned after the equal sign (e.g., “. . . /testappl2.php?param1=somevalue¶m2=anothervalue . . . ”). As more parameters are used, the processing time to service a request increases, which may slow down the information exchange. When retransmissions are required, the congestion caused by the transmission of an identical second request may create further delays, which may eventually overload an Internet connection.
Therefore, a need exists for a system that overcomes some of these potential drawbacks in the related art.
This invention provides a wireless communication system that allows mobile users to access a resource from a content server. The wireless communication system includes a browser that allows mobile users to access resources through a wireless application protocol (WAP) compliant server. The (WAP) compliant server couples the browser to a content server. This connection allows resources to be passed between the browser and the (WAP) compliant server. The browser is further configured to transmit a request that includes an address for a resource, a protocol to be used, and one or more textual parameters encoded into a binary data packet.
The wireless communication method comprises generating a request for the resource; translating a textual portion of that request into binary data at the client; transmitting the request to a wireless gateway; and converting the request into a format that is compatible with a protocol used by a receiving network.
Other systems, methods, features, and advantages of the invention will be, or will become, apparent to one with skill in the art upon examination of the following figures and detailed description. It is intended that all such additional systems, methods, features, and advantages be included within this description, be within the scope of the invention, and be protected by the following claims.
The invention can be better understood with reference to the following drawings and description. The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention. Moreover, in the figures, like referenced numerals designate corresponding parts throughout the different views.
An improved communication protocol embodiment provides an effective way to control congestion on a wireless system. The communication protocol may adjust the transmission rate of all requests by controlling the size of the data stream or packets used to locate and access resources. The communication protocol may verify the integrity of the data stream by determining whether any errors have been introduced into the data stream during transmission.
A wireless internet gateway server 104 may receive requests for resources and/or services and convert or translate the requests to forms that are compatible with a content provider 106. When a wireless internet browser uses the same communication protocol used by a content provider 106, the wireless internet gateway server 104 may act as a bridge that simply connects the wireless internet browser 102 to the content provider 106.
The wireless internet gateway server 104 may include a device or program that converts the coded binary data back to its original form (e.g., a decoder) before converting or translating it to a form that is compatible with protocols used by the content provider 106. When necessary, the wireless internet gateway 104 may also interpret data fragmentation and may reunite parts of the data stream or data packets that have become fragmented by the wireless web browser 102 or the content provider 106. When the data transmission protocol transports fragmentized data, a defragger resident to the wireless internet gateway 104 may interpret the data transmission protocol and reunite those parts of the data stream that were broken apart or have become detached.
When a response is received from the content provider 106, the wireless internet gateway 104 may parse the response and convert or translate the information contained in the response to a form that is compatible with the wireless internet browser 102. In some embodiments, the information received by the wireless internet browser 102 will adhere to the protocol that the wireless internet browser 102 used to transmit requests. In these embodiments, the data stream or data packets may include encoded binary packets that may be converted back to its original form by a decoder resident to the wireless internet browser 102.
The communication protocol embodiment may transmit large data streams and automatically transmit large data packets. The embodiments support a normal client/server model where a user enters a request, such as a Uniform Resource Indicator (URI) or a Uniform Resource Locator (URL), that is sent to a server, and the server answers by sending a response. In contrast, some communication protocol embodiments also support push technology. In a push technology, a host or server may request data from a client. A push operation may be accomplished by allowing an initiator, which may comprise a content provider 106, to push content and delivery instructions to the wireless internet gateway 104 or a push gateway. The wireless internet gateway 104 or push gateway may then deliver the content and its related data to the wireless internet browser 102 according to the delivery instructions. If a connection cannot be made with the wireless internet browser 102, the wireless internet gateway 104 or push gateway may store the content until a connection with the wireless internet browser 104 may be made. The data transmitted with the content may indicate how long data may be retained within the gateways and/or the browser.
In some communication protocol embodiments, internal task identification codes may also be delivered with the data. In these embodiments, internal task identification codes may provide information about the outcome of a task, such the delivery of a request, the delivery of a resource, the cancellation of a message, the outcome of a handshake, or the outcome of other tasks that are to be carried out by a browser, a gateway, a server, or other devices.
Using a WAP protocol, the vehicle 200 may communicate with an origin server or mirror server 214. In
In operation, a user may access the satellite navigation system by pressing keys on the panel of the radio 202. A user may enter any parameter such as a chosen city, a road name, a house address or select one of the many destinations that may be pre-programmed in the radio memory. Selections may include selecting amenities such as points of interests, hotels, gasoline stations near projected fuel stops, and route selections (e.g., the fastest, shortest, most use of interstates routes).
Once the data is entered through the data interface it may be stored in a volatile or non-volatile memory under a user profile. The data interface may comprise a graphical user interface (GUI), a command line interface, or a textual input. Once received, the satellite navigation system 204 initiates a data connection through the GSM modem 208, which may be built into or may be separate from the radio 202. As the connection is made, the navigation system 204 may select or access the user's profile.
Once connected, a requested Internet portal may be accessed through a WAP service provider 212 and all possible services may be displayed on a WML (Wireless Markup Language) page. The Internet portal call or request may pass one or many parameters, such as a device number, a password, vehicle identification number (VIN), and geographical (geo) coordinates through a URI or URL parameters.
A responding server may assemble a WAP page with stored or dynamically generated information that may be customized to a particular user. In some embodiments, a user may navigate through the contents like a conventional browser. If a user selects a hotel search, the traveling area may be analyzed on a server side automatically. Depending on the vehicle's 200 position that may be transmitted to the server 214 when a user logs in, the server may select possible hotels from a database. These results may then be sent back to a display or terminal coupled to the radio in the form of a WML page.
A user may select a desired hotel and receive detailed data or information on the hotel. The information may be relayed through a WML page that includes a data link. In some embodiments, the data link may conceal a data packet, which includes a destination description that may used by the navigation system.
In the navigation system 204 shown in
The following structures may be used to implement the communication systems described above.
1. Format of the Data Packets
A format of the data packets exchanged between the client and server is described below. In addition to the MIME type protocol, the following sections describe the format of the data packets that are sent from the server to the client (Service packets) and those sent from the client to the server (Request packets).
1.1 Content/MIME Type
The Content type or MIME type selected for some of the described embodiments may be called, for example, x-becker/vnd.wap.lbs. The MIME type begins with “x-”, to fulfill Advanced Network Architecture Group's (ANA's) requirements (see www.w3c.org-RFC 1700). This format used to transmit data from a server to the client is extensible, and may be modified or changed to work with later developed languages because different services can be handled through a separate Service ID with this MIME type. In some communication systems, only data packets that have this MIME type may be decoded by the client, according to an included Service ID.
1.2 Service Packet (Server)
The Service packets may be transmitted from the server portal to the client when requested. In addition to the Service ID code, device numbers and procedures to check for errors in data transmissions may be executed. A cyclical redundancy check such as a CRC32 may be checked to ensure that the service packets contain useful data. The length of the useful data may depend on the service a user selects, which makes this format flexible.
1.21 Format of the Data Packet
The packets may follow an MPEG2 syntax. The protocol setup, for example, may be structured as follows:
The device id contains the device number. It may also be called the user name in some parts of the source code. The two 4-bit values last_section_number and section_number describe the number of types of packets that are transmitted, such as in a sequence one after another, and by packet number. This is useful for future versions of communication protocols in which the data volume exceeds a normal capacity. In one embodiment, these two values can always be set to 1.
To transmit more than one section, the session_id is needed. The session_id may be included in the transmission of each data exchange. It has a variable length and is generated/stipulated by the server the first time the server is called. By using this ID, the server may determine which client is making a client request. Handshaking processes, such as those needed for TDS, for example, can be realized using a combination of section_number, last_section_number and session_id.
With the exception of the last value, an error checking code (e.g., CRC 32), further decoding takes place depending on the service_id. Encoding of the potentially useful data is treated in the appropriate sections below.
1.2.2 Service.ID SERVICE NAVDESTINATIONS
The search for destinations in the vicinity of a user defined profile that may be associated with the SERVICE_NAVDESTINATIONS ID makes it possible to request navigation data for special destinations (restaurants, hotels, train stations, museums, etc.). In those navigation systems that may use resident memory and CD-ROM to store an entire or a portion of a navigation route, destination information may not be contained in the “normal” CD navigation data.
This additional service provides a type of dynamic reference or yellow pages for the car through the radio. The navigation data that is requested by a user through this process can be billed to the user, just as it may also be billed to the owner of the destination (for example, a restaurant owner).
The format of the data packet may look as follows:
Additional data, such as one URL per navigation destination, can be attached to a data packet, depending on the definition. If the Service ID SERVICE_NAVDESTINATIONS was found when the header data was decoded, then the data is decoded according to the syntax recorded in the program.
The two values start_mode (2-bit value) and save_mode (1-bit value) may be used in the navigation logic. The start mode may be used to establish whether the navigation process starts up right away or whether the transmitted destinations should first be placed into a local or a remote memory as a possible destination for later use. Possible values for this mode may include:
Subsequently, the value number_of_dest, (e.g., the number of destinations in this packet), may be established in this block. Then comes a loop which is run through exactly number_of_dest times. By this loop, the individual destinations are read out.
184.108.40.206 Destination String
The Destination string indicates the destination that is being transmitted. The string is made up of tags, the selection criteria, followed by the respective description. The selection criteria are in square brackets and contain a number (decimal). The string may look like:
DEUTSCHLAND,,0−73450,, McDonalds Ecuador
Likewise, there is the possibility of specifying a destination in WGS84 format. WGS-84 coordinates may have an inaccuracy of 50 meters (10 meters Nav-Tech data +20 meters inaccuracy of the GPS data in each direction) for destination guidance.
1.2.3 Service-ID SERVICE SERVERREQUEST
This service makes it possible for the server to query the current position of a device making the request. This information may be used for Location Based Services.
Current geo data may be transported to the server when a user logs onto the car radio or wireless web browser. The current geo data is, however, preferably supplied when the client's request are sent to the server through data packets or a data stream.
If the server wants position data at some future time, then the server may issue a request when needed. This functionality may be important to fleet management, placing an emergency call, return call actions, etc.
The client may need the URI or URL to which it should reply for the answer to the server's request. This is specified in this location. First, the length of the URL length_of_url is specified as an 8-bit value, and then comes the actual character string.
1.3 Request Packet (Client)
In the same way as the server reply, a more binary oriented format may be followed in client requests for data. The format of the data packet is described in more detail as follows:
In contrast to the service packet, the binary packet cannot simply be transmitted (push transmission), but must instead be attached to the request to the URI or URL, because of browser restrictions. This requires that the data be converted into a URI or URL-specific notation. In this embodiment, the length of the URI or URL should not exceed a total of 256 characters to remain compatible with older gateways that may cut off data that exceeds those limits.
By transmitting a Session ID in the packets being passed back and forth, it is not always necessary that an ongoing session be ended by a URI or URL call. For example, at the applicant's online portal, one may log in, for example, at the beginning of a session with the user's name and the user's password. Once logged in, the user is in a session in which the data is transmitted in an encoded form. As soon as an attempt is made to call a link with a self-generated URL not from the client, one starts a new session, as long as the server does not recognize that it is the same session based on the Session ID.
1.3.1 Format of the Data Packet
The format of the data packet is as follows: The Session ID can either be attached to the URL as a separate parameter or integrated into the data request packet. In the first case, the length of the Session ID is set to 0. An example of a Session ID set to 0 may be:
The tag task_name may still be contained in this format, to make the transmission from the old to the new easier. The actual request is in the service id tag. This is where the Service_ID that the receiver wants to use is specified, or consequently requested. If additional data is needed for individual requests, they may be to be implemented in the lower part of the packet.
The device_id is the client's device number, the same as in the server reply. It may comprise about 14 characters. The six values that may follow it may describe the current position of the vehicle in X and Y coordinates.
While various embodiments of the invention have been described, it will be apparent to those of ordinary skill in the art that many more embodiments and implementations are possible within the scope of the invention. Accordingly, the invention is not to be restricted except in light of the attached claims and their equivalents.