Services shared between network and endpoints

1. Services shared between network and endpoints Lill Kristiansen Prof. Dr.Scient, Telematics, NTNU Norway

2. Existing and new smart endpoints • GSM: New phones: • SonyEricsson P800 • Nokia Communicator • MS Smartphones • Samsung Smartphone for fixed network (ISDN) • PDA • Classical version without network • Or e.g. WLAN enabled • Future: In several parts

3. Existing and new networks • Circuit switched: • GSM for voice • UMTS for interactive multimedia (H.324M) • HSCSD for data (streaming, big files etc) • Packet switched • GPRS: • best effort, streaming • GPRS release 5 with QoS • UMTS IMS: IP Multimedia Subsystem (with SIP) • Fixed IP

4. Services vs applications • Traditional call related services: • Call forwarding, screening etc • standardised services • No/little competition on new services • Applications: • Using the underlying network e.g. GPRS • New combinations such as: • click-to-call-while-web-shopping, • call screening based on my calendar info • Competition!

5. Long term goals • Study modelling with both RPC-calls and states/messages • Javaframe: giving Javacode from SDL/UML- like models • Combinations of ’fat’ and ’thin’ machines, tradeoffs and business implications • Use of middleware even between the components inside the distributed endpoint • Use of SIP/IMS for combined services or create own applications with similar properties using e.g. JavaFrame

6. Short term goals • Study Javabased services/applications running on todays phones and networks • Study other applications or call based services that we may put on todays endpoint

7. 3 concrete examples • PDA • Classical solution: running a local DB • Networked solution • Call related services like personalised call screening • Either ’classical’ telco networked solution • Or ’IETF-inspired’ endpoint solution • Other screen based applications • May run locally, while the endpoint is networked

8. Classical vs networked PDA • Classical PDA • Running a local DB • No network, no phone, no IM system • Networked PDA/phone • Running the DB in the network • Imply 2 totally different business cases

9. DB Combinations seems better • Little need for voice and data at same time • Need endpoint with: • large storage (PDA-like) • network (phone-like) Data (synchr. on demand) GUI/browser IP DB/ Cache SMS/IM GSM/GPRS click-to-call call(voice)setup

10. Personalised call screening • Today when in a meeting: • Use CFU in the network • BUT: offers no personalisation/ differentiation • Use CallerID+ silent/vibrating mode in the endpoint • Is manual service and very personal • BUT is disturbing • May be automated and personal: • if endpoint is allowed to intercept call setup signalling

11. Ring/vibrate Screening setup Call related services on the endpoint • Open up the terminal • (or even create a ’virtual terminal’ in many pieces): • Run (Java-) application capable of automated personal screening on the endpoint • (Cannot be done today on most GSM-phones)

12. Run application locally Phone need not support GPRS and voice simultanously Menu is rather static, hence suitable for a local ’cache’ Voicemail with screen menu

13. Start the application first Application will initiate the outgoing call to voicemail Ex.1:Push ’save’ Generates a ’push 2’ Which generates a DTMF for 2 Same screenshot, next message Ex.2: Push ’pause’ Generates a ’push 5’ And changes screenshot And changes button from ’pause’ to ’play’ A screenshot of the Nokia implementation

14. Some findings • We implemented in Personal Java on Nokia Communicator • WAP-cache could have been an other option • Several code examples for the Symbian book did not work • Changing look and/or function on buttons depending on state was not predefined • Our application involved call setup • Makes the emulator less usefull • Need to test on the real endpoint

15. More on the voicemail helper • Offers enhanced functionality for the enduser • multimodal interface (eye+ear) • While keeping the network unchanged • Voicemail server is as before • GSM and GPRS need not run at same time • Runs on existing phones • (Not intended as a replacement for ’unified messaging’)

16. New combinations • Use address book on the endpoint (phone) • Group your friends, collegues, family • Upload this to the network and to the voicemail server • Update the voicemail server • Enable personalised greetings based on who-is-calling, e.g. groupwise • Use the same grouping: • for IM, addresses and voice mail greetings

17. Requirements, non-technical • Telcos must not believe they shall make everything themselves • Telcos must allow balanced combinations • Telco can enable new things, but only at the right cost • Telco cannot have full control of everything • (Applications using the network as a pure bearer will always exist)

18. Requirements, technical • Open interfaces in the network • E.g. OSA is underway in 3GPP • Open interfaces in the endpoints • E.g. intercept calls, get caller-id from call set-up • Allow applications access to addressbook (also for games etc.) • Gives: • New business cases! • New applications!

19. Traditional computer science view: UML ODP remote procedure calls little focus on realtime Traditional telecom view: SDL state and message based signalling tiny /dumb endpoints Distributed system modelling

20. Computer science: RPC between objects on some machines In OMG/CORBA: Traditional telecom: Clear separation between: endpoints Servers (switches) Visualising the differences Middleware