Transcript TD27 STF228 presentation Oct03 - Docbox

STF228 :
User interoperability criteria
P-Y Hébert
Afutt-STF228 leader
Paris Workshop - October 2003
22/10/2003
1
Report framework



Summary of interoperability user
requirements
Generic recommendations
Specific recommendations for
interoperability improvement
22/10/2003
2
Survey of the user requirements
on interoperability



Users from Belgium, France, Italy, India, UK,
19 face to face interviews and 3 email inquiries
Market area









Administration
Bank
Insurance
University
Utility (Railways, Power)
Service provider
Consumer organisation
Telecomm Business User organisation
Telecomm User organisation
22/10/2003
2
2
1
2
5
3
1
2
2
3
User Requirements



Interoperability is a major issue in the ICT
world and should be provided as widely as
possible.
Rules are needed to ensure standards are
providing interoperability
Users need a clear indication on how far
interoperability is provided:
 either via regulation making mandatory
conformance to appropriate standards
 or via a mutual agreement between providers
and customers
22/10/2003
4
Report framework


Summary of interoperability user
requirements
Generic recommendations
 Principles for an interoperable communication
environment
 Principles for service interoperability
 Principles to ensure application interoperability
22/10/2003
5
Principles for an interoperable
communication environment (1)

Addressing the terminal
 G01 - Checking network independent terminal
addressing :
Users expect an appropriate methodology being
identified to check that any address is understood across
every kind of network independently of the operators and
the technologies. Any supplier should refer to such a
checking to self-certify that interoperability is provided in
this area.
22/10/2003
6
Principles for an interoperable
communication environment (2)

Locating the terminal
 G02 - Terminal location :
To ensure the interoperability of new services requiring
an actual location information, the Calling Line
Identification (CLI) should be enhanced to include a
caller terminal location information that should be
provided by every fixed or mobile network.
22/10/2003
7
Principles for an interoperable
communication environment (3)

Addressing the user:
 G03 - Unified Communication Identifier development
Users
expectlogin
a Unified
Communication
Identifier being
 G04
- Unified
procedure
implementation
developed
to identify
user
and the terminal
linked
to him
Users
expect
a unifiedthe
login
procedure
be set up
to access
 G05
Authentication
harmonization:
while moving with as far as possible an automated location


service/application
requiring
low security
level.
Such
aevery
user
configurable
login
and
password
including
user
procedure
toshould
make such
a process
as
efficient
and usera
procedure
be
merged
with
the
simpler
configurable
restrictions for low level authentication
friendly
as possible.
authentication
procedure described in 6.1.3.3.
other more sophisticated means on the user choice
according to his own equipment for high level
authentication.
22/10/2003
8
Principles for an interoperable
communication environment (4)

Directories:
 G06 - Common directory data modelling :
Users expect a common data model being developed
with an appropriate protocol to ease the information
exchanges between directories and correlated
applications and equipment (staff management, PBX,
PC, PDA, etc). Incidentally, an adequate control of
these exchanges has to be implemented to comply with
the user privacy rights.
22/10/2003
9
Principles for an interoperable
communication environment (5)

Management:
 G07 - An effective and unified management of
networks
 heterogeneous
G08 - Users' profile
management interoperability

expect the
current
SNMP
standard
the
 Business
a standard
be
developed
to for
allow
 G09
- Billingusers
management
interoperability
management
of networks
and
network
components
be
them
to
manage
their
users'
profiles
across
multiple
 Business
users QoS
expectdata
that amodelling
standardized format like that
 G10
- Common
improved
to allowrequiring
an effective
and unified
management
of
suppliers
without
separate
proprietary
equipment.
developed by ETIS is implemented in order to enable the
 Users
expect
a common
data
model becomponents
developed with
heterogeneous
networks
and network
without
 G11
Single
QoS
class
definition
consolidation of the bill of ICT services from multiple

an
appropriate
protocol
to ease
the
exchange
of the
requiring
separate
proprietary
equipment.
Users
expect
a
single
QoS
class
definition
be
operators to big companies and their breakdown for
pieces of QoSfor
information
along
the whole
standardized
all
fixed
and
mobile
networks.
internal needs.
communication path and the multiple providers.
22/10/2003
10
Principles for an interoperable
communication environment (5)

Management:
 G11 - Single QoS class definition

Users expect a single QoS class definition be standardized
for all fixed and mobile networks.
22/10/2003
11
Principles for an interoperable
communication environment (6)

Security:
 G12 - Checking security infrastructures
interoperability

A methodology to check the interoperability of the
security infrastructures at the national and international
plane in order to ensure that the security level is kept
across multiple networks and countries. An audit of this
issue over public networks should be carried out
regularly by an independent authority and its results
made public.
22/10/2003
12
Principles for an interoperable
communication environment (7)

Interoperability check:
 G13 - An automated procedure for
Interoperability failures identification

Users expect an automated procedure be defined and
implemented in addition to the QoS tests by the
regulators in order to identify interoperability failures.
22/10/2003
13
Report framework


Summary of interoperability user
requirements
Generic recommendations
 Principles for an interoperable communication
environment
 Principles for service interoperability
 Principles to ensure application interoperability
22/10/2003
14
Principles for service interoperability

G14 - Identification of terminal capabilities
suited to access a service:
 In order to make clear to the users what are the
areas where interoperability is provided, users
expect a table of terminal capabilities be set-up
with a list of services identifying what are the
terminal capabilities appropriate to get each
service. This list of the minimum set of
interoperable services should be used as an
interoperability commitment of the supplier and
should be updated regularly.
22/10/2003
15
Principles for service interoperability (2)

Principles for choosing the terminal suited to
access a particular service
 Table 1: Terminal capabilities
 Table 2: Minimal terminal capabilities suited to
access a particular service

Definition of a list of services candidate to a
committed interoperability
 Table 3: Services candidate to a committed
interoperability
22/10/2003
16
Table 1: Terminal capabilities
Type of communication:
Keyboard:
Sound capabilities:
Display capabilities:
Access Network Data bit-rate:
Storage capabilities:
Terminal identification
capabilities
Location capabilities
Subscriber identification
capabilities:
User Authentication capabilities:
User Interface capabilities:
User Interface data bit-rate:
Computing power:
Firmwares:
Printer
F/M
Y/N/S
N/V/HQ
N/L/T/
SP/AP
A/nn
Y/N
Y/N
Fixed/Mobile
Yes/No/Special
None, /Voice, /High Quality
None/Lamp/Text only/
Still picture/Animated picture
(kb/s)
Yes/No
Yes/No
Y/N
Y/N
Yes/No
Yes/No
N/CR/O
N/W/C
I64../
O64..
N/B/M/H
N/J
Y/N
No specific one/Card reader/Other
None/Wired/Cordless
Input (kb/s)
Output (kb/s)
None/Basic/Medium/High
None/Java
Yes/No
22/10/2003
17
Table 2: Minimal terminal capabilities
suited to access a service (extract)
SERVICE
Supplementary
services
AoC-D (Advice of
Charge - During
the call)
Other services
File transfer
NETWORKS
SUITED TO THE
SERVICE
MINIMAL
TERMINAL
CAPABILITY
SUITED TO THE
SERVICE
ALL
Display/T
ALL
Storage or Output
Interface
capabilities
22/10/2003
RELEVANT
STANDARDS
ETS 300 179
18
Table 3: Services candidate to a
committed interoperability (extract)
Voice call
POTS, PSTN, ISDN, IPcablec,
NGN, PLT, DECT, GSM,
UMTS, VoIP, x DSL,
Bluetooth,
PISN, VPN, TETRA,
TETRAPOL,
Supplementary services
AoC-D (Advice of Charge d. the call)
CCBS (Compl. of Calls to Busy Subs.)
CCNR (Compl. of Calls on No Reply)
Other services
Access authentication
CSTA/CTI
According to
the usr area
NETWORKS
Defined by
regulation
SERVICE
Defined by
agreement
INTEROP.
AREA
ALL
ALL
ALL
ALL
ALL
22/10/2003
19
Report framework


Summary of interoperability user
requirements
Generic recommendations
 Principles for an interoperable communication
environment
 Principles for service interoperability
 Principles to ensure application interoperability
22/10/2003
20
Principles to ensure application
interoperability

Principles for application interoperability:
 G15 - Agreements on common data modelling

settlement of agreements on common data modelling
for application interoperability should be encouraged at
the highest level in any environment where exchanges
are needed. XML-like data modelling could be a path
towards application interoperability.
22/10/2003
21
Report framework



Summary of interoperability user
requirements
Generic recommendations
Specific recommendations for
interoperability improvement
22/10/2003
22
Specific recs: Terminals

T1 - Keyboard layout:

 The
current terminals
have different keyboard
T2
- Backward
interoperability
layout hence hindering easy use and service
 While
developing
new
technologies,
mobile
 T3
- A single
communication
access.
Terminals
should
havehandling
a standardised
handset
backward
interoperability withparticularly
legacy
layout
(same
or
“subset-compatible”),
mobile and
fixed terminal would
 between
T4networks
- Connectivity
interoperability:
is
needed.
for to
“special”
characters, likecommunication
“+, “*”, “#”,.….
help
an
homogeneous
 sockets and connectors used for external power
environment:
supplies, headset, microphone, … and any
 interface
the mobiletoinanother
the office
acts :as
a cordless
of the
system
car,
PC, hearing
or
fixed terminal
which
actsbe
asstandardized
a “base”;
disable
aids, etc
should
and
 interoperable.
outside the office the mobile acts as a mobile.
22/10/2003
23
Specific recs: Access

A1 - VoIP over every network

 Voice
over
IP service
should
be available to the
A2
- LAN,
GPRS,
xDSL
Interoperability
user over any carrier services: GSM, ISDN,
 Interoperability
of all typemobile
of LAN networks
(wired or
 A3PSTN,
- Roaming
between
VPN, 802.11/b.LAN,
GPRS, xDSL of
wireless) with GPRS, xDSL is needed.
Interoperability
different
technologies



A4
- Interoperability
of voice
 Roaming
between such
mobilecommunications
networks
including
over
Wi-Fi TETRA is needed.
A5
- Data transmission
across fixed/mobile
 Interoperability
of voice communications
is needed
between any Wi-Fi area and any kind of wide area
networks
network,across
i.e:data
GSM,
ISDN, UMTS,
PSTN,
A6
- Signalling
fixed/mobile
networks
 public
Interoperability
of
transmission
using
VPN.
acrossoffixed
+ mobile
switched
networks
 modems
Interoperability
signalling
between
TETRA
and
is
needed
even
when several
operators
are
other
mobile
networks
with public
fixed or
mobile
involved.
network is needed.
22/10/2003
24
Specific recs: HumanMachine/Service Interface

HI1 - Key strokes and short numbers to
access usual services
 for example directory consultation, emergency
services, messaging services, etc should be
standardized.
22/10/2003
25
Specific recs: Services




S1 - Interoperability of the supplementary
services
 (CLIP,
CNIP, AOC-D/E/S,
etc.) is needed across
S2
- A SMS/email
acknowledgement
kind of networks.
 every
fully interoperable
mechanism is needed.
S3 - Interoperability of prepay services
 across
heterogeneous
networks
to be
S4
- A standard
video format
forneeds
mobile
ensured to implement a widespread service both
phones
across mobile and fixed networks and using any
 is
needed
to ensure
kind
of prepaid
card.the interoperability of
Internet services with a convenient display
quality.
22/10/2003
26
Specific recs: B2B/B2C



O1 - Interoperability in B2B voice
communications
O2
CTI/CRM
Interoperability
 is- not
fully provided.
Additional standardization of
information of
content
that for
is passed
through
 the
Interoperability
CTI used
example
in CRM
O3
- LAN/WAN/Cellular
Interoperability
the
protocol
(e.g. rank
digits) is needed
in
is needed
between
anyofoutsourced
call centre
(on
Board R-LAN, GPRS and WiFi)
particular:
and
corporate computer/software/PBX.
 Interoperability
is needed
between on Board R In inter-exchange
calls.
LAN, GPRS and WiFi in railway stations in order
 In transnational on-board mobile communications due
to ensure
high
bit-rates
in the stations and
to multiple
standards
(GSM-R).
continuity of the data service outside the
 In transnational private communications as well
stations.
(QSIG).
22/10/2003
27
Specific recs: TELECONFERENCE

O4 - Unique H.323/SIP profile/interpretation:

 Since
many audio/videoconferencing
proprietary
O5
- Minimum
bandwidth availability:
solutions are unable to properly interoperate and
 Additional
standardization/regulation
is alsohave
therefore H.323
videoconference systems
needed
to ensure
a minimum bandwidth
to be tested
for interoperability
between them
availability
and synchronization
account
and with respect
to the gateways(taking
between
of
things like
delay and
characteristics
of channels
Ethernet
networks
public networks,
a unique
with
respect to their physical
routings).
profile/interpretation
for H.323/SIP
is needed to
provide actual interoperability.
22/10/2003
28
Emergency call location

EM - Emergency call location should be
based on terminal location and not on user
address
 to ensure that location is not corrupted by
services like VoIP, re-routing, transfer, etc.
22/10/2003
29
THANKS FOR YOUR ATTENTION
Comments welcomed
The document is available at
http://docbox.etsi.org/usergroup/
open/50-200310-Paris/TD13r1
DTR-User-0001 v124.doc
22/10/2003
30