Mitel Agent Framework: Architecture and Applications

1. Mitel Agent Framework: Architecture and Applications • Michael Weiss • Nov 16, 1999

2. Contents • Motivation • Objectives and issues • Architecture • Enabling technologies • Agent architecture and support environment • Case Studies • Feature interaction • Automatic route selection • Big Picture • Agent-based design • Call Processing Language

3. Motivation

4. Convergent Paradigm Broadband Backbone

5. Objectives • Main objective • Rapid creation and customization of services • Support transparency • Service (who) • Technology (what) • Location (where) • Meet reliability and real-time constraints • Unexpected contingencies • Quality of service guarantees for services

6. Issues • Service and resource discovery • Communication • Ontology • Coordination • Integration with legacy systems • Configuration • Visualization and monitoring

7. Architecture

8. Agents - Our Definition • A reusable software component that provides controlled access to services. • A printer agent provides printing services schedules requests to a shared printer. • Basic building blocks for applications organized as networks of collaborating agents. • A desktop agent "recruits" the services of a trunk and a set resource agent. • Behavior constrained by policies set by higher-level agents (security, user prefs etc). • 60% of the calls routed over one trunk agent are reserved for a specific user agent.

9. Integration • XML KQML/ACL Communication Distribution • CORBA Objects • Java • Operating System Platform Enabling Technologies

10. Mobility Network Translation Collaboration Service Actions Reasoning Beliefs Resource Sensory Layered Agent

11. Yellow-page directory of agent capabilities. For scalability, facilitators are arranged in hierarchies. White page directory of agent names. A pool of reusable agents and agent components (features and resource adapters) that can be added to an application without recompiling or even stopping the application. Network Layer

12. Service Layer

13. Resource Layer

14. Agent Application Super- visor Agent Service Feature Feature Sub- ordinate Feature Feature owns owns owns owns uses uses uses uses Resource adapters Resource Features (device independent) Contracts uses/owns

15. Factory ANS Factory Factory Support Environment deployment and configuration ADE AEE notifications

16. Case Studies

17. Resources Application Features Services Feature Interaction • System = { Applications } + { Resources } • Application = { Services } • Service = { Basic service } + { Features }

18. Causes of Feature Interaction • Conflicts • Indeterminacy • Assumption violation • Resource contention • Design by others (integration) • Design evolution (impact of changes) • Fault management

19. Example • MCA = { BasicCallApp } + { Phone, CallDB } • BasicCallApp = { BasicCallSvc, BillingSvc } • BasicCallSvc = { TermCall (TC), OrigCall (OC) } + { CallForwardBusy (CFB), CallWaiting (CW) } • BillingSvc = { CallLogging (CL) } BillingSvc BasicCallSvc TC CL OC CFB CallDB CW BasicCallApp Phone

20. Hypothetical Call Center CallCenter Desktop Group Set Group Trunk Group TC OC Desktop Desktop Trunk Trunk Set Set CFB CW uses uses uses uses Resource adapters Features (device independent)

21. State Machines for Features

22. Conflict Resolution Conflict set {TC, CFB, CW} Precedence rules CFB > CW CFB > TC CW > TC Result set {CFB}

23. Multi-Party Interaction • Consider the example of the interaction of CFB and OCS. The problem is typically stated as: If a caller X who subscribes to feature Originating Call Screening calls person Y, and if Y forwards all of their calls to a number Z on X’s list of forbidden numbers, then X can reach a forbidden number by calling Y. call(Y) forward(Z) X isCallerScreened(Z) Y forwardTo(Z) Z

24. Negotiation

25. Automatic Route Selection • Equal access allows a company to route their calls through multiple carriers. • Conventional LCR selects route only on time of day and requires route tables to be precoded. • Our approach uses intelligent bidding between agents representing the carriers. • In this approach the agents interpret the service plans directly (no precoding of route tables).

26. User/Task/Mediator Pattern • Context • You want to use agents to facilitate between people and information sources, and people to people. • Problem • To encapsulate information about people, queries, and information sources. • Forces • Agents don't have extensive domain knowledge. • Since users may play multiple roles at the same time you must keep role-specific information separate. • Queries may be long-lived (e.g. days or weeks). • User feedback should be used to make recommendations to other users in the community.

27. User/Task/Mediator Pattern • Solution • User agents form the interface between the user and the other agents. They receive the user's queries and feedback, and present information tailored to the user. • Task agents are created for each user query. They propagate the query to all available sources. The task agents collect the results returned and sort them. • Task agents may be long-lived (e.g. days or weeks) and permanently represent a user in a given role. • Mediator agents mediate between task agents: • Recommender agents store the users’ evaluations of recommendations. They apply both content-based and collaborative filtering before recommending items. • Search agents forward a user query to a user-specified search engine. The search agent extracts the search results from the pages provided by the search engine.

28. User Agent Task Agent Mediator Agent Task Agent Mediator Agent Task Agent User Agent Task Agent User Agent Mediator Agent Task Agent User/Task/Mediator Pattern

29. 1-* 0-100 10¢ 100-1000 8¢ 1000- 5¢ Call 1-416-234-5678 Volume 400 Carrier Agent Trunk Agent Customer Agent Task Agent Carrier Agent Task Agent Router Agent Carrier Agent Trunk Agent Customer Agent Task Agent 8-* 0- 35¢ 1-* 0-500 20¢ 500- 3¢ Application to ARS

30. Message Flow Customer Agent Task Agent Router Agent Carrier Agent Trunk Agent Carrier Agent Trunk Agent ask-route ask-route ask-bid propose-bid ask-bid propose-bid accept-bid reject-bid tell-route tell-route ask-trunk tell-trunk

31. Visualization

32. Big Picture

33. Agent-Based Design Non-functional requirements Performance Use case maps Agents Test cases

34. Call Processing Language

35. End

36. OPI • Deontic logic model • Obligation O(P) • Interdiction O(~P) • Waiver ~O(P) • Permission ~O(~P) • Examples • O(Originate) • O(Terminate) & I(Forward) • O(Redirect) & dn=4578 • O(Terminate) & P(Display)

37. Apply Reorder No Answer Available (Perform (O Terminate) (I Redirect)) Originate (Perform (O Originate) (I Redirect)) Redirect Process Call Acquire Destination ID Connect Voice Path Offer Call to Destination Connect Collect ID Verify Destination Availability Verify Destination ID Wait Originator On Hook Wait Destination On Hook Wait Answer Call Forward Terminate Identify Redirection ID Redirect Establish Connection Verify User Availability Indicate Call Wait Originator On Hook Wait Own On Hook Connect Voice Path

38. OPI-XML • <sequence name="processCallOrigination"> • <sequence name="acquireDestinationId"> • <command name="collectDestinationId" timeout="5s"> • <timeout> • <fail action="applyReorder"/> • </timeout> • </command> • <command name="verifyDestinationId"> • <invalid> • <fail action="applyReorder"/> • </invalid> • </command> • </sequence> • <sequence name="offerCallToDestination"> • <propose> • <assertion aspect="oblige" value="terminate"/> • </propose> • <command name="verifyDestinationAvailability" timeout="10s"> ... • <command name="waitForAnswer"> ... • </sequence> • </sequence>