RSS icon Home icon
  • Rise and fall of WAP

    Posted on February 19th, 2019 admin No comments

    In the perspective of an engineer…

    I started working as a Service Quality engineer at a telecom company in 2001. After many small projects a manager asked me whether I can create a software to grab the content of our entire mobile site to verify everything, literally (broken links, grammar, changes, pictures etc). Mobile sites were using WAP technology back then and there was no deep knowledge on how to communicate via the WAP protocol. I got a small byte array (less than 50 bytes long) from a WAP Gateway operator which meant to be the WAP request. The software used it to generate the WAP request by appending the URL to it. That was a simple WAP Class 0 (connectionless) transaction. I sent one UDP packet with the request then the WAP Gateway sent me the response. That was it.

    My application was using a depth-traversal algorithm to visit every node. It was able to check the pages either via the WAP Gateway or directly at the server via HTTP. It parsed the received WML content (Wireless Markup Language) to collect links and save the readable content. WML is based on XML so it was much easier to process compared to plain old HTML.
    First, I didn’t know what was those bytes I got for the request. But soon I faced a more serious challenge. The WAP Gateway can respond a WMLC content instead of WML. WMLC stands for compiled WML which is a tokenized (binary) form of a WML page. I felt I can made a WMLC decoder but the manager tried to convince me I cannot. “It’s a proprietary stuff you don’t know nothing about it” – he said. To my fortune, the whole WAP specification can be downloaded from the WAP Forum’s webiste (which later became part of the Open Mobile Alliance) so I had the opportunity to decode the bits and bytes. In the specification it is referenced as WBXML (WAP Binary XML). After a few weeks I had a working WBXML decoder. I put everything together and I finally created an application which fulfills all the requirements.

    I told my colleagues that I may implement the whole WAP specification to emulate a real mobile handset. After seeing the success of my WAP software a supervisor from our department came to me with the following offer: I give you a full month to implement the whole WAP stack. I was grinning from ear to ear. That was the opportunity I was hoping for.

    The WAP 1 specification was huge and I have very little time to use it as only source of information. To speed up the process I wanted to see what real devices do. We built a proxy to capture WAP traffic. The mobile sent all packets to our proxy which sent them to the WAP gateway afterwards and of course handled the reverse communication too. By that time there was no software I was aware of can decode the protocol. Even Ethereal (later renamed to Wireshark) the popular opensource network analyzer was unable to decode the WAP communication. I had to manually decode the protocol data. Interesting to note, I started to extend Ethereal with the WAP decoding capability but before I finished the official version got it. With these captures along with the specification I was able to learn the operation of the protocol very fast. It had been revealed soon that mobiles are using the more sophisticated WAP Class 2. Contrary to the WAP Class 0 we used in our first software Class 2 is very analogous to TCP. It is connection oriented, handles retransmission and reorders packets arrived out-of-order. It has several layers to accomplish all of these.

    I have intentionally left the WTLS layer out. I have never seen the security layer in operation hence I had not implemented it. Not to mention the WAP 1 WTLS has a critical drawback. The TLS transaction must be re-encrypted into WTLS. Since it is terminated at the WAP Gateway the user gave no true end-to-end encryption which can be considered a huge security flaw. For example, in bank payments it is imperative that no one is able to capture data in clear text form. It was called the WAP GAP. It can be seen as a man-in-the-middle attack.

    The WDP layer was simply implemented with the help of a UDP/IP socket. The WTP layer was the most complex one. It acts very much like TCP. It handles transactions (instead of sockets), has its own header, arranges packets, deals with lost packets etc. To implement the WTP was the most challenging because every manufacturer interpreted the specification a little differently. I had to tweak the internal timers to mimic the observed behaviour. The WSP layer is very similar to HTTP. It handles GET and POST methods, page redirections, has headers just like HTTP.
    You might wonder why the WAP 1 standard had reproduced almost everything that already existed many years before. But the answer is obvious: in the era of 2G we had CSD (circuit switched data) and GPRS (packet switched data) with a very limited downlink or uplink bandwidth. We had 10-40 kbps downlink and a few kbps uplink speeds. Saving some bytes here and there was crucial.

    Development of the WAP stack was a huge success. We had been using it until the company had been removed the WAP 1 service. It was integrated in our monitoring system to watch WAP services and alert the NOC in case of service degradation. We were able to monitor complex services such as M-Commerce transactions (ie. online purchase) and WAP LBS (Location Based Service). Later on by the help of the WBXML decoder we implemented the Push-to-Talk service testing. Out of curiosity I even wrote an Internet Explorer like browser to download and show WAP pages.

    The MMS service introduced in spring 2002. Since it was partly based on the WAP technology we had implemented the MMS measurement quite fast. We were able to send and receive Multimedia Messages, measure the transaction time, the success rate, the availability of the MMSC centre etc. The MMS notification arrives in an SMS Push message so we had to implement the decoder for it which had an added benefit to decode other Push notification such as OTA messages. One of the key benefit implementing the whole WAP and MMS stack is that we were able to spot service problems at a very low level and the evidence was recorded for verification. Even we were able to detect inter-operator communication faults.

    After a few years – I’m not aware of the exact date – the company introduced the WAP 2 service. We were already in the 3G era, the available network bandwidth and the phones’ processing power render the WAP 1 protocol useless. WAP 1 was particulary introduced for bandwidth limited networks. After introducing UMTS and even so the HSPA bandwidth problems slowly faded away. WAP 2 drops the WDP-WTP-WSP layers and uses the TCP/IP and HTTP protocols instead. The WAP Gateway had been replaced by the WAP Proxy. There was no WML or WMLC anymore. A web page download became as simple as was on a regular PC. This was greatly simplified the software part. MMS can live on top of HTTP. We still measure the service albeit it is less important nowadays.

    In retrospect, I’m grateful that I could play a major role in developing such a powerful and important system. I’m proud of what we have achieved.

    Monitoring of online services is still important today. However it means we are required to control smartphones (Android and iPhone). But this is another story…

    Leave a Reply

    Your email address will not be published. Required fields are marked *