Download network - Department of Telematics

Services shared between network and
endpoints
Lill Kristiansen
Prof. Dr.Scient, Telematics, NTNU
Norway
1
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
2
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
3
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!
4
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
5
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
6
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
7
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
8
Combinations seems better
 Little need for voice and data at same time
 Need endpoint with:
 large storage (PDA-like)
 network (phone-like)
DB
GUI/browser
DB/
Cache
click-to-call
9
Data
(synchr.
on demand) IP
SMS/IM
call(voice)
setup
GSM/
GPRS
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
10
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)
Ring/vibrate Screening
setup
11
Voicemail with screen menu
OR one piece
12
 Run application
locally
 Phone need not
support GPRS
and voice
simultanously
 Menu is rather
static, hence
suitable for a
local ’cache’
A screenshot of the Nokia
implementation
 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’
13
Call Back
Save
Delete
Timestamp
Main meny
Help
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
14
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’)
15
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
16
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)
17
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!
18
Distributed system modelling
 Traditional computer
science view:
 UML
 ODP
 remote procedure
calls
 little focus on
realtime
19
 Traditional telecom
view:
 SDL
 state and
message based
signalling
 tiny /dumb
endpoints
Visualising the differences
 Computer science:
 RPC between
objects on some
machines
 In OMG/CORBA:
Middleware
20
 Traditional telecom:
 Clear separation
between:
 endpoints
 Servers
(switches)