LBO or not, I want to break out...
This article was written by Peter Nas, Senior Solution Architect of F5's Traffix SDC solution For more than 10 years, the technology to offer local breakout (commonly known as LBO) exists, allowing the data use by roaming customers to be supported by the visited operator’s network. This is in contrast to the scenario in which data requests are sent back to the roamer’s home network, which of course, costs more. But despite the obvious fact that many people would like to get lower data roaming rates, a wish not limited to Europeans traveling in the EU, sadly it is not offered yet. I can definitely understand some key arguments why mobile operators are not inclined to offer LBO, particularly when it applies to their subscriber. I also understand (a bit) that visited networks don't want to offer LBO, but let's see if we are about to see a change. After all, roaming has been a significant source of revenue for operators on both sides for some time now. When I worked at a MNO over 10 years ago, I did some testing myself to see if and how LBO works. At the time, I became very enthusiastic and never expected it would take so long before this technology would be deployed on a large scale. In the early days of GPRS, indeed data roaming rates were also very high. However in those days, roamers used their mobile phones for data much more infrequently than when in their home network. And if you have been observing the investments that have been made by mobile operators and GRX operators (GPRS roaming operators) to allow good quality data roaming, I can understand that these investments need to be earned back before the business could consider offering LBO. In the meanwhile, I believe that many things have changed and surveys have shown that customers consider data roaming far too expensive. As a result, roamers typically switch off their data while traveling abroad (some recent figures show 73% of the roamers as silent roamers, meaning while abroad but disabled their device for data roaming). Now the EU Roaming Regulations, in effect since July 2014, is explicitly mandating EU citizens to have the right to use LBO (when offered by the visited EU network), and VoLTE (Voice over LTE) is expected to be available. Therefore, we are approaching the inflection point during which LBO will be a realistic option for roamers. If I was an IPX carrier how should I approach LBO? Today all users’ data is backhauled via IPX carriers to the home network. IPX carriers have various sources of revenues and transporting users’ data is one important source of revenues. Currently, the main advantage to use IPX carriers seems to be the ease of connectivity among MNOs. However, people expect prices for pure transport to decrease making new and differentiating services the way IPX carriers can stay competitive and valuable. It is simply a matter of time that IPX carriers will offer a wide range and the right destinations of roaming agreements that will bring prices down. So while anticipating that operators are willing to pay less per transported bit... and remaining confident in the escalating trend of high data growth in the future, would I advise MNOs to invest heavily in more transport capacity or try to be innovative by leveraging wide-scale LBO usage? Let’s look at it this way. Assume an MNO can achieve service differentiation by looking at what opportunities LBO would bring. Well similarly, there are opportunities around LBO for IPX carriers which must be looked at as LBO will reduce revenues from backhauled data. One interesting aspect of LBO is that the signaling for two additional Diameter interfaces, S9 for policy and Gy for charging, could be exchanged between visited and home networks, and if so, this will be done via an IPX network as per GSMA guidelines (IR.88). There are different views on whether or not using the S9 interface to exchange policy information between the visited PCRF and home PCRF, will be massively used once LBO is offered, but let's assume it will be used. In this case, an IPX carrier can offer various services around Diameter interworking, security and perhaps also screening, overload control, prioritization and potentially adapting policy rules and more. People who doubt the uptake of using the S9 interface might be more interested if IPX carriers could offer services that help visited networks control which policies can be applied in the home network or in the visited network. The offering around S9 signaling can be the same as what is currently offered for transporting and managing S6a signaling (for authentication and mobility management), but offers security, quality, and many more differentiating features. Another very interesting Diameter interface is the Gy, related to charging. Once LBO is offered, the visited network will have primary control of charging the visitor (for example to offer various ways how a customer can be charged, like per credit card, voucher, scratch card, loyalty points, other credits from OTT applications, etc.) but there is also interest by the home network to receive charging information. Again, an IPX carrier can offer various innovative services beyond just transporting Gy charging information between visited network and home network. As we discuss charging information, what comes to mind are the potential of services in the areas of security, priority, firewalling, interworking, overload control, enriching, for example. If you think about other creative services that a mobile customer like myself would like to have while roaming, there are more services that an IPX carrier is well positioned to offer. For instance, perhaps I’d like to choose the visited network that best fits to my needs (there could be static rules but also dynamic rules). For instance, intelligent steering in roaming could be a service offered by the home network, but perhaps might be offered by an IPX carrier, at least as an outsourcing partner for the various aspects of having a new Diameter based solution next to potentially existing SS7 steering. Some other ideas are in the area of OTT apps, such as enabling an IPX carrier to provide value add to the QoE of the apps that I am using while abroad. Also when looking at LBO, it might be an IPX carrier that hosts other parties who want to offer LBO, or the IPX carrier itself can provide its 'own' LBO services via a local breakout gateway that reduces the costs (in region or on the other side of the world). Also IPX carriers can start to offer MVNE services that enable MVNOs to operate in their specific niche by providing the infrastructure and other services around it. Much more value-add can be added by IPX carriers, and some will become a commercial success and others maybe not.... but if you don't explore, you'll never know. Let’s discuss some other value-add ideas in more detail in a next post, so stay tuned.
Sometimes a Hack is Not a Hack, but We Should Still Worry
#LTEWS #Security I was at a roundtable discussion recently talking about security in the mobile carrier networks. During the discussion the recently announced SS7 signaling hack was introduced as an example. I would propose that this vulnerability is not a hack, but just poor design where trust is poorly assumed. Before you scream that I have my head stuck in the sand and I am ignoring a real threat that exists today for all mobile users, let me explain. The ‘hack’ in question depends on an agent to pose as a carrier wanting to interconnect with another established carrier for roaming and message forwarding capabilities. This is where the trust is involved. Interestingly, this is not as hard to do as one might think. With all the small carriers around the world and the MVNOs popping up like rabbits, it is hard to validate an entity with a 100% certainty. Once the trusted connection is established, now it is possible to send SS7 messages that can gain information that one should not normally have access to. There have been NO cases where an agent with malicious intent has been able to establish themselves to be in a position to send and receive SS7 information without establishing a trusted connection via a wrongly trusted, but legitimate processes. The reason I do not call this a hack, is that there is nothing technical about the method to gain access. This is purely social engineering. I can pose as a hedge fund and potentially gain some access to a larger financial company’s network infrastructure through a dedicated partner connection, but is that a ‘hack’? There are no software bugs, buffers to overflow, root access to obtain, or any other technical function that one thinks of when hacking to accomplish this compromise. So far, there have been NO instances reported or claimed of someone consciously and maliciously hacking or gaining information via the SS7 protocol. Now that I have THAT out of the way, let’s talk about the security in the current and future generation mobile networks, LTE. LTE uses a completely different model which uses an all-IP infrastructure and new protocols including Diameter, and protocols like SIP for new functions such as VoLTE. And we have our favorite attack vector, DNS, pervasively within the entire control plane infrastructure. LTE has major security concerns that need to be addressed because the traditionally closed control plane network is becoming exposed to the external (and hacker) community. SIP messages can be generated from one’s smart device and forwarded directly into the IMS infrastructure. DNS is used to forward messages from service function to service function within this previously closed network. It is possible that Diameter messaging can be exposed since it is easy for a malicious agent to hide their identity so it is impossible to find the source of the compromise via a fake origin ID. I wrote an introduction to this problem in an earlier blog post, Mobile Service Providers are missing a Key Security Issue - And it is not DNS. This is the time to take a close look at the security profile of the control plane network and determine what assurances can be put in place to prevent the malicious attacks that will certainly be forthcoming if nothing is done.How Diameter routing for policy can become a differentiator when offering VoLTE services?
This blog post was written by Peter Nas, Senior Solution Architect, F5 In a discussion around the added-value of a Diameter Routing Agent (DRA) in a VoLTE deployment, I was asked the following questions and would like to share my response: How does the PCRF (Policy and Charging Rules Function) make decisions around policies? Are all policies defined per subscriber, or are some policies defined per bearer (e.g. default bearer, regardless of the identity of the subscriber)? Does the PCRF collect the subscriber-related policies from the subscriber’s HSS (Home Subscriber Server) record? PCRFs are very conducive to contain a combination of general policies and subscriber-specific policies, all depending on how an operator wants to use them (assuming these PCRFs are the kind that have wide flexibility). For example, you could have a default policy for a bearer, access-type (RAT is 3G, 4g, and onwards) location, or other parameters, plus the subscriber-specific parameters depending on the HSS profile (e.g. the services and options that the subscriber has opted for), and all on top of the subscriber’s quota or other variables. We have seen that OTT providers could register a certain subscriber as a premium user of their OTT video service (or any other service), which guarantees the subscriber the highest quality-of-service (QoS) possible. Obviously, this service level would be accompanied by the appropriate charging level when he/she wants to download or interact with a video or any other service from that OTT provider. A VoLTE scenario is perfect for this example. If you are a VoLTE subscriber, you deserve to receive the highest quality of voice. But what happens if during the VoLTE call, the same subscriber requests another IMS-based service? In that case, the operator may want to assign a dedicated bearer for that specific service, enforce session binding, and manage the QoS if the bearer is shared (this is the PCRF’s role). Otherwise, the quality of service of the VoLTE call would probably deteriorate. All of the above scenarios involve a mixture of PCRF profiles, in addition to information on the network state, type of access, type of device, in home network or roaming, if an OTT provider is involved, and other parameters. Obviously, there are many factors involved, both network related and subscriber specific which a Diameter Routing Agent (DRA) can manage and ensure that the information is transmitted to and from the PCRF assigned to the subscriber for the particular session. Finally, I believe more and more operators are beginning to use PCRFs to differentiate themselves from competitors, and not “just” for cost reduction. Ensuring that the PCRF receives the right information, and transmits the information back to the Policy and Charging Enforcement Function (PCEF) to apply the policies is the critical role of signaling (mainly Diameter signaling but not limited to). Therefore, a DRA with gateway functionalities, such as the F5 Traffix Signaling Delivery Controller (SDC) is the key enabler to benefit from cost reduction and competitive differentiation in many VoLTE scenarios.Why do you need a Diameter Routing Agent (DRA) in a VoLTE deployment?
This article was written by Peter Nas, Senior Solution Architect for the Traffix SDC Operators have begun to get more and more serious around deploying VoLTE (Voice over LTE) in their networks. Since the announcements of VoLTE services from some Korean and US operators, others, particularly in Asia, North America and EMEA, have launched or are about to launch VoLTE (see GSA announcement of 17th Sep 2014: 71 operators in 36 countries investing in VoLTE deployments, studies or trials, 10 operators commercially launched HD voice using VoLTE). More often than not, operators use a Diameter Routing Agent (DRA) to support correct routing and control of the Diameter signaling related to VoLTE. Basic session binding In 3GPP, a DRA is defined for session binding in IP-CAN sessions (equivalent to PDP context in 3G) towards a PCRF server. This was designed for multiple Diameter sessions in VoLTE in order to control the LTE and the IMS parts of the VoLTE service. To maintain an efficient and scalable network rollout, it is important that the LTE parts of an IMS VoLTE call, together with the IMS parts, are controlled by one and the same PCRF (server). Similarly, consistent policy rules need to be applied to the session that are related to the same VoLTE call. Let's explore in some more detail what needs to be managed by the same PCRF server and why. When using a VoLTE-enabled device, the mobile subscriber first needs to register to the network and establish the default data bearer to exchange data with the network or applications. This is followed by the authentication and authorization procedures, and mobility management communication between an MME and the HSS where the subscriber profile is stored. (Incidentally, the signaling for these procedures typically uses the Diameter S6a interface that is also often routed with help of a DRA). Now this device can establish the always-on LTE default user data bearer. In order to do so the device communicates with the PGW and establishes a user data session. For that user data session, in this case still the default bearer, the PGW needs to contact the PCRF via the Diameter Gx interface and receive the policy and charging rules for this customer's data session. Once the policies have been exchanged and applied by the PGW and sometimes there are other involved PCEFs (Policy and Charging Enforcement Function), the mobile user can either use Internet services via the established default bearer or in our scenario, opts to continue to establish a VoLTE call. To do so the VoLTE application on the handset will communicate (via SIP, over the established default LTE bearer) with the IMS network and its embedded VoLTE application server. First a SIP signaling bearer needs to be established after policy for that bearer is applied. To apply the policy, the IMS's P-CSCF needs to communicate via the Diameter Rx interface with a PCRF server. Actually, it needs to communicate with the same PCRF server that was already involved in managing the related LTE default bearer. This is exactly where the added-value of a DRA's session binding functionality becomes necessary, because the DRA has to search its memory for the same PCRF server that was used in the Gx session for that specific customer (e.g. specific IMSI and session ID). It has to match the unique and related information in the Rx signaling in order to make the same routing decision and end up at the same PCRF server. The relevant IMS information is the Framed-IP address because IMSIs are not usually required in IMS. A smart DRA has stored in its memory the association between an IMSI and Session-ID plus the Framed-IP address used by the device. If now that same Framed-IP address shows up in an IMS Diameter Rx message, a match can be made and the same routing decision can be applied. Now once the Diameter Gx for the LTE part and the Diameter Rx for the IMS part are bound to the same PCRF server we are almost there. Next comes the exchange and application of the policy and charging rules for the SIP Signaling bearer. And now we can move to the third key component of the VoLTE call and that is the SIP signaled voice. For voice signaling, the same PCRF server needs to be addressed, and the related IMS signaling is again exchanged via the Diameter Rx interface. Finally, once the policies and charging have been exchanged and applied, the VoLTE call can be made successfully. If there is a need for changing the policy or charging rules (for instance, if a customer reaches a certain threshold), than the same PCRF server can communicate via Gx to the LTE's PCEFs and via Rx to the involved IMS elements like the P-CSCF. In this way, the various sessions that are related to the same VoLTE service are managed consistently. Also when the VoLTE call is terminated the various sessions need to be released, except for the LTE default bearer, and the correlation between the LTE and IMS part of this VoLTE call can be cancelled. Other DRA added-value in VoLTE There’s additional value to the fundamental session binding functionality of a DRA. A DRA can enable optimal call management ensuring higher quality-of-service VoLTE calls. For instance, think of all the different vendors’ equipment that is needed to exchange Diameter Gx and Rx signaling. One example is when the LTE PGW has a different Gx implementation than the PCRF. In turn that PCRF can have a different Diameter Rx implementation than the IMS's P-CSCF node. Typically inside an operator's network, there will be various vendors for LTE, PCRF and IMS core network elements. And this is the norm in roaming use cases where the visited LTE network is out of control (meaning a different vendor) than the home IMS network, where the P-CSCF (and other elements) will be involved. In addition, once VoLTE takes off more substantially, the quantity of signaling also will take off and increase dramatically. Therefore, a DRA will play the most significant role in providing load balancing and overload control, both in normal circumstance but clearly also under special circumstances like when network elements went down and recover or other heavy signaling loads are occurring. A DRA could also prioritize VoLTE related signaling, over all the various Diameter interfaces. When serving this function, operators can provide a higher quality VoLTE service over other services, particularly when other services load the network. In this case, a network without this DRA functionality of prioritization, would experience degraded VoLTE service. There are more added-value functionalities – all made possible by a DRA, like VoLTE specific KPI generation. As time goes on and we experience increased use of VoLTE, we will learn more and more about how a DRA can improve the quality and efficiency of VoLTE and its related services. Peter Nas serves as Senior Solution Architect for the Traffix SDC team at F5 Networks and draws from more than 20 years of telecom experience to advise operators how to leverage Diameter signaling solutions to enable the optimal LTE experience. Peter joined F5 with the company’s acquisition of Traffix where he was responsible for global business development. Prior to joining Traffix, he worked at Tekelec focusing on market development for Diameter and SIP routing. In his days before Tekelec, he served as Core Network Engineering Manager at a prominent mobile operator in the Netherlands.
Sally Orders Lunch: Retail On-Line Payment
Sally is hungry but she left her wallet at the office. “I know, I’ll go to the Local Diner,” she thought. “Let’s see what looks good.” She opens the website and sees: “Yum, the hot dog looks good, and I’ll also have a coffee.” Sally clicks the two items and sees: When Sally placed her order, the Local Diner website established a session with Sally’s mobile service provider to get authorization for the purchase: The website requests the Diameter Routing Agent to make sure that Sally can pay for her order. Sally has a contract with her mobile provider that allows her to pay via her monthly bill or via a pre-paid account. The Diameter box checks with the carrier’s On-line Charging System and reserves the total amount of Sally’s lunch. Sally continues her walk to the Local Diner and thanks goodness that she pre-ordered because the line is out the door. She notices a short line, “Pre-Orders here.” Sally walks to the register and sees a placard: The placard is printed with invisible capacitive ink in a specific pattern that's detected by the touchscreen as multiple simultaneous finger presses. The arrangement of this pattern is used to link Sally’s phone with the Local Diner website. The website triggers a second set of messages to the Diameter Routing Agent that first verifies that the phone is actually Sally’s, then confirms the charge to the carrier’s billing system: The On-line Charging System assigns a transaction id and the Diameter Routing Agent sends the Local Diner website a receipt. The OCS settles the transaction by transferring funds to the Local Diner at the end of the day. The clerk sees Sally’s confirmation of payment on his screen so he hands over her order with a big smile. Sally’s phone displays the following: This customer scenario can be realized today using secure RESTful transactions between the Diner’s website, an F5 Signaling Delivery Controller and proven Diameter Credit Control Application messages to a carrier’s On-Line Charging System. The touch screen phone’s capability to read invisible ink is new technology but is currently available, without the requirement to download a reader onto the handset. Next: Sally Goes to the GroceryLooking for gold under a standard DRA
People have often told me that I should share some of the content of my discussions with customers. So here goes: While speaking to a customer I begin to reflect on why DRAs (Diameter Routing Agent) usually interest core network signaling engineers as they are the ones who are building the Diameter signaling network and require a solution for optimal network scaling. Our conversation focuses on how much more efficient, smarter, flexible, cost effectively, and securely we can manage the signaling load for Diameter messages and other protocols. Most people who are involved in mobile broadband or LTE are not that interested in Diameter signaling. At least I find this to be true when I address Diameter directly in pure technical language. However, when I speak about what great things we can do by using the information contained in every signaling message, you get a complete different conversation, and an interested audience. Typically, when discussing Diameter signaling the interest is in terms of what a DRA and DEA (Diameter Edge Agent) should be able to do according 3GPP and GSMA specifications. But as there are now more vendors claiming to have a DRA/DEA (although only a few are actually deployed) … customers are usually surprised at the possibilities of adding services, increasing security, and optimizing the network when deploying a DRA. If we rename DRA/DEAs to more of a smart proxy (or charging controller), meaning a function that can look inside a message and make decisions on message content, while looking from the application level downward (remember Diameter is an application layer protocol), you get a completely new field of opportunities. The people working on an operator’s commercial services side understand that their customers are generating more and more traffic. And they have been notified that this traffic congestion can be a huge challenge for their network people to manage properly. (In fact this is the ‘standard’ technical DRA discussion) However, when an element like a DRA is inserted in their network to manage the signaling load, here we see the added value of a DRA to look into application specific aspects. Here are some examples that have been well received by services/commercially oriented people. Example 1: Offloading from OCS resources When a prepaid customer is out of credit, it usually takes quite a few re-attempts before the customer or application realizes that there is no credit left and that is the reason the requested service is not working. However, during this process, there has been lots of signaling messages generated to communicate in “Diameter language Gy” that there is zero balance left, and these messages use the resources of an OCS (Online Charging System). But by looking at the Diameter message in a smarter way (e.g. with application view) you can proxy the OCS for this very simple function and optimize its resources for use by only revenue-bearing messages. This is what our SDC does, the Signaling Delivery Controller for Diameter management. Example 2: Rollout special campaigns at lightning speed If a DRA is deployed to sit in front of an OCS to protect it for problems like overloading, this same DRA node can enable a quick rollout of special marketing campaigns without even touching the existing OCS and its surrounding provisioning system. This news would make your marketing team extremely happy as currently, they must wait for long development times plus each new service is weighed against high costs. For example, if you want to offer a specific segment of customers or devices a special offer such as free minutes on a public holiday there no need to bother the OCS. A smart DRA can do the job quickly and at minimal cost. Example 3: Speak all dialects of Diameter Our customers know that our SDC “speaks” all the Diameter dialects that the various vendors have implemented (more than 50 at this writing). And if that wasn’t already enough, it also “speaks” to other protocols like SS7, RADIUS, LDAP, etc…. All this information is all very interesting to technical people but not to marketing services and commercial people. However, I explain that by speaking the same language, new services and promotions can be offered much faster and more cost efficiently. Plus the fact that these offerings will also increase signaling traffic without any negative impact on the network so the network engineers won’t get angry. In fact, it’s a pure “win/win” as it is the traffic you want to generate because it brings revenues and creates customer loyalty. In summary, my discussions usually leave people pleasantly surprised with the knowledge of the added value of our smart Diameter solution, known as the SDC. . It is not just another award winning DRA/DEA but a platform that is the starting point of application-relevant signaling management by giving you access to the gold that is inside the signaling messages… so don’t hesitate and contact us, surprise us and we will surprise you!Diameter - SS7 IWF - Bridging the Signals between New and Old Worlds
This is written by a Guest Blogger,Ohad Ramot, Principal Software Engineer at F5 Indeed, LTE (4G) networks are spreading rapidly and are being deployed all over the globe. However, most of the networks out there are based on 2G/3G technology, and it seems they’re here to stay for awhile. This requires operators and roaming mediators (IPX) to face the challenge of maintaining and interacting with both network architectures in parallel. 4G networks are growing, while 2G/3G networks still serve most of the subscribers as they have been doing successfully for the last decades. 4G and 2G/3G network architectures differ in many aspects. One of these differences is the signals mechanism which allows network nodes to interact with each other for authentication, billing, subscriber profile provisioning and more. While 2G/3G signaling mechanism is based on SS7 protocol stack, 4G networks use the relatively modern Diameter protocol on top of TCP/SCTP/IP stacks. Although both signaling methods provide solution to the same set of problems, they stem from different architectures and design philosophies. As a result, many 2G/3G network elements cannot interact directly and seamlessly with 4G network elements. A solution is needed for all those cases where this inter-network communication is required. Common examples for such scenarios could be: A 4G subscriber who roams to a foreign 3G network. In this case, the hosting 3G network needs to interact with the home 4G network of this subscriber. The same could be if a 3G subscriber who owns a device supporting 4G roams to a 4G network. The device will connect locally to the 4G hosting network, which will need to interact with the home 3G network. An operator which starts deploying a new 4G network, but still didn’t cover all areas while its 4G subscribers might be in geographical areas where only 3G coverage is available. An interworking Function (IWF) solution enables an LTE network to have an extension towards an SS7 network. It provides the capability to translate Diameter signals to their corresponding signals on MAP and vice versa. This translation is based on 3GPP organization specification. However, the challenges faced during the development were not only “translate this attribute on MAP to that AVP on Diameter” but involved the different behavior of the application, for example, a DRA like our F5 Signaling Delivery Controller (SDC) has to behave like a 4G network node when it interacts with a 4G network, while simultaneously behaving like a 2G/3G network node, on its other interface. An example for this “behavioral translation” (which is beyond mere protocol conversion) are some flows of simple Diameter transaction of Request-Answer, which turn into complex flows containing several requests and answers dialog between IWF and its SS7 peer. Some of these different behavioral aspects were not even covered or defined in any spec and we had to invent our own ways to implement them. And as always, keeping the future in mind, our current design of the solution has enough flexibility to be enhanced for some more SS7-wise applications besides mere Diameter-SS7 interworking. One example of such enhancement is enabling our SDC to act as an enhancement of 3G STP for smart manipulations of MAP messages, which the latter cannot do. Another example is to make SDC translate RADIUS authentication on requests from Wi-Fi domain to 3G HLR on traditional telephony domain. To summarize, the development process of such an application gives developers the opportunity to be pioneers, creatively think of solutions and overcome new challenges. We believe that having the F5 SDC act as a bridge between the new and the old worlds of telephony signaling enables F5 to enlarge and strengthen our footprint in this very important domain.TRAFFIC! Growth and Carrier Challenges – Part II
This is Part Two of Two for a Guest Blog by Tom Carter, VP Worldwide Sales at F5 Networks. What enhancements are needed to address the network and signaling congestion? The 3GPP standards provide a very useful architecture reference to enable mobile data connectivity and an essential suite of services. There is a need to support numerous third party applications and infrastructure so the reference guide provided via 3GPP is very useful. The additional network elements and features can integrate across Layers 1 thru 7 in both the control and data planes to enable a more holistic approach to network utilization when deployed where standards are employed. The move to next-gen networks is challenging for operators and sometimes overwhelming due to the incredible pace of innovation in applications both in terms of the sheer number of applications and their diverse requirements on the networks. To address this application vs network visibility and control gap while also managing to the requisite onslaught of signaling that is created – there is a need for a mechanism to expose network information to app developers and applications to network resource requirements and DIAMETER is a defined Protocol within 3GPP to do just that. Data is MONEY to the operators and Diameter as an underlying standards based protocol that will be used to “Move and Monetize” this data into Service Revenue. Diameter – what does it do? • Controls how content traverses network equipment and devices • Gives subscribers permission to access websites, applications and services • Delivers charging commands • Enables mobility management, giving subscribers the ability to roam onto partner networks The massive scale of wireless subscribers and the huge growth in wireless data and 4G smartphones that are continually connecting and disconnecting are driving tremendous growth in signaling traffic and challenging the operators to stay current with demand. The key however is that operators are evolving. They are shifting from providing only connectivity to focusing on providing a compelling user experience. The network value has shifted from layer 3 (IP) to layers 4‒7 which are the application layers. As such, the networks of tomorrow need to be policy aware, service aware, subscriber aware and highly adaptable to the changing market landscape. The network needs to move from static inflexible elements to software-based and programmable elements to help operators address the market changes today and in the future. Understanding customer behavior and utilizing policy control is becoming a very powerful mechanism to enhance the network. Subscriber and service aware traffic insight includes the ability to identify subscribers, applications, services in both the traffic access AND the signaling control elements. Using techniques such as content inspection to classify and steer traffic appropriately is imperative or what many call table stakes. As specific traffic is identified it can be individually addressed and service specific policy based on the type of the traffic and the nature of the traffic flow can be utilized. Based on the nature of the traffic flow certain types can be blocked or deferred or throttled. Combining traffic awareness with full control and visibility of the signaling path enables operators to have granular control leading to adjusting their network to support numerous services. There are many who believe (and I am one of them) that the operators who can dynamically create services based on an individual subscribers usage and patterns will ultimately win. Policy based networks utilizing DIAMETER that give full traffic visibility can be deployed to not only protect against congestion and overload but to empower operators as they shift their business models to address the opportunity for data. Mobile media and data services are the only drivers for growth in the near term as voice revenues decline globally. Operators will need to invest in infrastructure, developer ecosystems and be able to capitalize on the flow of new and improved handsets. An intelligent, dynamic or “Stateful” Diameter infrastructure that is tightly coupled to the DATA path, the CONTROL path as well as the SIGNALING path will be the key for operators to unlock this growth opportunity bring upon by data while managing the “PINGING” signals. Operators who distinguish packets, applications and connections at wire-speed will be equipped to monetize.TRAFFIC! Growth and Carrier Challenges – Part I
This is a Guest Blog by Tom Carter, VP Worldwide Sales at F5 Networks. The incredible growth of smartphones in mobile operators’ networks has had dramatic effects. It’s GREAT for users but a huge challenge for operators, and in fact a double edged sword. The insatiable desire for consuming mobile data has enabled operators to lock in long term contracts and drive new revenues, but the increased demand from these new powerful data hogs comes with a price - the host cost of managing the effects on the network. However, this volume of content that users are consuming is not the greatest challenge that mobile operators have to deal with, but rather it is the dramatic rise in SIGNALING that is generated. So what is “signaling”? Simply put, signaling is the communication system that authenticates users to get connected to wireless networks. When you turn on your device, or when you land in a foreign airport, the first thing that happens is user and device authentication. This is a type of transaction that takes place in an LTE network, using a communications protocol called “Diameter”, between the device and the network’s subscriber database and unique subscriber service provisioning as verified by the policy rules established per subscriber. As data consumption rises, the number of transactions to the radio tower increases together with the signaling that is required to support them. Plus, the apps that are left open in idle mode (in the background) on smartphones, also “ping” the network frequently and add significantly to the number of signaling messages. Every time a phone is asked to retrieve content whether it be Facebook, Instagram, Twitter, and the like, there is a need for the device to connect via a signaling path. Therefore, mobile consumer behavior creates so much signaling traffic within the carrier’s network that it now outweighs the mobile content data traffic by FAR - at least by a factor of 3x. As new smartphones hit the market the carriers are faced with this deluge of data requests (“pinging” the network) and need to cope with the associated signaling. MANY carriers struggle to keep up as their next- gen networks evolve and bring on congested signaling operations. And the problem only grows as more apps aim to deliver content and messages in real time. Improvements to network, device, platform and application design can help. They will help alleviate the capacity issues but users are unpredictable and the only sure thing is that mobile consumers will increase their data use, particularly with faster LTE networks. All these factors require new enhancements to mobile operator networks with capabilities that are designed specifically to deal with these new and evolving challenges. What enhancements are needed to address the challenges? Look for a few thoughts on that (Part II) in the next few days. I will have some airplane time while travelling to Mobile World Congress.
