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.
F5 LTM SNAT: only 1 outgoing connection, multiple internal clients
I have an F5 LTM SNAT configured: ltm snat /Common/outgoing_snat_v6 { description "IPv6 SNAT translation" mirror enabled origins { ::/0 { } } snatpool /Common/outgoing_snatpool_v6 vlans { /Common/internal } vlans-enabled } ... with a translation configured as: ltm snat-translation /Common/ext_SNAT_v6 { address 2607:f160:c:301d::63 inherited-traffic-group true traffic-group /Common/traffic-group-1 } ... with snatpool configured as: ltm snatpool /Common/outgoing_snatpool_v6 { members { /Common/ext_SNAT_v6 } } ... and finally, with the SNAT type set to automap: vs_pool__snat_type { value automap } The goal is to achieve a single Diameter connection (single source IP, port) between F5 and the external element, while internally multiple Diameter clients connect via F5 to the external element: However, what ends up happening with this SNAT configuration is that multiple outgoing Diameter connections to the external Diameter element are opened, with the only difference between them being the source port (source IP, destination IP and port remained the same). The external element cannot handle multiple connections per the same origin IP and the same Diameter entity (internal clients are all configured to use the same Origin-Host during the Capabilities Exchange phase). Is there a way to configure F5 to funnel all the internal connections into a single outgoing one?
Why Separate the DRA from PCRF Functionality?
Or Why Not Combine the Functionality if Possible? To begin, we should ask what are the intended functionalities of a Diameter Routing Agent (DRA) and a Policy Charging & Rules Function (PCRF). A PCRF is the Policy Decision Point (PDP) virtually cut-and-pasted into IMS and afterwards taken by the 3GPP who awarded it with a new acronym based on the older concept of policy based networking. It is a place where business rules are merged with network actor information (in the case of mobile, subscribers). It acts as a centralized engine for deploying policy to enforcement points in a specific, limited domain (in the case of mobile, usually a MSC, APN, or geographic region). In theory, upstream from the PCRF the business rules themselves are stored in a rules base (the SPR), and the user information is stored in a directory (the HSS or UPSF) and the execution of the policy (rules+user+context) is done downstream by policy enforcement points. However, this theory isn’t always strictly translated to practice. A DRA is a message switching engine that acts on a peer-to-peer network to perform proxy, translation, routing, and relay actions against messages. This is analogous to how the packet switching engine in a network element performs proxy, translation, routing, and relay actions against Ethernet/IP frames (L2-4) but it is performed on the L7 Diameter message in the context of the named interface application. It is deployed as a strategic point of control to direct Diameter message delivery in the EPC and IMS control plane; facilitates message-proxy, horizontal scaling for control plane elements that cannot scale (load balancing); provides virtual end-points to secure and simplify external communications (virtual servers /DEA); enhances interoperability by performing translation (interop fix-up); bridges between 3GPP and Web 2.0 messaging and architectures; and creates mechanisms for the capture, distribution of, and action on information contained in messages across domains or subsystems in the EPC and IMS (the message switching stratum). So, given those definitions, should the function of a DRA be separate from the PCRF function? Firstly, they don’t have anything to do with one another other than they are both Diameter peers. Another way to think of it is to ask why would someone separate the routing and switching function from the SMTP and IMAP function? They both use TCP/IP, so why not put them in the same sheet metal? Deploying a DRA as part of an EPC or IMS functional element is like deploying a L3 switch as the NIC for a server; there isn’t anything wrong with doing that, but you’d better have a way to justify the cost and tame the operational complexity of doing that if all you really need is a NIC. Secondly, the PCRF is part of the Policy Control and Charging (PCC) subsystem and the Integrated Multimedia Subsystem (IMS). Those are only two functional domains in the EPC and IMS, so by integrating the DRA into the PCRF you’ve created a hurdle to provisioning that function in the Mobility subsystem, the roaming subsystem/internetworking function, the integration of fixed access, and the visibility and reporting subsystems necessary to actually operate the packet core. Thirdly, by choosing an embedded DRA over a message switching stratum for the EPC control plane, the operator is hitching scalability embedded in the DRA function to the expandability of the rest of those functional elements. This is the same conundrum that the dynamic datacenter faces when trying to embed ADC functionality into the elastic compute node; these two functions have different scaling metrics, different utilization curves, and different scaling requirements. Just like OpenFlow and network virtualization doesn’t solve that for the cloud, there isn’t a viable solution for the elastic packet core. Finally, when you don’t have a message switching stratum in the EPC control plane (that also extends to the VoLTE functions of the IMS core), you lack a mechanism to apply policy end-to-end on the network, or to deploy offerings that extend policy to roaming customers to enhance value because you don’t have a message switching stratum. Instead you have a heterogeneous mix of DRA-like functionalities that may or may not interoperate in a way that can be operationalized, some of which are controlled by the vendor of the function who has a vested interest in not participating in an end-to-end policy architecture. Put another way, operators who are content to become commoditized dumb pipes shouldn’t deploy embedded DRA functionality in their EPC functional elements, because they aren’t going to operationalize or monetize their networks with policy based networking driven product offerings. All they really need is a Diameter stack with a static configuration to maximize the fixed configuration economics required for commodity access providers. Conversely, operators that do intend to pursue value above connectivity should invest in a message switching stratum, because they cannot currently deploy the DevOps apparatus required to tame the operational complexity associated with managing embedded DRA elements in a high capacity dynamic heterogeneous network to deliver policy based offerings that customers will pay extra for (because such an apparatus does not currently exist). Vendors and system integrators will maximize their short-term revenue by selling integrated DRA function at premium rate. And by doing so, they ensure that functional systems are forced to scale in the least cost-effective way as traffic increases. However, they do so with the risk that their solution will be pre-maturely re-evaluated when the need to deploy a message switching stratum arises.
What is Intelligent Roaming?
Roaming means you connect with an operator in the country in which you are visiting: What can make it intelligent? When you are traveling abroad the last thing you want to worry about is loss of service from your mobile phone. And you also don’t want to start worrying about your next bill. Now that LTE is here, why can’t you just enjoy fabulous data speeds while downloading or watching a video and forget about the costs. Wouldn’t it be great if you could simply enjoy the local culture, exotic cuisines, colorful scenes and sit back and chat, talk and video about all these with your friends and family back home?!! Many people don’t realize what roaming entails and what it means for both the user and the telco operator. Apart from the basic concept of throwing your smartphone or other devices in your carry-on luggage there is a lot of technology that supports their operation. Currently, there are over 100 networks live with 4G capabilities offering subscribers rich experiences while at home. Undoubtedly, 4G subscribers expect the same quality and level of service to continue while they travel abroad. However, if you would have looked “behind the scenes” even way before 4G, enabling roaming required SS7 supported signaling for just voice and text messages in visited networks. With the evolvement of 2G/3G data, these roaming capabilities have become even more complex. For SS7- based roaming, there are some very good intelligent roaming solutions available. Many, if not most, operators use them. Typically they are based on so-called OTA (over the Air) mechanisms to remotely control the preferred visited network list. They are often enhanced with SS7-based network traffic steering. The OTA mechanism tells the SIM what is the order of network preferences for logging on. Usually, the SIM memory for this list is limited, so that in practice, the selection of visited networks can change frequently. Therefore to direct the roamer’s selection, a network traffic steering mechanism is often used which ignores attempts of a roamer to locate a specific network that is not among the top preferences of the home operator, forcing the handset to select another network until it either gets to the preferred network or selects the second best available network. This solution works because the signaling is sent back to the home network, enabling the home operator to decide the preferred network in real-time for each subscriber. Customers benefit as the best quality can be selected. However, the main driver behind this mechanism however, is that the home network can select the visited network chosen for the best negotiated price (even if this price can change on a daily basis in theory, but usually every few months contracts are agreed upon for a price per minimum volume). One important note is that with always-on services, like Blackberry email push, once the visited network has been selected, there is minimal chance that the roamer can update to another network. The selected network is completely invested in keeping roamers hooked in. And typically this happens with high usage, always on, high value roamers. Now we are entering the LTE/4G roaming era in which we have a fundamentally different situation. For the subscriber with a 4G smartphone, it doesn’t mean that much changes as the phone also supports the frequencies of the visited network. Operators want it to look simple and “just make it work.” The important technical change is that in LTE there is no longer use of SS7 signaling. Now Diameter is the chosen signaling protocol for mobility management (and for other functions like policy control, charging and more). Another major technical difference in LTE is that there is always a default bearer active, so that all smartphones/devices will be always on. Diameter-based Intelligent Roaming Take the scenario of a visited LTE network and assume the visiting customer has an LTE/4G supported device for that network. Also assume that there is a commercial LTE roaming agreement in place, and the roamer wants to use his smartphone just as he did in 3G technologies. The <!--ZZZLinkBegZZZ-->GSMA <!--ZZZLinkEndZZZ-->has defined how roaming for LTE should work commercially and technically. So in theory, there is nothing else needed other than implementing what the GSMA has defined. But now we get to the real unique value that can be added to the roaming experience. Here is how in a very intelligent way, the home network can remotely control the selection of the visited network by a specific subscriber. Here is how to force the device to reselect the network it originally selected, even overruling attempts by visited networks to capture the revenue generating customer. In addition to what was already possible in an SS7 based network, where a specific device could be steered to register to a preferred network, now there are customer, device and service-aware intelligent roaming capabilities. Since the intelligent roaming solution is configured as an application on the Diameter Agent functionality (DRA) that is required per GSMA guidelines (as per IR.88), it has full visibility of what’s going on in a specific device. It “sees” what services are being used and how “active” those services are. In other words, a network operator has real-time access to the signaling supporting policy control (typically Gx and/or S9 interfaces) and charging functions (typically Gy or related interfaces) while roaming. In addition, it has visibility to the service quality and the availability of all potential visited networks at any given moment. Simply put, we have a complete set of information to make the smartest decisions at any specific moment. So the operator can make decisions as to the best service selection for every roaming smartphone/device given all the business and operational alternatives available. The criteria used to decide to which network to connect is a real differentiator for the home network. The different factors can range from best quality to best price. The home network now has the power to control the redirection of high value traffic. This is possible even following the initial selection of a visited network. So at any given moment the home network can decide to interrupt the active default bearer or any other active link. With this capability the home network has full control of the revenue it can generate on a specific visited network. This capability of controlling the assigned traffic also allows the home network to negotiate a better price than when the home network will generate revenues almost at random for the visited network. With this capability, we’ve made a major jump in the roaming value chain. And keeping in mind that the global roaming market size is about 45 Billion (see reference 1 by <!--ZZZLinkBegZZZ-->Visiongain<!--ZZZLinkEndZZZ-->), the value of controlling the use of a specific visited network or minimizing the use a specific network is huge. Operationally speaking, when other traffic on the visited network, either generated by the visited networks’ own subscribers or by other visitors, cause the visited network to behave below a certain expected level, the home network can select an alternative network. In this way an operator can deliver a truly premium service to its own customers, according to the service agreements, customer and application experience for any individual customer, device and service. By deploying a Diameter Router (DRA) with intelligent roaming capabilities in addition to the GSMA required Diameter Edge Agent (DEA) functionality, operators can benefit from real-time control of the user experience while roaming abroad. And this benefit continues regardless of the time or service used by customers and devices. Diameter signaling and its unique position in the network for total visibility make this possible. 1 Visiongain has determined that the value of the global roaming market in 2012 will reach $45.1billion.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.Looking 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!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.
What Ingredients Make A Leading Signaling Delivery Controller and Diameter Router?
Prospective customers often ask, “What makes the F5 Traffix Signaling Delivery Controller the market leading Diameter solution, and the top Diameter Routing Agent (DRA)?” We put our heads together and here’s why we can proudly say that F5's Traffix Signaling Delivery Controller (SDC) is the market’s first and most mature Diameter routing solution, available since early 2009. Here are some more value added benefits of the Traffix SDC. The market’s most deployed Diameter routing solution with close to 30 live deployments at topcarriers. The market’s only full Diameter routing solution combining DRA, DEA and IWF functionality on one platformthat goes far beyond the industry standards’ requirements. Offers far more connectivity functions between Diameter to Diameter, and an IWF between Diameter to SS7. Has unbeaten performance and value/cost ratio –3 times more than the closest competitor. Is the onlyDiameter solution thatsupports over 50 Diameter interfaces The only market solution supporting Active/Active configuration. Is unmatched in supporting highly scalable and redundant configurations. Offers the wide look into the network control plane, providing performance statistics andtroubleshooting options. Includes a full Diameter testing and simulationsuite. Demonstrated unbeaten commitment to our customers for the best support, flexibility and satisfaction. Convinced? If not, tell us why in the comments below and let’s continue the conversation.
