RPCP is a generic interface protocol between two entities,
where one entity acting as Resource Pool (RP) and other being
the Resource Pool Controller (RPC). The RP entity in turn
may be acting as RPC for other RPs in a hierarchical manner.
The resource being defined can be any hardware/software, physical/virtual
resource.
In today's telecommunication world, the intelligence is being
moved away from the hardware (the embedded platform) or the
switching fabric to a more generic computing resource (high-end
servers). These computing resources controls the call logic,
service logic and the network signalling part. This implies
that there is a need for an open interface protocol by which
call agents or signalling agents can control this rather dumb
hardware as resource pools. This helps in easy and smooth
integration of these entities even if they come from different
vendors.
The Interworking and Gateway market is a very big market
today. The network architecture proposed for these solutions
carries the intelligence away from the resource pools (also
called media gateways) to call agents or pool controllers
(also called media gateway controllers). With such network
architectures the need for such a protocol is more prominent.
There are many other needs and use of such a protocol which
will be discussed in detail in this white paper. This paper
does not try to define the complete protocol, however the
basic definition and the protocol architecture will be defined.
The document first describes the application of Resource
Pool Control protocol, followed by requirements from this
Protocol and then defines the Protocol Architecture with basic
protocol definition. The annexure of the document gives few
examples on RPCP usage.
There are many applications for a resource control protocol,
but all of them will not be discussed over here. However a
few of the representative needs are detailed below.
1.1 Signalling and Call Agents separation from
switching fabric
As new switching architecture or network components are moving
intelligence away from the hardware (embedded platforms) to
more generic computing resources (high-end computers). Different
vendors can produce these two components, with an open interface
defined between them. The call agents/signalling agents controls
the hardware resource pools through such a control protocol
or interface. Each vendor is defining its own interface to
control the hardware resources or to communicate signalling
information, from the controlling entity (call agents/signalling
agents) to resource pool. It will require efforts on the controlling
entity part to comply with number of such interfaces. However
if an open and flexible protocol definition exists and being
used by both the sides, the integration of switching fabric
and call intelligence will be an easy task.
1.2 Gateway Architecture
Most of the gateways today have a distributed architecture
with intelligence moved away from the resources required for
the application/service, to the call-agents/signalling-agents
and an interface protocol being defined between these two
entities by the vendor himself. One of the examples for such
architecture is voice over packet network gateways. These
gateway supports SCN interface on one side and packet network
interface on the other side. The architecture suggested for
such gateways requires the resource pool (voice processing,
voice packetization, echo cancellation etc) being concentrated
on one entity called the media gateway and the intelligence
for call handling and resource control being located on other
entity called media gateway controller. The media gateway
controller can control multiple of such media gateways depending
on the processing and interface capacity of the controller.
However to the external world i.e. the PSTN network and the
packet network the gateway appears as a single entity providing
the interworking/gateway functions. Therefore for such architecture
there is a need for an interface protocol by which media gateway
controller can control multiple media gateways. As of today
there exists few such protocol which defines the interface
for such communication. The major drawback of these protocols
is a bias towards the voice over packet gateways and the protocol
is not generic to cater to all the gateway/interworking function
requirements.
1.3 Resource Sharing
Toady's telecom network architecture is moving towards resource
sharing concept, instead of each application/service to own
the resources required. One of the example is the Intelligent
Peripheral (IP) component in AIN (Advanced Intelligent Networks).
IP provides the voice resources required for any call-related
application, to any of the SSP/SCP (Service and Switching
Point/Service Control Point) in the network. This can access
these components. The logic for moving such a resource to
a separate component in network to allow sharing of resources
and easy definition of service logic. Similar to this there
are many other services which requires sharing of resources
like, Interactive Voice Response (IVR) applications, call
centres, conference bridges etc. If the service logic resides
somewhere else and the service resources concentrated on a
separate entity, it requires an interface protocol for communication
or for resource control.
1.4 Rapid Introduction of new Services
In case of traditional telecommunication network, any new
service development requires changes throughout the network
for the service logic to be supported at each and every node
in the network, since the service logic is embedded into each
and every node. The current AIN network architecture moves
the service logic away from service node and is being controlled
by a few service controls points in the network. As the demand
for new service in the market is high, the same reasoning
applies to other network domains as well, which requires the
service logic to be easily adaptable/introduced in the network
by changing the logic (or putting a new service) at a few
nodes in the network. Therefore for a fast and easy service
introduction in the market the service development may require
parallel development by many. This requires the interface
to be defined every time a new service is developed. If no
standard interface exists, a new local interface is used every
time a new service is defined.
1.5 Hierarchical Networks
Most of the toady's telecommunication networks have hierarchical
network configuration. This sometime requires different protocols
at different levels. The need for different protocol for network
management, signalling control, node management or even for
service management, if the network node has a different perspective
view of the nodes below it in the hierarchy or for the nodes
it is controlling. However, if each node in the network views
the other node that it is controlling or managing, as resource
pool and the interface between them is the resource control
protocol, the interface at all levels is uniform. This definition
can be extended even to lower levels of communication, like
signalling protocol layers talking to hardware which is implemented
as RP and protocol control entity as RPC. Another example
can be the voice application (media control applications)
controlling the media control provided by hardware or firmware,
if media acts as RP and control application as RPC. If this
protocol provide uniform interface at all levels, then each
entity in the network needs to define the resources it hold
and the capability of each such resource. The resource control
entity needs to use this interface to control these resources
to provide the desired service in the network.
The requirements from Resource Control Protocol are listed
below -
Interface protocol definition to be simple and generic.
Definition needs to be standardised.
Definition of protocol to be defined as binary protocol
not text based (Being an application level protocol it may
use ASN definition for protocol constructs).
Protocol needs to support resource advertising.
Protocol to support resource capabilities advertising.
Protocol to support controller redundancy.
Protocol to support service/logic/script execution by
resource pool, the service/script logic to be derived from
resource capability.
Protocol to support failure management of resources and
entities.
Protocol definition can be extended to support management
(configuration/ statistics/alarms) interface.
Protocol to support any resource control, where the resource
can be a hardware resource, software resource or even the
algorithms.
Examples of resources are bearer trunks in network, SS7 node
advertising SS7 signalling as resource and capability as enable/
disable signalling.
Protocol definition to support the hierarchical resource
configuration, which means that the resource pool may in
turn be controlling other resources by same protocol and
the same definition is applicable at all the interfaces.
Protocol definition should be extendable to support any
generic protocol embedded in it.
Protocol to be superset of any popular gateway control
protocol like MGCP, i.e. any capability/function supported
by MGCP to be there in this protocol as well.
Initial definition of protocol to provide support for
international network signalling protocols like SS7 etc.
and later definitions may provide support for other protocols.
However the definition of protocol to be generic to support
any interface, but first definition to give representative
cases/ examples for such protocols or network configurations.
Resource, is the entity in the resource pool which along
with the resource capabilities can be used by Resource Pool
Controller either independently or in combination with other
resource entities to execute a service. Resource can be any
hardware, software, physical or virtual resource. Example
of hardware resources are bearer trunks, interface cards etc.
Examples of software resources are signalling software, voice
processing software etc. Examples of physical resources are
hardware resources, circuits, subscriber lines etc. Examples
of virtual resources are the resources controlled by any Resource
Pool Controller but being advertised by it as holding them
as resources.
Resource Pool : RP, is the logical collection
of resources of similar kind or different kinds with the
capability to interface with RPC, advertise and execute
the resource capabilities on command from RPC.
Resource Capability: RC, is the detection,
generation or execution capability of the resources defined
above. Examples of RC are detection of line signals on line
interface, tone generation or detection capability. Resource
capability is always specified along with the resource identification.
Resource Capability Category: Capability
category determines whether the capability is of detection,
generation, and execution or combination type.
RPC: Resource Pool Controller, is the
entity, which controls the resource pool entity through
interface protocol RPCP. However the service logic or the
control logic is supported by the RPC.
RPCP: Resource Pool Control Protocol,
is a generic interface protocol between two entities, where
one entity acting as Resource Pool (RP) and other being
the Resource Pool Controller (RPC), however the RP entity
may in turn be acting as RPC for other RPs in a hierarchical
manner.
Control Interface: Control interface
is the interface between RP and RPC.
This section describes the protocol architecture and few
of the constructs needed to define protocol. Each of these
constructs will have definition of the protocol elements required
for it.
However this paper does not try to define the complete protocol.
4.1 Network Architecture
This protocol is an interface protocol between RP and RPC.
The connection at the logical level or protocol interaction
level is assumed to be of tree type as shown in following
picture.
Figure 1 RPCP Network Architecture
One RPC can be connected to many RPs whereas
each RP can get connected to only one RPC. This definition
however is applicable at logical level or the protocol interaction
level. Single physical entity may host more than one RP, whereas
each RP may be interfacing with different RPC for resource
control. Each of this RPs may then be treated as separate
RPs
Figure 2 Physical Interface between
RP and RPC
Figure 3 Logical level interface between
RP and RPC
RPCP protocol is an application level protocol. The protocol
definition today does not define the lower layers required
for the transport of protocol element/constructs between RP
and RPC. However the lower layer support or the communication
channel type required are listed below.
Non Real-Time Reliable Communication Channel.
Examples are TCP connections on ethernet, SCCP connections
in SS7 networks etc. This channel is needed for protocol
construct, which do not have reliability defined with protocol.
However unreliable channel can be used instead with reliability
being handled by protocol.
Non Real-Time Unreliable Communication Channel.Examples are UDP connection on ethernet, high-
speed, local bus communication etc. This channel is used
for protocol constructs which have reliability defined with
protocol. However reliable channel can be used instead if
one available.
Real-Time Unreliable Communication Channel.Examples are RTP, RTCP channels as defined
by IETF RFCs, high speed local bus communication, circuit
switched communication etc. This channel is mostly used
for bearer data communication, which requires some real
time data transfer.
Each of the protocol constructs defined in later sections
will specify along with the definition, the type of lower
layer channel required.
5.1 Basic Protocol Definition
RPCP protocol supports three basic categories of protocol
constructs
- Service Execution constructs
- Node/Protocol Management constructs
- Transparent mode support
Service execution related constructs support resource and
capability advertising by RP to RPC and service execution
logic construct by RPC to RP. The results or updates are sent
in either direction. Initially each RP when it comes up, after
local initialisation it advertises its resource and resource
capability to RPC (if required). Once the resources and its
capabilities are known to RPC, it can send service or control
logic to RP for service execution. The events, results or
errors of service execution are returned by RP to RPC. Any
execution update or premature termination of execution is
sent from RPC to RP.
Figure 4 Service execution constructs
Node or Protocol management constructs supports the configuration
download, statistics alarm reporting, protocol status and
node management constructs. The direction of flow is either
direction, i.e. updates from RP to RPC and requests from RPC
to RPs.
Figure 5 Node, Protocol Management
constructs
Transparent mode constructs support two basic categories,
protocol data transfer and real time data transfer. Protocol
data transfer constructs are used to support any network protocol
transparently.
Real-time data transfer is used to have real-time bearer
or signalling data transfer.
This section defines protocol constructs related to service
execution with brief description along with the basic elements
for each construct, direction of information flow and type
of lower layer support.
1. Res_Cap_Update_req
Direction: RP to RPC Channel Required: Non Real-Time unreliable
channel. Elements: Update_id, Data_size, Duplicate_id Description: This protocol construct is used
by RP, when it comes up or at any configuration change, to
send a request to RPC for resource and capability advertising.
The update_id is the resource and capability database id.
It is used by RPC to check if no updates are required. Data
size is used to give RPC an estimate of total volume of resource
and capability database size. Duplicate_id is used, if RP
is exact duplicate of some other RP in terms of resource and
capability database (this is managed by local management entity).
This construct is repeated, if no acknowledgement is received
after the configurable protocol timer expires.
2. Res_Cap_Update_ack
Direction: RPC to RP Channel Required: Non Real-Time unreliable
channel. Elements: Update_mode, Delay Description: This protocol construct is used
by RPC to respond to RP's request for update. The Update mode
returned by RPC tells RP whether to send the update, delay
sending update or there is no need for the update. RPC based
on the duplicate_id, data_size and the update_id decides whether
to take the update now, delay it or no need for update (as
it has the most recent update). The delay parameter is used
when RPC tells RP to reattempt the request and specify the
delay amount, in seconds.
3. Res_Advertize
Direction: RP to RPC Channel Required: Non Real-Time Reliable
channel. Elements: Resource_id Structure Description: This protocol construct is used
by RP to update RPC with the resources available at RP in
case the RPC update is not the recent one. The Resource id
structure describes each resource with its id. This construct
is used to advertise only those resources, which needs to
be controlled by RPC.
4. Cap_Advertize
Direction: RP to RPC Channel Required: Non Real-Time Reliable
channel. Elements: Capability_id Structure Description: This protocol construct is used
by RP to update RPC with the resources capabilities available
at RP in case the RPC update is not the recent one. The Capability
id structure describes each resource capability along with
the capability category.
5. End_Advertize
Direction: RP to RPC Channel Required: Non Real-Time Reliable
channel. Elements: Record count Description: This protocol construct is used
by RP to tell RPC the end of advertising, and sends a record
count parameter. Record count parameter is used by RPC to
compare the records received with that sent by RP.
6. Execute_Logic
Direction: RPC to RP Channel Required: Non Real-Time Unreliable
channel. Elements: Update, logic_id, Update_frequency,
Execution logic Description: This protocol construct is used
by RPC to either update the RPs logic database or to request
RP to execute the service logic. If update flag is set to
update and execute, RP updates the database with execution
logic and then executes it. However if it says either executes
or Update, the service logic is executed and not updated in
database or Updated and not executed. The execution logic
defines the service logic including the resources and using
simple constructs based on the resource capability and its
category. Where category as defined before can be detection,
execution, generation or combination of these.The service
logic constructs include simple constructs like if, then,
else or loops like while, for etc. Update Frequency is used
by RPC to tell RP the frequency with which to update the status
of execution. It can be in terms of time or execution steps
etc. Example use of update_frequency are to report statistics
periodically, report alarms or update the status of execution
logic to RPC after each execution step.
7. Logic_Update
Direction: RPC to RP Channel Required: Non Real-Time Unreliable
channel. Elements: logic_id, Update_type, Execution_logic,
Update_frequency Description: This protocol construct is used
by RPC to either update the RP's current execution or terminate
it. The termination can be either graceful or abrupt, which
will be defined by this parameter. If logic is updated, RP
either starts re-executing the logic as specified by Execution_logic
parameter or adds to the current executing logic.
8. Result_Report
Direction: RP to RPC Channel Required: Non Real-Time reliable
channel. Elements: Logic_id, Result Structure Description: This protocol construct is used
by RP to update the status of execution to RPC, as specified
in Execute_logic by Update_frequency.
9. Event_Report
Direction: RP to RPC Channel Required: Non Real-Time reliable
channel. Elements: logic_id, Event Structure Description: This protocol construct is used
by RP to update the events, as reported by detection resources,
to RPC.
10. Error_Report
Direction: RP to RPC Channel Required: Non Real-Time reliable
channel. Elements: logic_id, Error Structure Description: This protocol construct is used
by RP to report any error during execution of service logic
for logic_id .
RPCP can provide a uniform interface protocol between different
network entities(signalling controllers, call agents, network
management centres etc.) if each of such entity defines the
resources and capabilities and identifies the resource controllers.
Different vendors can produce Resource pools and Pool Controllers
if the interface agreed upon is standard, flexible and open.
Media Gateway Control Protocol(MGCP), IETF Internet Draft
Bay Networks SS7-Internet Access Signalling Protocol, ITU-T
Q Series Recommendation Q.121x, Intelligent Networks Interface
Recommendation for Intelligent Network CS-1 ITU-T Q Series
Recommendation Q.122x, Intelligent Networks Interface Recommendation
for Intelligent Network CS-2 ITU-T Q Series Recommendation
Q.76x, SS7 ISDN User Part of Signalling System No. 7 ITU-T
H Series Recommendation H.323, Visual Telephone Systems and
Equipment for Local Area Networks which provides a Non-Guaranteed
Quality of Service ITU-T H Series Recommendation H.225, Call
Signalling Protocols and Media Stream Packetization for Packet
Based Multimedia Communications Systems ITU-T H Series Recommendation
H.245, Line Transmission of Non-Telephone Signals Schulzrinne
H., Casner S., Frederick R. and Jacobson, RTP: A Transport
Protocol for Real-Time Applications", RFC 1889, January
1996 Schulzrinne H., "RTP Profile for Audio and Video
Conferences with Minimal Control, RFC 1890, January 1996
Example of Protocol Use This section gives two examples,
each using RPCP to achieve the service execution. These two
examples are linked and the RPC of first becomes RP for the
second example.
A.1.1 Example1
The section on need for RPCP describes the new architecture
for telecom components with intelligence being moved away
from switching fabric. The first example is based on such
architecture.
In this example RP is the switching fabric and RPC is the
signalling and call agent.
Figure 7
The configuration of resource and its capability may be known
to RPC but if not, these are exchanged through protocol message
between two. Following resources and capabilities are assumed
Resources:
Bearer Circuits/Signalling Circuits/Switching Hardware or
Firmware/Echo Cancellation Firmware
Capabilities:
Bearer Circuits can be switched/Echo Cancellation can be applied
to any Bearer circuit/Signalling Data can be extracted from
Signalling Circuits and passed to RPC.
Figure 8
RPC sending a logic execution message to RP for signalling
circuits to be switched and data to be extracted.
Figure 9
All SS7 signalling traffic will be send to RPC by RP using
the real-time communication channel(it can be any connection
type between RP and RPC, a local high-speed bus, high-speed
ethernet etc.). RPC executing the SS7 Protocol, if required
to use bearer circuits or apply echo cancellation on these
circuits, will issue such command by another service execute
logic to RP. The switching of bearer circuits is controlled
by RPC using execute service logic command to RP.
Figure 10
Figure 11
For any error, like hardware failure for signalling
channels, it will be reported to RPC using error report.
Figure 12
A.1.2 Example2
In this example we will consider the RPC described
above as the RP for a network management station, which is
acting as RPC.
Figure 13
Resources:
SS7 Signalling.
Capabilities: Enable/Disable SS7 Signalling, Reporting Signalling
Statistics, Reporting Alarms, Generating Call Records etc.
RPC may initially download the configuration data to RP,
if required.
Figure 14
RPC will send an execute logic command to enable
the SS7 signalling on RP and send the logic to update execution
results by setting the frequency of update for statistics,
alarms and call records.
Figure 15
The RP will send updates to RPC for statistics
with the frequency specified and send any alarms as events
to RPC, generate Call records and update RPC at the frequency
specified.
Figure 16
Figure 17
In this example SS7 node (RP) in turn be using RPCP to control
the switching fabric to achieve the SS7 signalling capability.
This shows the hierarchical application of RPCP protocol.
