http://www.stratus.com/download/index.cfm/pdf/telecom/CSB-white-paper.pdf
Subscriber expectation – have multiple services and multiple devices, so they expect to access any services & content from anywhere on any device. So having IP backbone is essential to achieve such a need. So it is essential to have converged routing, messaging, content and centralized subscriber profile information. This is nothing but having a unified service delivery platform catering to different networks. In this service delivery platform, Stratus network is focusing on creating a service broker which can mediate in a multi service, multi access and multi network environment.
Stratus service broker consists of two part. One is the signaling gateway that converts and handles different protocols and the other is a mobile call converge device which takes care of handling call and call handover between different networks (like WiFi, Celluar, TDM etc); also it handles service interactions by connecting to external subscriber database lookup. Below is the architecture of this service broker.
Now this service broker would also provide an IDE to create relationship between the services and create service rules (in the same lines as business rule creation in an SOA environment). Service rules thus created will have to have a service rule execution environment similar to SLEE. But now will be the interaction between such a service rule engine and an independent service execution environment be handled? i.e., if there is already established legacy IN services and SIP application server, can the service rule engine work with this service broker. It is possible to achieve this only if the service broker can sit between the core network elements and the application servers (which is already proposed as SCIM in IMS architecture). But with all network service traffic hitting the service broker, it is essential for the service broker to make some kind of distiction whether the service requested by the end user is a straight forward one or has some interaction. So the transaction processing capability of service broker will have to be really good and should not introduce any additional delays. On the other hand, such service brokers would really help in avoiding the interoperability issues as it can have agreement with NEPs to support their proprietary protocols (INAP/CAP/SIP) and on the AS side it can publish its own protocol or can work as proxy/protocol coverter based on the actual need. Following is the architecture of the Stratus service broker solution.
SINAP – Stratus integrated network application platform
C-SLEE – converged SLEE
Interesting point to note here is the Stratus T series hardware. I wonder whether it an ATCA blade server built by Stratus. Overall I think this is a necessary component in the overall service delivery platform of an operator who is in the path of evolution to an IMS based network. And for the greenfield operators, this element could help them to explore the possiblity of using a shared application server either from an existing operator or use a hosted application server from the vendor.
