FORCES Project Workshop Report
February 1999

Note that some presentations were intentionally provocative and should not be taken as representative of the speaker's true views. Equally, the discussions reflected some `brain-storming' and should not be read as the considered views of the consortium or its members.

Migration of Functionality to the Network Edge

Speaker: Dave Marples, CITEL

Secretary: John Bates, University of Cambridge

The speaker introduced the topic as follows:

• customers require more functionality, including:
  • IP telephony
  • number portability
  • conditional routing, e.g. automatic call distribution amongst sales agents
  • unified messaging (fax, voicemail, email) all arrive to same mailbox
• intelligent routing based on caller ID: search database using caller ID as a key, returning details of caller
• applications:
  • always route the same customer to the same customer service representative
  • look up credit status; if account overdue, route to accounts department
  • if it is the Managing Director calling, route to my mobile; if it is a customer, take a message
• this customisation would be implemented by personal scripting rules defined by individuals
• however, recall the feature interaction problem:
  • independent services with their own world view will start re-routing calls in ways unknown to other services
  • how to determine which service is responsible for doing something to a call?
• a - world example:
  • suppose that calls are routed through Message Pad: if the call rings for 20 seconds without an answer it is routed to a designated number
  • the call might then be routed to the company switch, which goes to primary ringing
  • then after a delay the calls goes to tertiary ringing: all the phones in the building ring in the hope of getting an answer
  • because Message Pad re-routes after 20 seconds, the company's tertiary routing never happens
  • the systems thus do not know how to interoperate
• solution options:
  • create a new system with all the required features
  • what happens when this needs upgrading?
  • revolution rather than evolution is undesirable
  • put up with the problems, but these are difficult to explain to customers
  • develop open and enforceable interworking standards; this may be difficult to implement between organisations

Points raised during the discussion included the following:

• ideally use formal methods to prove there are no undesirable interactions within the rule base
• but what about interaction among rule bases?
• interconnect agreements can take a long time, which is something that OFTEL might investigate
• companies such as BT are working to open up the interfaces
• such comapnies have a lot of correspondent agreements that rely on interfaces between organisations
• market role may be more important than technical issues
• facilities management companies may not yet have the competence to do feature modelling
• the main effort is on creating new features rather than making features work together
• however it is not possible to predict the nature of new features

Billing

Speaker: Rob Booth, BT

Secretary: Muffy Calder, Glasgow

The speaker introduced the topic as follows:

• the motivation is to maximise network usage so as to maximise revenues
• marketing aspects:
  • billing is very expensive
  • new business models affect marketing issues (e.g. 10%-30% of services from other parties)
  • `electronic bonding' of operators is occurring, leading to huge volumes of chargeable traffic
  • `community of interest' systems are becoming common
• service creation tools have speeded up only core service provision, neglecting service management issues like billing:
  • the focus of innovation is shifting to `service surround'
  • there is a shift in approach from the `Wurlitzer' (multi-component service) approach to well-defined interfaces
• billing vs. recording:
  • billing cannot always be done in real time
  • billing cannot always be done separately either since there may be relationships between service functionality, cost, and quality of service
  • for example consider video conferencing: one bill for all vs. shared billing according to role
  • Internet billing is not connected to main billing (OFTEL forbids cross-selling of services)

Points raised during the discussion included the following research issues:

• policies regarding trust (e.g. assume payment, then check)
• macro/micro charging structures: is it worth collecting small sums?
• placing functionality at the edge of network, e.g. billing on a customer's PC with consequent implications for trust
• warehousing data
• `electronic bonding' to include electronic funds transfer
• what are the implications for real-time exchanges of data and synchronisation of clocks?

Middleware and CORBA

Speakers: Gordon Blair and Geoff Coulson, Lancaster

Secretary: Ken Turner, Stirling

The speakers took artificially opposed views on a `motion' that middleware was appropriate for telecomms systems. (They nonetheless admitted that their true views coincided!)

In brief, the arguments for the motion were:

• middleware has substantial industrial support
• there are a number of standards to choose from
• middleware builds on well-established ideas
• middleware makes use of a small number of concepts, integrates systems seamlessly, and compares favourably in case studies
• CORBA offers many add-ons and a sophisticated engineering approach
• new developments include a greater variety of ORBs and services

In brief, the arguments against the motion were:

• there is too much hype and too little substance
• key non-functional properties are missing
• the telecomms environment is hostile, large-scale and real-time: all challenges for middleware
• current middleware approaches lack the right `-ilities'
• current commercial ORBs are heavyweight

Points raised during the discussion included the following:

• For a fairer performance comparison, ORBs such as OmniOrb should be considered. It was reported that experiments on a variety of current ORBs showed that none of them could successfully complete a soak test.
• Telecomms engineers may be reluctant to move from lower-level, design issues to higher-level, architectural matters. In Middleware 98 there was exactly one paper on telecomms, so perhaps the applicability of middleware to telecomms is yet to be exploited.
• DCE is still alive, and is being used by (for example) BT. Nonetheless DCE is perhaps showing its age, and TINA may not be sufficiently new either. It was noted that RM-ODP was developed both as theory and as practice concurrently. The real issue is perhaps DCOM vs. CORBA. The ANSA project is now winding down, but has left its mark. It was reported that Citrix has bought over APM.
• `Switched' traffic will in future become increasingly `packetised' (e.g. via IP). Because of rapid technological developments, IP equipment is planned for relatively short life-times (e.g. 3 years, although routers may be obsolescent in 18 months).
• Software and services are becoming increasingly more important in telecomms than the underlying hardware. Traditional design approaches (such as those using Finite State Automata) are no longer so relevant. A modern view takes objects as fundamental, so services for example should be viewed as objects. OMG does not appear to be promoting formal object-oriented approaches (CDL) as heavily as before.
• Since the presentations were offered in the spirit of a debate, an informal vote was taken at the end. For the motion that existing middleware is suitable for telecomms systems, the voting was 3 for and 11 against. For an amended motion that future middleware would be suitable for telecomms systems, the voting was 11 for and 1 against.

TINA

Speakers: John Evans, Marconi Communications

Secretary: Evan Magill, Strathclyde

The speaker introduced the topic in a non-technical manner, focussing on the history of the TINA Consortium and the opportunities for academics within the restructured consortium. In brief the following observations were made:

• TINA is a large consortium of companies from around the world working to establish software architectures that will support the creation and deployment of future communications services
• the first phase of TINA finished at the end of 1997, with work expected to stop at that point
• the work up to this point was concentrated at one site (Bellcore, United States)
• however a second phase began at the start of 1998 and is expected to run until the end of 2000
• the second phase has a distinctly different way of working: work is spread across the globe located at sites provided by the consortium members
• in the new structure, three classes of membership exist in the consortium:
  • full members with voting rights
  • associate members without voting rights
  • academic members
• to be a full member is extremely expensive and is thus unlikely to be feasible for the academic community
• although academic membership offers an alternative route, to date only three Universities have joined the TINA consortium
• under the new structure, the work is directed through active working groups including:
  • Applications of TINA
  • Service Management
  • TINA-IN
  • Next Generation Mobility
  • Service Architecture Reference Points
  • Naming and Addressing Framework
  • Compliance Framework
  • DPE Architecture
  • Security
• in essence, `market forces' drive the groups and their activities
• each activity is of particular interest to part of the TINA consortium
• those exploiting TINA tend to be newer and smaller companies, rather than the large established companies that founded TINA-C
• the degree of commercial exploitation of TINA is currently small, although this may grow

Points raised during the discussion included the following:

• as to whether any of the active groups are considering interworking between services, it would appear that at present the work focuses on creating single services
• it was noted that one of the working groups is entitled Compliance Framework:
  • as the TINA consortium is presumably developing standards (rather than specific product designs), it would be desirable to have compliance-checking procedures to ensure that products meet TINA standards and achieve interoperability
  • TINA consortium partners would thus have to submit their products for compliance checking, and thus accept the ruling of those who administer them
  • in order to generate such a politically and economically important consensus, compliance checking and its effectiveness would have to be objectively validated
  • the only possible medium for such an objective validation would be a formal model of TINA
  • a convincing demonstration would be that compliant products could be guaranteed to interoperate
  • a compliance checking procedure would require suppliers to present valid proofs that their products complied
• the working group structure perhaps reflects `point solutions' driven by interested companies
• for information, it was mentioned that the next TINA conference would be in Hawaii during Spring 1999.

Secretary's Afternote: The speaker has subsequently received information suggesting that a TINA-C Academic Forum may be formed. Further details may be available at a later date.

Up one level to FORCES February 1999 Workshop