Transcript Strategisk plan

Effective communication in organizations:
Issues regarding choices between
F2F, voice-telephony, IM, email
and real-time video
Lill Kristiansen, Dept. of Telematics, ntnu
Egil Østhus, Tandberg
1
What is Tandberg?
 From Tandberg.com:
 ” TANDBERG is the market share leader and the fastest
growing company in the video conferencing industry. We
hold the highest market share for video infrastructure
products as well as video endpoints, whether measured in
terms of revenue or unit volume”
 From Aftenposten 14th Febr. 2010:
 All new employees:
3 days course in culture
 Picture: From night event in
Vigelandsparken (Monolitten)
 1640 employees in 49 countries,
500 in Oslo (Lysaker)
2
About the presenters
 Lill Kristiansen
 Former employed in Telenor R&D and Ericsson (IPtelephony)
 Now prof. in Telematics
Teaching now:
 ttm4130: Service intelligence and mobility
 ttm7: Convergence
Research:
 Technical research (incl. Techno-Business relations)
 research on coordination and communication from a ’softer’ side
(CSCW:Computer Supported Coop Work)
 Not representing Tandberg, indepent academic person
 Egil Østhus, MSc. In telematics, 2005
 Since then employed in Tandberg with SIP, UC, ..
 See also: http://www.komtek.ntnu.no/komtekerejobb_egil
3
About the presentation
 Background material
 Some existing applications and prototypes
 On ’soft issues’
 Organizational and human issues, some concepts and
theories
 Technology and infrastructure:
 Standardization vs proprietary solutions?
 Showing the film: PDA in Hospital
 Presentation of two solutions ENME and PPCom
 We invite you to work out scenarios / business plan for
Simple-PPCom
4
Acronyms: a few from technology...
5





BT
CMC
F2F
FMC
IETF


IM
IMS

MMoIP

QoS


SD
SIP


VC
VAS

VoIP
Bluetooth (Blåtann in Scandinavian language)
Computer Mediated Communication
Face to Face
Fixed Mobile Convergence
Internet Engineering Task Force (std.body, IP)
(mostly ignoring charging and QoS)
Instant Messaging
Multimedia Subsystem
(based on SIP, but with a business modell more similar to
GSM, defined in 3GPP /ETSI (who also defined GSM)
Multimedia over IP (or VVoIP with video and more,
as we will be using today (hopefully!))
Quality of Service (e.g. Reservation of
bandwidth or radio resources etc. related to charging)
Service Discovery
Session Initiation protocol (’call setup’ within
IP-networks) (an IETF protocol)
Video Conferenceing
Value Added Service (sometimes called supplementary service)
(related to / on top of) a more basic service like basic call or VoIP)
Voice over IP ( ”IP-telephony” )
Acronyms and terms:
a few from health care
 Discharge letter (Norsk: ”epikrise”)
 A written report from hospital til GP
 EPR (Norsk: EPJ)
 Electronic patient record (/journal)
 GP
 General Practitioner (norsk: ”fastlege”)
 Pager (Norsk: ”personsøker”)
 a device still in use in health care
 in Norway this device is one way only
(and not integrated with phone in/out)
6
Terminologies from telco and comp.sci
 Conversational service is used by 3GPP (IMS) to describe nonsame place real time communication where the timing
requirements support fully natural conversation between two
humans.
 Synchronous communication is communication taking place at
the same time (as opposed to traditional mail, voicemail etc).
 Real time communication is by some regarded as synonymous
to synchronous communication Note [1] . However, it may also be
used somewhat differently for communication with strict timing
requirements (such as lip synchronization, detailed jitter
requirements etc.), and this is the way it is used in telecom.
 Note [1] It seems that e.g. Bardram use the term ‘real time’ in this
sense without specifying any strict timing requirements.
7
Some applications for comm.&coord
and a classification system
Time
Diff.
time
snail mail
email
Low
EPR
yellow
notes
Medium
Paper based
patient journal
project room
IM
8
Face to Face
(F2F)
High
(planned or
opportunistic)
Peripheral
Awareness
Same
time
Same place
voice calls
video conf.
Medium
(planned or
non-planned)
Place
Different place
(example: room, corridor, bed ward, same house, ..
Some presence / IM systems with GUI
(1:from Cisco
2:from http://missig.org/julian/projects/jabber/
9
3:MSN: note online (PC) vs Mobile
general: note combined use of fixed icons (red, green) and free text
Presence/awareness in hospital today
(for nurses) Note: anonymous presence
Ceiling in corridor
10
Consoles by the door (old/new)
Lamp outside of room
(some nurse present)
Presence / awareness: ihospital.dk
(research)
11
Location
status of operation
video from op.
plan for new op.
fixed screen chat
++
dedicated for
surgical department
Status+location+ activity
into a phonebook-application on phones
 Status:
Relying on manual input
(ex. Operation)
 Location (ex. OP1)
Relying on a location
tracking infrastructure
 Activity (ex. Oper. (9-12):
Fetched from a calendar
Call
/contact
Send text
message
From AwarePhone www.ihospital.dk
(implemented on Nokia GSM phones with Java)
12
”Business relationship” of AwarePhone
 Endpoint (phone) supports ’click-to-call’ from
addressbook application
 Endpoints like big screens and PC via fixed IP network
IP
(WiFi
/GPRS)
VAS / applications for location and status +
texting (with priority)
on top of a local IP network
Public GSM network
13
No relationship (API) here
no location or call control to/from
GSM (TelenorFusion.no: offering
interfaces for such use (and more)
Compare to VoIP: two business models
 Skype (global, proprietary) and Telio (SIP based)
 Offers VoIP over a best effort IP network,
 Telio for a fixed monthly rate NOT by charging per minute
 Assumes that enduser has a separate relationship with the ISP
(Internet Service Provider)
 NO RELATIONSHIP between application (VoIP) provider and the
ISP (network provider). Two relationships for enduser
 Supports nomadic users (enduser needs to find/establish
relationship with local ISP by himself)
 IMS: IP Multimedia Subsystem (SIP-based mobile system)
 more bundling of network connectivity and the application (VoIP)
into one service to the enduser
 More similar to GSM, supports roaming via one customer
relationship
14
Soft issues (humans and organizations)
 Media Richness Theory
 Social translucence (or selective transparency)
 Affordance (much used for UI/GUI)
 Mobility work / overhead caused by mobility
 or similar overhead to maintain right status
 Workarounds
 Our choice: Humans shall have the final control
 no totally automatic ’smart’ call divert to voicemail or
similar ’smartness’ in the application
 relying instead on good use of social translucence /
utilizing social rules obeyed by persons
15
Media richness theory
 Media richness is defined in terms of how well a
medium can communicate equivocal or ambiguous
information
 (e.g. video of the face of the speaker, body language.
‘grounding’ etc)
 Face-to-face and video telephony is ‘rich’, and then
comes voice telephony, other synchronous media and
then asynchronous text.
 Note: Voice telephony (VoIP) and video telephony
(VVoIP) is differentiated regarding media richness.
16
Oral or written?
 Robert and Dennis (2005) argues that non same time
(asynchronous) communication will allow the receiver
to carefully consider the arguments and that this makes
well suited in many types of arguments and
discussions. (even though not rich according to media
richness theory (the ‘paradox of richness’).
 Inside a hospital doctors use much meetings and oral
communication (in addition to written EPR)
 Note: discharge letter from hospital to GP is always
written text
 which in general is less suited (that oral/ F2F) to
communicate equivocal or ambiguous information
17
Social translucence
 Eriksson and Kellogg:
http://www.research.ibm.com/SocialComputing/Papers/SocialNav.pdf
 ICT-solutions supporting accountability
 ”I know that you know, hence I behave properly”
 Example 1: A door with a small window (orally)
 Example 2: Communication by 30 persons in one room organizing an event
(oral explanation)
 I know (that sound is fading)
 I know that you know (that sound is fading)
 Everyone can be held accountable for what the heard, but not for what was not
able to be hear (due to distance), people place themselves acacordingly
 Our idea: make system that utilize social accountability e.g. in an
awareness system,
 allow persons to mark ’busy’ and utilize social accountability to trust
people to make this decision only when appropriate (others can see/judge,
hence I behave properly )
 I know that you know that I was in busy status, still you called me,
hence I trust that this is important etc.
18
ICT =/= physical world as we know it
 Sitation from Eriksson and Kellogg:
 ”[D]esigners in [architecture and urbanism] can assume the existence of a
consistent and unquestioned physics that underlies social interaction.
There is no such constancy in the digital world”
19

Example from paper: half-duplex telecomunication,

Other examples:
 Access rights/ privacy
 In a house privacy is governed via locks and closed doors + the
physical layout of the house
 Much more complex to understand access rights in Unix, Facebook,
LMS (like It’s Learning etc.)
Affordance
 An affordance is a quality of an object, or an environment,
that allows an individual to perform an action.
 Much used for UI/GUI design
 see e.g. Norman, in book The Design of Everyday Things)
 Norman's affordances "suggest" how an object may be interacted
with.
 Norman's 1988 definition makes the concept of affordance
relational, rather than subjective or intrinsic. This he deemed an
"ecological approach,"
 The focus on perceived affordances is relevant in practical design
problems from a human-factors approach, which may explain its
widespread adoption.
 Example from St.Olav:
 Awareness can be obtained by leaving the doors to patient rooms
semi-open. This system affords a gradual level of
awareness/privacy via both visual sight and audible sounds
 Awareness via pushing of buttons: This affords a binary presence
(less grading)
20
Affordances of fixed display
(as used in hospitals)
 Easy to see (’at a glance’)
 Hands-free operation in most cases
 Offer awareness to many
 (not directed only to one person)
 Allows good shared understanding (redundant knowledge
and redundant information)
 In the corridor ceiling:
 Outside the rooms
21
FMC: Fixed Mobile Convergence
or UC: Unified Communication
 FIXED =/= MOBILE !
 Just study the affordances of fixed and mobile
communication systems (’phones’ / PCs ++). They are are
not the same
 Or study the way people use IM on PC vs IM on Mobile
 Our aim: pick the best from both worlds
 Do not treat all devices as the same, as many consultants
claim is wise in UC
 It might be wise to handle both fixed and mobile
devices in the same system,
 but not as totally ”similar” entities
22
FMC / Unified user experience
 Picture
Telenor,
telektronikk:
 http://www.t
elenor.com/e
n/resources/
images/051062_Conver
gedTelecom
Marketver1_tcm2836179.pdf
 My claim:
Email on PC
=/= email on
mobile etc.
23
Concept: ”Mobility work”
 In GSM we have the formal protocoll of mobility management
 This was designed with the system, (in order to locate all mobile
phones, update location area etc.)
 In real words it is convinient that things and persons are
mobile, but this also give rise to overhead
 Additional (overhead) work to search/find for a thing/person
 Ad hoc procedures like writingyellow notes ++ (as a kind of ”mobility
management”)
 (Mobility work is described e.g. in Bardram and Bossen)
 ”Availability work”
 Additional (overhead) work to keep one’s presence/status up to
date
 E.g. Absentee marking on wireless phones becomes more
important than it was on fixed phones (more interrupts in
inappropriate situations)
 J. Grudin has much relevant discussion on manual updates of
collaborative systems in general:
 Rule: the one with new work must see some benefit for herself
24
Workarounds
 Any unintended way (not designed by the designer) that the
enduser works around a perceived problem (to solve a
problem)
 If a clock is missing in the system, place a clock next to it
 If the wireless phone is too interruptive (have no ’absentee
marking), take out the battery (St.Olav)
 May also be the case that functions exists in the system, but that
this fact is not known by the users
 Silent-button exists on the phone, but many users take out
battery instead (St.Olav)
 Presence buttons at St.Olav (when nurses enter/leaves a
patient room)




25
Buttons and lamps not always used,
often they leave doors semi-open instead,
A simple workaround
(the physical doors has richer/better/easier affordances)
Context matters! BUT....
 Organizational context matters, ref. all litterature in
CSCW (Computer Supported Collaborative Work)
 BUT
 How much of an applications neds to be tailormade to a
particular domain (like health care), or even to each
hospital?
 And how much can we rely on a common solution
which can be domesticated by the users
 How to utelize the “long tail” (very special solutions)
and who should do it? (Big telco operators or smaller
3rd parties alone or together with big telcos?)
26
Technology and infrastructure
 Why (not) standards?
 The role of (common) infrastructure
 The role of legacy
 (The next slides are just a personal perspective)
27
Why not standards?
 Quicker time to market
 Standardization efforts take time...
 Possibility to ”lock in” customers
 Ask Microsoft !
 NOTE: Microsoft html =/= proper html, MSN SIP =/= proper SIP
 Ask Apple, Amazon/Kindle and more
 Ask Skype!
 Note: Skype offer Skype-in and Skype-out to PSTN and GSM (but
not to other VoIP solutions)
 NOTES:
 One may start off proprietary, and later offer the result as an open
specification (not necessarily open source)
 PDF is an open and de facto industry standard
 Skype is not open at all
28
Why standards?
 Interoperability
 All-to-all-telephony is ALWAYS assumed in telco
 Independence of handset vendor, subscription, base station
vendor, etc.
 Competition
 Global market
 Ask GSM community!
 Multiple handset vendors (Nokia, Sony-Ericson, Samsung, LG,
++) each having a global market
 Multiple vendors of infrastructure components (Ericsson, NokiaSiemens, Alcatel-Lucent, Motorola ++)
 Multiple service providers (Telenor, NetCom (/TeliaSonera),
Orange, Vodephone,...
 (Not all telephony standards are easily undestandable to
’average-joe’ (Java-programmer),
 this may constrain service competiotion
29
SIP: Session Initiation Protocol
 A standard from IETF (Internet Engineering Task Force)
 Also used by traditional telecom standardization bodies
 3GPP (with ETSI for UMTS) for use in IMS
IP Multimedia Subsystem in UMTS
 Baseline SIP handles call set up
 SIP Refer handles ’call transfer’ (used by us)
 SIP allows for extensions (used by us)
 SIP for presence
 SIMPLE
not used here, but relevant for UC Ubiquitous Computing
 Relevant for IM/presence systems
30
Infrastructure
 ”Everything that may be used by many applications”
 The network (if properly layered with open interfaces)
 AAA (authentication, authorization, accounting) is generric and
typically used by many applications
 NOTE
 Same location technology may be used by many applications (if
properly layered)
 Same application (like ”Buddy”) may use many types of location
technology (if properly layered)
 Infrastructure may suffer from the chicken and egg problem.




31
”What is the killer app?”
This is not really a proper question for infrastructure
Ex.: smarthouse: Is energy saving the killer app?
Ex.: IMS: Is video (or location or...) the killer app?
The role of legacy
 ”Legacy is everything that works”
 ”Network externalities” has a value
 Owning the first fax machine has little value
 Value of interworking with GSM and PSTN
 Even Skype has found that useful (though otherwise
proprietary)
 Legacy may be a blessing but also a curse
 May limit the way we think
ex: email vs Facebook wall
 Interworking with legacy may also constrain the solutions
 How many of the peculiar solutions in PSTN shall be
carried over to VoIP?
Depends on who you asks and their knowledge and business
interest
32
Film: PDA in hospitals
 A few scenes from the film will be shown
33
ENME (network centric)
 A centralized solution made in cooperation with Telenor
 originally made as the master thesis of Egil Østhus in 2005
 Later published
34
2 Scenarios for ENME
 Business trip
 Health care
 A mobile worker Bob about
to enter the airport express
train
 Use of PDA, pat. terminal,
(IM+loc.) + phones
 A caller Alice phones Bob
with MMoIP
 Bob answer with
PDA/phone
caller
35
callee
 Nurse Ann phones Dr. Bob
with MMoIP
 Dr. Bob. answers on (IP)phone
caller + patient
callee
2 Scenarios for ENME (continued)
 Business trip
 Health care
 Later in the call
 Later in the call
 Traveller moves to booth
with bigger screen,
multimedia is added by the
ENME service after a
proposal towards Bob on
his PDA/phone
 Dr. Bob moves to booth
with bigger screen,
multimedia is added by the
ENME service after a
proposal towards Dr. Bob
on his PDA/phone
same callee
36
same callee
(different picture!)
Requirements of ENME (high level)
1. The ENME service shall be a value added service on top of an
all-to-all telephony service. It shall work with a major standard
MMoIP protocol.
2. ENME shall detect when a more suitable context occurs (i.e.,
fitting the proposed media types better). ENME shall then
suggest an upgrade of the media types by moving the
session to the new terminal(s).
3. The ENME service shall support mobility.
4. ENME shall work in a business case, i.e. it shall be possible
to make a sensible charging of the value added service, as
well as of the network resources used to transport the media
types.
5. Substantial parts of ENME shall be demonstrated in June
2005 after 5 mo. work.
37
SIP network (e.g.
IMS operated by
Telenor)
API IMS to VASprovider (3rd party or
Telenor) is needed
Architecture overview
SIP entity
Context/ENME
38
Design /animation
!
Voice
Voice
Video
39
PPCom: endpoint centric
 Network centric or?
 ENME handled context on central server(s) and via central SIP
servers for signaling
 This time we use a fully distributed service discovery.
 In PPCom we are putting the endpoint center stage
40
Network centric vs endpoint centric
 SIPcenter.com [14]:
 “The traditional network model gives service providers
ultimate control, “
 “IMS is clearly rooted in this approach”
 “[IMS] defines only the network core and has little to say
about edge devices”
 Our approach is different:
 We are using B2BUA on the endpoint itself
 In this way the endpoint itself becomes a kind of FMC
intagrator
41
Incoming vs outgoing calls
 Note that several previous papers has described
outgoing calls combining several devices
 Research shows that it is more important to cover the
case of an (unplanned) incoming call (see e.g. Belotti and
Bly [2])
 For outgoing call the user (callee) is most often able to
find a proper terminal up front
 Different for incoming calls (when not planned)
 The added value will probably lie in good handling of the
incoming case
42
Incoming scenarios
 Incoming call from customer with PPCom:
 A customer calls Tom from outside the company's domain.
 The customer Allan calls Tom on Tom's single URI
[email protected] from his video-equipped computer.
 Tom receives the call on his handheld, and chooses to answer the
call with a nearby video-phone.
 Incoming call from boss with PPCom:
 Tom is in a meeting room with some other employees. His boss
Jane is placing a call to [email protected]. Since all calls appears
on his handheld terminal before possibly transferred, he is in
control of all calls wherever he is.
 Depending on the social situation and the caller ID the human
(Tom) choose either not to accept the call, or to accept the call
and to use the wall mounted VC equipment in the room, or his
personal lap top or just use his handheld phone.
43
Scenario: Leaving the room suddenly
 Enhancement; leaving the room
 Tom might also choose to start by using the VC
equipment, but decide to leave the room at some stage.
 He will then bring his handheld with him in order to have a
confidential talk.
 He might then replace the streams on the VC equipment
with voice on the handheld.
 This shows that handling mobility / social rules may
also be important for the value of the service
44
Mobility and terminals in pervasive
environments
 We do not cover full
personal mobility
Personal device
(C)
 We also assume that the
callee is inside the (possibly
distributed) enterprise
1-1
(D4)
 using other devices (D) also
within the same enterprise
domain (near by)
 When outside of office
environment plain SIP
(MMoIP) is used as a basic
multimedia call.
(D1).
45
(D2)
Multi: C+D
Several possible Di’s
One used at a time with C
(or C used alone)
(D3)
C (B2BUA) on the endpoint (handheld)
 Note: In the
corresponding RFC from
IETF the entity C is shown
as a network server
2I
(S NVIT
DP E
1)
1I
(S NVI
DP TE
1)
 However, C may as well
the the endpoint
(PDA/phone) as shown
here
C
Alice’s
phone
Bob’s
device
RTP
User domain
User domain
Corresponding
entity
46
Di
Multi:C+D
Requirements (1/2)
 Req.H Human shall be in control of the decisions
 Req. 1.1 The value added service PPCom shall work
with SIP as the underlying signalling protocol.
 Req. 1.2 Only one of the parties (caller or callee) need
to be aware of the existence of PPCom. The nonPPCom subscriber shall not need any special software
or device to participate beyond standard based MMoIP
equipment.
47
Requirements (2/2)
 Req. 2 PPCom shall detect suitable contexts (e.g.,
terminals fitting the proposed media types better that
the current terminal at hand).
 This knowledge shall be used in a way allowing human
decisions.
 Req. 3 The PPCom shall support mobility:
 Multi:C+D-paradigm is used
 User is inside the (virtual / distributed) enterprise
 I.e.: No need to support personal mobility in general
 Note: No support of business traveller staying at a
foreign hotel etc. in first phase (may be added later)
48
Illustration (incoming call):
Req.1.2: Basic SIP
Local Domain (enterprise)
SD (BT)
SD (
BT)
SIP
signaling
SIP
Media streams
Foreign domain
 Much related work ignores req. 1.2 and add their own
SIP extensions on the external interface (even non-SIP
extensions)
 Req. 1.2 enables a stepwise introduction of the smart
environment
49
Incoming call flow
Handheld
(PDA)
C
Caller
(Alice)
Sip servers
1.INVITE
Local
device
D1(VC)
Local
device
D2 (PC)
BT SD
DEVICE INFO
BT SD
DEVICE INFO
4. OK
User
action
2.INVITE
3. OK
5. ACK
6. ACK
Auto
answer
media
50
Note: user action (”human in the loop”)
(The GUI on handheld is not shown (no real design made yet)
Architecture: separtion of SIP and
SD (service discovery)
 Note:
 BT was used
in the
prototype
Cntrl
 Evaluation of
SD is for
further work
 Issues:
 Battery
 Scalability
JAIN
SIP
Inquiry
BT Response BT
client
server
Event
Bluecove
Bluecove
BT
stack
SD-C
BT
stack
SD-S
 Alternatives
Session
to BT/SD
Module
including use
of manual
Handheld
routines?
controller (C)
51
SIP
UA
Local
Device (D)
Simple-PPCom
 Can we build a sensible version of PPCom without
using Bluetooth and service discovery? Issues:
 User interaction when receiving the call must offer a
sensible set of terminals
May be based on pre-configured user choices?
How to avoid too much manual overhead ”availability work”
Autoanswer may raise some privacy issues (and not only in
health care)
 For which domains?
 General office environments?
 Dedicated solutions for XXX domain?
 Note: The last scenario in the film offer a special value in
this particular setting because dressing up in sterile is a
cumbersome procedure
 Not all use of MMoIP offer the same added value
52