V5 Interface specifies the physical, procedural
and protocol requirements for interfaces between Access Network
(AN) and Local Exchange (LE). The V5 specification is split
into two types.
V5.1 interface supports only one E1 link whereas V5.2 may
use up to sixteen (16) E1 links on one interface. Association
of bearer channel to user ports in V5.1 interface shall be
provisioned and the equipment may have a pre-defined association
of bearer channels to user ports. V5.2 adds to V5.1 ability
by allocating the timeslots on E1-link to user ports on demand
via a Bearer Channel Control (BCC) protocol.
ITU-T has a series of recommendations describing
the V reference points. Reference points V1 through V4 are
defined, and they apply for different configurations of the
Access Digital Section. Loosely speaking, they are all reference
points in an archiecture where ISDN traffic is carried through
an Access Network to a Local Exchange. V5 is one of these,
and is the most comprehensive of the lot. V5.1 was named that
way because it was informally seen as a kind of a 'prototype',
while V5.2 was the full-fledged interface..
The evolution of V5 standards provides the standard
interface between the Access Network and Local Exchange. User
ports (PSTN/ISDN) interface terminates on the AN instead of
directly terminating on the LE (Local Exchange). Access Network
provides the narrow-band services to the users ports connected
to it. Call control responsibility still resides at the Local
Exchange. .
Q. What are the major
differences between V5.1 interface and V5.2 interface?
The V5.1 ETS (ETS 300 324-1) is a complete ETS
in itself whereas this V5.2 ETS
(ETS 300 347-1) references parts of ETS 300 324-1.
V5.1 uses only one 2.048 kbit/s link whereas V5.2 may use
up to sixteen (16) 2.048 kbit/s links on one interface.
V5.1 does not support concentration whereas V5.2 is inherently
designed to support it using a dedicated protocol known as
the Bearer Channel Connection (BCC) protocol.
V5.1 does not support ISDN primary rate access user ports
whereas V5.2 does. V5.1 has no concept of communication channel
protection whereas this function is available for V5.2 when
that particular V5.2 interface uses more than one 2.048 kbit/s
link. A specific protocol, known as the protection
protocol, is provisioned for this function.
Semi-permanent leased lines pass through the
V5.2 interface. For the V5.2 interface where the connection
for all bearer channels is established between the user port
of the AN and the LE by the BCC, no additional procedure between
the LE and the AN is required for the support of semi-permanent
leased lines. These are provisioned via Qle.
In the event of the 2.048 Kbit/s link on which the semipermanent
line is provided becoming faulty, the resource management
entity establishes another path for this line.
The V5.2 BCC protocol provides the means for
the LE to request the AN to establish and release connections
between specified AN user ports and specified V5.2 interface
time slots. It enables V5.2 interface bearer channels to be
allocated or deallocated by independent processes (on a per
call, preconnected or semi-permanent basis).
This is exactly what 'pre-connected bearer channel'
is all about. The situation here would be that a Police Station
connected to a Local Exchange through an Access Network, and
you want that a call that comes in for that 911 number to
the LE should not get rejected because there are no bearer
channels available on the V5 interface. For such a situation,
the user port corresponding to the 911 number would be pre-connected
to the Local Exchange, so that a bearer channel timeslot for
it is always reserved on the V5 interface.
Q. What is the least
# of V5 communication channels that is needed for 16 E1 links
i.e is the 16th slot on primary (protected by secondary) enough
to carry all V5 signaling needed for maintaining 16 E1 links?
If there is no ISDN traffic, then yes, TS 16
on primary (protected by TS 16 on secondary) is enough to
carry all the signalling. Actually, the number of E1 links
doesn't really come into the picture, because increasing the
number of links won't directly increase the V5 signaling traffic
(unless the links are constantly being locked and unlocked,
which is a pretty unlikely scenario). The amount of V5 traffic
depends on the number of calls being made. Increasing the
number of links increases the number of calls that can be
made simultaneously (since more bearer channel timeslots are
available), so that is the only impact it has on traffic volume.
If ISDN is included, the picture changes, because each ISDN
port adds to the signalling traffic on the V5 interface. As
per the market study it is found that if no F type (frame)
data is being carried, then one communication channel is enough
to carry the packet and D-chanel signalling (p-type and ds-type)
date of 124 ISDN ports. So, add one communication channel
for every 124 ISDN ports, that is the suggested level of concentration.
Note, these are empirical values. The protocol doesn't place
any restrictions, so one is allowed to carry any amount of
signalling data just on TS 16 of the primary. The other extreme
- since an ISDN-BA port has a 16 kbps D-channel, add one communication
channel for every 4 ISDN ports - that results in no concentration
for ISDN signaling.
Q. What is
the functionality of Protection Protocol?
In order to improve the reliability of the V5.2
interface, protection procedures for the switch-over of communication
paths under failure is provided.
A single V5.2 interface may consist of up to sixteen (16)
2.048 kbit/s links. According to the protocol architecture
and multiplexing structure a communication path may carry
information associated to several 2.048 kbit/s links ( non-associated
information transfer). The failure of a communication path
could therefore impact the service of a large number of customers
in an unacceptable way. This is in particular true for the
BCC protocol, the control protocol, and the link control protocol,
where all user ports are affected in case of a failure of
the relevant communication path.
A protection switch over may either be triggered
autonomously by the system management in the LE or AN as result
of a fault detection or link blocking procedure, or by the
operator(s) via the Qle and Qan operator(s) via Qan or Qle
interface.
Porting to new OS should require no change to
stack code. The OS services are required by the stack are
broadly classified into Memory Management, Timer Service and
IPC services. No OS service is directly requested by the stack
code. All the OS services will be invoked through the well-defined
function calls interface. These functions will be passed the
general parameters that are typically needed by the OS to
perform the service. As a porting effort only these function
calls has to be translated into the OS system call depending
upon the OS used.
Aricent has developed modular and
portable stack for V5 AN and LE applications, conforming to
the ETSI and ITU-T standards. The following products are available:
V5.1 AN application with System Management.
V5.2 AN (includes V5.1) application
with System Management.
V5.1 LE application with System Management.
V5.2 LE (includes
V5.1) application with System Management.
Each product is available with the following
deliverables:
Source Code in C language for PSTN,
BCC, Link Control, Control, Protection, LAPV5 and System
Management (In case of V5.1, only PSTN, Control, LAPV5 and
System Management )
Q.
What are the features of Aricent V5 product family?
The key functionality’s can be briefly
listed as follows:
The stack (and each constituent entity)
provides the functionality for handling one or more than
one V5.x interfaces.
Modular architecture
The complete V5.x protocol stack is
capable of execution on a multi-processor target environment
by distributing various entities across various subsystems.
Each stack entity is capable of execution
in a multi-tasking or single thread of control operating
environment.
The message processing is done under
entity’s own thread of control. There is a minimal
real-time overhead on the calling application’s
thread of control.
There is single entry point for
Message delivery from the call control
application or the peer VB5 entity.
V5 Core Engine, which parses and
processes the message and updates the finite state machine
(FSM), whenever required.
Communication between a stack entity
and the system is through the invocation of clearly defined
Application Programmer’s Interface (API). It is possible
to port the APIs to a message based or function based interface.
Portable on most of the embedded real
time operating systems such as pSOS, Vxworks etc. Porting
on a new platform requires changes to a few, clearly identified
modules.
The stack and each of its constituent
entity can be ported on platforms with redundancy for
the processor cards.
Capability for National Protocol Entity
Customization.
Q.
What is the testing strategy followed
for Aricent V5 stack product?
One of the key elements of the Protocol Development
Framework is the four-step testing strategy to ensure delivery
of reliable, error-free code which functions as per the specified
standards. The four steps involved in testing are
Code Unit Testing.
Conformance Testing using the standards
specified Abstract Test Suite.
Enhanced testing for functionality
not covered by the ATS.
Sample port on few targets and run-time
optimization.
Q.
Besides ATS, what additional testing steps does the product
go through?
There are several aspects of the V5 product,
which can not be tested just by executing the ATS. In this
testing step, the stack is ported on a system, available in-house
in the lab and tested for the following functions
OS failure and error handling.
Stack initialization and provisioning
failure.
Testing for Statistics and Trace functionality.
Integration and testing of the support
for redundancy.
Multiple V5 interfaces
Graceful recovery
Testing of a full connection establishment
scenario.
