V5 Protocols

The V5 protocol stack is used for the connection of an Access Network (AN) to a Local Exchange (LE). It is used for the following access methods:

• Analog telephone access.
• ISDN basic rate access.
• ISDN primary rate access (V5.2).
• Other analog or digital accesses for semi-permanent connections without associated outband signalling information.

V5 uses 2048 kbps links; V5.2 may use up to 16 such interface links. For analog access, on the LE side signalling from the PSTN user port is converted into a functional part of the V5 protocol for signalling to the AN side. For ISDN users a control protocol is defined in the V5 for the exchange of the individual functions and messages required for the coordination with the call control procedures in the Local Exchange.

In order to support more traffic and dynamic allocation of links, the V5.2 protocol has several additions:

• A bearer channel connection protocol establishes and de-establishes bearer connections required on demand, identified by the signalling information, under the control of the Local Exchange.
• A link control protocol is defined for the multi-link management to control link identification, link blocking and link failure conditions.
• A protection protocol, operated on two separate data links for security reasons, is defined to manage the protection switching of communication channels in case of link failures.

See SS7 for a description of SS7 protocols.
See Cellular for a description of GSM protocols.

The V5 and other telephony protocols are illustrated here in relation to the OSI model:
Click the protocols on the map to see more details.

LAPV5-EF

ITU G.964: http://www.itu.int/itudoc/itu-t/rec/g/g800up/g964.html

The V5 Envelope Function Sublayer exchanges information between the AN and the LE. The format of the frame is as follows:

Envelope function address
The envelope function address field consists of two octets. The format of the envelope function address field is shown here:

EF address
The envelope function address is a 13 bit number.

EA
The first bit of the envelope function address field is the Address Extension bit. The send bit of the first octet is set to 0.

FCS
Frame check sequence as defined in Section 2.1 of standard G.921.

Interested in more details about testing this protocol?

LAPV5-DL

ITU G.964: http://www.itu.int/itudoc/itu-t/rec/g/g800up/g964.html

The LAPV5 data link sublayer defines peer-to-peer exchanges of information between the AN and the LE. LAPV5-DL frames can be either with or without with an Information field. The format of these frames is shown here:

Link address
The V5 Data link address is a 13-bit number Values in the range of 0 up to 8175 shall not be used to identify a layer 3 protocol entity, because that range is used for identifying ISDN user ports.

Control
Identifies the type of frame which will be either a command or response. The control field contains sequence numbers, where applicable.

Information
An integer number of octets. The maximum number of octets in the information field is 260.

Interested in more details about testing this protocol?

V5-Link Control

ITU G.965: http://www.itu.int/itudoc/itu-t/rec/g/g800up/g965.html

The V5 Link Control Protocol is sent by the AN or the LE to convey information required for the coordination of the link control functions for each individual 2048 kbps link.

The format of the Link Control Protocol is as follows:

Protocol discriminator
Distinguishes between messages corresponding to one of the V5 protocols.

Layer 3 address
Identifies the layer 3 entity, within the V5.2 interface, to which the transmitted or received message applies.

Message type
Identifies the function of the message being sent or received. The message type may be LINK CONTROL or LINK CONTROL ACK.

Other Information Elements
The only IE for the Link Control Protocol is the Link Control Function. It's format is as follows:

Interested in more details about testing this protocol?

V5-BCC

ITU G.965: http://www.itu.int/itudoc/itu-t/rec/g/g800up/g965.html

The V5-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-interface time slots. It enables V5 interface bearer channels to be allocated or de-allocated by independent processes (on a per call, preconnected or semi-permanent basis). There may be more than one process active at any one time for a given user port.

The format of the BCC Protocol is as follows.

Protocol discriminator
Distinguishes between messages corresponding to one of the V5 protocols.

BCC Reference Number
The BCC Reference Number information element is specific for the BCC protocol and uses the location of the Layer 3 address information element within the general message structure as defined in Layer 3 protocols.
The BCC Reference Number identifies the BCC protocol process, within the V5.2 interface, to which the transmitted or received message applies.
The BCC reference number value is a random value generated by the entity (AN or LE) creating the new BCC protocol process (this random value is implemented as a sequential generation of values). It is essential that values are not repeated in messages for which a different BCC process is required (in the same direction), until the old BCC process has been finished and the number deleted. The BCC Reference Number information element, being part of the message header, shall be the second part of every message (located after the Protocol Discriminator information element). In the case of any process generating error indications, the BCC reference number should not be re-used until sufficient time has elapsed for delayed arrival of messages containing the same BCC reference number.
The length of the BCC Reference Number information element is 2 octets. Its format is shown here:

Source ID
One bit field specifying the entity (LE or AN) that has created the BCC reference number (i.e., the entity that has created the BCC protocol process). The coding of this field shall be zero for an LE created process and one for an AN created process.

BCC reference number value
13 bit field used for providing the binary coding that identifies the BCC process.

Message type
Identifies the function of the message being sent or received. Message types may be as follows:

• ALLOCATION
• ALLOCATION COMPLETE
• ALLOCATION REJECT
• DE-ALLOCATION
• DE-ALLOCATION COMPLETE
• DE-ALLOCATION REJECT
• AUDIT
• AUDIT COMPLETE
• AN FAULT
• AN FAULT ACKNOWLEDGE
• PROTOCOL ERROR

Other Information Elements
The following IEs are specific to BCC:

• User port identification
• ISDN port channel identification
• V5-time slot identification
• Multi-slot map
• Reject cause
• Protocol error cause
• Connection incomplete

Interested in more details about testing this protocol?

ITU G.964: http://www.itu.int/itudoc/itu-t/rec/g/g800up/g964.html

The signalling protocol specification and layer multiplexing PSTN protocol on the V5?interface is basically a stimulus protocol in that it does not control the call procedures in the AN, but rather transfers information about the analogue line state over the V5 interface. The V5-PSTN protocol is used in conjunction with the national protocol entity in the LE. The national protocol entity in the LE which is used for customer lines which are connected directly to the LE, is also used to control calls on customer lines which are connected via the V5-interface. For time critical sequences, it is necessary to extract certain signalling sequences (e.g., compelled sequences) from the national protocol entity into an ‘AN part’ of the national protocol entity. The V5-PSTN protocol has a relatively small functional part which is concerned with path setup, release of the path on the V5 interface, call collision resolution on the V5 interface and handling of new calls in case of overload conditions in the LE. The majority of line signals are not interpreted by the V5-PSTN protocol, but simply transferred transparently between the user port in the AN and national protocol entity in the LE.

The format of the header is shown in the following illustration:

Protocol discriminator
Distinguishes between messages corresponding to one of the V5 protocols. The value of the protocol discriminator for PSTN is 01001000.

Layer 3 address
This identifies the layer 3 entity, within the V5 interface to which the transmitted or received message applies.

Message type

• Identifies the function of the message being sent or received. Message types for PSTN may be as follows:
• ESTABLISH.
• ESTABLISH ACK.
• SIGNAL.
• SIGNAL ACK.
• STATUS.
• STATUS ENQUIRY.
• DISCONNECT.
• DISCONNECT COMPLETE.
• PROTOCOL PARAMETER.

• For PSTN the following information elements may appear:

Single Octet IEs:

• Pulse-notification.
• Line-information.
• State.
• Autonomous-signalling-sequence.
• Sequence-response.

Variable Length IEs:

• Sequence-number.
• Cadenced-ringing.
• Pulsed-signal.
• Steady-signal.
• Digit-signal.
• Recognition-time.
• Enable-autonomous-acknowledge.
• Disable-autonomous-acknowledge.
• Cause.
• Resource-unavailable.

Interested in more details about testing this protocol?

V5-Control

ITU G.964: http://www.itu.int/itudoc/itu-t/rec/g/g800up/g964.html

The structure of the V5-Control Protocol is shown below:

Protocol discriminator
Distinguishes between messages corresponding to one of the V5 protocols.

Layer 3 address
Identifies the layer 3 entity, within the V5.2 interface, to which the transmitted or received message applies.

Message type
Identifies the function of the message being sent or received. Message types for Control may be as follows:

• PORT CONTROL
• PORT CONTROL ACK
• COMMON CONTROL
• COMMON CONTROL ACK

Other Information Elements
For Control the following Information Elements may appear:
Single Octet IEs:

• Performance grading
• Rejection cause

Variable Length IEs

• Control function element
• Control function ID
• Variant Interface ID

Interested in more details about testing this protocol?

V5-Protection

ITU G.965: http://www.itu.int/itudoc/itu-t/rec/g/g800up/g965.html

A single V5 interface may consist of up to sixteen (16) 2048 kbps links. According to the protocol architecture and multiplexing structure a communication path may carry information associated to several 2048 kbps 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.

In order to improve the reliability of the V5 interface, protection procedures for the switch-over of communication paths under failur e are provided. The protection mechanisms are used to protect all active C-channels. The protection mechanism also protects the protection protocol C-path (itself) which is used to control the protection switch-over procedures. In addition, flags are continuously monitored on all physical C-channels (active and standby C-channels) in order to protect against failures which are not already detected by Layer 1 detection mechanisms. If a failure is detected on a standby C-channel the system management is notified and, as a result, will not switch a logical C-channel to that non-operational standby C-channel.

The structure of the V5-Protection Protocol is shown below:

Protocol discriminator
Distinguishes between messages corresponding to one of the V5 protocols.

Layer 3 address
Identifies the layer 3 entity, within the V5.2 interface, to which the transmitted or received message applies.

Message type
Identifies the function of the message being sent or received. Message types for the protection protocol may be as follows:

• SWITCH-OVER REQ
• SWITCH-OVER COM
• OS-SWITCH-OVER COM
• SWITCH-OVER ACK
• SWITCH-OVER REJECT
• PROTOCOL ERROR
• RESET SN COM
• RESET SN ACK

Other Information Elements
For the protection protocol, the following Information Elements may appear:

Variable Length IEs

• Sequence number
• Physical C-channel identification
• Rejection cause
• Protocol error cause

Interested in more details about testing this protocol?