Generally, "service logic" and "interaction logic" are intertwined and together provide services. Most operators run many services (sometimes also referred to as "applications"), hosted on multiple Service Control points (SCPs). With operator consolidation and competitive sourcing of SCPs and services, commonly a single network will use both SCPs and services from several vendors.

Why not use "service chaining"?

To combine these disparate services — and get around the SS7 signaling system limitation of only a single service controlling a call — operators often use "service chaining". This method alters telephone numbers in signaling messages, to make a series of services appear as a single service to the switch.

This works, but puts a great load on core network elements. For simple interactions, the core network must trigger the service layer many times, using numbering plans for feature interaction. For example, for a particular service, the switch would call the service layer (the SCP). By reconfiguring the SCP, when the switch gets a resulting message back, the "dialed number" transfers to another number that prompts a look-up, which sends it back to the SCP again, invoking another service (and so on).

The drawbacks to service chaining include:

  • New application insertion is difficult, because it requires re-configuration and feature modification of core networks and any new SCPs.

  • Operators may have difficulty making changes, because interaction requirements mean SCP application logic is tightly coupled.

  • As you have more and more services, and more and more combinations, the whole thing gets harder and harder to change and maintain.

The benefits of Service Interaction

The SIS takes a different approach, separating and structuring application and interaction logic. Using the Service Interaction (SI) model, you can change interaction logic without changing service logic. The benefits include:

  • higher service re-use — services are not contaminated with interaction logic related to their peer services

  • significantly less customisation — instead of requiring separate modifications for every application a service interacts with, you just need write the service once and then add compositions for new applications

  • vendor participation — each vendors' service logic does not need to tie into the others'

  • more prolific service creation — the market can expect more offerings from new compositions of existing (and new) services

  • faster and more cost-efficient development — composition authors don’t need the same knowledge as SCP application developers.

Previous page Next page