SS.

7 as an Agent Platform Message Transport Protocol

Rob Brennan, Brendan Jennings and Thomas Curran
Teltec Ireland, Dublin City University, Dublin 9, Ireland
{brennanr, brendan.jennings}@teltec.dcu.ie

Abstract. FIPA has provided a standardised model for implementing interoperable agent systems that may prove the basis for new solutions to the
problem of managing the growing complexity of the telecommunications
infrastructure. However, the ability of agents to operate in the
telecommunications domain would be greatly enhanced if the FIPA architecture
was refined to deal with the standardised SS.7 communications protocol suite
almost universally used for the control of telecommunications networks. The
current FIPA model is TCP/IP centred, thus in order to use the SS.7
infrastructure a mapping from FIPA message transport requirements to SS.7
protocol transport capabilities must be performed. A protocol for the
distribution of FIPA ACL messages in SS.7 networks must also be defined.
Analysis of the possibilities shows that there are different design choices
depending upon the exact deployment model and agent capabilities required. In
addition it is necessary to allow the use of SS.7 addresses within the FIPA
management protocols. An evaluation of best common practice for CORBAbased FIPA implementations in the SS.7 domain must also be defined. This
treatment highlights the failings of the current FIPA model when applied to the
real-time, bandwidth-constrained, specialised protocol environment of
telecommunications signalling.

1.

Introduction

Recent technological advances in the telecommunications arena have facilitated

increased bandwidth availability, user/terminal mobility and greater numbers of
increasingly sophisticated service offerings. Deregulation of the industry has
encouraged a more open approach towards service provisioning, resulting in the entry
of new actors into the market and increased offering of services across network
operator boundaries. These factors mean that the complexity and level of connectivity
of networks is continually growing in order to support the range and volume of
information produced by users. The introduction of service provisioning architectures
based on Distributed Object Technology is widely seen as means of rationalising the
organisation and interaction of complex service-related software and also associated
control systems. However, even in a distributed object based network environment,
the problem of developing effective means of managing information, networks and
intelligence remains significant. Many researchers believe that suitable solutions may
be provided through the adoption of Agent Technology, which, broadly speaking,
offers two advantages over traditional architectural approaches. Firstly, so called

Intelligent Agents offer a knowledge-centred methodology that is particularly suited

to management of information and network resources. Secondly, Mobile Agents
have the ability to migrate between the nodes in a network and thus offer the
capability to distribute and execute logic, where and when needed in the network. For
an overview of the potential advantages of and applications for Agent Technology in
the communications management domain see [1].
An important enabler for the introduction of agent-based systems into
telecommunications networks will be the availability of internationally agreed agent
platform inter-operability standards. Work in this direction is taking place within the
Foundation for Intelligent Physical Agents (FIPA). FIPA has produced specifications
governing interoperability between intelligent agents, which in particular specifies a
powerful Agent Communication Language (ACL), an inter-operable agent platform
architecture and management protocols used by agents to interact with the platform.
In the FIPA specifications there is an implicit assumption that the underlying data
communication network used to transfer information between remote agent platforms
is based on the TCP/IP protocol suite. This will be the case in many of the application
domains where agent-based systems will be deployed, however in the
telecommunications domain the situation may be different. Advantages would be
gained if agent-based systems deployed in network elements have the capability to
communicate via telecommunications specific protocol suites such as Signalling
System No.7 (SS.7) which is widely deployed to reliably support signalling for
basic telephony, Intelligent Network and mobile terminal services. SS.7 is designed
specifically to support real-time interactions in a highly reliable and robust manner,
thus it is more suited than TCP/IP for the transfer of potentially time-critical
information between agent platforms. Re-use of existing SS.7 infrastructure also
avoids the necessity of deploying separate networks for agent communications,
making it a more economically viable approach. In this paper we address a number of
options which would facilitate the use of SS.7 for the transfer of ACL messages
between FIPA-compliant agent platforms.

2.

FIPA Agent Platform Architecture

The primary goal of FIPA is to make available internationally agreed specifications

that maximise interoperability across agent-based applications, services and
equipment [2]. To date FIPA has produced two sets of specifications, FIPA97 and
FIPA98, FIPA98 being an evolution of FIPA97. FIPA98 is composed of 13
separate parts, some of which are normative (i.e. they must be adhered by an agent
platform for it to be FIPA-compliant), the others being informative only. The central
parts of the specifications are Part 1 [2], which deals with Agent Management and
Part 2, which specifies an Agent Communication Language (ACL) [3].
The Agent Management specification defines the Agent Platform and its
components: Directory Facilitator (a yellow pages service), Agent Management
System (manages agent lifecycle etc.) and Agent Communication Channel (for
transfer of inter-platform inter-agent communications). These elements are illustrated
in Figure 1 below. In order to co-operate to achieve their set tasks FIPA agents may

communicate using ACL, a powerful high-level communication language loosely

based on speech act theory.
Agent

Agent

ACL Messages

AMS

DF

ACC

ACC

DF

AMS

Internal Message Transport

Internal Message Transport

IIOP
Messages

IIOP
Messages

FIPA Agent Platform

TCP/IP
Stack

Legend
ACC: Agent Communication Channel
ACL: Agent Communication Language
AMS: Agent Management System

FIPA Agent Platform

TCP/IP
Stack

TCP/IP Network

DF: Directory Facilitator

IIOP: Internet Inter-Orb Protocol

Fig. 1. FIPA Agent Platform Structure and Inter-Platform Communication

3.

Signalling System No.7

Signalling in telecommunications networks consist of communications between

customer premise equipment, switches, network-based servers, and databases to
manage and complete end-user service sessions. The signalling protocols typically
used by telecom network operators and equipment vendors for communications
between the various network elements are those standardised by the ITU-T the
Signalling System No. 7 (SS.7) protocol suite [5].
TC-User Protocols

INAP

MAP

TC

CSL
TSL

.
Request/Reply Envelope

Legend
CSL: Component Sub-Layer
INAP: Intelligent Network Application Protocol
MAP: Mobile Application Part
MTP: Message Transfer Part
TC: Transaction Capabilities
TSL: Transaction Sub-Layer
SCCP: Signalling Connection Control Part

SCCP

Thin end-to-end
connection protocol
Reliable, connectionless
message transport service

MTP Levels 1-3

Fig. 2. The SS7 Protocol Suite

A brief overview of the parts of the SS.7 protocol architecture of relevance to this
paper is provided below, for further information see [6]. As shown in Figure 2, the
SS.7 protocols of interest comprise the Message Transfer Part (MTP) levels 1 to 3,
Signalling Connection Control Part (SCCP) and Transaction Capabilities (TC).
MTP1-3 provide a connectionless, highly reliable data-gram capability. This is

augmented by some additional addressing capabilities provided by the SCCP. On top

of this is the TC protocol, consisting of the Transaction sub-layer (TSL), which
provides a very thin end-to-end connection for the transfer of remote operations using
the Component sub-layer (CSL), which is based on the OSI Remote Operations
Service (ROS) [7]. This is essentially a RPC-like capability. The specifics of the
remote operations and their returns are described as TC-user protocols using the
Abstract Syntax Notation One (ASN.1) [8] and encoded using the Basic Encoding
Rules (BER) [8]. For example, the remote operations that define the interactions
between switches and network servers (containing service-specific intelligence) are
defined by a TC-user protocol called the Intelligent Network Application Protocol
(INAP).
The OMG has recently standardised SS.7/CORBA interworking and that work is
exploited here to provide the first look at an Agent messaging infrastructure based on
SS.7. This is of relevance to FIPA agents as many FIPA-compliant platforms are
based on CORBA distributed object technology. For an introduction to the CORBA
inter-ORB communication protocols see [9] and for an overview of the OMG
standardised SS.7/CORBA interworking see [10].

4.

Suitability of SS.7 as a FIPA Message Transport Service

Part 2 (ACL) of the FIPA specifications [3] prescribes a number of message transport
service requirements, which must be satisfied to ensure that assumptions central to
ACL itself are valid. However, there are a number of additional, implicit assumptions
made throughout the FIPA specifications about the nature of the message transport
service, in particular that it will utilise the TCP/IP protocol suite (as will be the case
for the vast majority of applications). All of these requirements, both explicit and
implicit must be assessed when evaluating the suitability of SS.7 as a transport
service. The discussion in this section shows that SS.7 protocols satisfy the prescribed
message transport service requirements, however the implicit transport requirements
are harder to satisfy, so they will form the subject of much of the remainder of the
paper.
4.1

Evaluation based on FIPA message transport service requirements

SCCP, and by extension TC, satisfy the FIPA Part 2 prescribed message transport
service requirements, the majority of which are quite rudimentary. We shall discuss
only those requirements where the compliance of SCCP/TC is not immediately
apparent:
The message service exposes through its interface whether it is able to cope
reliably with 8-bit bytes whose higher-order bit may be set: all SS.7 protocols
implicitly support the transport of octet streams, thus it hardly seems important that
this fact is exposed through the protocol interface;
The message service is ... orderly: SCCP class 1 is a sequence guaranteed
service, thus it must always be used for transmission of ACL messages. TC-Users

can ensure that TC utilises SCCP class 1 by appropriate setting of the Quality of
Serviceparameter of TC-primitives;
Indication of unavailability of synchronous/asynchronous message transport: both
SCCP and TC provide asynchronous message transport only, however agents
themselves may realise synchronous behaviour by suspending and waiting for the
result of a message;
Parameters of the act of delivering a message ... are part of the interface exposed
by the message delivery service: parameters, such as Sequence control in the
case of SCCP or Timeout in the case of TC are exposed as parameters in the
relevant N- (i.e. SCCP) or TC- primitives;
The message service will detect and report error conditions: Both SCCP and TC
report a range of error conditions by returning N-NOTICE and TC-ERROR
primitives respectively.
4.2

Evaluation based on implicit FIPA message transport service requirements

The implicit FIPA message transport service requirements are in fact more difficult to
satisfy in the SS.7 domain. This is because they are effects of an implicit dependence
on the TCP/IP suite of protocols in the FIPA specifications.
FIPA Messages may be of arbitrary size and hence assume a connection-oriented
transport: The most popular forms of SCCP in deployed SS.7 networks are both
connectionless protocols (class 0 and class 1), and hence only limited PDU sizes
are supported the maximum size is 2K octets1.
FIPA addressing is defined as an elaborated TCP/IP address: In order to support
SS.7-style addressing the current FIPA addressing syntax must be extended, see
5.1 below.
4.3

Support for IIOP Bootstrapping

An additional requirement of the FIPA specifications not yet discussed is that all
FIPA-compliant agent platforms support at least IIOP as a baseline inter-platform
protocol. The intention is to allow platforms make initial contact using IIOP and
subsequently switch to another transport protocol if desired. Because IIOP is a
mapping of the General Inter-ORB Protocol (GIOP) for the TCP/IP protocol suite it is
not suited for direct use with SS.7 protocols [11]. A possible resolution to this is to
use the SS.7 Inter-ORB Protocol (SIOP) defined in [11] for FIPA bootstrapping in the
SS.7 domain; since it uses the same message set and transfer encoding as IIOP this is
an easily implemented solution for platforms that have their own IIOP
implementation. Alternatively, agent platforms with the ability to interface with an
SS.7 stack and deployed in the SS.7 domain may use some SS.7 specific solution for
1

This value is based on the SS.7 White Book recommendations [4], in SS.7 systems
conforming (as many do) to the earlier Blue Book recommendations [3] the maximum
message length is 272 octets the change is due to the introduction of a segmentation/reassembly facility for SCCP class 0/1 in the White Book recommendations.

initial contact. In this case this should be an acceptable non-compliance with this
aspect of FIPA specifications. In any case if IIOP support is required, it must be
support via an interface to a TCP/IP protocol stack.

5.

SS.7-Capable FIPA Agent Platforms

In a FIPA-complaint agent platform, the responsibility for transferring ACL messages

to a remote platform will typically rest with the ACC (although FIPA specifications
do allow individual agents to communicate directly with an ACC of another
platform). This situation is illustrated by Figure 3 below. This section first suggests
how the current FIPA addressing scheme can be extended to allow support for SS.7
addresses. It then analyses whether TC or SCCP is the more suited protocol level for a
FIPA ACC to use to transport ACL messages.
Agent

Agent

ACL Messages

AMS

DF

ACC

ACC

FIPA Agent Platform

DF

AMS

Internal Message Transport

Internal Message Transport

TC or SCCP
Messages

TC or SCCP
Messages

SS.7
Stack

SS.7 Network

FIPA Agent Platform

SS.7
Stack

Fig. 3. SS.7 as Inter-Platform Transport for SS.7 Capable FIPA Systems

5.1

Extension of FIPA Addressing to support SS.7 Addresses

Addressing in the SS.7 domain is based on three values: the Signalling Point Code
(PC), the Sub-System Number (SSN) and the Global Title (GT). At its most basic,
addressing consists of a PC that defines a destination node in the network, and a SSN
that identifies a particular SCCP-User protocol. Instead addresses may consist of GTs
which are names which may be mapped by the SCCP GT Translation function into
specific PC, SSN pairs. Additionally an address may consist of a SSN specified with a
GT.
FIPA addresses are defined as follows:
AgentName =
CommAddress =
CommProtocol =
IPAddress =
DNSName =
ACCObj =

Word @ CommAddress.
CommProtocol ://(IPAddress|DNSName) : Integer
/ ACCObj.
[a-z,A-Z] [a-z,A-Z,0-9,_]*
Integer .Integer .Integer
.Integer
Word
Word

This seems to support multiple protocols but in fact they must all be of the TCP/IP
protocol suite as all protocols use an IP address or a DNS name and a TCP port. A
solution would be to change the definition of CommAddress as follows (and
additionally constrain the SS.7 address values in accordance with SS.7
recommendations):
CommAddress =
URL =
SS7 =
PointCode =
GlobalTitile =
SubSystemNumber =

(URL|SS7) / ACCObj.
CommProtocol ://(IPAddress|DNSName)
: Integer
ss7:: (PointCode|GlobalTitle) [:
SubSystemNumber]
HexLiteral
HexLiteral
HexLiteral

This new scheme allows us to register agents and/or agent platforms with SS.7
addresses. However it indicates a more general problem with FIPA addressing it is
not flexible enough to allow non-TCP/IP protocols to be specified and it does not
allow the association of one agent name with many addresses (each perhaps using
different protocols). Thus, a more general approach to addressing needs to be
explored.
5.2

Layers of SS.7 Useful as a Transport for ACL Messages

There are two possible layers of the SS.7 protocol suite that may be used as an ACL
transport: SCCP or TC. Each has its own possible strategies and drawbacks, as
discussed below.
5.2.1
Interfacing with SCCP
In most currently deployed SS.7 networks, only class 0 and class 1 SCCP are
available. Both classes offer connectionless services. The class 0 service does not
guarantee that the order of messages sent between a given source and destination is
maintained. Class 1 SCCP provides guaranteed message sequencing. Because of
guaranteed order of delivery SCCP class 1 fulfils the requirements FIPA explicitly
mandates for a message transport service for ACL messages. However due to the
connectionless nature and limited message size supported by the transport, the agent
platform would have to implement some sort of minimal segmentation and reassembly protocol on top of SCCP class 1 to simulate a stream-based interface
supporting arbitrary message sizes. This is not possible without considerable overhead
for SCCP Class 1. Additionally as there is no transfer syntax defined for SCCP other
than an octet sequence, the inefficient textual encoding of ACL messages would result
in increased message sizes and load on the SS.7 infrastructure. As SS.7 is optimised
for exchanges of small, connectionless messages transfer of a potentially large
number of arbitrarily large messages could easily have an adverse effect on network
performance [14]. Even with these disadvantages, this is the most general solution for
enabling ACL communication over the SS.7 network. However, as this solution
depends on the deployment of future ORB technology we do not define such a
protocol here, but instead refer to the SIOP protocol defined by the OMG [11], which

is similar to the IIOP (same messaging and transfer syntax) already implemented on
FIPA-compliant platforms.
5.2.2
Interfacing with TC
Because of the power of the SS.7 TC protocol to create and manage dialogues
(consisting of operation, result and error PDUs defined in Abstract Syntax Notation 1,
ASN.1) between TC-User application entities, it appears to be a more natural choice
for handling the transfer of ACL messages. Additionally, use of the ASN.1 transfer
syntax with BER encoding means that the textual inter-platform ACL messages are
significantly compacted and the message parsing and protocol handling tasks carried
out by the ACC are simplified.
TC operations are always transported between TC-User application entities in the
context of dialogues. It would be possible to utilise this fact to provide support for the
handling of ACL message protocols used by an agent system. This could be achieved
by using the Dialogue ID parameter of TC- primitives to associate the ACL
messages contained within TC operations with particular protocol instances. This
would simplify somewhat the protocol handling demanded of the agents. However, it
should be noted that ACL message protocols could take an arbitrarily long time to
complete, so a large number of dialogues may be open concurrently. It may then be
possible that the available pool of Dialogue IDs and other dialogue handling resources
could become exhausted (note that in existing TC based systems this does not happen
because TC dialogues typically terminate in a very short space of time). Thus the full
power of TC operation definitions can not be used to express FIPA interactions, as,
for practical reasons, these will take place over the course of several TC dialogues.
TC uses the services of SCCP class 1 and does not support segmentation of
operation invocations itself, thus general ACL communication (messages of arbitrary
size) cannot be supported unless fragmentation and re-assembly is supported at the
application level, i.e. in the ACC. This would incur an additional overhead in terms of
implementation complexity and inefficient use of bandwidth. In the next section we
present a TC-User protocol suitable for FIPA agent platforms where either a
segmentation and re-assembly protocol of this type is supported, or it is explicitly
understood that ACL messages can not exceed the maximum PDU size supported by
SS.7.
5.3

A TC-User Protocol for FIPA Agent Platforms

As discussed above agent interactions will generally map onto several TC dialogues,
the normal TC case of associating operations, replies, errors and linked operations
within a dialogue is not suitable. ACL messages are instead modelled as highly
asynchronous events passed between two agent platforms. This allows an arbitrary
mapping of ACL conversations to TC dialogues (either one-to-one or one-to-many) as
may be required to preserve dialogue resources in SS.7 nodes.
Thus a single operation, called ACLMessage, is defined to allow the transfer of
ACL messages using TC. In its most basic form, the operation parameter is encoded
as a single octet string containing the whole FIPA textually encoded ACL message. In
ASN.1 the ACLMessage OPERATION would be defined as follows:

ACLMessage
::= OPERATION
ARGUMENT
ACLMessageArg
ACLMessageArg ::= OCTET STRING

As an event model is being used no result or linked operations are specified in the
ASN.1 definition above. No error clause is required as standard TC reject conditions
will report the error conditions required by the FIPA message transport requirements.
Note that this definition is specifically designed to cope only with ACL messages that
are sufficiently short to traverse the SS.7 network.
While the ACLMessage operation defined above would be sufficient to enable
the transfer of ACL messages it does not utilise well the expressive power of ASN.1
definitions and the associated brevity of BER encoding. A better use of the power of
ASN.1 would result in the simplification of the ACL message parsing it would
make the decoding and delimitation of message fields a straightforward task. Another
advantage would be reductions in the length of ACL-carrying SS.7 messages (because
field names strings are replaced by integer representations), which is important for
signalling applications, where minimisation of bandwidth usage is critical. In light of
this the argument list for the ACLMessage operation is redefined below; the basic
approach being the use of separate ASN.1 field definitions for each potential ACL
message parameter. Note the definition of a CommunicativeActType field that
identifies the type of communicative act represented by an individual ACL message.
ACLMessageArg ::= SEQUENCE {
communicativeActType
[0]
receiver
[1]
sender
[2]
content
[3]
replyWith
[4]
inReplyTo
[5]
envelope
[6]
language
[7]
ontology
[8]
replyBy
[9]
protocol
[10]
conversationId
[11]
}

CommunicativeActType,
RecipientExpr,
AgentName
Content
Expression
Expression
KeyValuePairList
Expression
Expression
DateTimeToken
Word
Expression

OPTIONAL,
OPTIONAL,
OPTIONAL,
OPTIONAL,
OPTIONAL,
OPTIONAL,
OPTIONAL,
OPTIONAL,
OPTIONAL,
OPTIONAL,

CommunicativeActType ::= ENUMERATED {

acceptProposal(0), agree(1), cancel(2), cfp(3), confirm(4),
disconfirm(5), failure(6), inform(7), informIf(8), informRef(9),
notUnderstood(10), propose(11), queryIf(12), queryRef(13),
refuse(14), rejectProposal(15), request(16), requestWhen(17),
requestWhenever(18), subscribe(19)
}
RecipientExpr ::= IMPLICIT SEQUENCE OF AgentName
AgentName
::= CHOICE {
word
[0]
Word,
wordAtURL
[1]
WordAtURL
}

Word

::= --

In

accordance with
extra characters2
::= SET {
[0] Word,
[1] Word

ISO/IEC

2022

plus

WordAtURL
word
url
}
Content
::= CHOICE {
expression
[0] Expression,
mIMEEnhancedExpression[1] MIMEEnhancedExpression
}
Expression
::= OCTET STRING
-- In accordance with FIPA Part 2
MIMEEnhancedExpression
::= OCTET STRING
-- In accordance with FIPA Part 2
KeyValuePairList
::= SEQUENCE OF EXTERNAL
DateTimeToken

::= -- In accordance with ISO 8901 format3

The ASN.1 provided above defines the content of the ACL message as a single octet
string (either as type Expression or MIMEEnhancedExpression). Depending
on the characteristics of a given content language it may be desirable to provide a full
ASN.1 description to replace the content parameter above, thus allowing further
savings in terms of message parsing overheads and message size. There would
certainly be advantages in doing this for the SL-encoded content mandated for use in
the FIPA agent management communicative acts.
Another possible extension of the approach would be to define separate operations,
for each of the communicative acts (both FIPA-specified and application-specific)
used by the agent system in question. This would result in some savings in terms of
message parsing and message sizes because the operation name would alleviate the
necessity of having a CommunicativeActType parameter. However this
approach has disadvantages in that it is not as easily extendible as was the previous
case.
Another point to note is that it may be desirable to define explicit ASN.1 results
and errors for the communicative acts associated with the FIPA management
operations as this would ease the overhead on the platform for the handling of agent
management. However the down side of doing this would be that these ACL
conversations would be constrained to the context of a single TC dialogue.

6.

SS.7 Integration in CORBA-based, FIPA Platforms

As discussed previously interworking between SS.7 and CORBA can be achieved

through the use of TC/CORBA gateways, or through an ORB supporting SIOP. In
2

FIPA specifies that lexical tokens of type Word may contain any well-formed ISO/IEC
2022 encoded character, other (representations of) parentheses, spaces, or the # character.
As an ASN.1 definition for this would be quite lengthy we have not included one here.
FIPA specifies the lexical tokens of type DateTimeToken are based on the ISO 8601
format, with extensions for relative time and millisecond durations. Again we omit an
ASN.1 definition for this type.

this section we will address how both these approaches can be used to support the
transfer of ACL messages between CORBA-based, FIPA-compliant agent platforms.
It should be noted that the TC/CORBA gateway approach is more viable in the short
term as TC/CORBA gateways are expected to appear on the market shortly. The
SIOP approach is more long term as ORB vendors are not expected to introduce SIOP
support directly into their products for some time to come, however the concept of
pluggable transports and Open Communications Interfaces (OCI) [15] for ORBs
could allow a third party to interface SIOP to standard ORB products in the nearer
future.
6.1

TC/CORBA Gateway Approach

Use of a TC/CORBA gateway means that the basic transport service used for the
transfer of ACL messages is TC, however the significant difference from the case
described in 5.3 is that this fact is completely hidden from the ACC/agent that is
transferring the messages. The ACC/agent simply sends the messages as if the
receiving agent also resided on the same platform, it is the ORB which must identify
that the message is to be routed through a TC/CORBA gateway, which in turn handles
all interactions with an SS.7 stack. The straightforward nature in which agents send
messages in this scenario represents a significant advantage of CORBA-based agent
platform implementations. As illustrated in Figure 4 below, TC/CORBA gateways
may be used to support communication between a CORBA-based platform and a
TC-enablednon-CORBA based platform, or between two CORBA-based platforms.
In the latter case the SS.7 network is used as a tunnel to connect the two TCP/IP
based islands; the potential advantage of doing this is the much greater reliability and
robustness levels that would be offered by SS.7 in comparison to using a TCP/IP
based network.
The issues relating to the use of TC/CORBA gateways as illustrated above are the
same as those discussed for interfacing with TC, namely the approach offers
advantages in terms of simplified message parsing and reduced message lengths. An
additional advantage is that it offers a structured means of supporting IIOP as a
baseline message transport. The only significant disadvantage is that the platform will
need to support segmentation and re-assembly of ACL messages of size greater than
2K octets.
6.2

SIOP Approach

SIOP is designed as a GIOP mapping onto the connectionless SCCP transport

services that allows an ORB to interface directly (i.e. not through a gateway) with
SS.7. Transfer of ACL messages between two FIPA platforms built on ORBs
supporting SIOP is illustrated in Figure 5 below. The advantages of using SIOPenabled ORBs for the support of SS.7 as an inter-platform transport mechanism for
FIPA agent systems is that it places no restrictions on ACL message sizes and its use
is completely transparent to the sending and receiving ACCs/agents. Disadvantages
include the fact that SS7 message sizes may be very large (because SIOP, like all

GIOP mappings, uses CDR encoding) and the requirement that the agent platforms
are implemented using an ORB that can support SIOP.
Agent

Agent

ACL Messages

AMS

DF

ACC

ACC

DF

AMS

Internal Message Transport

ORB
FIPA Agent Platform

FIPA Agent Platform

TC-CORBA Gateway
TC
SCCP
MTP

SS.7 Network

TC
SCCP
MTP

Fig. 4a. Gateway Approach, CORBA-based & non CORBA-based FIPA Systems

Agent

Agent

ACL Messages

AMS

DF

ACC

ACC

DF

AMS

ORB

ORB
FIPA Agent Platform

TC-CORBA Gateway

TC-CORBA Gateway

TC
SCCP
MTP

TC
SCCP
MTP

SS.7 Network

FIPA Agent Platform

Fig. 4b. Gateway Approach, Two CORBA-based FIPA Systems

Agent

Agent

ACL Messages

AMS

DF

ACC

ACC

DF

AMS

SIOP-enabled ORB

SIOP-enabled ORB

FIPA Agent Platform

FIPA Agent Platform

SCCP
MTP

SS.7 Network

SCCP
MTP

Fig. 5. SIOP Approach, Two CORBA-based FIPA Agent Systems

7.

Conclusions and Future Work

This paper has addressed issues relating to the use of SS.7 for the transport of
information between FIPA-compliant agent platforms. An analysis was made of the
suitability of the SS.7 SCCP/TC protocols as a FIPA message transport service, both

in terms of the explicit requirements outlined in the FIPA specifications and implicit
requirements relating to assumptions on the use of TCP/IP based protocols. The
advantages and disadvantages involved with FIPA platforms interfacing to the SCCP
and TC protocol were outlined and, for the TC option, a basic TC- User protocol was
defined. Finally, some comments were made on how best to integrate CORBA-based
FIPA platform implementations into an SS.7 environment.
The paper has highlighted that a fundamental limitation of existing SS.7 systems is
that they cannot support the transfer of arbitrarily large messages in part because
doing so would be likely to adversely affect network performance. If, however,
support for very large messages is required (as is the case for a FIPA-compliant agent
platform using SS.7 as a transport mechanism), it must be achieved through
application-level support for segmentation and re-assembly. Because of the
undesirability of transferring very large messages over SS.7 it is the opinion of the
authors that every effort possible should be made to minimise both the number and
size of ACL messages transferred between agents in an SS.7 environment.
The paper has also highlighted a major failing in the current FIPA model. This
failing relates to FIPA agent addressing scheme in which addresses are formulated
as elaborated TCP/IP addresses. This scheme is incompatible with the SS.7 one,
although some workarounds such as the use of a proxy agent for address translation,
would be possible. The authors believe a better solution would be a redefinition of
FIPA addresses in a manner that would allow the flexible specification of non
TCP/IP-based addressing schemes. A suitable approach to this would be the adoption
of Uniform Resource Identifiers (URIs) [16] as the standard for FIPA addresses.
Given the two areas of difficulty discussed above, the paper concluded that, for
FIPA agent platforms not implemented using CORBA technology, there are
advantages to interfacing with TC rather than SCCP for the transport of ACL
messages. These advantages relate to the expressive power of ASN.1 syntax and BER
encoding, which results in simplification of the message parsing required in the ACC
and potentially significant reduction of message sizes sent over SS.7. For CORBAbased FIPA platforms the situation is somewhat different, as a better solution would
be the use of a SIOP-enabled ORB, which automatically provides for segmentation
and re-assembly of large messages. However as SIOP-enabled ORBs are not expected
to be available commercially in the near future a short-term solution would be
provided through the use of TC-CORBA gateways.
Future work items arising from this paper include the development of a proposal
for an alternative FIPA addressing scheme, based on URIs, which can be
straightforwardly enchanced to support SS.7 addresses. Also desirable would be a
means of compressing the size of the ACL messages in bandwidth limited
application domains like SS.7. This could be achieved by allowing agents to negotiate
on more size-efficient message formats, tailored to their specific needs. A quantitative
study on the performance implications of the transfer of ACL messages over SS.7
networks is also planned.

Acknowledgements
This work was supported by the European Commission in the context of ACTS
project MARINER; the authors wish to acknowledge the valuable contribution of
their colleagues in this project.

References
1. Hayzelden, A. L. G., Bigham, J., Wooldridge, M., Cuthbert, L. G. Future Communication
Networks using Software Agents. Chapter 1 in Software Agents for Future
Communications Systems. Hayzelden and Bigham (editors). Published by Springer Verlag,
ISBN 3-540-65578-6, 1999.
2. FIPA, FIPA 98 Specifications, Part 1, Agent Management, available at http://www.fipa.org
3. FIPA, FIPA 98 Specifications, Part 2, Agent Communication Language, available at
http://www.fipa.org
4. International Telecommunications Union, Q.7xx Series Recommendations Signalling
System No.7,Blue Book, 1988
5. International Telecommunications Union, Q.7xx Series Recommendations Signalling
System No.7,White Book, 1993
6. N. Mitra and S. D. Usiskin, Interrelationship of the SS7 Protocol Architecture and the OSI
Reference
Model
and
Protocols, The Froehlich/Kent Encyclopedia
of
Telecommunications, Volume 9, Marcel Dekker, Inc., 1995
7. ITU-T Rec. X.880 (1994) | ISO/IEC 13712-1:1995, Information technology - Remote
Operations: Concepts, model and notation.
8. ITU-T Rec. X.680 through 683 (1994) | ISO/IEC 8824-1/2/3/4:1995, Information
technology - Open Systems Interconnection - Abstract Syntax Notation One (ASN.1)
.
9. N. Fishbeck and O. Kath, CORBA Interworking over SS7, published elsewhere in this
volume
10.N. Mitra and R. Brennan, Design of the CORBA/TC Inter-working Gateway,published
elsewhere in this volume
11.Object Management Group, Interworking between CORBA and TC Systems,telecom/9810-03, October 1998, available at http://www.omg.org
12.Object Management Group, White Paper on CORBA as an Enabling Factor for Migration
from IN to TINA: A P508 Perspective,OMG DTC Document: telecom/97-01-01, January,
1997, available at http://www.omg.org
13.The Open Group, Preliminary Specification Inter-Domain Management: Specification
Translation, X/Open Document Number: P509, ISBN: 1-85912-150-0
14.J. Zepf and G. Rufa, Congestion and Flow Control in Signalling System No. 7 - Impacts of
Intelligent Networks and New Services, IEEE Journal on Selected Areas in
Communications, Vol. 12, No. 3, April 1994.
15.Object Management Group, Pluggable Protocols Request for Proposals (Draft),OMG
DTC Document: telecom/97-11-02, November, 1997, available at http://www.omg.org
16.Network Working Group, Uniform Resource Identifiers (URI): Generic Syntax,Network
Working Group Request for Comments: 2396.