By Arjan Lasschuit, Director of Product Marketing
Next to increasing bandwidth of mobile internet connections using LTE, operators should not miss out on the opportunity to jumpstart their text messaging traffic for their LTE and IMS subscribers.

As we all know, text messaging will continue to play an important role in the way subscribers will want to communicate. LTE/4G subscribers will assume that they can interchange text messages with 3G and 2G subscribers, despite the technology differences. Also many services and 4G applications will continue to depend on text messaging as an enabler to trigger communication.

Opening up the messaging exchange capability of the LTE subscribers to the large 2G/3G subscriber base will help increase the operator’s text messaging volumes of LTE subscribers. In order to do this, an IP-Short Message (IP-SM) Gateway is a critical and mandatory building block needed for LTE network deployments. It will soon become clearer that this messaging bridge will be the cornerstone of next-gen messaging because of its seamless interoperability with 2G/3G text messaging. This can also be one of the cards up the sleeve of operators to continue to defend the ownership of the messaging domain against the over the top players.

Tekelec’s IP-SM Gateway, which combines Tekelec’s SIP, SS7 and messaging expertise can be deployed and integrated in several configurations and is able to scale up to a complete Next Generation Messaging solution that works with Tekelec’s Next Generation Subscriber Data Management solution.

The benefits include:

• Increased messaging volume by bridging the 4G network domain with the 3G/2G network domain;
• Protection of investment by re-using the 2G messaging infrastructure;
• Grow as you earn deployment due to modular deployment and virtually unlimited scalability.

For more information, please see this product brief.

Arjan is director of product marketing at Tekelec for mobile messaging. He is based in Amsterdam.

By Bob Wallace, Principal Engineer

The adoption and deployment of LTE is presenting challenges across all aspects of the mobile industry.  On the technical front, carriers are making large capital investments to upgrade the infrastructure in their access networks in order to satisfy the subscriber’s demand for bandwidth.  Likewise, upgrades to the core networks are also required to handle both the increased bearer traffic as well as the signaling traffic.  But the change LTE is driving reaches far beyond the technical challenges.

LTE enables a different kind of mobile.  Initial roll-outs are offering bandwidth that is comparable to fixed broadband access, and the technology offers a roadmap with continued bandwidth growth.  The subscriber devices connecting to LTE networks also have much greater processing power, allowing the subscriber to effectively perform tasks previously reserved for desk-top devices.  This combination of available bandwidth and the processing power to take advantage of it has the mobile world on the brink of an unprecedented transformation.  Far more important than the technology introduced with LTE will be the emergence and development of entirely new usage models and business models.

During the initial roll-outs, carriers must rely on traditional services and business models to fund their investments.  Virtually all of the traffic carried on initial LTE networks will be data, and existing data services are billed simply by volume of traffic.  This means that even though subscribers are using more bandwidth for a greater variety of applications, the revenue returned from the increased bandwidth will grow at a reduced rate.   The biggest challenge for carriers will be to develop new services and business models which allow them to capitalize on these new usage models, while in the interim focusing on minimization of cap-ex and op-ex.

Carriers are caught between these two opposing forces – subscriber demand for more mobile bandwidth and reduced “cost-per-byte” value of that bandwidth.  There is more than enough demand (revenue) to justify the network infrastructure to carry the increased bandwidth, but there is not enough demand to justify multiple network infrastructures.  In other words, carriers can’t afford to provide complete vertical solutions as they do today.  On the low end, backhaul from the access nodes to the core network will be shared by multiple carriers.  On the high end, individual carriers will not be able to keep pace with the rate of innovation demanded for application content and other services.  In order to compete in this environment, carriers will need to open their networks – and their business philosophies.

Most carriers seem to be embracing one of four basic approaches to mobile data development and growth:

• Completely open networks.  Flat rate data access, no caps, no traffic classification.
• Controlled access to networks.  Even these carriers acknowledge there are going to be Over-The-Top (OTT) services that they can’t exert control over.  However, there is an expectation that the carrier will partner with 3rd parties and enterprises to create Value-Added Services which are unique to their networks.  Not quite the “walled garden”, but not really embracing fully open concepts either.
• Open access networks with a new set of Value-Added Services (VAS) through CoS/QoS, API’s for unique network information (presence, location, etc.), and other “smart pipe” features.
• Broadband service for unserved / underserved subscribers.  These carriers are using the lower “greenfield” deployment costs of LTE wireless service to bring broadband access to rural users who do not have cost-effective fixed broadband access.

Depending on which of the above approaches a particular carrier has adopted, the degree of the impact LTE has on network architecture and security will be different.  However, in all cases it is important to understand that LTE networks require a new approach.  While past experience and philosophies won’t be abandoned, the differences in LTE networks reach beyond technical changes to the underlying usage and business models.  As a result, value propositions for products and services that worked in the past may not work in the future.

Bob is a Principal Engineer at Tekelec, with a focus on core signaling systems architecture. He has more than 16 years of experience in the telecom industry, and more than 25 years in development engineering.

The Tekelec Blog will provide insights on the mobile data explosion and beyond. Increasing bandwidth demand and changing consumer behaviors are causing service providers to migrate to more flexible and cost-effective all IP network architectures including LTE and IMS. This transition requires them to manage hybrid network operating environments – with disparate  network technologies, handsets, and consumer expectations – for years to come.

The blog relies on the deep experience and expertise of a team of technologists and thought leaders within Tekelec. Check back periodically for updates.

In my last post, I discussed the Generic Bootstrap Architecture (GBA). If you recall, GBA describes an abstract Network Application Function (NAF). In a real application, the NAF is replaces with an application specific service.

3GPP TS 33.221 describes a concrete GBA based application, namely, “Support for Subscriber Certificates” (SSC). SSC uses the GBA approach for enrolling X.509 certificates for subscribers.

In SSC, the GBA NAF is replaced with PKI Portal function. This portal performs the PKI Registration Authority (RA) function, meaning that it authenticates certification requests. It may also perform the Certification Authority (CA) function in that it may actual generate certificates from subscriber’s private keying material.

When the subscriber needs an X.509 certificate, the UE authenticates with the BSF using AKA over HTTP, just like for any other GBA based application.  The BSF and the UE each derive the same application specific key, which is then used to protect the UEs interaction with the PKI Portal.

Once the bootstrapping process is complete, the UE uses HTTP Digest to authenticate to the PKI portal using the application specific shared key from the bootstrap process. The PKI portal gets that key, as well as any SSC related user security settings, from the BSF over Zn. Once authenticated, the UE can request a certificate using a PKCS10 formatted request over HTTP. It can also request the issuer certificates using HTTP GET requests.

This approach has some significant advantages compared to manual enrollment, or pre-shared certificates. Since new certificates can be created quickly and easily, certificate validity periods could be significantly shorter, making the problems of certificate revocation much more tractable. This of course assumes the applications in which those certificates are used do not, in themselves, require long-lived certificates. This is likely true of most real-time communication applications, but may be less true for applications that require future verification and decryption of long-lived data.

Since this blog is nominally about SIP, I should mention that the IETF has done some work around certificate management for SIP based applications. The SIP-Certs mechanism provides both certificate enrollment and distribution functions using using SIP-Events and the SIP PUBLISH mechanism.

One of the efforts currently gaining some traction within the IETF is a push to define a framework to allow the creation of web pages that can engage in real-time voice and video communication.

For quite some time, JavaScript – a staple for every modern browser – has had primitives that allowed browser-based scripts to send and receive arbitrary data from the server that they came from. This has allowed web sites – such as Gmail and Facebook – to implement presence and instant messaging solutions. These have been performed in near-real-time, which is perfectly acceptable for text messaging (in which latencies of several seconds are unnoticeable).  However, due to its security model, this information was limited to being sent over HTTP (and hence TCP), and little to no support for specific applications was provided.

For real-time video and voice, these behaviors are problematic. TCP is unsuitable as a transport for real-time audio, and the additional latency of sending the media through a web server will typically make the experience frustrating and unusable. Further, current JavaScript APIs provide no access to microphones, cameras, or codecs that would be required to collect, encode, and decode media.

Browser add-ons – such as Flash, Silverlight, and Java – have the ability to solve some of these problems (such as access to the microphone), but still share JavaScript’s “same origin” security policy that requires them to send and receive information only to and from the same web server that the application came from.

So, while we’ve almost been there for quite some time, there are some critical components missing to enable web application developers to provide two-way voice and video communication in a web browser.

At its heart, this effort will require work within two different organizations: the IETF (for selection and definition of network issues, such as datagram transport, framing, connection management, codec selection, and protocols for conference control), and the W3C (for additional JavaScript and HTML5 mechanisms that allow secure access to these protocols, to codecs, and to multimedia input devices). In fact, it’s probably this required division of labor that has caused this work to be so slow to develop: each group correctly identified substantial portions of the problem to be outside their areas of expertise.

Although these discussions are still in their infancy, key participants have proposed some very promising constraints: the use of ICE for firewall traversal (including using TURN servers where appropriate); the use of RTP and SRTP for media conveyance; and session management that is either explicitly based on or trivially  convertible to and from SIP and/or XMPP.  This means that gatewaying to existing real-time networks – such as IMS, Google Talk, Microsoft OCS, most enterprise PBX systems, and many commodity PSTN gateways – should be a straightforward exercise.

This work, if successful, takes us closer to ubiquitous communication. Imagine the convenience of logging into your voice- and video-enabled web site from anywhere, and being able to start making calls without installing a single piece of software. Imagine being able to create a web site that allows your users to interact with customer service representatives using a videoconference, without waiting for anything to download.

I expect there to be a lot of effort put into this work between now and the March IETF meeting in Prague. At that meeting, the plan is to hold a BOF session to nail down the charter for a new working group to complete the IETF portion of this work.

Of course, this level of coordination between the IETF and the W3C has never been attempted before, and I’m sure there will be growing pains as we attempt to jointly push this work to completion. But I’m excited that we’ve taken the first steps in this journey, and have high hopes that something fruitful will come out of the effort.