Proposal for FIPA's First Call for Proposals

Attachment to external software, applications and services



Business trip Information Filtering Agent (BIFA)

Ari Widodo

Takaaki Hasegawa

Saitama Univ. Dept. Electrical and Electronic System Eng.

255, Shimookubo, Urawa-Shi, Saitama 338, JAPAN


Abstract:

In multimedia communication services like Internet or Intranet, the network traffic's load becomes huge because of transferring multimedia data, such as movie and sound data. Such conditions, require a large capacity of line. To improve the efficiency of using line and the quality of communication, we propose business trip information filtering (BIFA). BIFA is an agent which performs information filtering at a server that as network load is reduced. In addition in this proposal we propose some interfaces which are used in BIFA to communicate with external software, applications and services.


1. Introduction

In multimedia communication services like Internet, the transfers of multimedia data like movie, pictures and sound data frequently occur. In these communication services, transferred data often exceed the maximum requirement. Therefore the network traffic's load becomes bigger and the quality of communication becomes worst. These two things have been a serious problem to be solved.

Recently, there are two methods of information filtering on the network. First, in receiver people or software will do these jobs. Second, by using a proxy server located between transmitter and receiver. A weakness of this method is heavy loading of the proxy server which causes delay for receivers and reliability of the proxy server. In addition, all of the uses cannot always use proxy servers; this situation makes the network's load high.

To solve these problems we propose the business trip information filtering agent (BIFA). In this system, the receiver (henceforth called "user") send an agent having a list of needed information with its version to the transmitter (henceforth called "server"). When the server has requested information whose version is newer that the agent (the user) has, the request is accepted and then transferred automatically to the user. It means the information transfer has been filtered. Therefore, the network traffic's load can be reduced. Also, the proxy server's problem does not occur.

BIFA consists of two different agents. The main agent is called "BIFA" and the sub agent is called "SUB BIFA." BIFA always exists but SUB BIFA is created when the communication is needed and is deleted if its mission is completed.

In this proposal we propose the BIFA's interface needed to communicate with other agents, external software, applications and services. First we will describe the function of BIFA. Next, we will also describe the structure of BIFA in network communication. By understanding these matters, we will explain the BIFA's interface. At the end of this proposal we will make conclusions. To complete and to support this proposal we also attach an appendix.


2. BIFA'S FUNCTIONS

2.1. FUNCTIONS

BIFA has some functions and they will be described below:

  1. BIFA has several methods to get information user's need (Interface models)
    1. User to Agent Interface (UAI) model
    2. Agent to Agent Interface (AAI) model
    3. Non agent Software to Agent Interface (SAI) model
  2. Having knowledge and self learning function
  3. Creating and deleting agent (SUB BIFA) function
  4. Managing agent (SUB BIFA) function

2.2. Required and methods to get information user's need

In this section, we describe information required and methods used BIFA to get information user's need.

2.2.1. Information required

  1. List of required information
  2. Required time, frequency and time-interval
  3. Information's version
  4. Required information reply BIFA's address (can be prural)

2.2.2. Methods to get information user's need

  1. Get information directly from user.
  2. Get information from personal agent (PA).

2.3. Information loaded to SUB BIFA

After getting the user's need of information, BIFA creates SUB BIFA and then load these information to SUB BIFA. With these information SUB BIFA communicates and negotiates with server. Information that BIFA load into SUB BIFA are described below.

  1. SUB BIFA's ID and BIFA's ID
  2. Required information list
  3. Required time, frequency and time-interval
  4. BIFA's Information version.
  5. Requiered information relpy BIFA's address


3. Structure and position of BIFA

3.1. Stucture of BIFA


Figure 1. Stucture of BIFA

As shown in figure 1, BIFA has five elements in its structure. Those elements are described below.

  1. BIFA ID
  2. Method
    Method consists of commands and events executed within agent, software and user.
    Example: Calling Agent, Record Information, Searching Information etc.
  3. Knowledge
    Knowledge and self-learning needed to negotiate with other agent, software and user.
  4. Databases
    Databases loading information such as required information list, information version etc.
  5. Negotiation
    An element consisting interfaces which have negotiate function with other agents, software and user.

3.2. Stucture of SUB BIFA

SUB BIFA uses almost the same model as BIFA has, but there are still some differences between them.

  1. SUB BIFA has not only its ID but also has BIFA ID.
  2. SUB BIFA has only databases, knowledge and method to communicate and negotiate with agent.
  3. Since SUB BIFA only work with BIFA, SUB BIFA only has AAI as its interface.

To describe the detail structures of BIFA and SUB BIFA, we use CORBA v.2.0 standard[1]. The detail structure can be seen in figure 2. From the figure, we can see that BIFA and SUB BIFA are independent agents above-mentioned the Agent Request Broker (ARB) [2]. Therefore BIFA and SUB BIFA has a flexibility which can be plug-in and plug-off. The interfaces shown at figure 2 will be explained in next chapter.


Figure 2. The detail structure of BIFA and SUB BIFA

3.3. BIFA And SUB BIFA Location

As communication platform we adopt the platform model that had been discussed on Telecommunication Information Network Architecture (TINA) workshop[3]. The location of BIFA and SUB BIFA at TINA's platform model can be seen in figure 3.


Figure 3. Referenced communication platform model

BIFA uses Agent Request Broker (ARB) to connect with other agents, software and user. Meanwhile to communicate with other networks communication, BIFA sends SUB BIFA through ARB, OS and network resources by using General Inter ORB Protocol (GIOP)[1]. At the network resources the SUB BIFA is mapped into network protocol that has been using. The detail explanation can be seen in appendix.


4.BIFA'S Interface

In this chapter we explain about BIFA's interface mentioned above. In this proposal we use Object Management Group Interface Definition Language (OMG-IDL)[1] to define these interfaces.

4.1. User to Agent Interface (UAI)

These commands and their paramater can be seen in table 1.

Table 1. User to Agent Interface's command and parameter

COMMAND PARAMETERS SEMANTICS
GUIDE Information list, helpGuidance for user by using GUI & API
ASK Information ID, task IDMake inquire to user
OPENDatabase IDOpen database that has been requested
CLOSEDatabase IDClose the active database
LISTInformation ID, Database IDMake the information list into database
RECORDInformation ID, Database IDRecord a new information or database
CANCELInformation ID, Database IDCancel the information from list or database
SHOWDatabase IDShow the database contents
RESETDatabase IDReset the current database contents

Exp. User wants to know about world news but what he wants is yesterday news. By using guide, the user tells the BIFA about it and BIFA make requested information list (database) and record it to BIFA's databases. And after BIFA's got the request information, BIFA shows it to the user, and the user can order to BIFA for deleting, resetting the database.

This interface is defined by IDL stubs and IDL skeletons of OMG-IDL.

4.2. Agent to Agent Interface (AAI)

These commands and their paramater can be seen in table 2.

Table 2. Agent to Agent Interface's command and parameter

COMMANDPARAMETERSSEMANTICS
CREATEAgent IDCreate SUB BIFA agent
DELETEAgent IDDelete SUB BIFA agent
SETDatabase IDLoad database into others agents
GETDatabase IDGet database from other agents
ASKAgent IDMake inquire with other agents
LISTDatabase IDMake task list of new other agents
RECORDDatabase IDRecord database to BIFA's databases
CANCELAgent ID, Database IDRemove agent ID and its database
SENDAgent IDSend SUB BIFA to other systems
ACTIONTask IDNegotiate with other agents

Exp. gets the requested information from personal agent or travel agent (using commands: ASK, LIST, GET and ACTION). This information is loaded into SUB BIFA which BIFA creates (using commands: CREATE, SET, and ACTION) and send SUB BIFA to server (using commands: SEND). After the SUB BIFA completed its mission, it is deleted by BIFA (using command: DELETE, CANCEL).

This interface is defined by dynamic invocation and dynamic skeletons of OMG-IDL. SUB BIFA has only this interface to communicate with external software, applications and services.

4.3 Non Agent Software to Agent Interface (SAI)

These commands and their paramater can be seen in table 3.

Table 3. Non Agent Software to Agent Interface's command and parameter

COMMANDPARAMETERSSEMANTICSL
ASKSoftware IDMonitoring the software condition
CONNECTSoftware IDMake connection with software using API
LISTInformation IDMake requested information list
GETInformation ID, database IDGet a single or prural requested information
SETInformation ID, database IDSet information into software
RECORDSoftware IDRecord a new software into BIFA's databases
ACTIONTask IDExecute the software

Exp. When new software installed, BIFA gets the software ID from ARB. Then, BIFA makes connection with this software to make database of it (using commands: ASK, CONNECT, LIST, GET and RECORD). If one of requested information created by this software, BIFA makes request to execute this software to get the requested information (using commands: ASK, CONNECT, SET, ACTION and GET).

This interface is defined by dynamic invocation and dynamic skeletons of OMG-IDL.

4.4 BIFA's Object Adapter Interface

In this proposal we do not propose Object Adapter's interface and Object Oriented Database Adapter's interface. These interfaces is taken from CORBA v.2.0[1].


5. BIFA'S WORKING METHOD

In this chapter we will explain the working method of BIFA.

  1. At first, BIFA gets a requested information from personal agent or user.
  2. BIFA creates SUB BIFA and loads the requested information.
  3. Through communication network, SUB BIFA is sent to server.
  4. At server, SUB BIFA negotiates with server's BIFA. When the negotiation finishes, SUB BIFA will be back to its own BIFA.
  5. SUB BIFA report to BIFA and BIFA then delete it because the mission is completed.
  6. If there is a new request by user or personal agent beyond the interval time, the process will be active automatically.
  7. The process will be active in every interval-time that has been set up.


6. Conclusions

From all explanations mentioned above, the conclusions of this proposal is described as follows :

  1. User receives only the requested item (information), not all of the information.
    Therefore of that the network traffic is reduced.
  2. By using the requested time, frequency and interval-time, the system gives the user a flexibility to customs the needed information.
  3. By using information's version data, network traffic is reduced.
    If the information version's data of the user is the same with server's one, the information will not be transferred. It mean the network tarffic load is reduced.
  4. The information that has been taken can be reply to plural users.
    By using this function, in a group of user it is only needed one user to send the requested information. From this point of view, the network traffic load is expected to be reduced.
  5. All of the proposed interfaces (AAI, UAI and SAI) satisfy the FIPA's requested functions. And these interfaces can be adapted to other agents.


Reference:

[1] OMG : "The Common Object Request Broker Architecture And Specification", July 1995
[2] R. KISHIMOTO:"Agent Communication Transport Network for Agent Communication Services", Trans. IEICE, vol.J79-B-I, No. 5,pp. 238-250,May 1996
[3] T. Bence: "Advanced Networked Systems Architecture; An Apporach for Furture Telecommunica tion Network", Workshop on TINA,1990 (New York)


Appendix:

A. BIFA'S NETWORK PROTOCOL

In figure 4, we proposed the network communication protocol that used by BIFA.


Figure 4. Network communication protocol

The detail explanation of these protocols is described below.

  1. Bridges
    This protocol exists within Agent Request Broker (ARB) and it used for communication inter- ARB (called "Message Passing"). CORBA's Object Inter Bridges adopted as the protocol.

  2. Internet Inter ORB Protocol (IIOP)
    IIOP has been standardized in CORBA v.2.0.

  3. GIOP for Common Management Information Protocol (CMIP) CMIP is a standard protocol of Telecommunication Management Network (TMN). GIOP is mapped to CMIP for using BIFA on TMN. The SUB BIFA's structure that has been mapped into CMIP shown in figure 5.


Figure 5. GIOP for CMIP structure

The content of command field as shown in figure 5 is AAI command. The information loaded in the parameter field are described below.

  1. Requested time, frequency and interval time.
    Exp. When we request information once and right now then the parameter field is formatted as [Now,1,0]
  2. BIFA's reply address (can be plural ID).
  3. Requested Information ID item and its version data.


FIPA's First Call for Proposals