ISPs shouldn’t be fly posters

Posted on by

I am a great fan of the old British sitcom Yes Minister. For those who may not be familiar it is about the plight of a politician, Jim Hacker, who constantly fights to maintain his position in the face of external events outside his control and the obduracy of his civil servants.  Apart from being very funny it has proved to be excellent training for a career involving large corporations and global standards bodies.

In one episode of Yes Minister, Jim Hacker has been talking to a European Commissioner about food standards and naming. The Commissioner is concerned that British sausages contain very little meat and are generally made of dubious content:

‘Bernard (Jim’s secretary): “They can’t stop us eating the British sausage, can they?”

Jim Hacker: “No, but they can stop us calling it a sausage. Apparently it’s got to be called the Emulsified High-Fat Offal Tube.”

Bernard: “And you swallowed it?”’

 

Fly posters, not popularThis came to my mind when thinking about reports that an ISP in the US could be injecting advertising on top of popular web pages. To me, if you are going to describe your service as Internet access then this means you will attempt to provide access to data on the Internet without undue interference. If the reports are true then in this case the ISP is adding advertisements on top of the Internet content. In the physical world we have a name for the practice of sticking unauthorized advertising on top of other peoples’ property. We call it fly posting.  Fly posting is a seedy business popular with get rich quick schemes, dodgy night clubs and “adult services”. Because fly posting is such an eyesore most cities now have very strict bylaws that manage the problem and fine the perpetrators.

It seems that there may be ISPs who are being tempted to become fly posters by the possibility of getting some new revenue. I invite them to think about the kind of companies that get involved in fly posting in the real world and perhaps to reconsider their position.  In the meantime, consumers need some real guidance as to what service they are getting when they sign up for Internet service. As with the Commissioner’s proposal for the British sausage it should be somehow more accurately descriptive of the product on offer. I suggest “Spam Producing Internet Manglers” (SPIMs).

Conference outings

Posted on by

I am not a big fan of the conference circuit. One day we’ll perfect a model of communication among the telecoms community that doesn’t require us all to regularly clog the worlds’ airports and hotels. But, until then it is good to get out the office once in a while and hear some different perspectives on what’s happening.

If you fancy hearing my thoughts then here are two upcoming opportunities:

BWCS Train Communication Systems 2013

June 12-13, London

“LTE for Critical Communications in Rail – How and When?”

  • LTE is being adopted globally for “blue light” public safety applications. Should rail follow suit and apply LTE to critical communications?
  • Are LTE standards suitable for rail requirements?
  • Is there a business case for migrating existing technologies?
  • Can we improve on GSM-R and avoid repeating past mistakes?
  • What are the sharing models for critical and non-critical users?

LTE World Summit

June 24-26, Amsterdam

“3GPP’s progress in delivering interoperable LTE Public Safety Standards”

3GPP Attaches WebRTC to the Crushing Weight of IMS

Posted on by

Well, here’s some entertainment for a cold Monday. At 3GPP SA Plenary last week they almost, but not quite, approved a work item for “Web Real Time Communication (WebRTC) Access to IMS”. The lack of approval is really just a formality as several working groups are going ahead to work on assessing the topic anyway.3GPP Anchors WebRTC to IMS

According to the draft work item the objectives are to specify service requirements (and subsequently implementation) for:

  • “the ability for WebRTC clients to access IMS, including for example, reusing IMS client security credentials and/or  public identities/credentials as appropriate;
  • how IMS clients communicate with WebRTC clients connected to IMS, both for originating and terminating calls;
  • the ability to realise any IMS services to the WebRTC client;
  • access to IMS client capabilities, including regulatory functions (e.g. lawful interception) and charging for WebRTC clients connected to IMS;
  • the ability to support applicable IMS access types (e.g., LTE) for webRTC clients connected to IMS;
  • ability for an IMS service provider to offer IMS services to users interacting with a 3rd party website which is using the webRTC client (users of the 3rd party website may or may-not have IMS credentials)”

Is it wise to rush to codify an interworking between a standard that’s not yet written with a standard that’s hardly deployed? Probably not, but the obsession with IMS as the “one true path” by some parts of the mobile industry makes this type of response highly predictable. Nobody has actually seen an IMS service that’s a meaningful improvement on existing technology but still we must ensure that IMS services are accessible via WebRTC.

At some level this work is harmless. Nothing will prevent the fans of IMS wishing to specify the interworking to everything in sight. You might as well let them have their fun and see how the market responds. The sad thing, which is ultimately bad for the mobile industry, is that this seems to be the only point of contact between WebRTC and LTE/3GPP.  If 3GPP frames WebRTC exclusively in the context of IMS then it risks not addressing broader questions about how to provide flexible and efficient support of non-IMS related WebRTC apps in the mobile context. QoS, policy management and congestion control are all topics that are relevant to (non-IMS) WebRTC.

If mobile operators just treat WebRTC as some kind of weird IMS client then they are once again going to find themselves out innovated and out classed by more agile players who operate in an OTT mode. The rhetoric will again be “these OTT players are not fair” but really the failure will be that of the mobile industry to adapt to disruptive technology.

Who adds value in the WebRTC ecosystem?

Posted on by

The W3C/IETF plan to support real time communication in the browser, WebRTC, is moving from high-flown concept to somewhat messy, but useful, reality. Generally, I am a fan. WebRTC offers new opportunities to both indie developers and the established players. It will undoubtedly accelerate the adoption of new conversational services at the expense of traditional fixed and mobile telephony. There are a lot of interesting and important topics to explore related to WebRTC but I want to start by talking about what kind of ecosystem will be involved in successful WebRTC services. A lot of the technically focussed analysis of WebRTC has not highlighted the extent to which WebRTC services will require multiple components and company inputs to be integrated.

To start this discussion we need to understand a bit about how WebRTC is structured. This isn’t a WebRTC tutorial but a sketch showing roughly where the main functions reside. The heart of WebRTC is a new W3C standardized API between the browser and Javascript running in a web page. The API provides three elements:

  • Mediastream which allows the Javascript to access media inputs on the local computer (eg cameras and microphones);
  • RTCPeerConnection which allows connections that send and receive media to be made with peer devices running WebRTC; and
  • RTCDataChannel which allows generic non-media data to be sent over an RTCPeerConnection channel.

In this discussion I am just going to focus on RTCPeerConnection. RTCDataChannel is a really interesting initiative with a lot of implications but it’s probably the least mature part of WebRTC and not really central to the point I want to make about ecosystems. Mediastream is the most mature element but it doesn’t feature majorly in my thoughts on the value chain.

WebRTC – Simplified service architecture

The most interesting point about these APIs for my discussion is where W3C decided to draw the boundary of the RTCPeerConnection API. It is quite different for the media part of the connection and the signalling part. In the case of the media the API has been put at a high level leaving the Javascript with a rather abstract view of the media. The browser takes on the task of managing the media coding and doing the heavy lifting to make media work nicely across unreliable networks. The browser is responsible for packet loss concealment, echo cancellation, media adaptation to varying network bandwidth, and dynamic jitter buffering and any proprietary technologies used to subjectively improve the perception of media. In practice this means that a lot of the features that dictate the quality of the service as perceived by users will be controlled by the browser. It also means that browser developers will need access to media technology that has traditionally been the domain of telephony app developers.

For signalling the WebRTC API is at a somewhat lower level than it is for media. The RTCPeerConnection component in the browser manages establishment of media connections between WebRTC peers. The browser also contains the tools to perform NAT and Firewall traversal for the media based on the ICE framework (ie using STUN and TURN). The Javascript interacts with, and manages, these capabilities using the API. However WebRTC does not define any service signalling between WebRTC peers or between WebRTC clients and network servers. It is up to the Javascript to implement its own signalling protocols based on the requirements of the designer of the unique WebRTC service. If you want to have a WebRTC client that talks SIP then you can do that, but you need to implement the SIP signalling and the interworking to the WebRTC APIs in Javascript. Whereas the browser largely controls the user experience for the media the Javascript will control the functional user experience.

Getting the Javascript right for any non-trivial service in the very asynchronous environment of real time communications management is going to be tricky. Despite the work of W3C there are going to be browser dependencies no doubt and subtleties about how to use the ICE capabilities in the browser to best effect that will take time to learn. Many WebRTC developers will choose to use a public or proprietary library built on top of RTCPeerConnection which provides a higher level interface as part of their app. Library providers will be another part of the ecosystem and will corral a lot of the value. What’s not clear is whether proprietary libraries will be able to retain value in the face of open alternatives.

Though WebRTC is a browser technology the complete services will need network servers as part of the solution. At least day one WebRTC services will rely on network servers for media transcoding, signalling interworking, media conferencing and media forking for multicast. In the open environment where Javascript controls the signalling it will be up to service designers to choose the functional split between clients and servers. Organisations with existing skills in VoIP systems are going to hold value in the server components and the systems design.

Lastly, we should not forget about the (not really) “dumb” pipes that all this flows over. WebRTC changes browser behaviour quite profoundly by creating the potential for a lot of traffic on new protocols and new IP ports. To some extent the support of web sockets have already opened up the use of multiple protocols on the browser but WebRTC will make this much more common. All this will have impacts on local personal firewalls, home gateways and ISPs but that is a discussion for another day.

In summary the factors that lead to the final user experience for a WebRTC service are going to be distributed across several technology components that are likely to be obtained from different sources. Some developers (eg in browsers and for the Javascript) are going to face problems that are outside their traditional areas of expertise and building the right skill set by recruitment or acquisition is going to be important to successful development of services. Vendors will take different roles as suppliers of individual components and/or complete solutions. Successful WebRTC services will not just require a good service concept but also the technical ability to design the service in a way that makes the best use of the tools available and integrates the value added by multiple underlying components.

Critical Communication on LTE

Posted on by

We’re now entering the most important and interesting period in the path to create standards for critical communications, also called “public safety”, based on LTE. The first set of standards will be in LTE Release 12 which means that the fundamental technical work will take place in 3GPP during 2013. The work in the next 1-2 years will carry over in to critical communications networks for many years to come. Here are my quick thoughts on the progress so far and how to get the best out of the opportunity.

The Good

The US National Public-Safety Telecommunications Council (NPSTC) made a bold move in 2009 when they committed to a national critical communications network based on LTE in the 700MHz band. Since then they have continued to show great leadership both in political and technical areas. It’s good to see this leadership paying-off in terms of growing consensus support for the project to make LTE the platform for critical communications evolution. The announcement in June

The differences between critical communications and cellular are not just skin deep.

from the TETRA & Critical Communications Association (TCCA) that they are supporting LTE is an important reorientation of a group that has historically treated critical communications as a separate technology silo from cellular.

Not of a lot of real technical work has happened in 3GPP yet but some of what has been done on requirements is refreshingly pragmatic. A decision that initially concerned me was the plan to define “proximity services” for direct mobile to mobile communication that were to be common for both public cellular and critical communications. The expressed desire of the NPSTC is to have maximum commonality with public cellular technology to provide the best economies of scale. In principle this is a good plan but it can be undermined if requirements that are really exclusive to one community are force-fitted in to a bodged common solution. Fortunately the requirements work on proximity services seems to have spotted this risk and separated requirements that are common, and could well have a commercial business case, from those that are exclusive to the critical communications roles.

The Bad

In these early days I worry that too many committees are becoming involved in the process and that organizations that are historically strong in critical communications may try and do too much by “remote control” instead of fully engaging directly with 3GPP. I’ve worked through standards projects like GSM-R and Common IMS that involved disjoint organizations firing liaison statements at each other and they were all inefficient, slow and ultimately rather unsatisfactory in the outcome. If you really believe in LTE as a critical communications platform then the most constructive thing to do is to use technical delegates empowered by their companies to directly contribute to progressing the work in 3GPP. By all means use industry groups like TCCA to address the wider development of the industry but don’t perpetuate parallel or shadow standards development activities.

Breaking down the tribal barriers between cellular and critical communications is going to be essential if the LTE critical communications project is going to meet its goals.

The Ugly

The 3GPP standards work on device to device communication (“Proximity Services”) seems to be progressing nicely and is well managed. Work on group calls, which are another important requirement for critical communications, is a bit late but recoverable. What looks least well controlled from a project point of view are the proposed changes to the radio aspects for example to support very high speed users and some cases of terrestrial communication to aircraft. The radio work is complicated and I wonder whether all the suggested requirements are essential to a first release. In any case it is urgent that this work is scoped and organized if anything is going to be delivered in Release 12.

Conclusion

Thanks largely to the initiative of the US NPSTC we have a rare opportunity to completely modernize and improve the technology platform used by a sector that is both commercially and socially important. We need to do a good job and that will require constructive cooperation beyond tribal boundaries as well as clear prioritisation and project management.

If you work for an organization that has an interest in critical communications on LTE then we would be pleased to talk to you about how Netovate can help you achieve your objectives. Contact us at info@netovate.com.

The “N” Stands for Network – SON is not just about radio

Posted on by

I’ve just had an interesting couple of days at Informa’s Self Organizing Network (SON) conference in Cannes. I was invited to take part in a panel discussion and one topic we explored was where SON could go next and how it can globally improve the user experience leading to user better retention.

For those new to the field the idea behind SON is that networks can automatically and dynamically configure themselves to optimize use of resources and performance. A wide range of tasks previously done manually are candidates for automation with SON. In the context of 3GPP technologies like UMTS and LTE the term “SON” has been specifically applied to certain RAN technologies like automatic establishment of neighbour relations between cells and tuning of radio parameters. These SON capabilities have been enabled by new 3GPP standards in recent releases.

We learnt from the conference that the current generation of RAN SON features can significantly improve the performance of RANs while also lowering Opex and Capex. AT&T seems to be leading the field with one of the most sophisticated and widely deployed RAN SON solutions. The way 3GPP associates the term “ SON” with particular and RAN-oriented standards causes confusion though. It is better to understand SON as a broad concept that has widespread applicability in many layers of the network.

Google is already showing the way with innovative application of SON ideas in their domain (though of course they don’t call it “SON”). Google has been a vigorous supporter of OpenFlow – a standard that allows real-time and server controlled reconfiguration of IP networks. In big data centres OpenFlow is being used to achieve new levels of elasticity and reliability. If additional server capacity is needed for a particular application OpenFlow allows a fat IP pipe to be opened in the data centre and the necessary disk images to be copied on to an idle server to configure it to run the stressed application. Once the new server is running the fat pipe used for the transfer is closed and the data centre’s routing behaviour reconfigured to direct user requests to the added capacity. These updates are being done automatically to meet changes in demand and service mix.

OpenFlow – a very network oriented SON concept

In mobile networks our concept of SON outside the RAN is much less developed but if we take the point that “N stands for Network” then we should see the user experience as a product of the whole network (well in fact the whole system – including the mobile) and not just a horizontal slice. The new horizon that’s opening is how SON can be applied to core network and system issues. Video transcoding and optimization is an exciting use case. Streaming video is already a major driver of traffic in mobile data networks. Operators are responding to this with a variety of network based transcoding and “optimization” solutions that aim to reduce the system impact. Blindly applying these techniques without reference to the radio conditions is wasteful and risks degrading user experience. Why reduce the bandwidth of a video for a user in an uncongested cell?

Pushing the boundary of SON is going to involve bringing RAN performance data up to network layers like content distribution and policy management. These higher layers can then decide on content how best to present content considering the radio status, device characteristics and user profile. Getting policy systems and SON to jive with each other is going to allow much richer and more accurate management of the user experience. We can even imagine a reverse flow where the RAN is dynamically reconfigured to optimize the delivery of particular services to particular users.

My plea today is that we should not allow SON to be a term that is exclusively used in the RAN context. SON is an idea that is too important to limit to a particular domain and let’s start to understand where broader application of this idea will yield best returns.

3GPP RAN Future Technology – D2D, MDT and Mobile Relay

Posted on by

The presentations from the recent 3GPP RAN workshop on future technology were interesting. Very strong interest in 3D beamforming, support for high-latency X2 interfaces between base stations and tighter WiFi integration with LTE.

I also took this as an opportunity to gauge interest in some of the topics that I have been particularly following.

Device to Device (D2D)

The popularity of D2D discussion was a surprise to me. This is a topic that has always been on the margins of interest in 3GPP but has now hit the mainstream. It is a broad subject and there are competing views on how much of the problem 3GPP should try and tackle. The likely starting points are going to be using the network to detect proximity between two devices that might become candidates for D2D communication and the specific needs of public safety applications. It is claimed that a network integrated solution to find device proximity can be more efficient than Over The Top approaches. This claim is probably true but unless the results are made available in a way that allows a platform for apps and innovation then OTT approaches will probably win in the market.

Presentations mentioning D2D (excluding those that specifically address public safety):

  • Operators (all regions)
    • Dish Networks
    • KDDI
    • Sprint (for public safety)
    • T-Mobile
    • Vodafone (implicitly as part of public safety)
  • European vendors
    • Alcatel-Lucent
    • Ericsson
    • Nokia
    • Renesis
  • Asian vendors
    • LG
  • US vendors
    • Intel
    • Motorola
    • Qualcomm
  • Research (all regions)
    • ETRI

Mobile Relay

The Mobile Relay feature is 3GPP’s approach to providing coverage on rail and transport systems. There was some support for this feature at the workshop but not obviously a critical mass. Mobile operators are noticably absent from the list of companies that commented on Mobile Relay.

Presentations mentioning mobile relay:

  • CATT
  • Intel
  • LG
  • Samsung

Minimization of Drive Testing (MDT)

The minimization of drive testing (MDT) feature uses data collected from mobile phones to build a view on network coverage instead of performing coverage measurements using a “drive testing” process. MDT didn’t get a lot of attention in the workshop but as the first two versions are already in the standard I guess that it isn’t “new” enough to feature prominantly. My view is that MDT is seen as a feature that will continue to be enhanced to provide new capabilities. Some interesting proposals were mentioned such as using features to specifically enhance MDT in fringe and inter-radio technology handover situations.

Presentations mentioning MDT:

  • NEC
  • Samsung
  • TeliaSonera

Train Communications Systems 2012 Wrap Up

Posted on by

I am just back from the excellent BWCS Train Communication Systems 2012 conference. The quality and knowledge of the speakers was exceptionally high and I gained new insights in to the current state of the art. Train Communications is a vast area but the primary focus of the conference was squarely on the provision of Internet service to passengers via in-train WiFi services.

In many ways the rail environment is a perfect storm for data services. To the passengers it feels like they are in a coffee shop and they expect to whip-out their data devices and go online for entertainment, social networking and work. Many speakers said that their newly installed WiFi systems had almost immediately reached maximum capacity and only with the application of service barring (particularly for video) and per-user throttling were they able to maintain a reasonable grade of service. Of course just because passengers want to make generous use of Internet services doesn’t mean they are willing to pay for them. Business cases and billing models are still very unclear with about half the European industry offering WiFi for free as an incentive to increase “ridership”.

Technically, providing the “ship to shore” communications between the train and the fixed Internet is massively challenging. The combination of high-speed trains (sometimes), difficult physical environment, high capacity and large user groups exhibits almost all the features that make mobile data systems difficult. The premier solution is to install a dedicated track-side wireless infrastructure operating in licenced, if you can get it, or unlicensed spectrum. This is undoubtedly the highest capacity option but the price-tag will deter all but the most determined. For long-distance routes that involved a lot of open countryside then satellite systems seem the preferred option. The new train operator NTV in Italy gave an impressive presentation on their new satellite-based infotainment systems but despite considerable attention given to the design and requirements these systems are already being challenged by the number of users and the generated loads.

The dominant solution in the market is cellular backhaul and even systems with other communication modes enabled normally have a cellular fall-back option too. The big limitations here are capacity and coverage. The question is can we bring together a solution to these problems which has a reasonable business case associated with it? Like many users the rail industry is excited about the potential of LTE but even when LTE is deployed and available it is clear that in the existing architectures it only offers a breathing-space as demand and expectations continue to rise.

How might this all get resolved? The combination of difficult or non-existent business cases combined with extremely high customer demand for data will be familiar to almost any mobile operator. Broadly the rail industry has the same levers as the mobile operators:
• New technology: LTE, small cells
• Tiered pricing
• Service-based pricing or filtering
• Enforcement of “fair-use” or “equitable sharing” policies
• Use of local (ie on-train) content storage and caching
Bringing these tools together in an effective combination is going to bring the best commercially feasible solutions. I would really like to see better cooperation between the rail and cellular industries to make the best use of the available technologies.

One odd outlier here is the role of the mobile operators in the rail sector. Only one operator was represented at the conference which had a global audience. Despite this there are clear signs that some mobile operators are thinking about developing their own approaches to providing rail communications. 3GPP has started a new work item on “Moving LTE Relay” which aims to light-up the insides of trains with an LTE signal which is relayed from the external network. Perhaps the mobile operators think that their ability to bill users in a “frictionless” way builds a better business case for them. However the Moving LTE Relay work seems to have very little input from the rail industry and I am concerned that it will ignore the hard-won existing experience already there and also the very complicated operational aspects of rail systems.

What is clear is that Internet access is going to become an essential part of the travelling experience for many train passengers and once you see past the technical and commercial difficulties this is going to make the travelling experience more productive and more enjoyable. It may even become an important factor in changing people’s choice of travel mode.

For more of my thoughts on how LTE could impact train communications please see my slides (with notes) on “LTE – service opportunities, threats and challenges for the rail industry” presented at the conference.

Will Minimization of Drive Testing Expose Some Surprising Coverage Data?

Posted on by

The 3GPP Release 10 standard contains an interesting feature under the rather unexciting title of “Minimization of Drive Testing” (MDT). Drive Testing is the process often used by operators to measure their network coverage. Special measuring equipment is installed in a car and it is driven round different locations to take measurements. The upside of traditional drive testing is that is provides a nice summer job for students. The downside is that even with students doing the work it is slow and expensive.

MDT exploits the fact that all mobile phone routinely measure signal quality information and use it to make decisions about how best to connect to the network. Once MDT is enabled (which in theory should require user permission for privacy reasons) then the network can request a phone that supports MDT to log its coverage measurements and report them to the network. The logging process can take place even if the phone isn’t in an active session with the network. MDT thus give the network operator a view of the coverage as measured by the phone actually in users’ bags, pockets and glove boxes.

The idea of MDT is simply to reduce the amount of drive testing a network operator has to perform (dur!) but in fact MDT may reveal facts about coverage that could be surprising or even uncomfortable for the operators. When the BBC used a mobile app to measure UK 3G coverage the results were significantly worse than the operators’ official coverage predictions (http://www.bbc.co.uk/news/business-14574816). What’s the difference between coverage as measured by a drive test and coverage as measured by a mobile? A drive test measures the available signal in an outdoor location. Mobiles measure the signal that actually reaches them – this could be limited by many factors including screening when inside cars or buildings, antenna orientation, proximity of other objects and interference by other devices. All in all signal quality as measured by the mobile could be very different (and more representative of user experience) that than seen in a drive test.

3GPP Prioritization and Productivity

Posted on by

A busy few weeks mean that it’s taken me until now to review the 3GPP Plenary Number 55 (SA#55) documents from way-back in March. As usual it is a mixed-bag with a few interesting highlights hidden among the many routine document approvals. One thing that particularly caught my eye was the discussion on prioritization related to two inputs – a company input from Japanese operator KDDI and a presentation by the chairman of the 3GPP Architecture committee (SA2). The documents are interesting but probably hard to interpret unless you are a 3GPP aficionado.

Both documents identify the same problem: 3GPP starts more work than it can finish in a reasonable time-scale. To get a 3GPP specification release out of the door a crude prioritization exercise is applied late in the day where the operators get to vote on which features they want kept. The chosen features get finished and the rest flounder. This process isn’t officially recognised in 3GPP but some variation of it has occurred for every recent release. The solution according to both papers is to prioritise sooner and to manage the time budget more actively. At some level this approach is reasonable but I think 3GPP needs to think more deeply about where it is going.

We are in the midst of major changes in the mobile world and one consequence of these is a growing misalignment between who is driving 3GPP and who is leading innovation in the external market. Traditionally the big vendors have done the technical heavy-lifting in 3GPP and the operators (often highly influenced by their vendors) have owned the prioritization and the politics. Some of the big power-houses of the past are reducing their participation: Nokia, Nokia-Siemens and Motorola have all scaled down. Many of the biggest network operator groupings only send small delegations to 3GPP. The Asian giants like Samsung and Huawei are taking up some of the slack and growing increasingly confident in their power-plays. When it comes to looking at industry leaders like Apple, Google, Microsoft and HTC though they are largely absent. If they contribute at all to the system aspects it is usually to fight on narrowly defined specific issues (like Apple and the good ‘ol SIM form factor dispute). Despite 3GPP’s great achievements this gives me the feeling that the party is, increasingly, elsewhere.

The operator-driven prioritization process is another issue. In theory the operators are better for this role than vendors because they are closer to the users and less inclined to use standards to lock-in their preferred technology. The operators also like to see themselves as the “clients” in the standards process – the people that set the requirements and ultimately sign the cheques.  The problem is that the successful operators are naturally inclined to try and protect their existing business models and user relationships in preference to doing anything too disruptive. Thus we end up with huge complexity trying to make IMS align to the behaviour of the circuit-switched world and no work items that study OTT voice performance in LTE.

My last thought is only touched on very obliquely in the plenary documents: the 3GPP system design is becoming incredibly interconnected and difficult to work with. The presentation by the SA2 chairman says:

“There are a growing number of architectural constraints that are quite complex.

  • Emergency
  • Voice service (CSFB [Circuit Switched Fallback], RAT [Radio Access Type]/NW [Network] selection implications)
  • Congestion Control
  • Network Sharing
  • ISR [Idle Mode Signalling Reduction]
  • PMIP [Proxy Mobile IP] and GTP [GPRS Tunnelling Protocol] Architecture
  • GPRS and EPC [Enhanced Packet Core] Architecture”

This list includes some technically horrible areas where the system layering breaks down and complexity, dependencies and interactions start to run-riot.  It is a topic for another day to discuss how these problems occurred (partly the penalties of su

ccess) and what to do about them. My firm belief is that until 3GPP can establish ways to introduce new system features without tying its architecture in knots the productivity is going to remain low. Clean separation of new features favours features that can be deployed in an OTT model and, in turn, this makes the operators uncomfortable. Thus the people tasked with the prioritisation also have in incentive to steer away from good technical solutions.

GSM and 3GPP were critical in creating the mobile revolution and have sustained a remarkable quality of work over many years. I would like to see a debate on vision and prioritisation which looks at how 3GPP can keep its strengths while still responding to the monumental changes taking place in the mobile industry.