This is where we started…

1. Telecommunications Service EngineeringLuigi LogrippoUniversity of OttawaSchool of Information Technology and EngineeringInvited talk at SBRC 2002Buzios, Brazil, May 2002www.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 SCP SCP switch switch switch

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 Service plane service 1 service 2 Services and Features SF3 SF1 SF2 Global functional plane (end-to-end) Service Indep. BB SIB1 SIB2 Distributed functional plane (distributed entities) EF4 EF1 EF3 Functional Entities, including Elementary Functions EF2 FE1 FE2 Physical plane PE2 PE1 Physical Entities

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…)