Reduce network costs and complexity while delivering new services
The standalone toolkit communicates directly with the SVI-STP over a comprehensive message API. Messages triggered at the SVI-STP are sent to the Python based toolkit where message decode, manipulation and logic can be applied to deliver the required feature or service. The Toolkit interfaces to a wide range of Open Interfaces including SQL, HTPP, XML, LDAP, SMTP and SOAP allowing lookups, storage and integration into clients OSS/BSS infastructure. The toolkit can also auto configure the SVI-STP via XML allowing, for example, the rapid development of firewall type applications. The powerful and flexible toolkit allows network engineers or Squire Technologies commissioning engineers to rapidly build complex logic, which can be tested offline before its deployment into your networks.
The following case studies show how our clients have used the Service Creation Toolkit to solve network complexity, reduce costs and introduce new services.
Case Study 1: Mobile Operator – MNPMobile Number Portability is obviously a key regulatory requirement for any Mobile Operator. Different countries implement number portability in different ways. Often there is a central number portability database controlled by a regulatory body from which the operators regularly take a copy. All operators logically implement MNP the same way, i.e. does the called subscriber belong to the network originally associated with the number and if not which operator does it belong to and where is it being routed? At a network equipment level there are a variety of options and solutions. Is it all controlled and realised via the operators HLR? Is it passed through a Signalling Relay Function? Is the lookup accessed over IN (SS7 Intelligent Network) via SQL or worse?
A client recently found themselves in the position whereby their IN platform used for MNP was reaching end-of-life. Not only were they running out of capacity but the interface to their OSS/BSS systems was via a vendor specific MML (Man Machine Language). The straight forward solution was to simply use the Service Creation Toolkit to provide access to an SQL database. The changes in the end-to-end signalling were provisioned in the toolkit as were the database lookups. The daily refresh against the centralised database was implemented through a simple script.
Now the client is in the position to decommission the IN platform, but perhaps more importantly can integrate their number portability platform directly into their OSS systems via standard SQL.
Case Study 2: Firewall / Fraud Detection
In 2016 there was a great deal of press surrounding security breaches and vulnerabilities in SS7 networks – particularly GSM but also fixed line. One reason for the rapid rise in this type of fraud over the last ten years is not particularly due to weakness in the underlying standards but rather the shift to SIGTRAN which carries SS7 over IP. Key network components in an SS7 network typically contain rudimentary blacklist/whitelist functionality allowing operators to identify and block unauthorised subscribers, calls and SMS. But fraud, as witnessed across all network types, has risen in its level of sophistication. To counter this the SS7 firewall industry has also developed in its level of sophistication, primarily taking advantage of big data technology to allow complex post processing to identify patterns and anomalies.
Somewhere between the extremes of white list/black list and big data is the need to be able to rapidly monitor and detect particular message types, identifiers or sources and then take appropriate steps to block offending traffic. One customer we are currently working with is using the Service Creation Toolkit to monitor incoming subscriber registration requests on a GSM network, probing the subscriber via MAP signalling to identify location and depending on the response blocking or tearing the subscriber call down.
Another customer is working on integrating the toolkit with their firewall allowing them to:
1. Easily store SS7 signalling in a database for post processing
2. Auto provision the STP to block suspect traffic
Case Study 3: Lawful Intercept
At the signalling level lawful intercept is all about identifying the subscriber that has been marked for interception and then passing the subscriber media to an appropriate device for recording. Lawful intercept at the signalling level can also be about proactively enabling lawful intercept on a device. Clients are able to use the toolkit to test and probe the network to see if they can enable intercept. Once a successful method has been found the surveillance can start.
As is the nature of lawful intercept targets are constantly evolving their knowledge and know-how and putting in place strategies to avoid surveillance. If an intercept technique becomes known then new methods and strategies can be rapidly tested and implemented to provide a new solution.
Case Study 4: DIPS and Lookups
The toolkit allows customers to easily provide lookup’s or dips. One of our clients in the US performs an 0800 dip for all relevant calls passing through their network . The dip is to an external provider and there is an associated cost with each dip. In order to reduce costs the operator is building an internal 0800 database. For an 0800 call a lookup is first done on the internal SQL database, if there is no record then the external IN based lookup is performed and the result is stored in the internal database and the call is routed accordingly. This simple update to the way the dips are done will allow our client to organically build their own internal database whilst reducing their long term costs.
Case Study 5: Message Modifications
The toolkit allows clients to rapidly modify individual SS7 messages or contents of messages in much the same way a modern day SBC / DSC does for SIP / Diameter messaging. A UK client of ours provides a helpline service in the health sector and it's imperative that all calls passed to the call centre have the calling party number available. They found on rolling out their service that certain calls have the calling party identifier turned off – the number is available in the message but a piece of kit in the providers network is disabling the presentation. The solution is to check the messages to see if the presentation indicator is disabled and if it is modify the message so the indicator is “enabled”. The message is then forwarded onto the call centre with the calling party number.
This solved, in a straight forward fashion, what could have been an intractable problem for our client.