attached to an AN. The following list contains the possible values
for the EFA as defined by V5:
Definition Value
---------- ------
ISDN_PROTOCOL 0 - 8175
PSTN_PROTOCOL 8176
CONTROL_PROTOCOL 8177
BCC_PROTOCOL 8178
PROT_PROTOCOL 8179
LINK_CONTROL_PROTOCOL 8180
RESERVED 8181 - 8191
For MPH messages which do not use DLCI and EFA, SAPI, TEI and EFA
SHALL be set to ZERO and SHALL be ignored by the receiver. For all
other messages, the DLCI SHALL be set as defined in the V5.2 standard
[2].
The Interface Identifier SHALL follow the naming conventions for the
Interface Identifier as defined below.
4.2. V5 Naming Conventions for Interface Identifier
The V5 standard demands that V5 System Management keep track of the
states of all links on a V5 interface. To perform tasks like
protection switching and bearer channel allocation on the V5 links,
it is necessary that system management has the full picture of the
signaling and bearer channels located on each link.
The IUA protocol identifies C-channels by endpoints without a defined
association with a specific link. Since no naming convention exists,
there is no guarantee that a C-channel is actually located at the
link it claims to be. Furthermore the V5 standard requires that the
MGC receives reports of the status of all links, and it defines a
link identification procedure to ensure that AN and LE are
referencing the same link when they address a link with a Link
Control Protocol message.
It would clearly be against the concept of V5.2 if there was no clear
association between E1 links and channels. To solve this problem, a
naming convention MUST be used for V5UA.
The format of the integer formatted Interface Identifier is shown
below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Identifier | Chnl ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link Identifier - Identifier for an E1 link on the SG (27 bits).
MUST be unique on the SG. This Link Identifier MUST match the
Link Identifier used in the Link Management Messages defined later
in this document.
Chnl ID - Channel Identifier (5 bits). This is equal to the time-
slot number of the addressed time slot. Possible values are 15,
16 and 31 representing the possible time slots for C-channels on a
V5 interface. For Link Management Messages, the Chnl ID MUST be
set to 0. All other values are reserved for future use.
If used, the text formatted interface identifier SHALL be coded as
the hex representation of the integer formatted interface identifier,
written as a variable length string.
4.3. V5 Additions to IUA Boundary Primitives
Some primitives for the V5 interface boundaries are similar to the
Q.921/Q.931 boundary primitive messages defined in IUA, but they need
to be handled in a different way. Therefore it is neccessary to
distinguish between these two message types by means of the Message
Class parameter.
For all V5 interface boundary primitives, a new Message Class is
introduced:
14 V5 Boundary Primitives Transport
Messages (V5PTM)
Other valid message classes for V5UA, which are also used by IUA,
are:
0 Management (MGMT) Message
3 ASP State Maintenance (ASPSM) Messages
4 ASP Traffic Maintenance (ASPTM) Messages
Q.921/Q.931 boundary primitive messages reused by V5.2 as V5PTM
messages are:
1 Data Request Message (MGC -> SG)
2 Data Indication Message (SG -> MGC)
3 Unit Data Request Message (MGC -> SG)
4 Unit Data Indication Message (SG -> MGC)
5 Establish Request (MGC -> SG)
6 Establish Confirm (SG -> MGC)
7 Establish Indication (SG -> MGC)
8 Release Request (MGC -> SG)
9 Release Confirm (SG -> MGC)
10 Release Indication (SG -> MGC)
All these messages are defined similarly to the QPTM messages.
In addition, new boundary primitive messages are defined:
11 Link Status Start Reporting (MGC -> SG)
12 Link Status Stop Reporting (MGC -> SG)
13 Link Status Indication (SG -> MGC)
14 Sa-Bit Set Request (MGC -> SG)
15 Sa-Bit Set Confirm (SG -> MGC)
16 Sa-Bit Status Request (MGC -> SG)
17 Sa-Bit Status Indication (SG -> MGC)
18 Error Indication (SG -> MGC)
4.4. Link Status Messages (Start Reporting, Stop Reporting, Indication)
The Link Status Messages are used between V5 System Management on the
MGC and the L1 FSM on the SG to track the status of a particular E1
link. This is required whether or not the E1 link carries
C-channels.
All Link Status Messages contain the V5UA Message Header. The Link
Identifier portion of the Interface Identifier identifies the
physical link on the SG addressed by the message. For all link
status messages, the Chnl ID SHALL be set to ’0’ and SHALL be ignored
by the receiver.
The integer value used for the Link Identifier is of local
significance only, and is coordinated between the SG and MGC. It
MUST be unique for every V5 link on the SG.
As defined by the V5 standards, V5 System Management must know the
status of the links on all active V5 interfaces. The Link Status
Start Reporting Message is used by V5 System Management on the MGC to
request that the L1 FSM on the SG starts reporting the status of a
particular link.
V5 system management SHALL send this Message on interface activation
for all links on the interface. The SG SHALL respond immediately to
this request with a Link Status Indication message, and it SHALL then
send a Link Status Indication message on all subsequent changes of
the link status. Since the SG has no other way to determine whether
a link is on an active interface or not, this message SHALL always be
sent on interface startup.
If the L1 FSM in the SG receives a Link Status Start Reporting
Message for a link that is already active (the link status is
reported to System Management), the SG SHALL immediately report the
actual status of this link by sending a Link Status Indication
Message. The SG SHALL then proceed with the automatic link status
reporting as described above.
To stop this reporting of the status of a link, e.g., at interface
deactivation, System Management sends a Link Status Stop Reporting
Message to the L1 FSM. The SG will then immediately stop reporting
the status of the particular link and will assume the link to be out
of service. It MUST NOT respond in any way to this message.
Since there is no other way for the SG to know that an interface has
been deactivated, this message SHALL be sent on interface
deactivation for all links on the interface. On reception of this
message, the SG SHALL take L2 down on this link.
If the L1 FSM in the SG receives a Link Status Stop Reporting Message
for a link that is not active (the link status is not reported to
System Management), the SG SHALL ignore the message.
The Link Status Start/Stop Reporting Messages contain the common
message header followed by the V5UA message header. They do not
contain any additional parameters.
The Link Status Indication Message is used by L1 FSM in the SG in
response to a Link Status Start Reporting Message to indicate the
status of the particular link. After a Link Status Start Reporting
Message has been received by the L1 FSM, it SHALL automatically send
a Link Status Indication Message every time the status of the
particular link changes. It SHALL not stop this reporting until it
receives a Link Status Stop Report Message from System Management.
The Link Status Indication Message contains the common message header
followed by the V5UA message header. In addition, it contains the
following link status parameter:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x82) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Link Status are shown in the following table:
Define Value Description
OPERATIONAL 0x0 Link operational
NON-OPERATIONAL 0x1 Link not operational
4.5. Sa-Bit Messages (Set Request, Set Confirm, Status Request,
Status Indication)
The Sa-Bit Messages are used between V5 System Management in the MGC
and the L1 FSM in the SG to set and read the status of Sa bits on the
E1 links. For V5, it is only required to set and read the status of
the Sa7 bit that is used for the Link Identification procedure as
described by the V5 standards [3].
All Sa-Bit Messages SHALL contain the V5UA message header. The Link
Identifier portion of the Interface Identifier identifies the
physical link on the SG addressed by the message. For all link
status messages, the Chnl ID SHALL be set to ’0’ and SHALL be ignored
by the receiver.
The Link Identifier MUST be the same as used in the Interface
Identifier to identify on which link a C-channel is located.
The Sa-Bit Set Request message is used to set the value of the
specified Sa-Bit on the defined link. The value of the Sa7 bit in
normal operation is ONE. For the Link Identification procedure, it
is set to ZERO.
The Sa-Bit Set Request message for the Sa7 bit with Bit Value ZERO
corresponds to the V5 defined primitive MPH-ID. The Sa-Bit Set
Request message for the Sa7 bit with Bit Value ONE corresponds to the
V5 defined primitive MPH-NOR.
The SG MUST answer a Sa-Bit Set Request message with a Sa-Bit Set
Confirm message when the setting of the bit is complete. This
message does not correspond to a V5 defined primitive.
The Sa-Bit Status Request message is used by system management to
request the status of the specified Sa-Bit on the defined link from
L1 FSM. The Sa-Bit Status Request message for the Sa7 bit
corresponds to the V5 defined primitive MPH-IDR.
L1 FSM answers the Sa-Bit Status request message by a Sa-Bit Status
Indication message in which the current setting of the bit will be
reported. The Sa-Bit Status Indication message for the Sa7 bit with
Bit Value ZERO corresponds to the V5 defined primitive MPH-IDI. The
Sa-Bit Status Indication message for the Sa7 bit with Bit Value ONE
corresponds to the V5 defined primitive MPH-Elg.
All Sa-Bit Messages contain the following additional parameter:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x83) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BIT ID | Bit Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Bit Value are shown in the following table:
Define Value Description
ZERO 0x0 Bit value ZERO
ONE 0x1 Bit value ONE
The valid value for BIT ID is shown in the following table:
Define Value Description
Sa7 0x7 Addresses the Sa7 bit
There are no other valid values for V5UA. All other values are
reserved for future use.
For the Sa-Bit Status Request and Set Confirm messages, the BIT Value
SHALL be set to ’0’ by the sender and SHALL be ignored by the
receiver.
4.6. Error Indication Message
The Error Indication Message is used between the V5 stack on the SG
and the V5 System Management in the MGC to indicate an error
condition at the SG.
The only valid reason for the Error Indication Message is Overload.
The SG SHOULD issue such an Error Indication with reason Overload for
a C-channel if it is not able to process all Layer 3 messages on this
C-channel in a timely manner (overload condition of the C-channel).
The Error Indication message SHALL contain the V5UA message header.
The Interface Identifier indicates the affected C-channel. SAPI, TEI
and EFA SHALL be set to ’0’ and SHALL be ignored by the receiver.
The Error Indication message contains the following additional
parameter:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x84) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Error Reason are shown in the following table:
Define Value Description
OVERLOAD 0x1 C-channel is in overload state
There are no other valid values for V5UA. All other values are
reserved for future use.
5. Procedures
5.1. V5 Layer 1 failure
The normal way to handle a V5 Layer 1 failure is described in the V5
standards[2,3] as follows:
- The L1 FSM detects the V5 Layer 1 failure. It reports this to
V5 System management by sending a MPH-DI primitive for the
affected link.
- V5 System management notifies V5 Layer 2 of the V5 Layer 1
outage by sending a MPH-Layer_1 Failure Ind primitive.
Since V5 Layer1/2 and V5 System Management are no longer co-located
in the backhaul architecture, it does not make sense to notify V5
Layer 2 about V5 Layer 1 failure via V5 system management. Instead,
V5 Layer 2 SHALL be notified directly by V5 Layer 1 on the SG. V5
Layer 1 SHALL report the outage to V5 system management by sending a
Link Status Indication message with status NON-OPERATIONAL,
corresponding to an MPH-DI primitive as defined by the V5.2 standard.
V5 system management SHALL NOT send an MPH-Layer_1 Failure Ind
primitive to V5 Layer 2 in response to this message.
5.2. Loss of V5UA peer
If SCTP failure is detected or the heartbeat is lost, the following
procedure SHALL be performed:
When loss of V5UA peer is reported to the V5UA layer, the ASP SHALL
behave as if it had received a Link Status Indication (non-
operational) for all links on this SG.
The ASP SHALL attempt to re-establish the connection continuously.
When the connection is re-established, the ASP SHALL send a Link
Status Start Reporting message to the SG for all links on active V5
interfaces on the SG.
An example for the message flow for re-establishment of the
connection is shown below for one active link on the SG:
ASP SG
| |
| -------- Link Status Start Reporting ---------> |
| |
| <------ Link Status Ind (operational) --------- |
| |
If the association can be re-established before the V5UA layer is
notified, communication SHALL proceed as usual and no other action
SHALL be taken by the ASP.
5.3. C-channel overload on SG
If the SG detects an overload condition on a C-channel, it SHOULD
indicate this by sending an Error Indication message, with the reason
Overload to the MGC. The MGC SHOULD then take appropriate actions to
clear this overload condition.
The SG SHALL resend the Error Indication message with the reason
Overload as long as the overload condition persists. An interval of
120 seconds for resend of this message is RECOMMENDED.
6. Examples
6.1. Link Identification Procedure (successful)
The Link Identification Procedures themselves are described by the
V5.2 standard [3].
A message flow example for an LE initiated Link Identification
procedure over V5UA is shown below. An active association between
ASP and SG is established prior to the following message flows, and
the V5 interface is already in service:
ASP SG
| |
| ------ Data Request (LnkCtrl: FE-IDReq) ------> |
| <-- Data Indication (LnkCtrl Ack: FE-IDReq) --- |
| |
| <---- Data Indication (LnkCtrl: FE-IDAck) ----- |
| ---- Data Request (LnkCtrl Ack: FE-IDAck) ----> |
| |
| ------ Sa-Bit Status Request ( Sa7 ) ---------> |
| <--- Sa-Bit Status Indication ( Sa7, ZERO ) --- |
| |
| ------- Data Request (LnkCtrl: FE-IDRel) -----> |
| <--- Data Indication (LnkCtrl Ack: FE-IDRel) -- |
| |
The next example also shows a Link Identification procedure, but this
time it is initiated by the AN. Again, the ASP association and the
V5 interface are already in service:
ASP SG
| |
| <---- Data Indication (LnkCtrl: FE-IDReq) ----- |
| -- Data Request (LnkCtrl Ack: FE-IDReq) ------> |
| |
| ---------- Sa-Bit Set Req ( Sa7, ZERO ) ------> |
| <--------- Sa-Bit Set Conf (Sa7) -------------- |
| |
| ------- Data Request (LnkCtrl: FE-IDAck) -----> |
| <-- Data Indication (LnkCtrl Ack: FE-IDAck) --- |
| |
| <---- Data Indication (LnkCtrl: FE-IDRel) ----- |
| ---- Data Request (LnkCtrl Ack: FE-IDRel) ----> |
| |
| ------------ Sa-Bit Set Req ( Sa7, ONE ) -----> |
| <----------- Sa-Bit Set Conf (Sa 7) ----------- |
| |
7. Security Considerations
The security considerations discussed for the ’Security
Considerations for SIGTRAN Protocols’ [5] document apply to this
document.
8. IANA Considerations
8.1. SCTP Payload Protocol Identifiers
IANA has assigned a V5UA value for the Payload Protocol Identifier in
the SCTP DATA chunk. The following SCTP Payload Protocol identifier
is registered:
V5UA "6"
The SCTP Payload Protocol identifier value "6" SHOULD be included in
each SCTP DATA chunk to indicate that the SCTP is carrying the V5UA
protocol. The value "0" (unspecified) is also allowed but any other
values MUST not be used. This Payload Protocol Identifier is not
directly used by SCTP but MAY be used by certain network entities to