1

Telecommunications Service Engineering Luigi Logrippo

University of OttawaSchool of Information Technology and Engineering

Invited talk at SBRC 2002Buzios, Brazil, May 2002

www.site.uottawa.ca/~luigi

2

This is where we started…

• These gentle ladies knew a lot about services, unfortunately they were automated…

3

Automating services in the very old world

• The first automated services had to be implemented in every switch:– Call transfer, three-way call

• When we got into 800 services, industries started to talk about value-added services and they realized that there was money to be made in the area of services

4

De-regulation

• De-regulation is trying to separate as many pieces as possible from old monopolies, and thus would like to enable service providers to operate independently from those responsible of basic connectivity

5

The Internet world

• Integration of voice and data in the Internet opens many new possibilities for enhanced services– As you read an ad in the Web, click on the

link and that will generate a call to the company

– Company may retrieve your user profile from a database…

6

The rush towards feature creation

• Basic connectivity at a low price is now a given fact

• Just as it is a given fact that any car will take you from here to there– Cars are being sold more for added features, color,

shape, CD driver, etc. than for their ability to move you cheaply

• Great pressure for operators to put on the market more features quickly– Contrast with pace of feature creation in the old world,

where it took many months to introduce a new feature

7

Parallel technical developments

• Separation of voice and signaling made it possible for signaling to follow a different routing than voice

computers

Voice connection

8

Identification of separate functional entities for services

• Service Control Point• Switch asks it instructions on how to execute

services• Revenue for service invocation goes to SCP

operator

switch switch

switch

SCPSCP

9

The (not-so) Intelligent Network

• IN intended to create a framework in which service creation would be easy

• Service Creation Environments

• Compilation of services from high-level functional descriptions, by using Service Independent Building Blocks (SIBs)

10

Elaborate Conceptual model for IN

SF1

SIB1SIB2

PE1PE2

FE1 FE2EF1

Service plane

Global functional plane(end-to-end)

Distributed functional plane(distributed entities)

Physical plane

service 1 service 2

Services and Features

Service Indep. BB

Functional Entities,including Elementary Functions

Physical Entities

SF2 SF3

EF2 EF3 EF4

11

Why the IN did not quite succeed…

• Allowing vendors and users to define own features remains difficult

• It does not consider the creation of user-defined features at the customer side

• SIBs remain vaguely defined and it is not clear how to transform a GFP view into a DFP view

• Some features are difficult to define in the IN model (features that do not have a specific PIC where to start or where to end)

• IN-related efforts are being cut short by the advent of internet telephony

12

Technical issues in the Internet world

• In the Internet, every node is independently programmable, thus the range and type of features that could be introduced is limited by imagination only…

• However uncontrolled introduction of features presents the risk of uncontrolled feature interactions– Features that defeat each others (intentionally or not)

• Note that even in the pre-IP world telephony systems designers had general-purpose computers at their disposal– They chose to limit their power, by following specific architectural

models

• Internet telecom gurus want to restart telecoms from scratch, they may be getting into some problems…

13

Some problems…

• A doctor wants her calls to be sent to her office at the hospital every second morning of the week, but at the same time wants all calls from Mr. Jones to be sent to voice mail (conflicting policies!)

• I want – all the .gif files I get to be transformed into .jpg, and – all the colored .gif files I get to be transformed to black and

white (also conflicting policies…)

• Many problems can be fixed by establishing priorities, however must first be detected!

14

More problems…

• User subscribes to certain services in Ottawa, wants same services when traveling to Melbourne, and regardless of whether she is on fixed or mobile phone (service portability!)

• User subscribing to carrier A wants to call user subscribing to carrier B and charge call to user on carrier C. While she calls, she travels through areas served by carriers D and F (interworking!)

15

The basic ideas already exist

• In the past 20 years, many concepts have been developed that can be recycled to find solutions in these areas

• Much of it was done with relation to OSI and IN.– These architectures may be dead, but

much of the related research is still quite usable…

16

Some reusable technologies:1 – Formal Techniques

• Formal techniques can be used to specify services in languages having precise mathematical semantics

• Implementation-independent• Useful for independent programming of several

interconnected features, or parts of features• In order for parts to interconnected well, each

part must be specified unambiguously and precisely, so the others will know what behavior to expect exactly

17

Some reusable technologies:2 - Verification and

Validation

• Once a system has been specified formally, then it is possible to do V&V on the spec, to see if it satisfies its intended properties:– Liveness, safety:

• behavioral properties, • Invariants• I/O relationships

– Compatibility of different implementations

18

Some reusable technologies:3 – Theorem Proving

• Sophisticated V&V may involve theorem-proving• E.g. I have specified the following policies for my

telephone (note example of location-based services)– When I am in Toronto, it should forward all my messages to

my Toronto office– When I am in the company president´s office, all my call

should go to voice mail

• Then a theorem prover, provided with an appropriate data base of facts, may be able to note that, since the president´s office is in Toronto, there is an inconsistency between these two policies

19

Some reusable technologies:4 – Testing: Conformance and

Interoperation

• A company has implemented a service that must interoperate with other implementations of the same or other services

• Testing can help finding if this is the case• Conformance testing centers

– Test the service remotely, issue a certificate of conformance

20

Some newer technologies5 – Automatic Generation of Implementations

• If a formal spec is proven consistent and complete

• Then implementations automatically derived from them will also be so, will interwork with others, etc. (do you believe this?)

• An elusive goal, because formal specs can be given – at many different levels of abstraction, – and for may different viewpoints

21

And yet newer tech...6 - Policies, Contracts, Negotiations

• Agents are programmed to follow policies• Contracts are policies agreed among agents• Negotiations may be necessary to establish

contracts as compromise between policies

22

And yet newer tech...7 – New Types of Logic, e.g. deontic logic

• Call number display (on callee end) permits the display of the caller’s number (policy)

• Caller may have display blocking, forbidding the display of its number (policy)

• Negotiation matches the two policies, concluding on a contract that the number is not displayed

• Sophisticated deontic logic may include weights and costs (penalties)– Negotiation concludes in a way as to minimize cost– But : negotiations must conclude quickly

23

And yet newer tech... 8 – High-level Design Techniques

• UML and related techniques are useful but seem to be awkward for the specification of complex distributed systems

• Use Case Maps (ITU standard under development, see paper by

Andrade in this conference) provide a more useful view, but they have not yet been widely tested

• No technique seems to adequately address the information viewpoint, to describe systems that will be heavily information-driven

• The need for several different views is one of the most challenging aspects – These views must be mutually consistent!

24

The view beyond

• Future systems will be directed by agents, acting according to policies, and using flows of information acquired in many different ways– Individual policies, organizational policies at

different levels– Presence, availability, role information– Generalizing what we have now, features will be

triggered by conditions on the available information at certain points

25

The need for uniform call models

• Many ideas on how this could work are being developed

• But each is a world on its own! – Telephone systems must interoperate

• The need to develop uniform call models and signaling accepted by all stakeholders will slow down the inclusion of these ideas in public networks

• Development can be faster in private networks

26

Conclusions• Research done in the past is still quite relevant• It will have to be rediscovered and adapted• New technologies loom• But there are still major open challenges• We are looking at revolutionary changes, will

they bring chaos?• After every revolution, there is a restoration

– leading to more order, – closing some of the possibilities

27

Or maybe…

NONE OF THE ABOVE

The one-company solution: everyone uses the same code worldwide and it will all work together…

(note that monopoly is what we wanted to avoid when we started…)