Home | | Mobile Communication | Application Layer

Chapter: Mobile Communication

Application Layer

1. WAP Model 2. Mobile Location based services 3. WAP Gateway 4. WAP protocols 5. WAP user agent profile 6. caching mode 7. wireless bearers for WAP 8. WML WMLScripts 9. WTA- iMode-,SyncML



1.     WAP Model

2.     Mobile Location based services

3.     WAP Gateway

4.     WAP protocols

5.     WAP user agent profile

6.     caching mode

7.     wireless bearers for WAP

8.     WML   WMLScripts

9.     WTA- iMode-,SyncML


Pre requisite discussion:


The growth of the internet, internet applications, and mobile communication led to many early proprietary solutions providing internet services for mobile, wireless devices. Some of the problems these partial solutions face were discussed in section


1.WAP Model



Figure below gives an overview of the WAP architecture, its protocols and components, and compares this architecture with the typical internet architecture when using the world wide web. This comparison is often cited by the WAP Forum and it helps to understand the architecture (WAP Forum, 2000a). This comparison can be misleading as not all components and protocols shown at the same layer are comparable. For consistency reasons with the existing specification, the following stays with the model as shown in Figure below The basis for transmission of data is formed by different bearer services. WAP does not specify bearer services, but uses existing data services and will integrate further services. Examples are message services, such as short message service (SMS) of GSM, circuit-switched data, such as high-speed circuit switched data (HSCSD) in GSM, or packet switched data, such as general packet radio service (GPRS) in GSM. Many other bearers are supported, such as CDPD, IS-136, PHS. No special interface has been specified between the bearer service and the next higher layer, the transport layer with its wireless datagram protocol (WDP) and the additional wireless control message protocol (WCMP), because the adaptation of

these protocols are bearer-specific (WAP Forum, 2000u). The transport layer offers a bearer independent, consistent datagram-oriented service to the higher layers of the WAP architecture. Communication is done transparently over one of the available bearer services. The transport layer service access point (T-SAP) is the common interface to be used by higher layers independent of the underlying network. The next higher layer, the security layer with its wireless transport layer security protocol WTLS offers its service at the security SAP (SEC-SAP). WTLS is based on the transport layer security (TLS, formerly SSL, secure sockets layer) already known from the www. WTLS has been optimized for use in wireless networks with narrow-band channels. It can offer data integrity, privacy, authentication, and (some) denial-of-service protection. The WAP transaction layer with its wireless transaction protocol (WTP) offers a lightweight transaction service at the transaction SAP (TR-SAP). This service efficiently provides reliable or unreliable requests and asynchronous transactions. Tightly coupled to this layer is the next higher layer, if used for connection-oriented service. The session layer with the wireless session protocol (WSP) currently offers two services at the session-SAP (S-SAP), one connection-oriented and one connectionless if used directly on top of WDP. A special service for browsing the web (WSP/B) has been defined that offers HTTP/1.1 functionality, long-lived session state, session suspend and resume, session migration and other features needed for wireless mobile access to the web. Finally the application layer with the wireless application environment (WAE) offers a framework for the integration of different scripting languages, special markup languages, interfaces to telephony applications, and many content formats adapted to the special requirements of small, handheld, wireless devices. Figure 10.9 not only shows the overall WAP architecture, but also its relation to the traditional internet architecture for www applications. The WAP transport layer together with the bearers can be (roughly) compared to the services offered by TCP or UDP over IP and different media in the internet. If a bearer in the WAP architecture already offers IP services (e.g., GPRS, CDPD) then UDP is used as WDP. The TLS/SSL layer of the internet has also been adopted for the WAP architecture with some changes required for optimization. The functionality of the session and transaction layer can roughly be compared with the role of HTTP in the web architecture. However, HTTP does not offer all the additional mechanisms needed for efficient wireless, mobile access (e.g., session migration, suspend/resume). Finally, the application layer offers similar features as HTML and Java. Again, special formats and features optimized for the wireless scenario have been defined and telephony access has been added. WAP does not always force all applications to use the whole protocol architecture. Applications can use only a part of the architecture. For example, this means that, if an application does not require security but needs the reliable transport of data, it can directly use a service of the transaction layer. Simple applications can directly use WDP. Different scenarios are possible for the integration of WAP components into existing wireless and fixed networks (see Figure 10.10). On the left side, different fixed networks, such as the traditional internet and the public switched telephone network (PSTN), are shown. One cannot change protocols and services of these existing networks so several new elements will be implemented between these networks and the WAP-enabled wireless, mobile devices in a wireless network on the right-hand side.




     interoperable, i.e., allowing terminals and software from different vendors to communicate with networks from different providers;


     scaleable, i.e., protocols and services should scale with customer needs and number of customers;


     efficient, i.e., provision of QoS suited to the characteristics of the wireless and mobile networks;


     reliable, i.e., provision of a consistent and predictable platform for deploying services; and


     secure, i.e., preservation of the integrity of user data, protection of devices and services from security problems.


2.               Mobile Location based services




The wireless datagram protocol (WDP) operates on top of many different bearer services capable of carrying data. At the T-SAP WDP offers a consistent datagram transport service independent of the underlying bearer (WAP Forum, 2000b). To offer this consistent service, the adaptation needed in the transport layer can differ depending on the services of the bearer. The closer the bearer service is to IP, the smaller the adaptation can be. If the bearer already offers IP services, UDP (Postel, 1980) is used as WDP. WDP offers more or less the same services as UDP. WDP offers source and destination port numbers used for multiplexing and demultiplexing of data respectively. The service primitive to send a datagram is


TDUnitdata. req with the destination address (DA), destination port (DP), Source address (SA), source port (SP), and user data (UD) as mandatory parameters. Destination and source address are unique addresses for the receiver and sender of the user data. These could be MSISDNs (i.e., a telephone number), IP addresses, or any other unique identifiers. The T-DUnitdata.ind service primitive indicates the reception of data. Here destination address and port are only optional parameters.

If a higher layer requests a service the WDP cannot fulfill, this error is indicated with the T-DError.ind service primitive as shown in. An error code (EC) is returned indicating the reason for the error to the higher layer. WDP is not allowed to use this primitive to indicate problems with the bearer service. It is only allowed to use the primitive to indicate local problems, such as a user data size that is too large. If any errors happen when WDP datagrams are sent from one WDP entity to another (e.g. the destination is unreachable, no application is listening to the specified destination port etc.), the wireless control message protocol (WCMP) provides error handling mechanisms for WDP (WAP Forum, 2000r) and should therefore be implemented. WCMP contains control messages that resemble the internet control message protocol (ICMP (Postel, 1981b) for IPv4, (Conta, 1998) for IPv6) messages and can also be used for diagnostic and informational purposes. WCMP can be used by WDP nodes and gateways to report errors. However, WCMP error messages must not be sent as response to other WCMP error messages. In IP-based networks, ICMP will be used as WCMP (e.g., CDPD, GPRS). Typical WCMP messages are destination unreachable (route, port, address unreachable), parameter problem (errors in the packet header), message too big, reassembly failure, or echo request/reply. An additional WDP management entity supports WDP and provides information about changes in the environment, which may influence the correct operation of WDP. Important information is the current configuration of the device, currently available bearer services, processing and memory resources etc. Design and implementation of this management component is considered vendor-specific and is outside the scope of WAP. If the bearer already offers IP transmission, WDP (i.e., UDP in this case) relies on the segmentation (called fragmentation in the IP context) and reassembly capabilities of the IP layer as specified in (Postel, 1981a). Otherwise, WDP has to include these capabilities, which is, e.g., necessary for the GSM SMS



Makes the Mobile systems faster.


The WAP is applied in almost all the Base Station infrastructures.


3. WAP Gateway



If requested by an application, a security service, the wireless transport layer security (WTLS), can be integrated into the WAP architecture on top of WDP as specified in (WAP Forum, 2000c). WTLS can provide different levels of security (for privacy, data integrity, and authentication) and has been optimized for low bandwidth, high-delay bearer networks. WTLS takes into account the low processing power and very limited memory capacity of the mobile devices for cryptographic algorithms. WTLS supports datagram and connection-oriented transport layer protocols. New compared to, e.g. GSM, is the security relation between two peers and not only between the mobile device and the base station (see chapter 4). WTLS took over many features and mechanisms from TLS (formerly SSL, secure sockets layer (Dierks, 1999)), but it has an optimized handshaking between the peers.

Before data can be exchanged via WTLS, a secure session has to be established. This session establishment consists of several steps: illustrates the sequence of service primitives needed for a so-called full handshake  (several optimizations are possible). The originator and the peer of the secure session can both interrupt session establishment any time, e.g., if the parameters proposed are not acceptable. The first step is to initiate the session with the SEC-Create primitive. Parameters are source address (SA), source port (SP) of the originator, destination address

(DA), destination port (DP) of the peer. The originator proposes a key exchange suite (KES)


(e.g., RSA (Rivest, 1978), DH (Diffie, 1976), ECC (Certicom, 2002)), a cipher suite (CS) (e.g., DES, IDEA (Schneier, 1996), and a compression method (CM) (currently not further specified). The peer answers with parameters for the sequence number mode (SNM), the key refresh cycle (KR) (i.e., how often keys are refreshed within this secure session), the session identifier (SID) (which is unique with each peer), and the selected key exchange suite (KES  ), cipher suite (CS  ), compression method (CM .The) peer also issues a SEC-Exchange primitive. This indicates that the peer wishes to perform public-key authentication with the client, i.e., the peer requests a client certificate (CC) from the originator. The first step of the secure session creation, the negotiation of the security parameters and suites, is indicated on the originator  s side, followed by the request for a certificate. The originator answers with its certificate and issues a SEC-Commit.req primitive. This primitive indicates that the handshake is com pleted for the originator  s side and that the originator now wants to switch into the newly negotiated connection state. The certificate is delivered to the peer side and the SEC-Commit is indicated. The WTLS layer of the peer sends back a confirmation to the originator. This concludes the full handshake for secure session setup. After setting up a secure connection between two peers, user data can be exchanged. This is done using the simple SEC-Unitdata primitive as shown in the figure below. SEC-Unitdata has exactly the same function as T-DUnitdata on the WDP layer, namely it transfers a datagram between a sender and a receiver. This data transfer is still unreliable, but is now secure. This shows that WTLS can be easily plugged into the protocol stack on top of WDP. The higher layers simply use SEC-Unitdata instead of T-DUnitdata. The parameters are the same here: source address (SA), source port (SP), destination address (DA), destination port (DP), and user data (UD). This section will not discuss the security-related features of WTLS or the pros and cons of different encryption algorithms. The reader is referred to the specification (WAP Forum, 2000c) and excellent cryptography literature e.g., (Schneier, 1996), (Kaufman, 1995). Although WTLS allows for different encryption mechanisms with different key lengths, it is quite clear that due to computing power on the handheld devices the encryption provided cannot be very strong. If applications require stronger security, it is up to an application or a user to apply stronger encryption on top of the whole protocol stack and use WTLS as a basic security level only. Many programs are available for this purpose. It is important to note that the security association in WTLS exists between the mobile WAP-enabled device and a WAP server or WAP gateway only. If an application accesses another server via the gateway, additional mechanisms are needed for end-to-end security. If for example a user accesses his or her bank account using WAP, the WTLS security association typically ends at the WAP gateway inside the network operator  s domain. The bank and user will want to apply additional security mechanisms in this scenario. Future work in the WTLS layer comprises consistent support for application level security (e.g. digital signatures) and different implementation classes with different capabilities to select from.


4. WAP protocols Conept:


The wireless transaction protocol (WTP) is on top of either WDP or, if security is required, WTLS (WAP Forum, 2000d). WTP has been designed to run on very thin clients, such as mobile phones. WTP offers several advantages to higher layers, including an improved reliability over datagram services, improved efficiency over connection-oriented services, and support for transaction-oriented services such as web browsing. In this context, a transaction is defined as a request with its response, e.g. for a web page. WTP offers many features to the higher layers. The basis is formed from three classes of transaction service as explained in the following paragraphs. Class 0 provides unreliable message transfer without any result message. Classes 1 and 2 provide reliable message transfer, class 1 without, class 2 with, exactly one reliable result message (the typical request/response case). WTP achieves reliability using duplicate removal, retransmission, acknowledgements and unique transaction identifiers. No WTP-class requires any connection set-up or tear-down phase. This avoids unnecessary overhead on the communication link. WTP allows for asynchronous transactions, abort of transactions, concatenation of messages, and can report success or failure of reliable messages (e.g., a server cannot handle the request). To be consistent with the specification, in the following the term initiator is used for a WTP entity initiating a transaction (aka client), and the term responder for the WTP entity responding to a transaction (aka server). The three service primitives offered by WTP are TR-Invoke to initiate a new transaction, TR-Result to send back the result of a previously initiated transaction, and TR-Abort to abort an existing transaction. The PDUs exchanged between two WTP entities for normal transactions are the invoke PDU, ack PDU, and result PDU. The use of the service primitives, the PDUs, and the associated parameters with the classes of transaction service will be explained in the following sections. A special feature of WTP is its ability to provide a user acknowledgement or, alternatively, an automatic acknowledgement by the WTP entity. If user acknowledgement is required, a WTP user has to confirm every message received by a WTP entity. A user acknowledgement provides a stronger version of a confirmed service because it guarantees that the response comes from the user of the WTP and not the WTP entity itself.


WTP class 0


Class 0 offers an unreliable transaction service without a result message. The transaction is stateless and cannot be aborted. The service is requested with the TR-Invoke.req primitive as shown in Figure 10.14. Parameters are the source address (SA), source port (SP), destination address (DA), destination port (DP) as already explained in section 10.3.2. Additionally, with the A flag the user of this service can determine, if the responder WTP entity should generate an acknowledgement or if a user acknowledgement should be used. The WTP layer will transmit the user data (UD) transparently to its destination. The class type C indicates here class 0. Finally, the transaction handle H provides a simple index to uniquely identify the transaction and is an alias for the tuple (SA, SP, DA, DP), i.e., a socket pair, with only local significance.

The WTP entity at the initiator sends an invoke PDU which the responder receives. The WTP entity at the responder then generates a TR-Invoke.ind primitive with the same parameters as on the initiator  s side, except for H  which is now the local handle for the transaction on the responder  s side. In this class, the responder does not acknowledge the message and the initiator does not perform any retransmission. Although this resembles a simple datagram service, it is recommended to use WDP if only a datagram service is required. WTP class 0 augments the transaction service with a simple datagram like service for occasional use by higher layers.



WTP class 1


Class 1 offers a reliable transaction service but without a result message. Again, the initiator sends an invoke PDU after a TR-Invoke.req from a higher layer. This time, class equals 1  , and no user acknowledgement has been selected as shown in Figure 10.15. The responder signals the incoming invoke PDU via the TR-Invoke.ind primitive to the higher layer and acknowledges automatically without user intervention. The specification also allows the user on the responder  s side to acknowledge, but this acknowledgement is not required. For the initiator the transaction ends with the reception of the acknowledgement. The responder keeps the transaction state for some time to be able to retransmit the acknowledgement if it receives the same invoke PDU again indicating a loss of the acknowledgement. If a user of the WTP class 1 service on the initiator  s side requests a user acknowledgement on the responder  s side, the sequence diagram looks like the fig below. Now the WTP entity on the responder  s side does not send an acknowledgement automatically, but waits for the TR-Invoke.res service primitive from


the user. This service primitive must have the appropriate local handle H  for identification of the right transaction. The WTP entity can now send the ack PDU. Typical uses for this transaction class are reliable push services.


WTP class 2


Finally, class 2 transaction service provides the classic reliable request/response transaction known from many client/server scenarios. Depending on user requirements, many different scenarios are possible for initiator/responder interaction. Three examples are presented below. The basic transaction of class 2 without-user acknowledgement. Here, a user on the initiator  s side requests the service and the WTP entity sends the invoke PDU to the responder. The WTP entity on the responder  s side indicates the request with theTR-Invoke.ind primitive to a user. The responder now waits for the processing of the request, the user on the responder  s side can finally give the result UD* to the WTP entity on the responder.


Wireless session protocol


The wireless session protocol (WSP) has been designed to operate on top of the datagram service WDP or the transaction service WTP (WAP Forum, 2000e). For both types, security can be inserted using the WTLS security layer if required. WSP provides a shared state between a client and a server to optimize content transfer. HTTP, a protocol WSP tries to replace within the wireless domain, is stateless, which already causes many problems in fixed networks. Many web content providers therefore use cookies to store some state on a client machine, which is not an elegant solution. State is needed in web browsing, for example, to resume browsing in exactly the same context in which browsing has been suspended. This is an important feature for clients and servers. Client users can continue to work where they left the browser or when the network was interrupted, or users can get their customized environment every time they start the browser. Content providers can customize their pages to clients  needs and do not have to retransmit the same pages over and over again. WSP offers the following general features needed for content exchange between cooperating clients and servers:



  Session management: WSP introduces sessions that can be established from a client to a server and may be long lived. Sessions can also be released in an orderly manner. The capabilities of suspending and resuming a session are important to mobile applications. Assume a mobile device is being switched off it would be useful for a user to be able to continue operation at exactly the point where the device was switched off. Session lifetime is independent of transport connection lifetime or continuous operation of a bearer network.

Capability negotiation: Clients and servers can agree upon a common level of protocol functionality during session establishment. Example parameters to negotiate are maximum client SDU size, maximum outstanding requests, protocol options, and server SDU size.

Content encoding: WSP also defines the efficient binary encoding for the content it transfers. WSP offers content typing and composite objects, as explained for web browsing.


5. WAP user agent profile



The schema for WAP User Agent Profiles consists of description blocks for the following key components:


HardwarePlatform: A collection of properties that adequately describe the hardware characteristics of the terminal device. This includes, the type of device, model number, display size, input and output methods, etc.


SoftwarePlatform: A collection of attributes associated with the operating environment of the device. Attributes provide information on the operating system software, video and audio encoders supported by the device, and user  s preference on language .


BrowserUA: A set of attributes to describe the HTML browser application NetworkCharacteristics: Information about the network-related infrastructure and environment such as bearer information. These attributes can influence the resulting content, due to the variation in capabilities and characteristics of various network infrastructures in terms of bandwidth and device accessibility.


WapCharacteristics: A set of attributes pertaining to WAP capabilities supported on the device. This includes details on the capabilities and characteristics related to the WML Browser, WTA [WTA], etc.



Faster when compared to all other user agent profiles.


6. Caching mode Conept:


Caching can reduce the bandwidth requirement in a mobile computing environment. However, due to battery power limitations, a wireless mobile computer may often be forced to operate in a doze (or even totally disconnected) mode. As a result, the mobile computer may miss some cache invalidation reports broadcast by a server, forcing it to discard the entire cache contents after waking up. In this paper, we present an energy-efficient cache invalidation method, called GCORE (Grouping with COld update-set REtention), that allows a mobile computer to operate in a disconnected mode to save the battery while still retaining most of the caching benefits after a reconnection. We present an efficient implementation of GCORE and conduct simulations to evaluate its caching effectiveness. The results show that GCORE can substantially improve mobile caching by reducing the communication bandwidth (or energy consumption) for query processing


While a WSP session is established (whether active or suspended), the WAP gateway caches all Profile and Profile- Diff headers associated with that session. A third party host may issue a request for this CPI to, for instance, generate content that wil subsequently be pushed to the client device. The request is initiated from the third-party host and delivered to a Push Protocol Gateway (PPG). This specification defines neither a protocol for issuing this request nor a means for addressing the requested information. However, it is expected that such requests will typically be made to the WAP gateway using HTTP, as suggested by [WAP-PAP]. Upon receiving the profile request, the gateway accesses the cached Profile and Profile-Diff headers and resolves them to form a complete CPI profile. It responds to the CPI request with the resolved profile (a CC/PP document) using a MIME type of text/xml.


It is important to note that the WAP gateway has incomplete information about the current CPI. In particular, the gateway is not aware of any request-specific profile information that the client would have provided to the requesting third-party server. Moreover, the WAP gateway cannot incorporate attribute information from Profile-Diff headers that would have been added by intermediate proxies through which the request would have passed had it originated at the client device. Finally, if the WSP session is currently suspended, then the gateway may be caching out-of-date profile information.



7. Wireless bearers for WAP



The above one defines properties for conformant User Agent Profiles, which are structured according to the CC/PP note [CC/PP], and correspondingly use RDF XML serialization syntax. This section defines a set of single-byte tokens corresponding to the attribute names and values of the RDF serialization syntax. These tokens are distributed among three code pages. Code page zero (0) defines tokens for RDF serialization attributes. Code page one (1) defines tokens for properties in the core profile schema. Code page two (2) defines tokens for properties in the Browser useragent component of the schema. User agents or applications other than the browser may define additional attribute code pages for their own properties. Each user agent or application that wants to define properties for use in the user agent profile MUST first define a component to hold its properties. The name of the component MUST be globally unique. Each such user agent component is considered to have a unique namespace, so that, for example, the property BackgroundColor for User Agent A is a property distinct from the property BackgroundColor for User Agent B. See Section 7for more information. In addition, each user agent or application SHOULD define a series of token table code pages containing the properties from its component. If it chooses to define code pages, then it SHOULD define at least two: one in the "Tag" space and one in the "Attribute" space. The property names SHOULD be inserted into each page. Any wellknown values for the properties should be inserted into the "Attribute" page. Additional pages may be required if the component contains a large number of properties. A default user agent has been defined as part of the schema: the browser.




These wireless bearers provides a major advantage of making a wireless telecommunication using the WAP


8. WML  WMLScripts



WML (Wireless Markup Language), formerly called HDML (Handheld Devices Markup Languages), is a language that allows the text portions of Web pages to be presented on cellular telephones and personal digital assistants (PDAs) via wireless access. WML is part of the Wireless Application Protocol (WAP) that is being proposed by several vendors to standards bodies. The Wireless Application Protocol works on top of standard data link protocols, such as Global System for Mobile communication, code-division multiple access, and Time Division Multiple Access, and provides a complete set of network communication programs comparable to and supportive of the Internet set of protocols.


WML is an open language offered royalty-free. Specifications are available at Phone.com's Web site. According to Phone.com, any programmer with working knowledge of HTML, common gateway interface, and Structured Query Language should be able to write a presentation layer using WML. A filter program can be written or may be available from a vendor that will translate HTML pages into WML pages.



This WML is much more preferred than the HTML mainly because of its User interface


9. WTA- iMode-,SyncM



The most common wireless technologies use radio. With radio waves distances can be short, such as a few meters for television or as far as thousands or even millions of kilometers for deep-space radio communications. It encompasses various types of fixed, mobile, and portable applications, including two-way radios, cellular telephones, personal digital assistants (PDAs), and wireless networking. Other examples of applications of radio wireless technology include GPS units, garage door openers, wireless computer mice, keyboards and headsets, headphones, radio receivers, satellite television, broadcast television and cordless telephones.


Somewhat less common methods of achieving wireless communications include the use of other electromagnetic wireless technologies, such as light, magnetic, or electric fields or the use of sound.


Light, colors, AM and FM radio, and electronic devices make use of the electromagnetic spectrum. The frequencies of the radio spectrum that are available for use for communication are treated as a public resource and are regulated by national organizations such as the Federal Communications Commission in the USA, or Ofcom in the United Kingdom. This determines which frequency ranges can be used for what purpose and by whom. In the absence of such control or alternative arrangements such as a privatized electromagnetic spectrum, chaos might result if, for example, airlines didn't have specific frequencies to work under and an amateur radio operator were interfering with the pilot's ability to land an aircraft. Wireless communication spans the spectrum from 9 kHz to 300 GHz.




Wi-Fi is a wireless local area network that enables portable computing devices to connect easily to the Internet. Standardized as IEEE 802.11 a,b,g,n, Wi-Fi approaches speeds of some types of wired Ethernet. Wi-Fi has become the de facto standard for access in private homes, within offices, and at public hotspots.[19] Some businesses charge customers a monthly fee for service, while others have begun offering it for free in an effort to increase the sales of their goods.


Cellular data service offers coverage within a range of 10-15 miles from the nearest cell site. Speeds have increased as technologies have evolved, from earlier technologies such as GSM, CDMA and GPRS, to 3G networks such as W-CDMA, EDGE or CDMA2000.


Mobile Satellite Communications may be used where other wireless connections are unavailable, such as in largely rural areasor remote locations. Satellite communications are especially important for transportation, aviation, maritime and military use


Wireless Sensor Networks are responsible for sensing noise, interference, and activity in data collection networks. This allows us to detect relevant quantities, monitor and collect data, formulate meaningful user displays, and to perform decision-making functions.




Study Material, Lecturing Notes, Assignment, Reference, Wiki description explanation, brief detail
Mobile Communication : Application Layer |

Privacy Policy, Terms and Conditions, DMCA Policy and Compliant

Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.