Orange and Vodafone have done it, 3 and T-Mobile have done it. Even educated tier two operators will soon be doing it. Although cost saving is the attraction, network sharing brings its own challenges – forcing engineers to meet the technical and business priorities of at least two competing operators. Shirin  Dheghan and Nick Cooper share this network space to outline the challenges and potential solutions.

One of the main expenses incurred by wireless operators is the operational cost associated with base station sites including rent, backhaul transmission and maintenance. Operators are constantly looking for ways to maintain and improve the coverage and quality of existing networks, whilst simultaneously ensuring that CapEx is kept under control. Network sharing is becoming an increasingly popular option for many service providers as a way to cut costs whilst accelerating ubiquitous coverage and high data rates. This brings a whole new set of challenges to the wireless industry. The task of bringing together two networks with legacy software, databases and processes requires new automated tools focused on network sharing. Such tools need to easily interface to individual operator's legacy systems and combine this data to optimise the shared network to maximise savings and service quality whilst serving two operators with potentially competing business objectives. Adoption of such tools is a vital step in achieving savings of 20% predicted by operators.
At first glance, the task of combining or optimising two networks into a "shared network" appears little different from the task of optimising a single network: An engineer will have a set of sites -both existing and potential candidates- and will have choices to configure those sites to provide an optimum level of service. They may have a budget to make changes and information concerning the capital costs of different changes they may make to this network. They may also have information on the ongoing operational costs of each component. The engineering task is to make the network decisions that result in the most profitable delivery of this service (balancing the revenue consequences of these decisions, if any, with the associated capital and operational costs). However, with a little closer inspection, network sharing becomes a more involved and complex task than first considered. This article discusses some of the factors that fundamentally change the process of optimisation in order to "share" networks.

Sharing resources allows overlapping and redundant equipment to be removed and then allows the cost of the remaining resources to be divided among the network operators. The benefits of sharing will depend on the extent to which network resources are to be shared and this in turn will determine the complexity of the engineering task. At one end of the scale the exercise may be only to share site locations and to maintain separate equipment for each operator. At the other end operators may choose to combine resources right through to antennas, cabling, base station and transmission equipment. The design approach will clearly differ according to what items are combined and what are kept separate. At the very least the scope of the sharing exercise will define whether engineering will be designing a single network or multiple networks.

It is important to stress one factor that is often overlooked in traditional engineering situations and tools: Sharing a network is all about the money. The primary reason for sharing networks is to reduce capital and operational costs while maintaining an acceptable level of service. This requires engineering teams to understand costs in much greater detail than they may be used to. Within a single operation, costs can often be pushed into the background as far as engineering is concerned. Engineers will of course spend money while performing their operational and maintenance activities but usually this spend is disconnected from the budgetary aspects of network operation. However, costs have to come to the fore as soon as there are multiple organisations involved. If the engineering objective is to re-design networks so that each operator benefits from continued service at reduced costs, then a balance of benefits has to be maintained for all operators. Engineering teams must hence justify their decisions to all operators and those justifications will have to be in terms of financial benefits versus the costs involved.

For a network sharing exercise to be successful, the design and engineering teams must understand the scope of changes that they can make. Then they must maintain details of the financial impact for each of the possible changes. Subsequent decisions must then count the cost of all the changes proposed and ensure that the financial impact of those changes can be calculated.

Competing point of view
A need for separation between sharing operators introduces another new concept for network design: engineers must maintain an appropriate "Point of View" for each operator. Operators will offer their existing networks into a network sharing agreement and their existing resources will be seen to the other operators as ‘potential resources'. So, the costs and benefits of using any one resource will differ for different operators.

For example, consider a case where Operator A owns a particular site on which Operator B may place equipment. Operator B will see that site as a ‘Candidate' and can choose to use it themselves. If they choose to use the site they will incur a capital cost to install equipment and will then incur ongoing operational costs. At the same time, Operator A sees the same site as an ‘Existing' site and can choose to decommission it if they wish. If they do so they will incur a capital cost to take equipment away but will gain the value of that equipment back again and they will lose the burden of operational costs. In other words for the same site, the cost-benefit issue for Operator A is different from the cost-benefit issue for Operator B. The site has to be seen both from the point of view of A and from the point of view of B at the same time.

To further complicate matters in our example; if Operator B chooses to join Operator A on the site, then the cost model for Operator A will change even though they have not made a change to their network. In the simplest terms the operational costs for the site itself will be shared so both Operators A and B will benefit from Operator B's action. This makes it clear that the engineering teams must consider all the possible permutations as well as operators' points of view when designing the shared networks.

Network sharing introduces some more practical problems for the engineering team. Operators will accumulate extensive amounts of data about their own network over time and they will develop data sets, file formats and working practices that are unique to their own operation. When it comes time to design a shared network the engineering team will be given two or more different sets of data in probably very different formats and derived from very different design and operational methods. The team will require a single model of the shared network so they will be tasked with merging these several sets of data together. They will clearly need tools that can support the various data in all forms and they will need to know how to relate the two sets of data together. This task will be somewhat easier if only the sites are to be shared (and the equipment kept separate) but the intention to share equipment will make this process substantially more complex.

Site selection
A further practical problem is introduced by the fact that the shared design requires site selection. When optimising a single, mature network, engineers do not often have to deal with the consequences of turning off a site. For network sharing however, the intent is to turn off and potentially redeploy upwards of half of the sites that are currently operational. Engineers must therefore think of the non-radio components of the network and the impact that changing network topology will have.
For example, a network may rely on sequences of microwave links to fulfil the backhaul transmission between base stations and the switching centres. Network sharing might lead to some of the intermediary sites in a microwave chain being decommissioned which might break the transmission links for some sites elsewhere. In a similar example, co-locating equipment from multiple operators will greatly increase the volume of data flowing from a site. The cost of managing the increased transmission might outweigh the savings made from co-locating in the first place. This forces the operating teams of shared networks to have the capability to perform end to end optimisation.
Site Selection issues are not confined to the transmission system. As another example, placing two operators' infrastructure at the same site location will increase the burden on the mast placed at the site. It may be that a site is prohibited from adding additional antennas (for example due to weight or wind loading limits or to planning regulations.) This restriction might mean that site sharing can only be performed if antenna sharing is also performed. However, the sharing of antennas may compromise service quality due to the fact that height, azimuth, tilt and other physical parameters have to be linked.

These situations can be worked through but they require new tools and capabilities within the engineering team that can look beyond the normal air interface considerations of optimisation. Engineers need tools that can incorporate the physical and logical limits on a network; that can factor in the costs of reaching or breaching those limits; that can understand the links that will form between resources as they are shared and that can understand the cost implications of making and breaking those links.

As a final point, all of the issues above will be further compounded by the choices of radio technology. What if the shared networks are to offer multiple radio technologies? What if the original networks offer different subsets of the available technologies? It should be noted that operators may have already performed a type of network sharing exercise when they chose to co-locate 3G equipment on their own, pre-existing 2G sites. However, 2G to 3G migration was still confined to a single operator experience. The challenges of network sharing between operators are far more complex in both financial and engineering terms. However; savings in excess of 20% are certainly possible within a shared network so the investment should be well worthwhile.

Shirin Dheghan is ceo Arieso, Nick Cooper is an Arieso product manager.

The landscape for mobile application development has changed enormously. The entry of Web 2.0 companies means instead of consolidation, operators are now facing increasing fragmentation. The challenge for operators is how to manage this diversity from their own perspective. Which direction will offer the greatest chance of consumer adoption of mobile apps?

The current situation with mobile application development has been compared to the early days of computer gaming. Then, developers, faced with a multitude of choices, developed for the biggest selling devices or specialised on one particular vendor. At that time, the Japanese attempted to create a standard for mobile games, MSX, which failed. As Bill Weinberg, general manager with the Linux Phone Standards Forum, points out, this plethora of choice is an unnatural situation for the cellular world. The whole industry has been based on standards like GSM and GPRS. He argues that standardisation in mobile apps, if it occurs at all, will centre around software platforms.
Establishing exactly which platforms existing players are developing for and which they will develop for in the future isn't an easy task. In Europe, the main focus has been on two operating systems – Windows Mobile and Symbian – whereas Palm and Brew have proved popular in the US and Linux has made some impact in Asia Pacific. The difference, Weinberg maintains, is that Microsoft and Symbian offer very different value propositions. "Microsoft promotes Windows Mobile not just on its own merits, but as one end of a platform continuum that spans from server to desktop to embedded," he observed. "Conversely, the Symbian OS is an isolated platform but the company promotes it as the 'best-in-class' mobile OS. Both companies have strong developer communities – Microsoft claims to have over 1,800 apps that can run on Windows Mobile. They both have published strong APIs that aid developers in creating new apps."

Asked whether the latest initiatives by the Web 2.0 players can disrupt the existing OS duopoly, Paul Goode, senior analyst with researchers, M:Metrics, argued that, "The arrival of the Android / Open Handset Alliance is important, but is of little commercial interest for at least the next five years." He maintains that it takes a long time to roll out new platforms into the hands of consumers. "Microsoft launched Windows CE ten years ago but it still has an under two per cent market share in the UK of installed base. Indeed, smartphones as a whole only have just over 10 per cent," Goode said.

Java
Consequently those aiming to develop a mobile application for the mass market have followed another direction – Java. According to Tom Godber, founder of specialist Mobile apps developer, Masabi, "Native OS apps were stillborn; AJAX is fundamentally wrong for mobile, so – despite its flaws  – Java is the only viable option for advanced clients in the next three to five years." Bill Weinberg agrees. "Today the vast majority of phone apps are written in Java (J2ME and MID-P)," he says. "Actually, operators like NTT DoCoMo, Sprint, and Vodaphone all have their own developer programmes, but they mostly concentrate on Java." The catch is that Java itself is extremely fragmented. As Tony Cripps, a senior analyst with Ovum, observed, "Java certainly failed to live up to its promise [write once, run anywhere] in the mobile world." Similarly, "Even where there is a common 'standard', such as J2ME, the implementations are vastly different across manufacturers and often incompatible," argued John Chasey, CEO with software house, Metismo.

Linux
Few believe that even if Java has so far failed the mobile industry, Linux can come to the rescue. "As for the various Linux initiatives – such as LiMo and Android – there remains a large degree of fragmentation," Geoff Blaber, senior analyst with CCS Insight, commented. "The fact remains that we're yet to see a commercially successful Linux based platform in Europe. We'll probably see a small number of devices based on LiMo and Android this year [2008] but it will be sometime before we see a vibrant developer community for Linux."

Flash
One development environment which was mentioned frequently to Mobile Europe was Adobe's Flash. The argument here is that Flash already has a very strong following amongst those developing for the Web and that this great pool of expertise could be harnessed to create mobile applications. There is, of course a mobile version of Flash – namely, Flash Lite. However, Masabi's Tom Godber  isn't convinced that it will provide the answer for creating mobile apps. "Flash Lite is proving that any platform that can reach a mainstream user base will fragment. Despite having less power and fewer units shipped than Java, it has multiple incarnations and many handset-specific bugs, let alone the inescapable form factor issues." Tony Cripps observed that Microsoft has taken the whole challenge presented by Flash very seriously and produced its own alternative – Silverlight. This was released back in September 2007 for the Web community. Microsoft's Derek Snyder was unable to confirm just how soon we might see a mobile version of Silverlight. However, he did confirm that Silverlight was shown working on a standard Windows Mobile [6.0] handset by Microsoft at a developer conference. Reports appear to confirm that it was working well, so there shouldn't be too long a wait.

Thought leader
Another force to be reckoned with is Apple with its iPhone. Despite worldwide sales of four million units in 200 days, the iPhone is influencing mobile software way beyond its actual installed base. James Tagg, CEO with mobile VoIP provider, Truphone, described Apple as the "thought leader" in the mobile apps space. The same influence was observed by Shlomo Wolfman, COO with software house, Starhome. He claimed that the Windows Mobile developer community has recently increased its output – chiefly by imitating features offered by the iPhone and then translating them into Windows Mobile apps. Significantly, Derek Snyder, product manager for mobile communications with Microsoft, questioned just how effective Apple's approach was. If the iPhone really had succeeded in bringing the Web 2.0 to mobile phones, then why were web designers declaring that their sites had been 'optimised' for the iPhone, he asked?

Despite all competition, in terms of a winner in the mobile apps space, it is probably Nokia that currently dominates. According to Geoff Blaber, "From a an open platform perspective, [the Nokia] Series 60 is by far the most dominant platform in terms of volume, accounting for over 60 per cent of the European market." He also notes that Nokia's development community, Forum Nokia, is "a huge and highly comprehensive developer support program which has been central to driving growth of the Series 60 eco-system." So Symbian and Nokia could be viewed as the current market leaders. There is one drawback, though. Nokia has begun to develop its own web services under the Ovi banner and Blaber believes this could deter some Web 2.0 developers given that a potential conflict of interest exists.

Yahoo! Go
Generally speaking the arrival of Web 2.0 giant, Google, with a version of Linux in the shape of Android is viewed as increasing the fragmentation of the Linux developer community. "We'll probably see a small number of devices based on LiMo and Android this year but it will be sometime before we see a vibrant developer community for Linux," Geoff Blaber believes. "Portability of applications between platforms remains a big problem which inhibits growth of the developer community for mobile Linux." So what has attracted the fiercest criticism is Yahoo!'s claims that its 'Go' will allow third party developers to write applications that will run on a wide variety of mobile devices. Carsten Brinkschulte, CEO of mobile email specialist, Synchronica, commented, "Once again we see a big vendor heralding an 'open' mobile platform which is, in fact, proprietary technology that does not support common industry standards such as push IMAP and SyncML." Brinkschulte added, "In addition, Go mobile technology takes over the user interface of the device rather than working with the manufacturers' firmware." He therefore predicts that Go will meet with considerable resistance from the mobile handset manufacturers themselves. 

The entry of web 2.0 players into mobile is not a completely negative event, According to Paul Goode, the easy viral success of Web or PC based applications is hard to replicate in the mobile space. That viral capability increases the power of the consumer, of course. Tony Cripps also believes that 'widgets' make more sense in the mobile sector than they actually do on the computer desktop. Widgets actually require a small amount of processing power on the host device and leave the real processing to Web based servers.

Pulling the strings
Handset manufacturers aren't the only players seen as influencing the mobile apps market. Bill Weinberg feels that reference designs from handset chip suppliers and not the 'standard' commercial versions of software that will often form the basis for new mobile apps. Nonetheless, the vast majority of observers say that it is the mobile operators who are calling the shots in specifying mobile apps. There has, however, been a subtle move towards consumer choice and influence.  Geoff Blaber, for example, observes that, "Windows Mobile has to date remained predominantly business orientated from an applications perspective although this is beginning to change as vendors such as HTC and operators like Vodafone utilise Windows Mobile in more of a consumer centric setting."
Solution

If there's no clear winner as the leading software development platform, then one answer for network operators is to specify apps that can run in multiple environments. "Many developers have created their own middleware to abstract the differing handset issues on Java," John Chasey explained. "Metismo's particular version of middleware, called BedRock, goes a step further and as well as handling all the J2ME handsets it can cross-compile from Java to C and produce builds for Symbian, Brew, and even Flash." According to Ovum's Tony Cripps, there are niche companies which specialise in taking the pain out of developing mobile apps for Java enabled handsets. Providers such as Tierra Wireless in Canada can take an existing Java application and re-specify it so that it runs properly against its own database of Java handset capabilities.

Fragmentation
The fragmentation within the mobile apps development community is something of a double-edged sword for network operators. "In their struggle against being reduced to pipes of various girth, operators take pains to differentiate along lines that can encourage fragmentation," says Bill Weinberg. Conversely, as James Tagg observed, mobile apps developers are forced by this very fragmentation to spend out millions on multiple versions of their client software just to keep all the operators happy. Without fragmentation that money could be spent usefully elsewhere.