OASIS SOA TC

1. OASIS SOA TC John Storrie – CTO Technology Field Office 1

2. Telco Business Model

3. Telco Owned Products Telco Sourced Third Party Products Current Telco Business Model Costs Revenues Network Termination Charges Residential Subscriber Government Content Providers $ $ Enterprise Device Providers SMB Application Providers

4. Telco Owned Products Third Party Products Future Multi-sided Business Model Developers Multi-Sectors Multi-subscribers Retail Sector ISV $ $ Advertisers Content Owners Virtual Operator

5. Voice 2.0 Use Cases

6. Enhanced Find Me • User requests connection to another party • The system checks the end users terminal status to determine if they can be reached • If this status is acceptable then the users presence information is requested to determine if they will accept a connection from the calling party • If this is acceptable then the called party is contacted • Once the session terminates then the charging data is collected • If the presence or location information indicates the called party cannot be contacted then the caller would be connected to the called party’s message system

7. Enhanced Find Me Web Service Instance Terminal Status TS 29.199-08 Terminal Status Supplier Presence TS 29.199-14 Third Party Call TS 29.199-02 Payment TS 29.199-06 Third Party Call Supplier Presence Supplier Payment Supplier Enhanced Find Me: Service Model Flow Message Bus

8. Use Cases • Some Representative Use Cases • Monitoring and Compliance • Orchestration • System2System • Internet • Security • Dynamic Configuration • Communications stack in public domain • Communications Switcher • Multi-Functional Application • Composition • Text Cross Modal • Multi-Modal • Disability

9. Monitoring Application • Mike creates analytics application on corporate application server that needs to observe calls or conferences that are active for a given set of user types. System will store time, length and known parties of the conversations in communications data mart. • If certain key words are detected in conversations of these user types, the system will automatically start recording the conference and tagging time, length and parties records. • In conversation the application will monitor the status (talking, muted …) of all users on that conference. • A week later, Mike decides to change application processing workflow to also look for same key words in e-mail traffic. • Changes workflow for notifications are sent to compliance officer for high suspect communications • Record multi-modal type conversations saving tags and conversation to data mart. • Compliance officer looks at communication analytics • Communications preferences based on certain types of communication interactions • Potential compliance breaches based on key work event activations

10. Public - Internet Scenario • Mike is on public internet browser at customer site. Mike links thru web to system. Communications toolbar w/ add-ons allowing for rich desktop/ web interaction (i.e. drag and drop) between shipping application and communication application • Mike sets up call to Pete. Clicks on toolbar, open contact list and see if Pete is available by voice or video. Note: download toolbar figured out characteristics of local device and provided this to system • Mike places video call to video, browser opens up with video widget. • Customer want trial on supplier/ shipping site as a test for a week long trial. • Mike goes to sales system and configures a guest account with users and capability. • Virtual boundaries are set up across company boundaries. • Workflow and widgets created for capability to be embedded into application(s) • Users go to site, a tool bar and browser page is opened displaying instructions and flash demo. • User opts in, signs up and is auto configured in system. • At the end of the week, those that opted in were surveyed, a report was created to see the actual usage pattern of the test set of people.

11. Communication Switcher • Mike needs to get in touch with Alice • Mike’s and Alice’s active sessions are determined • The preferred and allowable modes of communication and device characteristics are accessed • System places call from Mike’s mobile to Alice’s desktop • Alice accepts, call is connected. • Alice needs to run and wants to transfer call to mobile. • Alice tells application to switch call to her mobile. System informs Alice that this is possible. • Alice switches call. • Alice wants to add Stanley to call, selects monitoring option • System searches for Stanley’s availability. System locates Stanley at his mobile – establishes conference. • Alice ask Stanley a question. • Stanley hangs up. Alice looks for status of Stanley on conference to confirm disconnect. • Alice continues with conversation with Mike

12. Disability - Cross-Modal Use Case • Mike needs to get in touch with Alice • Mike’s and Alice’s active sessions are determined • The allowable modes of communication and device characteristics are accessed. Alice is hearing impaired. • System looks Alice’s availability with device characteristics supporting voice and TTS. • Alice is available by web phone with linked TTS Application for hearing impaired • Call is made to Alice and system directs to appropriate device • Alice answers call and web page pops up indicating Mike’s call transcribing Mike’s voice to text.

13. SOA Adoption - Mobility

14. WiMAX vs. SIP perspective in SOA • WiMAX Forum is looking at using a model based upon Web Services to expose the network capabilities to the application space, via the USI, Universal Service Interface • Discussion is on-going as to the best model to achieve this given the existence of standards such as OMA OWSER, Parlay-X, OASIS and others • Liaison statements exchanged between USI and OMA ARC, the current owner of Parlay-X specifications • Current defined USI enablers do map to the majority of the current OMA Parlay-X interfaces

15. SOA solutions: SIP and non-SIP models • SOA applications need to interact with multiple network protocols, SIP being just one of these • In many cross network applications SIP based services may end up being converted into a legacy signalling protocol • SIP to SS7 • SIP to AIN/INAP/MAP • An SOA solution running via WSDL/REST can map to any signalling protocol as required by the network

16. Open Mobile Alliance (OMA)

17. Real Time Composition/Orchestration

18. Real Time Composition/Orchestration • SOA provides capabilities for application consumption • Capabilities can come from multiple providers • Each service may consume multiple capabilities • WSDL interfaces can return information for application decision making • There may be multiple application layers each with different latency tolerances • Orchestration has to be performed in a latency model suitable for the telecommunication protocol state machines • The lower in the network the orchestration occurs the tighter the latency tolerances become

19. BPEL • BPEL originally designed for IT application space • Purpose: integrate long running inter-machine business processes • Evolution to include BPEL4People to provide human time frame interactions rather than machine speed • Current benchmarks show 80 TPS on dual Xeon cpu • Baseline HLR runs 5500 TPS (Telecom One TM1 benchmark) • Basic SIP B2BUA is 10+ network transactions “I feel the need for speed!”

20. Parlay-X • Parlay-X API co-ordination is at the WSDL level • Designed to be incorporated into WSDL tooling • API’s moved from 3GPP to the OMA enabler model providing capabilities that can be co-ordinated as per the SOA model rather than bulking out each API to do everything • OMA ARC API’s are evolving to include “correlation” to allow composition of API’s into WSDL based service • Some Parlay-X API’s are synchronous and some are asynchronous

21. Orchestration Approaches • SIP servlets • Service Component Architecture • JAIN SLEE • CDL – Choreography Description Language • BPML – Business Process Management Language