Feeds:
Posts
Comments

Archive for February, 2009

Recently I was asked if WiMAX base stations come with MPLS support. This might have sounded an innocuous question for someone from an IP background. If you are from a wireless background like I am, it might sound a little strange. A WiMAX base station provides wireless connectivity at the physical layer. In particular, WiMAX provides last mile connectivity to the end user. It can also be used to provide point-to-point (PTP) backhaul links.

From this perspective, anything above the physical layer can run transparently on WiMAX. While this is so, WiMAX has defined Convergence Sublayers (CS) at its interface which can then be mapped correctly to 802.16 MAC layer before the packets are sent on the wireless channel. The supported CS Specifications include ATM and Packet (IPv4, IPv6, Ethernet, 802.1Q-VLAN) CS. So where does MPLS fit in, if at all?

MPLS is a technology that sits between Layer 2 and Layer 3. It can be seen to be outside the scope of a WiMAX base station and certainly outside the scope of the WiMAX standards. This is where we, as engineers, have to look at the whole thing from a deployment and operational angle.

Firstly, operators want MPLS because of the many advantages it offers. It leverages on both IP and Ethernet, technologies which are cheap and ubiquitous. It offers QoS. It provides multipoint connectivity but in a simpler way than IP. Its faster to switch at Layer 2 using labels than perform routing decisions at Layer 3. The attractiveness about MPLS in the coming years is that it is set to enable the move towards all-IP transport networks. When IP replaces TDM and ATM architectures, MPLS is set to play a major role.

So operators are interested in MPLS. Before they install new devices into their network, they want to know if it supports MPLS. The problem is that there is a clear distinction between core networks and access networks. MPLS is usually limited to the core. However, there has been significant push towards bringing MPLS to the access networks. This enables end-to-end traffic engineering, right up to the WiMAX base station. 3ROAM offers such a base station with MPLS built-in. Likewise, New Edge Networks is another company that is taking MPLS beyond the core to edge networks.

What if the WiMAX base station did not support MPLS? In this case, an MPLS-enabled network would terminate at an MPLS edge router (ingress or egress). This router would then be co-located and connected to the WiMAX base station. The problem for the operator in this situation would be to have a router for every base station. This is simply not cost-effective.

In general, WiMAX base stations operate in bridge mode (Layer 2) or routing mode (Layer 3). If a base station has to be MPLS-enabled, it has to work in Layer 3 mode. In other words, the base station doubles as an ingress/egress router. It does more than simply provide wireless connectivity.

Sprint has in its long-term roadmap this architecture in mind for backhauling of its WiMAX network. Sprint’s WiMAX base stations would be  MPLS-enabled and the backhaul between such a base station and its ASN Gateway would be IP over MPLS. One of Sprint’s providers for its WiMAX backhaul is Ciena which uses PBB-TE. This may very well carry IP over MPLS right up to the base station. The backhaul itself is wireless with equipment supplied by DragonWave.

To answer the question with which we started, WiMAX base stations may very well support MPLS for cost-effectiveness from operator’s point of view. Practically, it makes a difficult case since the MPLS-enabled network is likely to be from a different provider than the base station itself. Integration becomes an issue. It is well-known that managing an MPLS network is a challenge and requires a steep learning curve. Nonetheless, MPLS may be that small factor to choose one base station over another when an operator is unable to decide otherwise.

Read Full Post »

While HTML has been the traditional markup language for the wired world, it was too complex and not strictly structured to suit the wireless world. To start with, mobile devices of the early days were power hungry and less on resources. Due to such limitations devices would end up implementing them in a partial way leading to a disconnect between content providers and mobile browser support. It is therefore no surprise that in the early days mobile devices did not support HTML. Rather, a few proprietary markup languages reared their independent heads (HDML from Openwave, ITTP from Ericsson, TTML from Nokia). From the point of adoption, they were never independent. Independence comes only by way of standardization.

Standardization is a beautiful thing. Like we use English universally as a language of choice, it enables content to run on any number of browsers that conform to the standard. It builds competence by enabling developers to learn one language and use it across many projects and companies. It is something that’s good for the industry, those who work in it and consumers of devices. It is that comfort and familiarity that in a fast changing and varied world, there are some things that help us (and our devices) to connect.

The currently recommended standard for the wireless world comes from Open Mobile Alliance (OMA). It is called XHTML-MP which was standardized way back in 2000. Almost a decade has gone and it is still going strong. It’s predecessor, WML, was in rage for many years but all new websites meant for the wireless world are using XHTML-MP. When WML came out, it was right for the mobile devices of the time. HTML was too complex for those devices with small screen, static display, monochrome rendering and little by way of scrolling. WML had this concept of deck/cards that made best use of precious air resources. It introduced compression in the form of WAP Binary XML (WBXML). It had programmable softkeys that was a great idea to ease user interaction. It enabled client-side scripting through its WML Scripting. So WML was a success, at least for a while.

Timeline of Markup Languages

Figure 1: Timeline of Markup Languages

The problem with WML was that it was too different from HTML. When WML came out in 1998, HTML had been around for a good number of years. This coupled with the steady growth of the Internet and the popularity of HTML, meant that it had it all – better browers, better and larger developer community, better tools. Websites written in HTML could not easily be viewed on mobile devices. Site developers had to re-write in WML.

In an effort to bring WML closer to HTML, a radical approach was adopted. Dump WML and create something new out of XHTML (eXtensible HyperText Markup Language), a new standard. This may be appalling to many on account of its backward incompatibility but this has been a sensible and logical decision on part of the standardization community. During the time WML has evolved, a new language had taken shape that had revolutionized every other language – XML. XML had become a popular language for data representation. It was being used in backend processing, data storage or transfer. It was being used on websites to represent data processed or rendered on client-side by Javascript or Flash. XHTML is in fact a combination of both XML and HTML – the former provided strictness of structure while the latter provided document semantics.

XHTML formed the basis of XHTML Basic, a stripped down version that was suitable for adoption by the mobile community. That’s exactly what they adopted it but they extended XHTML Basic into what we call XHTML-MP, XHTML Mobile Profile. This is the beauty of XHTML – it is extensible and modular without loss of strictness in its syntax. One of the extensions over XTHML Basic is the use of WAP CSS. XHTML-MP is also influenced by cHTML (Figure 2), which is a standard used by NTT DoCoMo in its iMode.

Evolution of XHTML-MP

Figure 2: Evolution of XHTML-MP

XHTML-MP is the official markup language for WAP 2.0. All sites for WAP 2.0 must use only XHTML-MP. Although WML 2.0 exists, it is only WML 1.x re-engineering with XHTML syntax for backwards compatibility. WML 2.0 is rarely used and is discouraged.

XHTML-MP has worked well so far. It’s future however is not so certain. With devices getting better all the time, with mobile phones getting almost as good as laptops, with better browsers such as Opera Mini that is able to display full websites in XHTML on devices with bigger colour screens, site developers may forget about XHTML-MP in the years to come.

Read Full Post »

Follow

Get every new post delivered to your Inbox.