Beyond WAP. By Zhongyin J. Daye Han-Chung Lee

Beyond WAP By Zhongyin J. Daye Han-Chung Lee

Abstract & Scope The research investigates the various aspects of the Wireless Application Protocol (WAP) in relations to its substitutable wireless standards and proposals. It then suggests modifications and alternatives of the WAP suite for the 2.5 and 3 G wireless infrastructure. The transport and networking layer discussion focuses upon the WAP integration over the CDMA technology and considers only SMS and Packet Data as the bearer within CDMA, wherein SMS represents the current wireless network bearer in the US and the CDMA Packet Data suffices as the 3G wireless network bearer. The optional Wireless Transport Layer Security (WTLS) stack is omitted to facilitate concentration upon the core transport stacks. To avert connotational misunderstanding, a few terminologies are redefined herein. The phrase Application Layer does NOT refer to the Open Systems Interconnection (OSI) reference model but to the protocols/applications running upon the transport layer. The phrase Transport Layer refers to the transport layer of the OSI reference model. And the phrase Network Layer refers to the network layer of the OSI reference model.

The Wireless Application Protocol (WAP) Via the development of the Internet and the telecom industry, the convergence of the Internet and wireless devices such as cellular phones and PDAs finally becomes a reality. Though desperate in providing mobile Internet services, wireless service providers are concerned about low bandwidth and limited network resources. Wireless terminals low processing and battery power deeply ensnares the metamorphosis. Furthermore, the Transport Control Protocol/Internet Protocol (TCP/IP) that initiated the Internet revolution seems inapt for the current wireless wide area communication systems. During the development of WAP, instead of the TCP/IP, the telecom companies offer a myriad of protocols at the networking layer, destining the advent of a convergent protocol. The wireless terminal devices at the time also lack computational power to accommodate the HTTP and HTML application layers. WAP Architecture [WAP] Wireless Application Environment (WAE) The WAE introduces an application development environment that composes of the Wireless Markup Language (WML), WMLScript, Wireless Telephony Application (WTA, WTAI), and Content Formats. Furthermore TCP does not support high latency and low bandwidth communication links that are characteristic of the wireless systems. TCP assumes low error rates over wired networks and hence assumes all packet losses as results of congestion. In a wireless environment, the presence of high error rates renders the congestion assumption absurd. Especially during a handoff, the TCP at sender will interpret the result as a congestion, drops transmission window size, initiates congestion control mechanisms, and resets transmission timer using exponential backoff computation of previous values, rendering significant yet unnecessary reduction in bandwidth. Instead of modifying the existing TCP/IP stack to support wireless networks, the WAP technology group manufactured a new protocol stack that reuses HTTP and complements the current wireless networks. To create WAP, major telecom giants purported and consolidated the WAP Forum. The Forum is responsible for designing the new set of protocols that address the efficiency needs of mobile wireless devices. Treating mobile devices as unique cases, the Forum develops an entire new stack of network protocols analogous to the existing TCP/IP stack. Wireless Session Protocol (WSP) WSP provides the application layer of WAP with a consistent interface for two session services. The first is a connection-oriented service that operates above the transaction layer protocol WTP. The second is a connectionless service that operates above a secure or non-secure datagram service (WDP). The protocol allows WSP client to connect to standard HTTP server connection through the WAP proxy server. Wireless Transaction Protocol (WTP) WTP runs on top a datagram service and optionally a security service. WTP offers transaction services including unreliable one-way requests, reliable oneway requests, and reliable two-way request-reply transactions. Wireless Transport Layer Security (WTLS) The WTLS provides wireless data integrity, privacy, authentication, and denial-of-service protection. Wireless Datagram Protocol (WDP) WDP is the transport layer protocol of WAP that offers communication between the upper layer protocols of WAP and bearer services, such as short message, circuit-switched data, and packet data. [WDP] The WAP specification supports the following wireless network bearers: CDMA, GSM, TDMA, IS- 136, PDC, PHS, FLEX, ReFLEX, iden, TETRA, DECT, DataTAC, and Mobitex.

Future Wireless Environment Indulged in the 2G wireless networks systems, WAP is confronting an ever more imminent threat with the introduction of 2.5 and 3 G. A. Mobile multimedia services will become more complex and advanced as the bandwidth increases. The current WAP is only capable of supporting simple multimedia contents such as images and text. Services such as streaming media remain unattainable by the current protocol. Platform Networking System Cost per Base Station Cost per Operator Maximum Data Transmission Rate CDPD TDMA Circuit Switched $500-1000 $3-6 million 32kbps HSCSD GSM Circuit Switched $4000 $20-30 million 57.6kbps GPRS GSM Packet Switched $20,000 $50-120 million 115kbps EDGE GSM Packet Switched $70,000 $300-600 million 384kbps IS-136+ TDMA Circuit/Packet $20,000 $50-120 million 64kbps Switched IS-95B CDMA Packet Switched $20,000 $50-120 million 64kbps 1XRTT CDMA Packet Switched $70,000 $300-600 million 144kbps W-CDMA GSM/PDC Packet Switched N/A N/A 2Mbps IS-136HS/UWC- TMDA Packet Switched $70,000 $300-600 million 384kbps 136 CDMA2000 CDMA Packet Switched N/A N/A 144kbps Generation Attributes Applications First Analog Basic Voice Second Digital, 9.6kbps Advanced Voice, SMS 2.5 Digital, 57.6-384kbps SMS, Internet Third Digital, 384kbps-2Mbps Video, Internet, Multimedia Bandwidth Evolution [Farrell99 & Beyond WAP Group] B. The introduction of new networks systems may render the current WAP transport protocol obsolete. 2.5G networks such as HSCSD, EDGE, IS-136+, IS-95B, 1XRTT, and 3G networks such as W-CDMA, IS- 136HS/UWC-136, and CDMA2000 can be difficult to implement with the current WAP Datagram Protocol. WAP 2G 2.5G 3G PDC GSM TDMA IS136 CDMA CDPD PHS FLEX ReFLEX IDEN TETRA DECT DataTAC Mobitex PDC GSM TDMA IS136 CDMA IS-95 CDPD HSCSD GPRS EDGE IS-136+ IS-95B 1XRTT W-CDMA IS-136HS/UWC-136 CDMA2000 Illustration of Telecom Development [wapforum00, Farrell99, & Beyond WAP Group]

Protocol Stack Overview The Lightweight and Efficient Application Protocol (LEAP) [Banan00], [BananM00] LEAP substantiates as a set of wireless application protocols originally intended for wireless small message deliverance. The current LEAP architecture also supports web browsing and emailing. The Application Layer The protocol s claim for efficiency originates from its EMSD protocol. By using smaller overheads, the protocol offers four or more times efficiency increase relative to other messaging protocols. LEAP Protocol Organization [BananM00] Efficient Transport Services (ESRO): ESRO provides the lowest layer for the LEAP protocols stack. By offering reliable connectionless transport services, ESRO allows various applications to be built. Efficient Mail Submission and Delivery (EMSD): The service parallels that of the existing SMTP protocols, by providing message submission and delivery capabilities. The protocol is especially optimized for efficiency for CDPD, Wireless-IP, and Mobile-IP wireless networks. Efficient HyperText Delivery (EHTD): The protocol will provide efficient transfer of short markup pages. A plethora of markup languages are claimed to be supportable by EHTD. Currently, the protocol is still under development. Efficient Dictionary Protocol (E-DICT): The E-DICT is intended to offer efficient access to dictionaries and other look-up data structures. The protocol is still under development. EMSD performance evaluation [BananM00] WAP LEAP Closed protocol Patent-free Inherent Security Imposes no security Vulnerability assumptions Inconsistent protocol Consistent protocol number number assignment assignment WAP vs. LEAP [BananM00] Conclusion: The protocol lacks substance relative to the current Wireless Application Protocol. LEAP is originally intended for small messaging applications (approx. 4K). Many of its proposed protocols (e.g. EHTD and E-DICT) are still under development. Furthermore, based upon messaging protocols, LEAP is not likely to support the multimedia services enabled by the 3G-wideband systems

The Application Layer IMode[Euro00] Supporting equivalent services to WAP, imode becomes a dominant contender against WAP, possessing 60% of the world s wireless Internet users and rending WAP to second place. Application Language Market Division [Euro00] Imode prioritizes chtml instead of WML as its developing language. Though WML is quite similar to HTML, it does offer fundamental new concepts like the card/deck concept in which HTML-ish pages are subdivided into cards and decks and strict restrictions. Imode, on the other hand, is solely build upon the current HTML and simply imposes guidelines (as regards to character limitations, etc.) and offers a smaller set of tags. In essence, to someone familiar with HTML, one can program in chtml instantly by following a list of guidelines and tags presentable at http://www.nttdocomo.com/i/tagindex.html. Bombarded by specialized tags and new concepts, WML prohibits immediate development. Hence, imode s barrier to developers is lessened in relation to WAP s. Using a packaged switched system in Japan, imode supports an always on, no dial-in, data packet priced service. WAP however uses circuit-switched (dialup) system that forces users to wait during dial-up and charges users by connection time instead of data size. Imode also excel in supporting color animated gifs and sophisticated downloads. Its partnership with JAVA also enables its handsets to download and run Java Applets. [See JAVA ] Imode and WAP are both introduced in Japan and suffice the Japanese market as a battlefield between WAP and imode. With three times more imode users in Japan than WAP users, the trend is apparent that imode is likely to replace WAP if marketed worldwide. From both technical and industrial perspectives, imode is different from WAP by nature. WAP is a simple application protocol for the mobile phones while imode is more like a brand name purported by NTT DoCoMo. The imode competitive edge is enabled by the vertical industrial dominance that NTT DoCoMo has over the Japanese communications industry. By packaging all aspects of the industry under one management, NTT DoCoMo is more capable of integrating support and improvement for imode. Imode s packaged switch system is not something that WAP is capable of implementing, but, instead, it is subject to the will of telecom bearer service providers. However, NTT DoCoMo will have a harder time implementing imode worldwide. Imode is not designed for the different telecom infrastructures that were implemented. To support imode, the targeted area must have existing packet switched IP systems. WAP on the other hand is quite easily implemented upon different bearer systems and makes WAP more attractive to the European nations that have varied systems. Imode s current dominance is build upon the Japanese susceptibility to new gadgets. With greater prevalence of mobile data services in non- Japanese nations, WAP will become more dominant. Imode chtml Packet switched Colored gifs Application and applet downloads WAP WML Circuit switched Wireless (uncolored) bmp Server-centric application Mobile Markup Language (MML) The MML, developed by MOBiDY, is intended to suffice as a WWW application protocol that can apply to current narrow-band oriented cell phone and wider bandwidth later on. Similar to imode s chtml concept, MML is an application layer language built upon the HTML. By shortening HTML tags, MML positions itself as an HTML subset. MML also compresses HTML and removes many of its functionalities. By following the HTML 4.0 standard, MML seeks to lower the learning barrier for developers.

The MML comprises three subsets to accommodate different devices. The Small MML (S-MML) supports minimum mobile terminal. The Middle MML (M- MML) supports mobile terminal with higher performances while the Full MML offers complete support of HTML4.0. S-MML M-MML Full MML 12 letters by 4 ¼ VGA display PC display lines display No Images Images support Images support Tables not indicated Tables not indicated Tables indicated MML Subsets [MOBIDY00] The MML offers a Proxy server (similar to the WAP concept) to intelligently determine MML levels and perform information filtering to optimize mobile transmission. The introduction of the Proxy leaves the MML standard to target more upon the high-end terminal and to offer fuller supports. Proxy Concept [MOBIDY00] MML is built chiefly upon the SMS system that accommodates the smallest data transmission capacity. Nonetheless, it is directly applicable also to circuit and packet switching systems. MML network architecture [MOBIDY00] MML s chief strength over WAP is in its attempt to support HTML 4.0 and improvisation of the subet concept. The future wireless market is certainly to be divided into different niches according to different devices. By providing a common language that intentionally supports division of levels of devices, MML appeals to developers who wishes to use the same language for different devices. JAVA At the heart of the JAVA wireless application platform is the Java 2 Platform, Micro Edition (J2ME). The J2ME seeks to offer support for any and all consumer information appliances or devices with embedded controllers. [Heiss99] The new technology allows dynamic download and implementation of new applications over the wireless network. Moreover, by using a vector-driven clientgenerated graphics tactics as opposed to the bitmapped strategy, Java ensures the viability of realtime games such as Tetris and 3D Maze. [Meloan00] Like all Java products, the J2ME promotes code reuse upon a variety of wireless devices from PDA s to screen phones and to pages. This simplifies application transition to improving device and system architecture. The inclusion of the K Virtual Machine (KVM), the Mobile Information Device (MID) profile, and PersonalJava platform further enhances the JAVA prominence. The K Virtual Machine (KVM) provides a highly optimized runtime environment for small hand-held devices such as digital phones, pagers, and PDA s that are limited by memory, processing power, and display capabilities. By offering multithreading and garbage collection, KVM emulates the standard Java virtual machine and is compatible to work with Java 2 Platform, Standard Edition (J2SE) and the Java 2 Platform, Enterprise Edition (J2EE). A Mobile Information Device (MID) profile offers APIs that facilitates user interface, persistent storage, security and messaging on wireless devices.

JavaPhone API is created to suffice as a programming interface that provides direct telephony control, datagram messaging, address book and calendar information, user profile access, power monitoring, and application installation. Wireless APIs [Source: Sun Microsystems, Inc.] The Java wireless development is marked by strong industrial alliances. Its alliance with NTT DoCoMo to improve upon the imode system is especially noteworthy. The companies are integrating Sun s Java, Jini, and JavaCard technologies with the imode digital technology and the 3G W-CDMA services. The Java addition to imode will enhance security and enables game downloads and device interactivity. KVM Enabled Imode Phones [Source: Sun Microsystems, Inc.] HDML The Handheld Device Markup Language (HDML) is the forerunner of the current WML. It is developed by the Unwired Planet, currently phone.com, and the current WML inherits the HDML concepts. The HDML is developed for narrowband width handheld devices and originally introduces the deck/card concept. With restricted display size and lack of context for traditional navigation, the deck/card concept is improvised. This concept provides discrete packages that enable transaction-based navigation. A card is equivalent to a page on the Internet browsers, and a deck is a group of cards. Different types of cards exist to accommodate data displaying, data inputting, and choice listing tasks. Cards are packaged into a deck and transmitted from the application provider to the mobile agent all at once. This limits number of wireless transmissions while guaranteeing limited data display. Emulated and condensed versions of the HTML tag concept are also implemented. WAP improvements By introducing WML into the application architecture, the suite forces developers to create dual sites one in WML and one in HTML, for mobile and wireless users correspondingly. The restriction imposes inconvenience to developers and aggregates costs for application providers. The effect is compounded with NTT DoCoMo s imode service that purports a form of compact HTML (chtml) and J-Phone s MML (Mobile Markup Language). Hence, the application providers must also create a third and fourth site using compact HTML and MML if they intend to distribute their services world-wide. WAP (Wireless Application Protocol) WML i-mode CHTML (Compact Hyper Text Markup Language) Closed J-Phone Group MML (Mobile Markup Language) Open Standard standard Closed Standard Current wireless application environmental standards [Source: WAP Forum, NTT DoCoMo, J- Phone Group] Resolution: WAP 2.0 The industry hopes to address the issue in its next standard, WAP 2.0, publishable by the end of 2000. The standard will converge WAP and XHTML. The XHTML is the next generation HTML that seeks to separate content from transmission.

become standardized on all networks. With standardization using IP and implementing highefficiency protocols above layer 3, the wireless networks can become Internet-uncentric, shattering the WAP claim to Internet-centricity in wireless communications. Wap vs. TCP/IP When engineering WAP, the WAP Forum technology group employed the TCP/IP protocol stack as its fundamental reference, hence resulting in the WAP and TCP/IP resemblance. The following is a comparison of WAP and TCP/IP. Converging Wireless Standards [Source: Phone.com] On- the-fly Conversion A temporary solution would be to convert HTML pages to WML pages on the fly through software programming. Several WAP proxy servers are capable of supporting such conversion already. Advanced Browsers Several vendors are also seeking to build HTML functionality directly into the WAP browsers. Conclusion: Due to the excess of markup standards proposed and their deviance from standard application languages, mobile application and content providers experience great inconveniences. The proposed WAP 2.0 offers an optimal solution with its convergence with XHTML while the imode will persist as a functional superior development environment. Java will act as a development supplement instead of an independent environment. The trend is easily seen with its alliance with NTT DoCoMo. MML will share the market with its revolutionary subset concept while HDML will be replaced by its more functional WML descendent The Transport Layer Wireless networks are rapidly standardizing towards the Internet Protocol. Most modern wireless networks (e.g. CDPD, Packet CDMA) already support active IP, and we can expect that additional IP networks will be created. As a matter of fact, all of the 3G wireless networks proposed purports IP packet switching. Even 2.5G s General Packet Radio Service (GPRS) provides the active IP and is scheduled to be rolled out in the United States by Q2 01. The convergence of wireless networks on IP upon the network layer is already a technological reality, and it is inevitable that it will eventually Network Layer Priding itself over its accommodation over various telecom networks, WAP is designed to improvise a vast range of telecom networks. Foremostly, WAP employs the Wireless Datagram Protocol (WDP) as its lance in adopting different network protocols via the transport layer. The convergence of the wireless communication networks to the Internet Protocol with the advent of 2.5 and 3G deems the usage of the IP in WAP s network layer protocol in the near future. Transport Layer The Wireless Transaction Protocol (WTP) and the Wireless Datagram Protocol (WDP) suffices as the transport layer protocol in the WAP architecture. WDP operates between the data bear services that are provided by different telecom networks and the WTP, hence offering transparent communications and independence to the WAP upper layer protocols. The creation of WAP s transport layer protocols, WDP and WTP, are inspired from the TCP/IP transport layer protocols, UDP and TCP respectively. WDP The design of WDP is a natural evolution stemming from the UDP. WDP improves upon the UDP by empowering itself to support different kinds of wireless network layer bearers while the UDP can operate only upon the Internet Protocol. Though the current WDP has a header of up to 15 bytes, it is functional with just 2 bytes, a significant improvement over UDP s 4 bytes header limit. This certainly accommodates WAP to the narrowband wireless environment better since even a 2-byte improvement can mark significant convenience. However, if the wireless bearer supports wireless communication, WDP can be replaced by UDP. Thus, the 2.5 and 3G bearer networks that fashion themselves more to the wireless data environment can render WDP irrelevant. The future high

bandwidth environment will also deem the 2 bytes header improvement less astonishing. Figure 2 Comparison of TCP/IP, WAP, and OSI Protocol Stack. Notice that the WAP Protocol stack does not specify anything below Network Layer because the potential difference in bearer at the underlying layers. (Shown with CDMA as the bearer of the Network) WTP The WTP is a transaction protocol defined by the WAP Forum to provide services necessary for browsing applications. Two reasons undermine the decision to create WTP instead of transporting the TCP into the wireless environment. 1. TCP uses a three-way handshake to establish connections. In a browsing session, a client requests information from a server, resulting in a client-server communication. This request/response duo is termed as a transaction. As a result of the three-way handshake, TCP will create unnecessary overheads when it is used for web browsing. 2. Furthermore, the TCP streaming service does not perform well to its full capacity when used in a transaction based application, especially web browsing. The objective of WTP is to enable transactions while balancing the degree of reliability required for an application with the cost of reliable deliverance. WTP, designed as a lightweight transaction oriented protocol, suits the implementation in thin clients and operates over the wireless datagram networks efficiently. Historically speaking, WTP is inspired by the Transactional Transmission Control Protocol [RFC 1644] (T/TCP) and the Efficient Short Remote Operations (ESRO) [RFC 2188]. T/TCP runs WTP on top of WDP and optionally provides security services, much equivalent to ESRO running on top of UDP. Further emulating the ESRO concept, WTP provides several classes of services ranging from unconfirmed request to confirmed single request with confirmed single response transaction. The WTP utilizes the Class 2 transaction for web browsing services, offering the basic request/response transaction service. Both considering the TCP connection setup and teardown too expensive, WTP and T/TCP suffice as partners in developing the TCP replacement. WTP uses an invoke and response message to implement its transaction service. The client first sends out the invoke Protocol Data Unit (PDU) with the data request to the server. With its reception of the PDU, the server processes the data unit and sends out the response PDU along with the responding data to the client. If the server has not finished processing the request, a hold on PDU is sent to prevent the client from sending the invoke PDU again, hence avoiding wasted air bandwidth. Hence, the WTP enables the bypass of the three-way handshake tactic and allows the data sending party to being data transmission as the first segment is sent. Especially helpful for short request/response traffic, the tactics enables potentially long setup phase when no useful data is transmitted. Despite its multifold advantages, WTP possesses numerous fallacies as well. WTP does not implement congestion control. The current WTP implementation forfeits control at the WAP proxy server, hence destining congestion control impossible and only by using TCP/IP on the WAP proxy server can congestion control be implemented to a minimum level. With 2.5 and 3G wireless networks, the data bearer will be IP-based and the edge of the Internet will be the mobile terminals, not the proxy server. As a result, congestion control must be implemented in the next generation wireless protocol stack. Moreover, the improving bandwidth enables multimedia applications such as video conferencing and graphical web pages. Multimedia applications certainly require streaming data services, and WTP, as a transaction-based protocol, certainly lacks the capacity to handle multimedia applications. TRANSPORT LAYER ALTERNATIVES AND SUGGESTIONS It is apparent that if future applications are dominated by multimedia software, WTP cannot handle such streaming services. TCP, though excellent for streaming applications, is inapt for the

wireless medium that encompasses significant noncongestion losses. TCP always assumes packet loss due to congestion and adjusts to smaller window size with packet losses. The wireless medium conjures packet losses upon both congestion and corruption due to BER, fading, and so forth. And in the wireless environment, the right approach is consistent data sending without decreasing window sizes. To revolve the situation, [RFC 2757] suggests several alternative transport protocols: the Mobile Network Computing Protocol (MNCP), Efficient Short Remote Operations (ESRO), and Versatile Message Transaction Protocol (VMTP). Moreover, improvements over TCP and WTP can be make. ESRO: The Efficient Short Remote Operations (ESRO) provides reliable connectionless remote operations services upon the UDP with minimum overhead. The ESRO protocol designed to accommodate the wireless network, CDPD, supports segmentation and reassembly, concatenation and separation as well as multiplexing for service users (applications) [RFC 2188]. It purports reliable connectionless remote operations on top of UDP (or any other non-reliable connectionless transport services) with minimum overhead. Similar to WAP, ESRO specifies both 2-way handshake and 3-way handshake based protocols. ESRO does not operate alone, but instead inherits and serves commands from layers on top of it. Hence, to efficiently use ESRO as a transport service, an application must be customized accordingly, hence rendering arcane TCP/IP applications to be incompatible with the ESRO architecture. Operating as a transport service to its upper layers, ESRO does not carry authentication methods and assumes security handling by its upper layer applications. Due to influence ESRO bears upon the WTP design, the protocols share numerous traits. The foremost is that ESRO is a transport service running on top of UDP, not a stand-alone transport layer protocol. However, ESRO is a connectionless protocol created for remote procedure calls while WTP and TCP are designed as connection-oriented protocols. In 2.5 and 3G IP packet-switched networks, a service running upon UDP will only increase its header length and decrease efficiency. Thus, ESRO should not be considered a viable alternative to WTP or TCP. MNCP: Similar to WAP, the Mobile Network Computing Protocol (MNCP) is a proxy service that operates upon the UDP/IP stack. MNCP provides interoperability and efficiency by utilizing an underlying UDP/IP transport infrastructure. It provides a set of protocol functions that satisfies both the reliable delivery requirements for certain mobile applications and introduces a framework for session control over wireless infrastructure. Its reliable delivery features include packet size selection, error checking, single and multi-packet delivery modes based on positive acknowledgement with retransmission mechanisms, and data compression. These features certainly map nicely onto TCP s reliable transmission mechanism. However, all these features MNCP provides are also purported in WTP while MNCP also holds a relative small amount of patriots. Thus, from both economical and technical point of view, MNCP cannot be considered as a viable transport layer alternative. VMTP: The Versatile Message Transaction Protocol (VMTP) suffices as a transport protocol specifically designed to support transaction models of communications. VMTP provides an efficient, reliable, optionally secure transport service in the message transaction or request-response model. It holds the following features. Selective retransmission and rate-based flow control Multicast message transactions with multiple response messages per request message Multiple message transactions per client As a transaction based protocol, WMTP does not have capability to handle 3G multimedia applications that would require streaming data. Also, VMTP does not offer the layer-to-layer communication that the WAP protocol stack can provide. Thus, VMTP cannot be used as a general-purpose transport layer protocol for the wireless networks. IMPROVING TCP FOR WIRELESS LINKS Considering the alternatives suggested in [RFC 2757], a sound solution cannot be found. The Beyond WAP group believes that a more viable solution will be to provide improvements to the current TCP model. As of to-date, the use of TCP for the wireless communication networks has been criticized chiefly for three reasons. TCP assumption of all packet loss due to corruption Too much overhead during TCP connection setup/teardown. TCP window size not tuned for high bandwidth, high latency links for the 3G networks. Detecting Corruption Loses Differentiating between congestion and corruption losses in the wireless environment is an important but difficult task for TCP. TCP must retransmit the damaged segment in case of corruption and adjust its window size during congestion. The current TCP assumes all losses are due to congestion. One partial solution is to implement a Forward Error Correction (FEC) to the data sent over the wireless link.

Nonetheless, the FEC performance is not guaranteed and cannot be universally applied. Another suggestion is to implement some sort of communication between the transport and network layer, i.e. TCP and IP. The tactics will offer TCP awareness of what has actually happened and respond accordingly. Large TCP Windows The standard TCP buffer size at 8KB is relatively low compared to the high bandwidth offerable by the 3G wireless networks. A small window size in a large bandwidth atmosphere prevents maximum throughput. The relationship is as follows: Throughput = window size / RTT. Assume 2Mbps = 256 kbps maximum bandwidth and 200ms delay of a typical 3G link. The window size will be 51.2KB. The value is apparently larger than the default 8KB buffer space used by many TCP implementations. The result indicates that the future wireless wide area networks must operate over a greater default buffer size or must suffer inefficient utilization of bandwidth. convergence to the IP standard and application compatibility deem TCP superiority. Nonetheless, improvements must be made to prevent its shortcomings during its transportation to the wireless environment. Delayed Dupacks and SACK must be implemented, along with FEC to detect corruption loss. However, a layer-to-layer communication scheme that equivalents to WAP must still be implemented in the TCP/IP stack to optimize performance. Delayed Duplicated Acknowledgements (Delayed Dupacks) And Selective Acknowledgements (SACK) The link-layer retransmissions may decrease the bit error ratio (BER) significantly enough that congestion accounts for most packet losses; still, interruptions due to handoffs, moving beyond coverage, etc. can be captured. In the instance, it is imperative to prevent interaction between link-layer retransmission and TCP retransmission since these layers may duplicate each other s behaviors. In this case, it is sensible to delay TCP efforts to allow linklayer recovery. The Delayed Dupacks strategy selectively delays duplicate acknowledgements at the receiver end and saves bandwidth from duplicate retransmission. The Delayed Dupacks combined with SACK will significantly increase performance. The Delayed Dupacks prevent duplicated retransmission while the SACK retransmit the lost packets, indeed resulting in quite a harmonious duet. Nonetheless, research as of to-date has not elucidated the length of the receiver delay of duplicated acknowledgements and the intricacies of the MAC layer of the wireless networks. CONCLUSION Although WTP suffices as the most viable option for the wireless wide area network today, it certainly will not perform efficiently under the future wireless networks due to increase in bandwidth and application complexity, rendering alternatives a must. Evaluating the different applications used, any transaction-based protocols cannot be used, and TCP seems the most viable suggestion. The mobile

REFERENCES [Banan00] Banan, Mohsen. LEAP: One Alternative to WAP. Free Protocols Foundation, Version 0.3, June 23, 2000. [BananM00] [DoCoMo99] [Euro00] [Farrell99] Banan, Mohen, The Lightweight & Efficient Application Protocols (LEAP) Manifesto. Version 0.9, August 10, 2000. NTT DoCoMo Technology. NTT DoCoMo R&D, 1999. http://www.nttdocomo.co.jp imode -Eurotechnology s short guide to DoCoMo s wireless internet system. Eurotechnology Japan K. K., October 14, 2000. Anita Farrell, Adnaan Ahmad, & Andrew Griffin. Mobile Data Handbook: The Road to the Mobile Internet. Merrill Lynch, Pierce, Fenner & Smith Inc., 1999. [Heiss99] [Hyland97] [IETF draft-iab- wirelessws- 01.txt] Heiss, Janice J. Converge and Connect: The Embedded Systems Conference 99. Sun Microsystems, Inc., 1999. Hyland, Tim. Proposal for a Handheld Device Markup Language. Unwired Planet, 11 April, 1997. Overview of 2000 IAB Wireless Internetworking Workshop, D. Mitzel. IETF, August 2000. [Khare99] Khare, Rohit. W* Effect Considered Harmful. 4K Associates, April 9, 1999. [Llana00] Llana, Andres Jr. Convergence of Wireless Technology and Enterprise Networks: Integrating the Internet. Charleston: Computer Technology Research Corp. (http://www.ctrcorp.com), 2000. [Luke00] Tim Luke, Jeff Kvaal, and Noelle Swatland. Phone.com. Lehman Brothers, 2000. [Meloan00] Meloan, Steven. WIRELESS WONDERS : Java Technology for Wireless Data Solutions. Sun Microsystems, Inc., 05 April, 2000. [Mobidy00] Mobile Markup Language : MML For Mobile Network. Mobidy, English Version, 2000. [RFC1045] VMTP: Versatile Message Transaction Protocol, Cheriton, R., RFC 1045, February 1988. [RFC1644] Extending TCP for Transactions Concepts, Braden, R.,RFC 1644, July 1994. [RFC2002] IP Mobility Support, Perkins, C., RFC 2002, October 1996. [RFC2188] AT&T/Neda s Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2, Banan, M., Taylor, M., Cheng, J., RFC 2188, September 1997. [RFC2488] Enhancing TCP Over Satellite Channels using Standard Mechanisms, M. Allman, The Internet Society. January 1999. [RFC2757] Long Thin Networks, G. Montenegro, The Internet Society. January 2000. [RFC2760] Ongoing TCP Research Related to Satellites, M. Allman, The Internet Society. February 2000. [Walrand00] High-Performance Communication Networks, J. Walrand and P. Varaiya. Morgan Kaufmann Publishers, 2000. [WAP] Wireless Application Protocol Architecture Specification, WAP Forum, April 30, 1998. URL: http://www.wapforum.org/ [wapforum00] WAP June 2000 Conference Releases. Wireless Application Protocol Forum Ltd., 2000. http://www.wapforum.org [WDP] [WSP] [WTP] Wireless Datagram Protocol Specification, WAP Forum, April 30, 1998. URL: http://www.wapforum.org/ Wireless Session Protocol, WAP Forum, April 30, 1998. URL: http://www.wapforum.org/ Wireless Transaction Protocol Specification, WAP Forum, April 30, 1998. URL: http://www.wapforum.org/