3G SCNSIG

Switching Core Network Signalling

Training Document M13 BICC

13-459939 Issue 1.0 en

Nokia Networks Oy

1 (65)

The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This document is intended for the use of Nokia's customers only for the purposes of the agreement under which the document is submitted, and no part of it may be reproduced or transmitted in any form or means without the prior written permission of Nokia. The document has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia welcomes customer comments as part of the process of continuous development and improvement of the documentation. The information or statements given in this document concerning the suitability, capacity, or performance of the mentioned hardware or software products cannot be considered binding but shall be defined in the agreement made between Nokia and the customer. However, Nokia has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia will, if necessary, explain issues which may not be covered by the document. Nokia's liability for any errors in the document is limited to the documentary correction of errors. NOKIA WILL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THIS DOCUMENT OR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL (INCLUDING MONETARY LOSSES), that might arise from the use of this document or the information in it. This document and the product it describes are considered protected by copyright according to the applicable laws. NOKIA logo is a registered trademark of Nokia Oyj. Other product names mentioned in this document may be trademarks of their respective companies, and they are mentioned for identification purposes only. Copyright Nokia Oyj 2006. All rights reserved.

Contents
1 2 3 4 4.1 4.2 4.2.1 4.2.2 4.2.3 4.2.4 5 5.1 5.2 5.3 5.4 6 6.1 6.2 6.3 6.4 6.5 7 7.1 7.2 7.3 8 General ..................................................................................................... 4 BICC in 3G Rel. 4 ..................................................................................... 9 BICC messages ..................................................................................... 11 BICC message format ........................................................................... 14 BICC message format and codes (Q.1902.3) .......................................14 Application Transport Mechanism APM (Q.765.3) .............................16 Format of Application Transport Parameter (APP) ................................17 Encapsulated application information....................................................18 Transcoder Free Operation (TrFO) and Tandem Free Operation (TFO) ........................................................................................20 Bearer Control Information....................................................................21 Call-related BICC signalling procedures ............................................ 23 Successful call setup en block operation ...........................................23 Bearer setup procedures ......................................................................35 Answer and release procedures ...........................................................39 Additional BICC call setup procedures ..................................................44 BICC network features .......................................................................... 50 BICC segmentation...............................................................................50 Automatic repeat attempt ......................................................................51 Blocking and unblocking of CIC values .................................................52 CIC group query (national use) .............................................................53 Bearer Redirection and Crankback/Automatic Rerouting ......................55 Abnormal conditions ............................................................................ 56 Dual seizure..........................................................................................56 CIC and group reset procedures ...........................................................57 Unreasonable/unexpected/unrecognised signalling information ...........60 Automatic congestion control ............................................................. 63

Appendix: BICC timers .......................................................................................... 64

13-459939 Issue 1.0 en

Nokia Networks Oy

3 (65)

General
The Bearer Independent Call Control Protocol (BICC, ITU-T Q.1902) is a call control protocol designed to be able to transport call control signalling information, independent of the used bearer technology and signalling message transport technology. BICC accomplishes this by defining a set of procedures separately for call control signalling and bearer control signalling. The actual call control level signalling uses BICC, which is based on ISUP, and allows different protocols, such as AAL2 signalling, to be used for bearer control signalling. Signalling message transport independence means that BICC signalling can be transported over several different signalling transports such as MTP3, SSCOPMCE or SIGTRAN. Bearer independence means that the actual used media can thus be ATM, IP/Ethernet or something else. Since BICC is based on ISUP it provides natural interworking with ISUP and BICC networks and allows the existing supplementary services to be used without modifications. The BICC protocol is an adaptation of the ISUP protocol definition, but it is not peer-to-peer compatible with ISUP (see ITU-T Q.1912.1).

Figure 1.

Signalling Transport converters for BICC

The BICC protocol uses the Signalling Transport Converter (STC) layer for Signalling message transport. The Generic Signalling Transport Service is described in ITU-T Q.2150.0. The STCs are defined in other Recommendations in the Q.2150.x family of Recommendations. Several arrangements are possible for nodes that support BICC signalling. These nodes may have an associated Bearer Control Function (BCF) in which case they are referred to as Serving Nodes (SN). A node without an associated BCF is referred to as Call Mediation Node (CMN). Between Serving Nodes the control of bearers is provided by other protocols. In a Serving Node (SN), the Call Service Function and the Bearer Control Function (BCF) entities may be physically separated. The Call Bearer Control (CBC) signalling is used between these two entities in case of physical separation. The CBC protocol is specified in ITU-T Q.1950

SERVING NODE (SN) Call Control Signalling (BICC protocol or other signalling system) Call Control Signalling (BICC protocol or other signalling system)

Incoming procedures

Call Service Function (CSF)

Outgoing procedures

SCOPE OF THIS RECOMMENDATION

Call Bearer Control (CBC) signalling

BIWF
Bearer Control Signalling

BCF

Bearer Control Signalling

Bearer

T11111830-01

Figure 2 Signalling Functional Blocks in Serving Node (Q.1902) According to 3GPP rel.4 core network concept BICC protocol is to be implemented at Nc interface, between MSC servers and MSS GMSS. In the MSS concept the User Plane (bearer) and the Control Plane (signalling and call control) have been separated. There is a new Network Element (NE), Media Gateway (MGW), which takes care of the User Plane and the MSS controls it. MGW brings new media and functions which must be taken into account in call control signalling. For that reason Bearer Association Transport Application Service Element/Application Transport Mechanism (APM/BAT ASE) has been

13-459939 Issue 1.0 en

Nokia Networks Oy

5 (65)

introduced in BICC. Its main task is to transfer the bearer-specific information between the two MSSs on a Control Plane level. This feature implements the BICC CS2 signalling through the IP network

Figure 3

Core Network UMTS rel.4 interfaces

Table 1 lists the signalling capabilities supported by BICC for supplementary services. These capabilities are categorised into two classes: international and national use class.
Table 1.
Function/service (Basic Call) Speech/3.1 kHz audio 64 kbit/s unrestricted Multi-rate connection types (Note 1) N 64 kbit/s connection types En bloc address signalling Overlap address signalling Transit network selection Continuity check Forward transfer Simple segmentation Tones and announcements

Signalling capabilities supported by BICC (Q.1902.1)

National use / / / / / / / / / / International / / / / / / / / / / Supported Supported Supported Supported Supported Supported Nokia BICC Supported Supported Not supported

Function/service (Basic Call) Access delivery information Transportation of user teleservice information Suspend and resume Signalling procedures for connection type allowing fallback capability Propagation delay determination procedure Simplified echo control signalling procedures Automatic repeat attempt Blocking and unblocking of circuits and circuit groups Circuit group query Dual seizure Reset Receipt of unreasonable signalling information Compatibility procedure (BICC and BAT APM user application) ISUP signalling congestion control Automatic congestion control Interaction with INAP Unequipped circuit identification code User Part availability control MTP pause and resume Over length messages Temporary Alternative Routing (TAR) Collect call request procedure Hop counter procedure Hard to Reach Calling geodetic location procedure Carrier selection indication Codec negotiation and modification procedures Joint BIWF support Global Call Reference Procedure Out of band transport of DTMF tones and information / represents ITU-T support. represents ITU-T non-support.

National use / / / / / / / / / / / / / Note 2 / / / Note 3 Note 2 / / / / / / / / / / /

International / / / / / / / / / / / / Note 2 / / Note 3 Note 2 / / / / / / / / / /

Nokia BICC Supported Supported Supported Not supported Partly supported Supported Supported Supported Supported

Supported Supported Supported

Supported

Supported Not supported Supported Supported Not supported Not supported Supported Not supported Not supported Supported Partly supported

Supported

Note 1 Multi-rate connection types are 2 64, 384, 1536 and 1920 kbit/s. Note 2 - If BICC is deployed on an MTP3 or MTP3b signalling transport service, these functions are provided by the STC sublayer as described in ITUT Q.2150. Note 3 - If BICC is deployed on an MTP3 or MTP3b signalling transport service, an equivalent procedure is provided by the STC sublayer as described in ITU-T Q.2150.1.

13-459939 Issue 1.0 en

Nokia Networks Oy

7 (65)

Table 2.
Function/service

Signalling procedures for supplementary services

National use International Nokia BICC

Generic signalling procedures for supplementary services End-to-end signalling pass along method End-to-end signalling SCCP connection orientated End-to-end signalling SCCP connectionless Generic number transfer Generic digit transfer Generic notification procedure Service activation Remote Operations Service (ROSE) capability Network specific facilities Supplementary services Direct-Dialling-In (DDI) Multiple Subscriber Number (MSN) Calling Line Identification Presentation (CLIP) Calling Line Identification Restriction (CLIR) Connected Line Identification Presentation (COLP) Connected Line Identification Restriction (COLR) Malicious Call Identification (MCID) Sub-addressing (SUB) Call Forwarding Busy (CFB) Call Forwarding No Reply (CFNR) Call Forwarding Unconditional (CFU) Call deflection Call Waiting (CW) Call HOLD (HOLD) Conference calling (CONF) Three-Party Service (3PTY) Closed User Group (CUG) Multi level precedence and pre-emption Completion of Calls to Busy Subscribers (CCBS) Explicit Call Transfer (ECT) Call completion on No Reply ETSI mobile number portability Advanced Call Drop Back for VMS interface User-to-User Signalling (UUS) / represents ITU-T support. represents ITU-T non-support / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / Partly supported Partly supported Supported Supported Supported Supported Partly supported Partly supported Supported Supported Supported Partly supported Supported Supported Supported Supported Supported Not supported Supported Not supported Supported Supported Supported Supported / / / / / / / / / / / / / Not supported Not supported Not supported Partly supported Not supported Partly supported Not supported Not supported Not supported

BICC in 3G Rel. 4
In the MSS concept the User Plane (bearer) and the Control Plane (signalling and call control) have been separated. There is a new Network Element (NE), Media Gateway (MGW), which takes care of the User Plane and the MSS controls it. MGW is the based on ATM HW and IPA2800 platform. It brings new media and functions which must be taken into account in call control signalling. For that reason Bearer Association Transport Application Service Element/Application Transport Mechanism (APM/BAT ASE) has been introduced in BICC. Its main task is to transfer the bearer-specific information between the two MSSs on a Control Plane level. Nokia implements BICC with feature 1330. This feature implements the BICC CS2 signalling through the IP network between the two MSSs according to ITU-T Draft Recommendations Q.1902.X /1/, /2/, /3/, /4/ specifications. This includes the following: Call and bearer establishment over ATM AAL1, AAL2 and IP

Codec negotiation procedure Codec modify procedure Out of band transport of DTMFs APM/BAT ASE functionality

The vertical interface MGW-MSS (Mc in 3GPP) uses H.248 to convey the bearer-related information. The needed bearer-information is transferred between MSSs in BICC through APM-mechanism.

13-459939 Issue 1.0 en

Nokia Networks Oy

9 (65)

Figure 4.

Interfaces in MSS

Nb interface is backbone interface. It can be IP or ATM. For both IP and ATM backbone interface, BICC can be used on Nc interface. Depending up on backbone, different bearer establishment methods are possible between MGWs. For IP backbone, bearer control signalling is encapsulated (tunneled) in BICC. Following methods are used for IP backbone. Fast Forward setup

Delayed Forward setup Backward setup

In case of ATM backbone, bearer control signalling is AAL type 2 signalling between MGWs. For ATM backbone, following bearer establishment methods are used.

Forward bearer set up Backward bearer set up

Origination node always selects the bearer establishment method as well as used bearer network connection characteristics.

BICC messages
The BICC messages are used by the peer-to-peer protocol. All BICC messages may be divided into two groups presented in the table 3-5. Table 3 BICC call control related messages (Q.1902.3)

Message ACM

Code 0000 0110

Description Address Complete Message: A message sent in the backward direction indicating that all the address signals required for routeing the call to the called party have been received. Answer message: A message sent in the backward direction indicating that the call has been answered. In semi-automatic working, this message has a supervisory function. In automatic working, this message is used in conjunction with charging information in order to start metering the charge to the calling subscriber (see Recommendation Q.28 [2]); and start measurement of call duration for international accounting purposes (see Recommendation E.260. Application Transport message: A message sent in either direction to convey application information using the Application Transport mechanism. Continuity message: A message sent in the forward direction indicating that the establishment of the bearer is complete up to and including the SN sending the COT message. Call Progress message: A message, sent in either direction during the setup or active phase of the call, indicating that an event, which is of significance, and should be relayed to the originating or terminating access, has occurred. Connect message: A message sent in the backward direction indicating that all the address signals required for routeing the call to the called party have been received and that the call has been answered. Identification Request message: A message sent in the backward direction to request action regarding the malicious call identification supplementary service. Identification Response message: A message sent in response to the identification request message. Information message: A message sent to convey information in association with a call, which may have been requested in an information request message. (National use) Information Request message: A message sent by an exchange to request information in association with a call. (National use) Initial Address message: A message sent in the forward direction to initiate seizure of an outgoing circuit and to transmit number and other information relating to the routeing and handling of a call. Pre-release Information message: A message to be used with the Release message for the transport of information where sending of that information in the Release message itself would cause compatibility problems with ISUP Q.764 and BICC CS1 Q1902.4.

ANM

0000 1001

APM COT

0100 0001 0000 0101

CPG

0010 1100

CON

0000 0111

IDR IRS INF

0011 0110 0011 0111 0000 0100

INR IAM

0000 0011 0000 0001

PRI

0100 0010

13-459939 Issue 1.0 en

Nokia Networks Oy

11 (65)

Message REL

Code 0000 1100

Description Release message: A message sent in either direction to indicate that the circuit /CICis being released due to the reason (cause) supplied and is ready to be put into the idle state on receipt of the release complete message. Where the call is to be redirected the message will also carry the redirection number. Release Complete message: A message sent in either direction in response to the receipt of a release message, or if appropriate to a reset circuit message, when the circuit/CIC concerned has been brought into the idle condition. Resume message: A message sent in either direction indicating that the calling or called party, after having been suspended, is reconnected. Segmentation Message: A message sent in either direction to convey an additional segment of the message. Subsequent Address Message: A message that may be sent in the forward direction following an initial address message, to convey additional called party number information. Suspend message: A message sent in either direction indicating that the calling or called party has been temporarily disconnected. User-to-user information message: A message to be used for the transport of user-to-user signalling independent of call control messages.

RLC

0001 0000

RES SGM SAM

0000 1110 0011 1000 0000 0010

SUS USR

0000 1101 0010 1101

The use of the BICC messages depends on the BICC procedure and will be discussed in the following chapters.
Table 4 BICC maintenance related messages (Q.1902.3)
Message CGB Code 0001 1000 Description Circuit/CIC Group Blocking message: A message sent to the node to permit the switching equipment or maintenance system to remove from (and return to) traffic a group of circuits/CICs. A node receiving a Circuit/CIC group blocking message must be able to accept incoming calls on the group of blocked circuits/CICs unless it has also sent a Circuit/CIC group blocking message. Circuit/CIC Group Blocking Acknowledgement message: A message sent in response to a circuit/CIC group blocking message to indicate that the requested group of circuits/CIC has been blocked. Circuit/CIC Group Reset message: A message sent to release an identified group of circuits/CIC when, due to memory mutilation or other causes, it is unknown whether for example, a REL or RLC message is appropriate for each of the circuits/CICs in the group. If at the receiving end a circuit is remotely blocked, reception of this message should cause that condition to be removed. Circuit/CIC Group Reset Acknowledgement message: A message sent in response to a circuit/CIC group reset message and indicating that the requested group of circuits/CIC has been reset. The message also indicates the maintenance blocking state of each circuit/CIC. Circuit/CIC Group Unblocking message: A message sent to the exchange at the other end of an identified group of circuits/CIC to cause cancellation in that group of circuits of an engaged condition invoked earlier by a blocking or circuit/CIC group blocking message.

CGBA

0001 1010

GRS

0001 0111

GRA

0010 1001

CGU

0001 1001

Message CGUA

Code 0001 1011

Description Circuit/CIC Group Unblocking Acknowledgement message: A message sent in response to a circuit/CIC group unblocking message to indicate that the requested group of circuits/CICs has been unblocked. Circuit/CIC group Query Message: A message sent on a routine or demand basis to request the far-end exchange to give the state of all circuits/CICs in a particular range. Circuit/CIC group Query Response message: A message sent in response to a circuit group query message to indicate the state of all circuits in a particular range. Confusion message: A message sent in response to any message (other than a confusion message) if the exchange does not recognize the message or detects a part of the message as being unrecognised. (Partly supported) Facility Accepted message: A message sent in response to a facility request message indicating that the requested facility has been invoked. Facility message: A message sent in either direction at any phase of the call to request an action at another exchange. The message is also used to carry the results, error or rejection of a previously requested action. Facility Reject message: A message sent in response to a facility request message to indicate that the facility request has been rejected. Facility Request message: A message sent from an exchange to another exchange to request activation of a facility. Reset Circuit/CIC message: A message sent to release a circuit/CIC when, due to memory mutilation or other causes, it is unknown whether for example, a release or a release complete message is appropriate. If, at the receiving end, the circuit/CIC is remotely blocked, reception of this message should cause that condition to be removed. Unequipped Circuit Identification Code message: A message sent from one exchange to another when it receives an unequipped circuit/CIC identification code. (National use).

CQM

0010 1010

CQR CFN

0010 1011 0010 1111

FAA FAC

0010 0000 0011 0011

FRJ FAR RSC

0010 0001 0001 1111 0001 0010

UCIC

0010 1110

The use of the BICC messages depends on the BICC procedure and will be discussed in the following chapters.

13-459939 Issue 1.0 en

Nokia Networks Oy

13 (65)

BICC message format

3.1

BICC message format and codes (Q.1902.3)

The ASN1 format

BICC messages use the ASN1 format. Any message in this format, depending on the type of message, can contain different parameters. Each parameter has this structure: parameter code, parameter length and parameter contents

Order of octet transmission

Message type code

Mandatory parameter A

Mandatory fixed part

Mandatory parameter F Pointer to parameter M Pointer to parameter P Pointer to start of optional part Length indicator of parameter M Parameter M Mandatory variable part

Length indicator of parameter P Parameter P Parameter name = X Length indicator of parameter X Parameter X Optional part

Parameter name = Z Length indicator of parameter Z Parameter Z End of optional parameters

T1178720-96

Figure 5

General ASN1 message format

This structure results in a logical division of the BICC messages into these parts (Figure 5):

call instance code (CIC) message type code mandatory fixed part mandatory variable part optional part, which can contain fixed length and variable length fields.

CIC Message type code Mandatory fixed part Mandatory variable part Optional part

Figure 6

BICC PDU format

The Call Instance Code (CIC) in the BICC protocol is used to identify signalling relation between peer BICC entities and associate all the PDUs to that relation. The format of the CIC field in BICC is shown in Figure 2.

5 CIC CIC CIC

1 LSB

MSB

CIC

Figure 7

CIC format

A bilateral agreement is required with regard to the CIC values provisioned. The total number of provisioned CIC values for any particular signalling association shall indicate the maximum number of peer-call signalling relations between the BICC peer entities. The parameters of a mandatory fixed part are required; they occur in a fixed order and have fixed lengths. Therefore, they do not identify the parameter name or the parameter length. They have only the parameter contents called the parameter variable.

13-459939 Issue 1.0 en

Nokia Networks Oy

15 (65)

The parameters of a mandatory variable part also occur in a fixed order; this means that they do not need a parameter code. However, they have a variable length of the variable part and a parameter length field in them. To point to the parameters in the mandatory fixed part, there are pointers to each mandatory variable parameter. The pointer contains the count of bytes between itself and the beginning of the variable parameter. The optional part has optional parameters. The parameters have to identify themselves with parameter code, specify their length, and specify their variables. To mark the beginning of the optional part, the end of the mandatory fixed part has a pointer . The end of optional parameters is marked with the code, "End of optional parameters, coded as "00h". If no optional parameter is present the end of optional parameters is not transmitted. In the next chapter messages like Initial Address Message, Answer, Release etc. are discussed in details.

3.2

Application Transport Mechanism APM (Q.765.3)

Q.765.3 Recommendation describes the extensions required for the transport of bearer-related information associated with the Bearer Independent Call Control (BICC) as defined in ITU-T Rec. Q.1902.1. The BICC is used to manage the call control instance that has been separated from the bearer control instance. The BICC needs to transport bearer-related information between call control instances. The Application Transport Mechanism (APM) will be used for this purpose. APM allows applications to send application specific data between nodes using call control messages. An application is running in the nodes besides call control instance. Application specific data can be sent in CC messages e.g. in IAM message, optional parameter APP (Application Transport Parameter) can carry application specific data. If any suitable call control message is not available then application specific data can be send in separate message called APM. In Rel. 4, BICC carries bearer related information in the messages. The application using APM for bearer control is called Bearer Association Transport Application Service Element (BAT- ASE).

3.2.1

Format of Application Transport Parameter (APP)

Figure 8.

Application transport parameter field

The following codes are used in APP

Extension indicator (ext)

-

If the extension bit is set to 0, next octet e.g. 1a is present. Value 0000101 here represents BAT ASE application is used. 0 1 0 1 Do not send notification Send notification Do not release call Release call Final segment

Application Context Identifier (ACI)

-

Send Notification Indicator (SNI)

-

Release Call Indicator (RCI)

-

APM segment indicator

-

0000000

0000001 to 001001 Indicates number of following segments 0 1 Subsequent segment to first segment New sequence

Sequence Indicator (SI)

-

APM user field information

13-459939 Issue 1.0 en

Nokia Networks Oy

17 (65)

This field is as per ACI, Encapsulated application information is included here. It is defined in Q.765.3.

3.2.2

Encapsulated application information

Figure 9.

Encapsulated application information field

Each information element within Encapsulated Application Information field has same structure. It consists of four fields in given order

Identifier
-

Identifier governs interpretation of the contents Length in octets of compatibility information and content. It contains instructions for the case that the received information is unrecognised. E.g. to release call, send notification, pass on, discard information element etc. This field is the substance of the element. It contains the information to be conveyed.

Length indicator
-

Compatibility information
-

Content
-

Value

Information element name

Information It can have codes like Connect Forward, Connect Backward etc. It is bearer specific with maximum length of 4 octets (BNC_ID) It is in NSAP format (BIWF Address) Single codec information elements are listed in decreasing order of preference level It has information about single codec information element e.g. Organisation identifier, codec type, codec configuration Instructions on information received that is unrecognised Information to identify type of bearer used e.g. AAL2, IP/RTP, AAL1, TDM etc. It contains PDU (Protocol Data Unit) for BCTP in case of IP backbone. It indicates whether tunnelling is used or not. It contains information about the BCU. BCU is represented with Network ID and local BCU-ID

00000001 Action Indicator 00000010 Backbone network connection identifier 00000011 Interworking function address 00000100 Codec list

00000101 Single codec

00000110 BAT compatibility report 00000111 Bearer Network connection Characteristics 00001000 Bearer Control Information 00001001 Bearer Control Tunnelling 00001010 Bearer control unit identifier

00001011 Signal 00001100 Bearer Redirection Capability This information element indicates whether bearer redirection capability is supported at sending node and also indicates options within the capability. 00001110 Signal Type It indicates Signal type e.g. DTMF tones, dial tone, ringing tone, busy tone etc. Duration of signal in millisecond

00001111 Duration

Figure 10.

List of identifiers

13-459939 Issue 1.0 en

Nokia Networks Oy

19 (65)

3.2.3

Transcoder Free Operation (TrFO) and Tandem Free Operation (TFO)

The Transcoder Free Operation (TrFO) uses and end-to-end common compressed codec from User Equipment (UE) to another UE through the access network and the core network avoiding the unnecessary transcoding stages. It also saves the Digital Signal Processor (DSP) capacity in the Multimedia Gateway (MGW), thus reducing expenses of the MGW. The Transcoder Free Operation (TrFO) provide enhanced speech quality and transmission capacity savings in the 3G core network. The operation is based on codec negotiation and selection performed by the MSS and the user plane operations of the MGW, including user plane protocol handling and automatic transcoder removal and insertion, when applicable. The codec negotiation between MSSs can be performed using BICC. The Application Transport Mechanism (APM) is used to transfer bearer-related parameters, such as, speech codecs. The User Equipment (UE) indicates its codec capabilities during the call setup. The originating MSS creates a proposed list of codecs in priority order. The possible intermediate MSS forwards the list, possibly deleting some codecs. The terminating MSS inspects the capabilities of the terminating UE and selects the codec to be used. The selected codec is indicated backwards and the user plane is established, based on the selected codec. Every time a transcoding takes places, the speech quality is decreased, partly due to the way the conversion process works, partly since the delay is increasing. Using the Tandem Free Operation (TFO), these tandem connections can be avoided by relaying the compressed codec all the way from the Mobile Station (MS) to MS. The TFO mainly aims to improve the quality of speech, however it does not lead to the optimisation of the transmission capacity itself. The aim of using the payload optimisation with TFO is to agree that the codec used at the access side is also used in the IP/ATM based backbone network. Since the used cellular codecs typically require only a fraction of the G.711 capacity (that is, GSM FR 13 kbit/s, GSMEFR 12.2 kbit/s, and AMR-NB codecs a maximum of 12.2 kbit/s), significant savings can be gained. The MGW transfer only the compressed codec, which is available in TFO frames at the A interface, towards the IP/ATM backbone, and the rest of unnecessary bits are simply stripped of.

3.2.4
3.2.4.1

Bearer Control Information

Bearer Control Tunnelling Protocol (BCTP)

Figure 11.

Operation of BCTP tunnelling mechanism

In case of IP backbone, bearer control signalling does not pass horizontally between two BIWFs. Instead of that it is passed on vertical interface (in case of Rel. 4 it is on Mc interface) and then it is tunnelled in BICC interface. Q.1990 Recommendation defines the BICC bearer Control Tunnelling Protocol (BCTP) which transports the tunnelled Protocol Data Units (PDU) of the bearer control protocol. BCTP puts two octets in front of every tunnelled BCP PDU. These two octets contain information on BCTP version indicator and Tunnelled Protocol Indicator. Tunnelled Protocol Indicator has value 10 0000 for IPBCP.
3.2.4.2 IP Bearer Control Protocol (IPBCP)

IP Bearer Control Protocol is used in IP network environment where the BICC protocol is deployed. The purpose of IP bearer control protocol (IPBCP) is to exchange information between two BIWFs necessary to establish or modify IP bearers. IPBCP makes use of the Session Description Protocol (SDP) defined in RFC 2327 [10] to encode the information that is exchanged. SDP descriptors used for IPBCP also contain IPBCP-specific SDP attributes.

13-459939 Issue 1.0 en

Nokia Networks Oy

21 (65)

IPBCP uses four messages to convey information between peer BIWFs. These messages are

Request It is sent by a BIWF to initiate an IP bearer establishment or modification request. Accepted It is sent by a BIWF that receives an IP bearer establishment or modification message if it accepts the request. Confused It is sent by a BIWF in response to an IP bearer establishment or modification message if it cannot process the received message. Rejected - It is sent by a BIWF in response to an IP bearer establishment or modification message if it rejects the request.

IPBCP message contents. IPBCP message consist of the following SDP fields. Session and time description fields 1. 2. 3. 4. 5. 6. 1. 2. Protocol version (v) Origin (o) Session name (s) Connection data (c) Session attribute (a) Time (t) Media Announcement (m) Media Attributes (a)

Media description fields

Some of the fields and subfields are included because they are mandatory and required by SDP but not relevant to IPBCP environment. SDP messages are in text format.
v=0 o=- 0 3010101061 IN IP4 102.13.12.1 s=IP call c=IN IP4 102.13.12.251 t=0 0 A=ipbcp:1 Request m=audio 49000 RTP/AVP 0 a=rtpmap:<dynamic payload number> VND.3GPP.IUFP/16000 a=fmtp:97 mode-set W X Y Z

Figure 12

IPBCP in SDP format

Call-related BICC signalling procedures

Basic call procedures for the BICC protocols are defined in ITU-T Q.1902.4 recommendation.

4.1

Successful call setup en block operation

Figure 7 and 8 show the normal call setup procedure.

ISN-A ISU P CSF-N SWN-1 BCF-N (x) BCF-R BICC SWN-2 BCF-R

TSN CSF-T SWN-1 BCF-N (y) BCF-R BICC SWN-2 BCF-R

ISN-B CSF-N BCF-N (z) ISUP

IAM IAM (Action = Connect forward), (BNC characteristics) APM (Action = Connect Forward, no notification) (BNC-ID = y1), (BIWF Addr = y) Bearer-Set-up req (BNC-ID = y1), (BIWF-Addr = y) Bearer-Set-up req Bearer-Set-up req Bearer-Set-up req (BNC-ID = z1), (BIWF-Addr = z) COT Bearer-Set-up-Connect Bearer-Set-up-Connect Bearer-Set-up-Connect Bearer-Set-up req Bearer-Set-up req "BBB" Bearer-Set-up-Connect Bearer-Set-up-Connect Bearer-Set-up-Connect ACM ACM ACM ACM ANM ANM ANM
T11112090-01

IAM (COT on previous), (Action = Connect Forward), (BNC characteristics) APM (Action = Connect Forward, no notification) (BNC-ID = z1), (BIWF Addr = z)

"AAA"

ANM

Figure 13

Forward establishment of backbone network connection, no bearer notification

13-459939 Issue 1.0 en

Nokia Networks Oy

23 (65)

ISN-A ISUP CSF-N SWN-1 BCF-N (x) BCF-R BICC SWN-2 BCF-R

TSN CSF-T SWN-1 BCF-N (y) BCF-R BICC SWN-2 BCF-R

ISN-B CSF-N BCF-N (z) ISUP

IAM

IAM (Action = Connect backward), (BNC-ID = x1), (BIWF-Addr = x), (BNC characteristics)

IAM (Action = Connect backward), (COT on previous), (BNC-ID = y1), (BIWF-Addr = y), (BNC characteristics)

"AAA"

Bearer-Set-up req (BNC-ID = x1), (BIWF-Addr = x) Bearer-Set-up req Bearer-Set-up req Bearer-Set-up req Bearer-Set-up-Connect Bearer-Set-up-Connect Bearer-Set-up-Connect Bearer-Set-up-Connect Bearer-Set-up-Connect COT Bearer-Set-up-Connect Bearer-Set-up req (BNC-ID of BIWF y), (BIWF-Addr = y) Bearer-Set-up req

"BBB" ACM ACM ACM ANM ANM

T11112110-01

ACM ANM

ANM

Figure 14.

Backward establishment of backbone network connection

At the originating exchange

When the CSF at the originating SN has received the complete selection information from the calling party, and has determined that the call is to be routed to another CSF, the outgoing signalling procedure is initiated. (A BIWF may be selected at this point - depending on the characteristics of the incoming access type the BIWF may also be pre-determined.) The selection of the route will depend on the called party number, connection type required and the network signalling capability required. This selection process may be performed at the CSF or with the assistance of a remote database. A free CIC value is selected and the Outgoing bearer set-up procedure is invoked to send an IAM and perform bearer set-up to the next SN. The IAM is populated with call control information as follows:

The information used to determine the routing of the call by the CSF will be included in the IAM (as Called Party Number, Transmission Medium

Requirement and Forward Call Indicators parameters), to enable correct routing at intermediate CSFs.

Called Party Number parameter

The sending sequence of address information on international calls will be the country code followed by the national (significant) number. On national connections, the address information may be the subscriber number or the national (significant) number as required by the Administration concerned. The ST Address Signal will be used whenever the CSF is in a position to know by digit analysis that the final digit has been sent.

Transmission Medium Requirement parameter

The information received from the access interface is used to set the value of the Transmission Medium Requirement parameter, see the relevant interworking Recommendation, e.g. ITU-T Q.1912.2.

Forward Call Indicators parameter

The CSF will set the fields of the Forward Call Indicators parameter to indicate: "no end-to-end method available"; "no interworking encountered"; "ISDN-User Part/BICC used all the way"; network signalling capability required (ISDN-User Part/BICC Preference indicator). The ISDN-User Part/BICC Preference indicator is set according to the bearer service, teleservice and supplementary service(s) requested. The exact setting depends on the service demand conditions and may be different depending on individual cases. In principle, if the service demand requires ISDN-User Part/BICC to be essential then the indicator is set to "required", if the service required is optional but preferred it is set to "preferred", otherwise it is set to "not required". The indicator is set to either "required" or "preferred", or "not required", according to the most stringent condition required by one or more of the parameters in the IAM.

The Nature of Connection Indicators parameter.

The Satellite Indicator is set appropriately based on the characteristics of the selected outgoing network connection. The Continuity Indicator is set to "no COT to be expected" if the incoming bearer is established, or may be set to "COT to be expected" if the incoming bearer is not established yet. The Echo Control Indicator is set according to Echo Control procedures.

13-459939 Issue 1.0 en

Nokia Networks Oy

25 (65)

The CSF will include BAT ASE data. The CSF may also include other parameters required by procedures specified in clause 8 or the relevant interworking Recommendation, e.g. ITU-T Q.1912.2.

The IAM may be subject to Simple Segmentation The initial address message can contain an access transport parameter. The structure of an IAM is shown in Table 5.

Table 5. IAM message structure

Parameter Message type Nature of connection indicators Forward call indicators Type F F Length octets 1 1 IAM Satellite connection included/not included, Continuity check required/not required, echo control device included/not included Call national/international, end-to-end method indicator, CCS7 interworking indicator, end-to-end information availability, ISDN user part use indicator, ISUP preference indicator, ISDN access indicator, SCCP method indicator. Ordinary, payphone, priority, operator language. Speech, 3.1 kHz audio, 64 kbit/s, Nx64kbit/s, 1920 kbit/s, 1536 kbit/s etc. Information to identify the calling party Information generated on the access side of a call and transferred transparently in either direction between originating and terminating local nodes. The information is significant to both users and local nodes Information sent in either direction to allow the peer-to-peer communication of Application Transport mechanism user applications Information sent in the forward direction concerning treatment of call diversion. Information sent in the forward direction concerning treatment of call offering. Circuit independent information identifying a particular call. Information to indicate the directory number. The directory number is a number in the national numbering scheme that is allocated to a customer for a telephony service Information indicating the number which was received in the SSP as called party number in IAM and SAM messages. Description

Calling party's category Transmission medium requirement Called party number (Note 2) Access transport

F F V O

1 1 4-? 3-?

Application transport

5-?

Call diversion treatment indicators Call offering treatment indicators Call reference (national use) Called directory number (national) Called IN number (Note 2)

O O O O

3-? 3-? 7 5-?

4-?

Parameter Calling party number (Note 2) Carrier selection information CCSS

Type O O

Length octets 4-? 3

Description Information sent in the forward direction to identify the calling party. Information sent in the forward direction to indicate the method (namely call per call or preselection) being used to invoke carrier selection Information sent in an initial address message indicating that a call is a CCBS or a CCNR call as defined in the CCBS or CCNR supplementary service. Information uniquely identifying a closed user group within a network. Information sent in the forward direction indicating whether or not a call is a collect call. Information sent in both directions concerning treatment of a multi-party call. Information used by the SCF (service control function) for correlation with a previous connection. Indicators used to request activation and deactivation of echo control devices, and to respond to such requests. Information sent in the forward direction used for a GVNS (global virtual network service) call to convey GVNS related information. Digit information, which is not suitable to be sent within numbering address parameter, sent in either direction to convey information between exchanges due to supplementary service. Information sent in either direction intended to provide supplementary service notification to a user. Number information sent in either direction to enhance network operation or for supplementary services. Information sent in forward direction to uniquely identify a call and correlate activities associated with that call Information sent in the forward direction to minimize the impact of looping. The initial count determines the maximum number of contiguous ISUP interexchange circuits that are allowed to complete the call, assuming all subsequent intermediate exchanges decrement the hop counter. Information sent in either direction indicating the IN Services being invoked in a call Information sent to identify the geographical area (e.g. region, country, city, etc.) of the origin of a call. It is primarily intended to provide services for mobile originated calls. Information relating specifically to the multilevel precedence and pre-emption service. Information sent in the forward direction concerning network management related action for a call. Information to indicate the network routing number. The network routing number is a number used by the network to route a call

3-?

Closed user group interlock code Collect call request Conference treatment indicators Correlation id Echo control information Forward GVNS Generic digit (national use) (Note 1) Generic notification indicator (Note 1) Generic number (Notes 1 and 2) Global call reference Hop counter

O O O O O O O

6 3 3-? 3-? 3 5-26 4-?

O O O O

3 5-? 8-? 3

IN service compatibility Location number (Note 2)

O O

3-? 4-?

MLPP precedence Network management controls Network routing number (national)

O O O

8 3-? 4-?

13-459939 Issue 1.0 en

Nokia Networks Oy

27 (65)

Parameter Network specific facility (national use)

Type O

Length octets 4-?

Description Service related information transparently transferred in either direction between the local exchange and the identified network which contracts the service. The information is significant to both user and the identified network Information sent in the forward direction concerning treatment of number portability Information relating to the characteristics of the connection, signalling path and called party sent in the forward direction. Information sent in the forward direction indicating the original called IN number, if multiple IN interactions have taken place Information sent in the forward direction when a call is redirected and identifies the original called party. Information sent in the initial address message of an international call, indicating the point code of the originating ISC (international switching center) Information sent in either direction indicating how an exchange should react in case the parameter is unrecognised. Information sent in forward direction to indicate the propagation delay of a connection. This information is accumulated whilst the parameter is transferred through the network. The propagation delay information is represented by a counter counting in integer multiples of 1 ms. Information sent in the forward direction when a call is diverted, indicating the number from which the call was diverted. Information sent in either direction giving information about call redirection or call rerouting. The Remote Operations parameter is used to indicate the invocation of a supplementary service identified by an operation value and also carry the result or error indications depending on the outcome of the operation. Information indicating the SCF identifier. Information sent in either direction to indicate the invocation, acceptance or rejection of supplementary services, when no service associated parameter is to be sent. Information sent in the initial address message indicating the transit network requested to be used in the call. Information sent in the forward direction indicating the fallback connection type in case of fallback. Information sent in the forward direction to inform succeeding exchanges that on request a user interactive dialogue is possible. Information sent in the forward direction indicating the bearer capability requested by the calling party. Information sent in the forward direction indicating the additional bearer capability requested by the calling party.

Number portability forward information (network option) Optional forward call indicators Original called IN number Original called number (Note 2) Origination ISC point code

3-?

O O O O

3 4-? 4-? 4

Parameter compatibility information Propagation delay counter

O O

4-? 4

Redirecting number (Note 2) Redirection information Remote operations (national use)

O O O

4-? 3-4 8-?

SCF id Service activation

O O

3-? 3-?

Transit network selection (national use) Transmission medium requirement prime UID capability indicators User service information User service information prime

O O O O O

4-? 3 3-? 4-13 4-13

Parameter User teleservice information User-to-user indicators User-to-user information

Type O O O

Length octets 4-5 3 3-131

Description Information sent in the initial address message indicating the Higher Layer Compatibility information requested by the calling party. Information sent in association with a request (or response to a request) for user-to-user signalling supplementary service(s). Information generated by a user and transferred transparently through the inter exchange network between the originating and terminating local exchanges. The end of optional parameters field indicates that there are no more optional parameters in the message.

End of optional parameters

The address information sending sequence is as follows:

-

On international calls: Country code followed by national (significant) number On national connections: the subscriber number or the national (significant) number as required by the Administration concerned.

The end-of-pulsing (ST) signal is used whenever the originating exchange is in a position to know by digit analysis that the final digit has been sent.

Internal through connection of the bearer path

Internal through connection of the bearer path will be completed in the backward direction at the originating SN when the Outgoing bearer set-up procedure is successfully completed (Note). (It is also acceptable that on speech or 3.1 kHz audio calls, through connection of the bearer path will be completed in both directions.) In addition, if the Outgoing bearer set-up procedure is performing "Per-call bearer set-up in the forward direction", with Connect Type "notification not required", the bearer path shall be connected in the backward direction when the Bearer Set-up request has been sent by the Outgoing bearer set-up procedure. (It is also acceptable that on speech or 3.1 kHz audio calls, through connection of the bearer path will be completed in both directions.) The internal bearer path is completed in the forward direction on receipt of a CON or ANM. Note As an additional condition the through connection of the internal bearer path in the backward direction will be completed when the incoming bearer is also available. (This is dependent on the characteristics of the incoming access type.)

13-459939 Issue 1.0 en

Nokia Networks Oy

29 (65)

Network protection timer

When the originating SCF sends the IAM, the awaiting address complete timer (T7) is started. If timer (T7) expires, the connection is released and an indication is returned to the calling subscriber.

At intermediate exchanges

The CSF at an intermediate SN, on receipt of a IAM will analyse the Called Party Number and the other routing information to determine the routing of the call. If the call can be routed using the connection type specified in the Transmission Medium Requirement parameter a BIWF may be selected and the Outgoing signalling procedure is started. The BIWF selected, at this time, or later in the set-up procedure, shall be able to support the bearer set-up direction indicated by the Action indicator, support the received BNC characteristics, as included in the BICC_Data indication primitive associated with the IAM, and support bearer control tunnelling if required. Other information elements, if received, shall be taken into account. The Incoming bearer set-up procedure is started when a BIWF has been selected. A free CIC value is selected, and the Outgoing bearer set-up procedure is invoked to send an IAM and perform bearer set-up to the next CSF. When constructing the IAM the CSF may modify signalling information received from the preceding CSF:

The Satellite Indicator in the Nature of Connection Indicators parameter should be incremented if the characteristics of the selected outgoing network connection indicate satellite usage. Otherwise, the indicator is passed on unchanged. The Continuity Indicator in the Nature of Connection indicators parameter shall be set to indicate "COT to be expected". The Echo Control Indicator in the Nature of Connection indicators parameter shall be set according to Echo Control procedures, see 8.4. Signalling procedures in clause 8 may modify parameters. BAT ASE data is not necessarily passed on transparently.

Other signalling information is passed on transparently, e.g. the Access Transport Parameter, User Service Information, etc.

Internal through connection of the bearer path

The internal bearer path shall be connected in both directions when both of the following conditions are satisfied:

the Incoming bearer set-up procedure is successfully completed; and

the Outgoing bearer set-up procedure is successfully completed.

In addition, if the Outgoing bearer set-up procedure is performing "Per-call bearer set-up in the forward direction", with Connect Type "notification not required", the bearer path shall be connected in both directions when both of the following conditions are satisfied:

the Incoming bearer set-up procedure has been successfully completed; and the Bearer Set-up request has been sent by the Outgoing set-up procedure

Network protection timer

When an outgoing CSF sends the IAM, the awaiting address complete timer (T7) is started. If timer (T7) expires, the connection is released and an indication is returned to the calling subscriber.

At the destination exchange

Upon receipt of an IAM the CSF at the destination SN will analyse the called party number to determine to which party the call should be connected. It will also, if possible, check the called party's line condition and perform various checks to verify whether or not the connection is allowed. These checks will include correspondence of compatibility checks, e.g. checks associated with supplementary services. In the case where the connection is allowed a BIWF is selected and the Incoming bearer set-up procedure is started. The BIWF selected shall be able to support the bearer set-up direction indicated by the Action indicator, support the received BNC characteristics, as included in the BICC_Data indication primitive associated with the IAM, and support bearer control tunnelling if required. Other information elements, if received, shall be taken into account. The connection to the called party will be set up when:

the incoming bearer set-up procedure is successfully completed; and if the incoming IAM indicated "COT to be expected", a Continuity message, with the Continuity Indicators parameter set to "continuity" is received.

If the IAM had been segmented by the use of the Segmentation message, the remainder of the call set-up information is awaited.

Address complete message

An ACM (table 7) will be sent by the CSF at the destination SN as soon as it has been determined that the complete called party number has been received,

13-459939 Issue 1.0 en

Nokia Networks Oy

31 (65)

or an indication received from the called party that an in-band tone is being connected. However, there is no direct mapping from alerting, received from the access signalling system, to address complete in the network. In the case that the Continuity message is awaited, the CSF shall withhold sending the ACM until a successful continuity indication has been received. The CSF will set the fields of the Backward Call Indicators parameter to indicate:

"no end-to-end method available"; "no interworking encountered"; "ISDN-User Part/BICC used all the way".
Address complete message
Parameter Message type Backward call indicators Access delivery information Access transport Application transport (Note 3) Call diversion information Call reference (national use) Cause indicators CCNR possible indicator Conference treatment indicators Echo control information Generic notification indicator (Note 1) HTR information IN service compatibility Network specific facility (national use) Optional backward call indicators Parameter compatibility information Pivot routing backward information Redirect status (national use) Redirection number (Note 2) Redirection number restriction Remote operation (national use) Service activation Transmission medium used Type F F O O O O O O O O O O O O O O O O O O O O O O Length octets 1 2 3 3-? 5-? 3 7 4-? 3 3-? 3 3 4-? 3-? 4-? 3 4-? 3-? 3 4-? 3 8-? 3-? 3

Table 6

Parameter UID action indicators User-to-user indicators User-to-user information End of optional parameters Note 1 parameter may be repeated

Type O O O O

Length octets 3-? 3 3-131 1

Note 2 - peer-to-peer interworking with a pre-1997 version of ISUP may result in format errors and lead to the release of the call. Note 3 multiple application transport parameters (APP) can be sent in the same message, provided that they belong to different segmentation sequences

At the intermediate exchange

Upon receipt of an ACM the CSF will send the corresponding ACM to the preceding CSF, and if this is the CSF controlling charging, the awaiting answer timer (T9) is started. If Timer T9 expires, the call is released and an indication is sent to the calling subscriber. The call is released in the backward direction with cause value #19, "no answer from user; user alerted". If a CON is received instead of an ACM, a CON will be sent to the preceding CSF.

At the destination exchange

On receipt of the ACM the awaiting address complete timer (T7) is stopped and the awaiting answer timer (T9) is started. If Timer T9 expires the connection is released and an indication is sent to the calling subscriber. If the CON is received, then the awaiting address complete timer (T7) is stopped. The sending of the awaiting answer indication (e.g. ring tone) at the destination SN depends on the type of call. On speech, 64 kbit/s unrestricted preferred, 3.1 kHz calls and calls to an analogue called party the awaiting answer indication is applied to the bearer path to the calling party from the destination SN on receipt of an alerting indication from the called party or from information contained within the destination SN that the called party will not or is prohibited from providing in-band tone. Regardless of whether tones are to be provided or not, the destination SN will through connect after the reception of the connection indication from the called party and before sending the ANM/CON to the preceding CSF.

13-459939 Issue 1.0 en

Nokia Networks Oy

33 (65)

If the destination SN does not send the awaiting answer indication because the destination user provides for the sending of tones, then the destination SN will through connect the internal bearer path in the backward direction on receipt of the progress indication.

Continuity message

If the Continuity Indicator in the Nature of Connection Indicators parameter sent in the IAM was set to "COT to be expected", then the Continuity message, with the Continuity Indicators parameter set to "continuity" is sent when the incoming bearer set-up procedures are successfully completed (see relevant interworking Recommendation).
Actions required at an intermediate SN

The IAM is sent before completion of the bearer set-up, and the Continuity message is used to withhold call completion until establishment of the bearer is complete. The Continuity message, with the Continuity Indicators parameter set to "continuity" is sent when the two following conditions are satisfied:

If the incoming IAM indicated "COT to be expected", a Continuity message, with the Continuity Indicators parameter set to "continuity" shall be received. One of the following events, which indicate successful completion of bearer set-up, shall also be received by the Incoming bearer set-up procedure, depending on the procedure being applied: Bearer Set-up indication - for the forward bearer set-up case where the incoming Connect Type is "notification not required". BICC_Data indication primitive with Action indicator set to "Connected" - for the forward bearer set-up cases (with, or without bearer control tunnelling) where the incoming Connect Type is "notification required", and for the fast set-up (backward) case. Bearer Set-up Connect indication - for the backward bearer set-up case. BNC set-up success indication for cases using bearer control tunnelling, except as identified in item above.

When an IAM is received with the Nature of Connection Indicators parameter set to indicate "COT to be expected", Timer T8 is started. On receipt of a Continuity message with the Continuity Indicators parameter set to "continuity", Timer T8 is stopped, and the message passed to the outgoing signalling procedures. However, if Timer T8 expires, the call is released with cause #41, "temporary failure".

Actions required at a CMN

A CMN shall pass the Continuity Indicator in the IAM and any subsequent COT message unchanged. A CMN does not run Timer T8.
Actions required at the destination SN

When an IAM is received with the Nature of Connection Indicators parameter set to indicate "COT to be expected", Timer T8 is started. On receipt of a Continuity message with the Continuity Indicators parameter set to "continuity", Timer T8 is stopped, and the call shall proceed according to 7.7.1. However, if Timer T8 expires, the call is released with cause #41, "temporary failure".

4.2

Bearer setup procedures

BNC-ID

A Backbone Network Connection identifier (BNC-ID), is an identity, unique within the scope of one BCF, that identifies a Backbone Network Connection. It is exchanged between SNs for the purposes described below.
BNC-ID usage during call and bearer set-up

For the cases where a new bearer is set-up for a new call, using a bearer type that has a set-up protocol, the BNC-ID is:

allocated by the BCF at one SN, when a BCF-CSF association is instantiated; sent to the adjacent SN via the BICC protocol; returned to the BCF at the original SN via the bearer set-up protocol; used to identify the relevant call for the newly set-up bearer connection.

BNC-ID usage for structured AAL1 bearers

For networks that provide for the use of structured AAL1 bearers, each BCF manages pools of bearer network connections to adjacent SNs. Within each pool there are two sets of bearers: those set-up (and thus "owned") by this BCF, and those set-up by the remote BCF (and thus not "owned" by this BCF). Both sets are further divided into subsets, each subset associated with a structured AAL1 bearer. At any moment in time any of these pools may be non-existent or empty. The management of bearers within the pools, sets and subsets, i.e. what bearers are in which pools, sets and subsets, is beyond the scope of this Recommendation. The bearers within the pools are labelled with BNC-IDs. For bearers owned by this BCF, the BNC-ID was allocated by the far BCF, and for those bearers owned by the far BCF, the BNC-ID was allocated by this BCF.

13-459939 Issue 1.0 en

Nokia Networks Oy

35 (65)

For a bearer network connection associated with a structured AAL1 bearer, the BNC-ID is four octets long and structured as (X, n). The first three octets (X) are used to identify the structured AAL1 connection. The fourth octet (n) is used to identify a particular channel within the structured AAL1 bearer. The fourth octet is interpreted as a binary number indicating the channel within the structured AAL1 bearer. The values of 0000 0000 and 1111 1111 within the fourth octet are reserved and should not be used to indicate channels within a structured AAL1 bearer. During the call set-up procedure, when a new bearer connection is to be set up, a structured AAL1 bearer consisting of N channels is set up, N being the value coded in the fourth octet of the BNC-ID, (X, N), carried in the BICC protocol. The call is associated with the BNC-ID, (X, N), and the remaining (N-1) BNCIds are marked as corresponding to idle bearer network connections associated with the structured AAL1. In other words, the BNC-Ids (X, 1) to (X, N-1) are idle and can be used for new calls. During the call set-up procedure, when an idle bearer network connection associated with a structured AAL1 bearer is to be reused, the corresponding BNC-ID is transferred by the BICC protocol to indicate to the remote BCF which bearer network connection is to be reused for the call. A BCF can only select a bearer network connection for reuse that it originally set-up, i.e. one that it owns.
Bearer release control

Under normal call handling situations a bearer shall only be released by the BCF that originally set it up, i.e. by the BCF that "owns" the bearer. Thus, when a request to release a bearer is received from the BICC CSF procedures, the BCF shall only initiate the bearer release protocol if it owns the bearer. It may also choose not to release a bearer it owns if it is determined by the BCF management function that it is needed for the reuse of idle bearer procedure. (This is a network option.) In the case of structured AAL1 bearer, the BCF shall not release the structured AAL1 bearer until such time as all of the channels associated with the structured AAL1 bearer have become idle. Under abnormal conditions the BICC CSF procedures can request reset of the bearer connection and in this case the BCF shall unconditionally initiate the bearer release protocol.
BIWF address

The BIWF Address is information exchanged between SNs to identify the address of the BCF within the BIWF at the peer SN.
BNC characteristics

The BNC Characteristics is information exchanged between SNs to identify the selected BNC type, i.e. AAL1, Structured AAL1, or AAL2.

Outgoing bearer set-up in forward direction

In this procedure, the bearer is set up from the SN that sends the IAM. Information to enable addressing and bearer identification is awaited from the succeeding SN before the bearer set-up can be initiated. Initial actions depend on whether a BIWF has been selected at the initiation of outgoing bearer set-up.

If a BIWF has been selected: in the response to the BNC Information request primitive the BCF returns the BNC characteristics, and may include the BIWF Address. The response also indicates that bearer control tunnelling is not being used. If no BIWF has been selected BNC Characteristics is set to a value determined by the CSF application logic. An IAM is sent including in the BICC_Data request primitive: 3. Action indicator set to "Connect forward". 4. BNC characteristics. 5. BIWF Address, if received from the BCF. 6. Bearer Control Tunnelling set to "no indication", if the BIWF has not been selected, providing that bearer control tunnelling is allowed.

Subsequently BICC_Data indication primitive (corresponding to an APM message), should be received:

If the received Action indicator is "Connect forward, plus notification" the Connect Type is set to "notification required", else it is set to "notification not required". A BIWF is selected, if one was not selected earlier. A Bearer Set-up request is sent to the selected BCF. This request includes: 1. BNC-ID (as received in the BICC_Data indication primitive). 2. BIWF Address (as received in the BICC_Data indication primitive). 3. Bearer Characteristics, i.e. Transmission Medium Requirements (as sent in the IAM) and User Service Information (if sent in the IAM).

When a Bearer Set-up Connect indication is received this indicates successful completion of the outgoing set-up procedure.

If the Connect Type is "notification required" a BICC_Data request primitive (corresponding to an APM message), is sent containing Action indicator set to "Connected".

If ACM or CON are received, and Bearer Set-up Connect indication has not yet been received the ACM/CON shall be handled and Bearer Set-up Connect or Bearer Set-up Failure indication is awaited.

13-459939 Issue 1.0 en

Nokia Networks Oy

37 (65)

Incoming bearer set-up in forward direction

This procedure is invoked if the received Action indicator is set to "Connect forward", and the Bearer Control Tunnelling information element indicating "tunnelling to be used" is not present. In this procedure the bearer is set up from the SN that sends the IAM. Addressing and bearer identification information is sent backward to enable the preceding SN initiate the bearer connection. Alternatively, if the Bearer Control Tunnelling information element set to "no indication" is received in the IAM, the BCF may indicate that bearer control tunnelling is applicable and the procedures continue.

If Codec negotiation is applicable, the following steps are delayed until indicated by that procedure. A BNC Information Request primitive is sent to the BCF. This request includes: 1. BNC Characteristics (as received via BICC_Data indication primitive associated with the IAM). 2. Bearer Characteristics, i.e. Transmission Medium Requirements (as received in the IAM) and User Service Information (if received in the IAM). 3. BIWF-Address, if received in the BICC_Data indication primitive. 4. An indication that bearer control tunnelling can be used if the Bearer Control Tunneling information element set to "no indication" was received in the BICC_Data indication primitive.

If the response indicates that bearer control tunnelling is applicable, the procedure continues. Alternatively, the response primitive returns the BNC-ID and BIWF Address and the procedure continues as follows:

The Connect Type is set to "Notification not required". A BICC_Data request primitive is issued (corresponding to an APM message), containing: 1. Action indicator set to: "Connect forward, plus notification" if the Connect Type is "Notification required", else it is set to "Connect forward, no notification". 2. BNC-ID.

3.

BIWF Address.

When the bearer connection arrives at the SN a Bearer Set-up indication is received from the BCF:

The Bearer Set-up indication is correlated with the call instance. A Bearer Set-up response is sent to the BCF. If the Connect Type is "notification not required" the incoming set-up procedure is now successfully completed.

If the Connect Type is "notification required" the incoming set-up procedure awaits a BICC_Data indication primitive (corresponding to an APM message) containing Action indicator set to "Connected". The incoming set-up procedure is now successfully completed.

4.3

Answer and release procedures

At the destination exchange

When the called party answers, the destination SN connects through the internal bearer path and the ringing tone is removed if applicable. An ANM message is sent to the preceding CSF. If the CSF at the destination SN controls charging, then charging may begin.
Table 7 Answer message
Parameter Message type Access delivery information Access transport Application transport (Note 3) Backward call indicators Backward GVNS Call history information Call reference (national use) Conference treatment indicators Connected number (Note 2) Display information Echo control information Generic notification indicator (Note 1) Generic number (Note 1 and 2) IN service compatibility Network specific facility (national use) Optional backward call indicators Parameter compatibility information Pivot routing backward information Redirect status (national use) Type F O O O O O O O O O O O O O O O O O O O Length octets 1 3 3-? 5-? 4 3-? 4 7 3-? 4-? 3-? 3 3 5-? 3-? 4-? 3 4-? 3-? 3

13-459939 Issue 1.0 en

Nokia Networks Oy

39 (65)

Parameter Redirection number (Note 2) Redirection number restriction Remote operations (national use) Service activation Transmission medium used User-to-user indicators User-to-user information End of optional parameters Note 1 parameter may be repeated

Type O O O O O O O O

Length octets 5-? 3 8-? 3-? 3 3 3-131 1

Note 2 - peer-to-peer interworking with a pre-1997 version of ISUP may result in format errors and lead to the release of the call. Note 3 - multiple application transport parameters (APP) can be sent in the same message, provided that they belong to different segmentation sequences.

When connections are set up to terminals having an automatic answer feature, the alerting indication may not be received from the called party. If the CSF at a destination SN receives an answer indication an ANM is sent provided that an ACM has been sent, otherwise a CON is sent.
Table 8 Connect message
Parameter Message type Backward call indicators Access delivery information Access transport Application transport (Note 3) Backward GVNS Call history information Call reference (national use) Conference treatment indicators Connected number (Note 2) Echo control information Generic notification indicator (Note 1) Generic number (Note 1 and 2) HTR information IN service compatibility Type F O O O O O O O O O O O O O O Length octets 1 2 3 3-? 5-? 3-? 4 7 3-? 4-? 3 3 5-? 4-? 3-?

Parameter Network specific facility (national use) Optional backward call indicators Parameter compatibility information Pivot routing backward information Redirect status Redirection number restriction Remote operations (national use) Service activation Transmission medium used User-to-user indicators User-to-user information End of optional parameters Note 1 parameter may be repeated

Type O O O O O O O O O O O O

Length octets 4-? 3 4-? 3-? 3 3 8-? 3-? 3 3 3-131 1

Note 2 - peer-to-peer interworking with a pre-1997 version of ISUP may result in format errors and lead to the release of the call. Note 3 - multiple application transport parameters (APP) can be sent in the same message, provided that they belong to different segmentation sequences.

Note Connect messages may be received by DX200 elements, but not generated or transmitted by them.

At intermediate exchanges

Upon receipt of an ANM, the CSF sends the corresponding ANM to the preceding CSF. If this is the CSF controlling charging, charging may begin, and timer (T9) is stopped. If a connect message is received at an intermediate exchange instead of an address complete message, a connect message will be sent to the preceding exchange.

At the originating exchange

When the originating exchange receives an answer message indicating the required connection has been completed, the transmission path is connected through in the forward direction. The Awaiting Answer timer (T9) is stopped. If the originating exchange is the exchange controlling charging, charging may begin.

13-459939 Issue 1.0 en

Nokia Networks Oy

41 (65)

Release message

The release procedures are based on a two-message (REL, RLC) approach whereby the REL initiates release of the call. Note NOTE - At an SN an indication of call release is issued to the BCF, but the subsequent decision to initiate bearer release protocol is the responsibility of BCF logic.

Release initiated by a calling party

Actions at the originating SN

On receipt of a request to release the call from the calling party, the CSF requests the BCF to disconnect the internal through-connection of the bearer path, and invokes the Release sending procedure.
Actions at an intermediate SN

On receipt of a REL from the preceding CSF, the CSF invokes the Release reception procedure, and initiates call release on the outgoing side by invoking the Release sending procedure towards the succeeding CSF.
Actions at a CMN

On receipt of a REL from the preceding CSF, the CSF invokes the Release reception procedure to pass the message on, or respond, as appropriate.
Actions at the destination SN

On receipt of a REL from the preceding CSF, the CSF invokes the Release reception procedure.

Release initiated by a called party

Actions at the destination SN

On receipt of a request to release the call from the called party, the CSF requests the BCF to disconnect the internal through-connection of the bearer path, and invokes the Release sending procedure.

Actions at an intermediate SN

On receipt of a REL from the succeeding CSF, the CSF invokes the Release reception procedure, and initiates call release on the incoming side by invoking the Release sending procedure towards the preceding CSF.
Actions at a CMN

On receipt of a REL from the succeeding CSF, the CSF invokes the Release reception procedure to pass the message on, or respond, as appropriate.
Actions at the originating SN

On receipt of a REL from the succeeding CSF, the CSF invokes the Release reception procedure.

Release sending procedure

To initiate the signalling of call release to an adjacent CSF:

The CSF shall send REL to the preceding/succeeding CSF (as applicable). Timers T1 and T5 are started to ensure that a RLC is received in response. When the RLC is received timers T1 and T5 are stopped. At an SN call release at the incoming/outgoing (as applicable) side is indicated to the BCF and the Cause parameter in the original REL is passed to the BCF.

Release reception procedure

Actions at an SN On receipt of a REL the CSF requests the BCF to disconnect the internal through-connection of the bearer path. The received Cause parameter is passed to the BCF and call release at the incoming/outgoing (as applicable) side is indicated. When the BCF acknowledges successful disconnection of the internal bearer path a RLC is returned to the preceding/succeeding CSF (as applicable).
Table 9 Release message
Parameter Type Length (octets) Message type Cause indicators Access delivery information Access transport F V O O 1 3-? 3 3-?

13-459939 Issue 1.0 en

Nokia Networks Oy

43 (65)

Automatic congestion level Display information HTR information Network specific facility (national use) Parameter compatibility information Redirect backward information (national use) Redirect counter (national use) Redirection information (national use) Redirection number (national use) (Note) Remote operations (national use) Signalling point code (national use) (ISUP only) User-to-user indicators User-to-user information End of optional parameters

O O O O O O O O O O O O O O

3 3-? 4-? 4-? 4-? 3-? 3 3-4 5-? 8-? 4 3 3-131 1

Table 10. Message type: Release Complete

Parameter Message type Cause indicators End of optional parameters Type F O O Length (octets) 1 5-6 1

Charging (national use) Charging is stopped upon receipt of the REL at the charging CSF or on the receipt of a request to release the call from the calling party when the charging CSF is at the originating SN.

4.4

Additional BICC call setup procedures

Call progress message The CPG is sent (only after the ACM) from a CSF in the backward direction indicating that an event has occurred during call set-up which should be relayed to the calling party. The CPG may be subject to Simple Segmentation.

Table 11

Call progress message

Parameter Type F F O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O Length octets 1 1 3 3-? 5-? 4 3-? 3 4 7 4-? 4-? 3 3-? 4-? 3 3 5-? 3-? 4-? 3 4-? 3-? 3 4-? 3 8-? 3-? 3 3-? 3 3-131 1

Message type Event information Access delivery information Access transport Application transport (Note 3) Backward call indicators Backward GVNS Call diversion information Call history information Call reference (national use) Call transfer number (Note 2) Cause indicators CCNR possible indicator Conference treatment indicators Connected number (Note 2) Echo control information Generic notification indicator (Note 1) Generic number (Note 1 and 2) IN service compatibility Network specific facility (national use) Optional backward call indicators Parameter compatibility information Pivot routing backward information Redirect status (national use) Redirection number (Note 2) Redirection number restriction Remote operation (national use) Service activation Transmission medium used UID action indicators User-to-user indicators User-to-user information End of optional parameters

13-459939 Issue 1.0 en

Nokia Networks Oy

45 (65)

Parameter Note 1 parameter may be repeated

Type

Length octets

Note 2 - peer-to-peer interworking with a pre-1997 version of ISUP may result in format errors and lead to the release of the call. Note 3 - multiple application transport parameters (APP) can be sent in the same message, provided that they belong to different segmentation sequences.

The CPG is sent from the CSF at a destination SN if the ACM has been sent and subsequently:

an indication is received that the called party is being alerted, the CPG contains an Event Indicator that is set to "alerting"; a progress indication is received from the called party, the CPG contains an Event Indicator that is set to "progress".

On receipt of a call progress message at the originating exchange, no state change occurs, and the appropriate indication is sent to the calling user.

Requesting information (national use) An Information Request message may be sent to any CSF in the forward (backward) call establishment direction after sending (receiving) an IAM until when routing is complete i.e. when the ACM or CON is generated by the CSF at the destination SN or when it is received by the CSF at an intermediate SN/CMN or originating SN.
Table 12
Parameter Message type Information indicators Call reference Calling party number (Note) Calling party's category Connection request (ISUP only) Network specific facility Parameter compatibility information End of optional parameters

Information (national use)

Type F F O O O O O O O Length (octets) 1 2 7 4-? 3 7-9 4-? 4-? 1

NOTE Peer-to-peer interworking with an earlier version of ISUP may result in format errors and lead to the release of the call.

Table 13
Parameter Message type

Information request message (national use)

Type F F O O O O Length (octets) 1 2 7 4-? 4-? 1

Information request indicators Call reference (national use) Network specific facility Parameter compatibility information End of optional parameters

Sending solicited information (national use)

On sending an Information Request message a timer (T33) is started. No second Information Request message may be sent in the same direction until a response Information message is received. If the timer (T33) expires before the response message is received, see 13.7.5. The value of this timer (T33) is 12-15 seconds to allow for a cascade of Information Request messages, as described in item ii). The response Information message may be sent as follows:

if all the information requested is available locally, then an Information message containing all the required information is sent in response; if all the information is not available locally, but may be available remotely, then an Information Request message may be sent to a subsequent CSF in the call in an attempt to extract the information not locally available. (This Information Request message may be delayed if one has already been sent and the response not yet received.) On receipt of a response, all the information necessary to respond to the original Information Request message is sent in an Information message; if all the information is not available locally or remotely, then an Information message containing only the available information is sent and the requested but not delivered information is indicated as "not available", using either the indication in the information indicator or an appropriate coding in the requested parameter.

Receiving a solicited information message (national use)

Upon receipt of an Information message Timer T33 is stopped. If this message contains neither the requested information nor an indication that the requested information is not available, the actions taken will depend on whether the call can be progressed. Any information which was not requested is discarded.

13-459939 Issue 1.0 en

Nokia Networks Oy

47 (65)

Charging

Charging indicators are basically defined for national use. Therefore, unless there is bilateral agreement, the decision to charge a call or not, or to start international accounting will not be decided upon reception of these indicators.
Call collect request procedure

As described in ITU-T E.141, a calling party may, during call set-up, invoke an operator service to request that a call be charged to a called party. For such calls, IAM sent beyond the CSF at the SN providing the operator service, shall include the Collect Call Request parameter coded to indicate "collect call requested". On receipt of a "collect call requested" indication in an incoming IAM, a terminating network may take such actions as it may consider appropriate in order to avoid the problem of uncollectable charges.
Tones and announcements Tones and announcements at an SN

The applicability of tones and announcements is decided based on the Transmission Medium Requirements. Tones and announcements are applicable for the following Transmission Medium Requirements:

speech; 3.1 kHz audio; and 64 kbit/s unrestricted preferred.

If a call set-up fails and no in-band tone or announcement has to be returned to the calling party from an SN succeeding the controlling SN, the CSF sends a REL to the CSF at the controlling SN. The cause value should reflect the reason of the call failure in the same way as the in-band tone or announcement to be applied by the controlling SN. If a call set-up fails and an in-band tone or announcement has to be returned to the calling party from an SN or called party, the in-band tone or announcement is connected to the bearer path either by a request from CSF to BCF, or by the user concerned. If a time-out occurs at the SN providing the in-band tone or announcement, the CSF sends a REL to the preceding CSF with cause value #31, "normal unspecified". Call failure cases are possible where the bearer establishment has not yet been initiated. If a tone or announcement should be required in such cases the Incoming bearer set-up procedure shall be performed prior to connecting the tone or announcement.

Call failure cases are possible where the bearer is not fully established, due to failure during the Incoming bearer set-up procedure, and thus no tone or announcement can be played to the calling party from the SN detecting the failure. e.g. in the backward bearer set-up case if the set-up of the bearer fails. In these cases the CSF shall release the call, (without sending ACM), with the cause value most accurately describing the cause of failure. If an ACM has been returned to the preceding CSF a CPG indicating that in-band tone information is available along with the Cause parameter, is returned to the preceding CSF (see 8.2). The cause value should reflect the reason of call failure in the same way as the in-band tone or announcement to be applied. If an ACM has not been returned to the preceding CSF already, an ACM, with the Cause parameter and the In-band Information Indicator set in the Optional Backward Call Indicators parameter, will be returned to the CSF at the originating SN. The cause value should reflect the reason of call failure in the same way as the in-band tone or announcement to be applied.
Tones and announcements at a CMN

Tones or announcements cannot be applied by a CMN. If a call set-up fails this CSF sends a REL to the preceding CSF. The cause value should reflect the reason of the call failure in the same way as the in-band tone or announcement to be applied by the controlling SN.

13-459939 Issue 1.0 en

Nokia Networks Oy

49 (65)

BICC network features

This section addresses the following network features: BICC segmentation Automatic repeat attempt Blocking and unblocking of circuits and circuit groups Circuit group query (national use)

5.1

BICC segmentation
The Simple Segmentation procedure uses the Segmentation message to convey an additional segment of an overlength message. Any message containing either the Optional Forward or Backward Call Indicators parameter can be segmented using this method. This procedure provides a mechanism for the transfer of certain messages whose contents are longer than 272 octets but not longer than 544 octets for the case when the transport mechanism is limited to 272 octets (i.e. MTP). The procedure is as follows:

The sending CSF, on detecting that the message to be sent exceeds the 272 octet limit, can reduce the message length by sending some parameters in a Segmentation message sent immediately following the message containing the first segment. The parameters that may be sent in the second segment using the Segmentation message are: the User-to-User Information, Generic Digit, Generic Notification, Generic Number and Access Transport parameters. If the User-to-User Information and Access Transport parameters cannot be carried in the original message and the two together do not fit in the Segmentation message, the User-to-User Information parameter is discarded. The sending CSF sets the Simple Segmentation Indicator in the Optional Forward or Backward Call Indicators parameter to indicate that additional information is available. When a message is received, by a CSF at a local SN, with the Simple Segmentation Indicator set to indicate additional information is available, the CSF starts timer T34 to await the Segmentation message. This action may also take place at incoming or outgoing gateway CSFs if policing of information is required.

When the Segmentation message is received timer T34 is stopped, and the call continues. In case any other message except the ones listed below is received before the Segmentation message containing the second segment the CSF should react as if the second segment is lost, i.e. the timer T34 is stopped and the call continues. Continuity. CIC Group Blocking. CIC Group Blocking Acknowledgement. CIC Group Unblocking. CIC Group Unblocking Acknowledgement. CIC Group Query. CIC Group Query Response. After expiry of timer T34 the call shall proceed and a received Segmentation message containing the second segment of a segmented message is discarded. At an incoming or outgoing gateway SN or CMN, when following the simple segmentation procedure it is possible that the CSF has to reassemble an incoming message and subsequently re-segment it for onward transmission. In this case it has to be ensured that any unrecognized parameters received in the first, or second segment are transmitted in the first, or second, segment respectively, when the passing of the parameter is required by the compatibility procedure.

The messages are: 4. 5. 6. 7. 8. 9. 10.

5.2

Automatic repeat attempt

Automatic repeat attempt is defined in ITU-T Q.12. An automatic repeat attempt will be made (up to the point when the IAM information is released)

on detection of dual seizure (at the non-control CSF) on receipt of the CIC Group Blocking message, including the relevant status bit for this CIC set to "1", after sending an address message and before any backward message has been received on receipt of a Reset CIC message after sending an address message and before a backward message has been received on receipt of an unreasonable message during call set-up

13-459939 Issue 1.0 en

Nokia Networks Oy

51 (65)

5.3

Blocking and unblocking of CIC values

The CIC Group Blocking (Unblocking) messages are provided to permit the switching equipment or maintenance system to remove from (and return to) traffic CIC values, thus providing a means to temporarily block use of CICs for maintenance purposes. The CIC Group Blocking message can be originated by either CSF. The receipt of a CIC Group Blocking message will have the effect of prohibiting non-test calls using the relevant CIC value(s) outgoing from the CSF until an appropriate CIC Group Unblocking message is received, but will not prohibit test calls incoming to that CSF. Test calls generated in the outgoing direction from the CSF that sent the CIC Group Blocking message will also be processed.
CIC group blocking procedures

CIC values are removed from (returned to) service using the CIC Group Blocking (Unblocking) messages. The range of CIC values to be blocked (unblocked) is indicated in the Range field. Those CIC values within the range that have to be blocked (unblocked) are indicated in the Status field. The same rule applies to the acknowledgements.
Table 14. Message structure: CIC group blocking/unblocking

Message Type: Circuit/CIC group blocking Circuit/CIC group blocking acknowledgement Circuit/CIC group unblocking Circuit/CIC group unblocking acknowledgement Parameter Message type Type F Length (octets) 1

The number of CIC values to be blocked (unblocked) with one CIC Group Blocking (Unblocking) message is in the range 1 to 32. An acknowledgement sequence is always required for the CIC Group Blocking message and CIC Group Unblocking message using the CIC Group Blocking Acknowledgement message and the CIC Group Unblocking Acknowledgement message respectively. The acknowledgement is not sent until the appropriate action - either blocking or unblocking - has been taken. Reception of the CIC Group Blocking Acknowledgement message is guarded by timers T18 and T19 and reception of the CIC Group Unblocking Acknowledgement message is guarded by timers T20 and T21.

The REL message should not override a blocking condition and return CIC value(s) to service. The blocked CIC value(s) will be returned to service on transmission of the CIC Group Unblocking Acknowledgement message at one CSF and on receipt of the CIC Group Unblocking Acknowledgement message at the other CSF. For all instances of CIC Group Blocking the maintenance system should be notified at both ends of the signalling association.

5.4

CIC group query (national use)

The CIC group query test allows a CSF to audit the state of a CIC on a demand or routine basis.
Table 15. Message structure: CIC group query

Message Type: Circuit group query (national use) Parameter Message type Range and status (Note) Note - the status subfield is not present. Type F V Length (octets) 1 2

The value N of the Range field of the CIC Group Query message, including N = 0 for a single CIC, indicates the range to be tested. The maximum value of N is 31. If that value is exceeded the CIC Group Query message is discarded. For the purposes of CIC query procedures, there are states which are classified into four major categories, as follows:

Unequipped and transient conditions Call processing states (idle, CIC incoming/outgoing busy) Maintenance blocking states (unblocked, remotely blocked, locally blocked, locally and remotely blocked) Hardware blocking states (unblocked, remotely blocked, locally blocked, locally and remotely blocked)

A CIC value is "unequipped" if the CIC value is not provisioned. This is a unique state and will not overlap with any other state. The "transient" state refers to any transient call processing or maintenance states.

13-459939 Issue 1.0 en

Nokia Networks Oy

53 (65)

Table 16.
Parameter Message type

Message Type: CIC group query response (national use)

Type F V V Length (octets) 1 2 2-33

Range and status (Note) Circuit state indicator

Note - the status subfield is not present.

An interrogation of circuit states in DX200 is shown in Figure 15.

Figure 15

Circuit group state interrogation printout in DX 200

To initiate the circuit group query procedure, the sending exchange sends a circuit group query message indicating in the routing label and range field those circuits to be audited. If no response to the circuit group query message is received before timer T28 expires, maintenance systems should be informed. The receiving exchange processes the circuit group query message and returns a circuit group query response message setting the circuit state indicators to the state of the circuits being audited.

5.5

Bearer Redirection and Crankback/Automatic Rerouting

Two new functionalities can be used with the BICC protocol on the M13.0 level: Bearer Redirection and Crankback/Automatic Re-routing. The Bearer Redirection procedure enables the re-routing of the user plane after which some sort of optimisation is needed (for example, after the CFNA). Bearer Redirection is a generic mechanism for optimising the bearer path when an end point of a call changes, caused by the operation of an application layer. The crankback mechanism (Automatic Re-routing) allows the call set-up to return to the preceding Serving Network (SN) so that the call can automatically be re-routed from there. An SN invokes the Automatic Rerouting procedure when a call cannot be routed further from that certain SN. Automatic Re-routing may or may not be invoked when the call cannot be routed further from an intermediate SN. Invocation includes setting or updating the re-routing counter. A network-specific parameter defines the maximum allowed number of re-routing attempts (values 063).

13-459939 Issue 1.0 en

Nokia Networks Oy

55 (65)

Abnormal conditions
The abnormal procedures discussed in this section are:

Dual Seizure Reset of Circuits and Circuit Groups Unreasonable Signalling Information

6.1

Dual seizure
CIC values for use across a signalling association may be allocated in two different ways:

The provisioned set of CIC values may be divided into two parts: one set selectable by one CSF and the remainder selectable by the other CSF. This scheme avoids the possibility of dual seizure of a CIC value, or, A common set of CIC values may be provisioned, i.e. either CSF can select any provisioned value. In this case it is possible that the two CSFs will attempt to seize the same CIC value at approximately the same time.

The procedures below apply only when the second method of CIC provisioning is used. A dual seizure is detected by a CSF from the fact that it receives an IAM for a CIC value for which it has sent an IAM, but before it receives a valid backward message.
Preventive action

Different methods for CIC selection can be envisaged to minimize/remove the occurrence of dual seizure. The following method is defined: An opposite order of CIC value selection is used at each CSF. (Other methods for CIC value selection may also be used provided that they give the same degree of protection against dual seizure also when the method specified above is used at the other end.)
Action to be taken on detection of dual seizures

In the event of dual seizure, one CSF will be the control CSF and the other the non-control CSF. On detection of a dual seizure, the call being processed by the control CSF will be completed and the received IAM will be disregarded. If the IAM has been segmented using a Segmentation message, then this second segment will also be disregarded. Any following SAM(s) will also be disregarded.

Under these conditions, the call being processed by the control CSF will be allowed to mature. The call being processed by the non-control CSF will be backed off and the internal bearer path disconnected (if applicable). A REL will not be sent. The non-control CSF will make an automatic repeat attempt on the same or on an alternative route. The control CSF will be determined as follows: Each CSF will control one half of the CIC values. One CSF will control all even-numbered CICs and the other CSF the odd-numbered CICs. Each CSF will examine the CIC_control parameter in the START-INFO.indication primitive from the STC, see ITU-T Q.2150.0 to determine whether it controls odd or even CIC values per signalling association.

6.2

CIC and group reset procedures

Reset of CICs

In systems which maintain call status in memory, there may be occasions when the memory becomes mutilated. In such a case the CIC values and associated resources must be reset to the idle condition at both CSFs to make them available for new traffic. Since the CSF with the mutilated memory does not know whether the CIC values are idle, busy outgoing, busy incoming, blocked, etc., Reset CIC messages or a CIC Group Reset message should be sent as appropriate for the affected CIC values.
Reset CIC procedure

If only a few CIC values are concerned, a Reset CIC message should be sent for each affected CIC value. Reception of the Reset CIC acknowledgement message (RLC) is guarded by timers T16 and T17. Expiry of these timers is covered in 13.7.1. On receipt of a Reset CIC message the receiving (unaffected) CSF will:

if it is the incoming or outgoing CSF on a call in any state of call set-up or during a call, accept the message as a REL message and respond by sending a RLC message, after the CIC value has been made idle; if the CIC value is in the idle condition, accept the message as a REL message and respond by sending a RLC message; if it has previously sent a CIC Group Blocking message with the Status bit for this CIC value set to "1", or if it is unable to release the CIC value as described above, respond by the CIC Group Blocking message. If an incoming or outgoing call is in progress, this call should be released and the CIC value returned to the "idle, blocked" state. A RLC message is

13-459939 Issue 1.0 en

Nokia Networks Oy

57 (65)

sent following the CIC Group Blocking message. The CIC Group Blocking message should be acknowledged by the affected CSF. If the acknowledgement is not received, the repetition procedure specified in 13.7 should be followed;

if it has previously received a CIC Group Blocking message with the Status bit for this CIC value set to "1", respond by releasing a possible outgoing call or call attempt using the CIC value, remove the blocked condition, restore the CIC value to the idle state, and respond with a RLC message; if the message is received after the sending of an IAM, but before receipt of a backward message relating to that call, make an automatic repeat attempt using another CIC value if appropriate; if the message is received after having sent a Reset CIC message, respond by a RLC message. After receipt of the appropriate acknowledgement message, the CIC value should be made available for service; at an SN: issue a request to the BCF to reset any allocated bearer resources, associated with this CIC value.

The affected CSF will then reconstruct its memory according to the received response(s) to the Reset CIC and respond to the message(s) in the normal way, i.e. CIC Group Blocking Acknowledgement message in response to a CIC Group Blocking message.
Table 17. Message structure: CIC/group reset

Message Type: CIC/group reset Parameter Message type Range and status (Note) Note - the status subfield is not present. Type F V Length (octets) 1 2

Group reset procedure

If a considerable number of CIC values or all CIC values are affected by a memory mutilation, (a) CIC Group Reset message(s) should be used to make them available for new traffic. Reception of the CIC Group Reset Acknowledgement message is guarded by timers T22 and T23. Expiry of these timers is covered in 13.7.2. The maximum number of CIC values to be reset with a CIC Group Reset message is limited to 32.

On receipt of a CIC Group Reset message the receiving (unaffected) CSF will:

restore the CIC values to the idle state; respond by a CIC Group Reset Acknowledgement message in which the Status indicator bits of the CIC values available for service are coded "0" and the status indicator bits of all CIC values blocked for maintenance reasons are set to "1"; if it had previously received (a) CIC Group Blocking message(s) for one or more of the CIC value(s) involved, remove the blocked condition and make the CIC values available for service; if a CIC Group Reset message is received concerning CIC values for which a CIC Group Reset message or Reset CIC message(s) have been sent, make the CIC values concerned available for service after receipt of the appropriate acknowledgement message; at an SN: issue (a) request(s) to the BCF to reset any allocated bearer resources, associated with the reset CIC values.

The affected CSF will then reconstruct its memory according to the possibly received CIC Group Blocking messages and the received CIC Group Reset Acknowledgement message. It will respond to the possibly received CIC Group Blocking messages in the normal way. A correct acknowledgement should match the original CIC Group Reset message in range and CIC value. The CIC value of both CIC Group Reset messages and CIC Group Reset Acknowledgement messages should be provisioned for BICC. All CIC values in the range of a CIC Group Reset and CIC Group Reset Acknowledgement message must be provisioned for BICC.
Table 18. Message structure: CIC/group reset acknowledgement

Message Type: CIC/group reset acknowledgement Parameter Message type Range and status Type F V Length (octets) 1 3-34

Abnormal group reset procedures

If a CIC Group Reset message is received indicating reset of more CIC values than allowed by the receiving CSF, it is discarded. If a CIC Group Reset Acknowledgement message is received which is not a correct response to a sent CIC Group Reset message, it is discarded. If a CIC Group Reset message is received requesting reset of CIC values that are not provisioned, or a CIC Group Reset Acknowledgement

13-459939 Issue 1.0 en

Nokia Networks Oy

59 (65)

message that contains CIC values that are not provisioned, the message is discarded.

6.3

Unreasonable/unexpected/unrecognised signalling information

The message transport service provided by the STC and its lower layers avoids mis-sequencing, or double delivery, of messages with a high reliability (e.g. see ITU-T Q.706). However, undetected errors at the lower message transport layers and CSF malfunctions may produce signalling information messages that are either ambiguous or inappropriate. Unreasonable or unexpected signalling information may also be received at a CSF due to differing levels of signalling protocol enhancements at different CSFs within a network: a CSF using a more enhanced version of the protocol may send information to a less enhanced CSF which is outside the protocol definition supported at that CSF. The degree of applicability of the procedures below at CSFs where there are differences between the capabilities of the incoming and outgoing signalling systems, e.g. between the national and international sides of a gateway, is for further study.
Handling of message format errors

The following are considered message format errors:

The message length is less than the number of octets required for the fixed mandatory part, the mandatory variable pointers and the start of optional parameters pointer. A mandatory variable or start of optional parameter's pointer points beyond the message length. A mandatory variable or optional parameter's length indicator causes the overall message length to be exceeded.

When a message format error is detected the message shall be discarded. Note A format error can only be detected when the message is recognised.

Handling of unexpected messages

An unexpected message is one which contains a message type code that is within the set supported at this CSF, but is not expected to be received in the current state of the call.

In order to resolve possible ambiguities in the state of a CIC when unexpected messages are received the following will apply:

if a REL is received relating to an idle CIC value it will be acknowledged with a RLC; if a RLC is received relating to an idle CIC value it will be discarded; if a RLC is received relating to a CIC value that is in use for a call, and a REL has not been sent, the call will be released and a REL will be sent; if a Segmentation message is received with a CIC value that is in use for a call, in case the segmentation has not been announced in the Simple Segmentation Indicator the Segmentation message shall be discarded;

If other unexpected signalling messages are received, the following actions will be undertaken:

if the CIC value is idle, the Reset CIC message is sent; if the CIC value is in use for a call, after receipt of a backward message required for the call set-up, the unexpected signalling message is discarded, except in certain cases, see item c); if the CIC value is in use for a call, before receipt of a backward message required for the call set-up, the Reset CIC message is sent. If the CIC is in use for an incoming call, any interconnected call segment will be released. If the CIC is in use for an outgoing call, an automatic repeat attempt is provided using another CIC value. If a message is received with a CIC value that is not provisioned within the CSF it shall be discarded, however if the CSF supports the national option using the Unequipped CIC message (13.5), that procedure shall be performed instead.

General requirements on receipt of unrecognized messages and parameters

It may happen that a CSF receives unrecognized. messages, parameter types or parameter values. This can typically be caused by the upgrading of the signalling system used by other CSFs in the network. In these cases, the following compatibility procedures are invoked to ensure the predictable network behaviour. The procedures to be used on receipt of unrecognized information make use of:

compatibility information received in the same message as the unrecognized information; the Confusion message; the Release message; the Release Complete message; the Facility Reject message

13-459939 Issue 1.0 en

Nokia Networks Oy

61 (65)

For all the above cause values a Diagnostic field is included containing, dependent on the Cause value, either the unrecognized parameter name(s), the message type code, or the message type code and the unrecognized parameter name(s). If messages are received without compatibility information and are not recognized, they are discarded and the Confusion message is sent. When an unrecognized parameter or message is received, the CSF should find some corresponding instructions contained in the Parameter Compatibility Information or Message Compatibility Information parameters respectively. The Parameter Compatibility Information parameter may contain compatibility instructions for more than one parameter. The Message Compatibility Information parameter contains the instructions specific for the handling of the complete message. If the CSF does not find instructions in an appropriate compatibility parameter or if the compatibility parameter is not found in the message, the actions default to a basic action.

Automatic congestion control

Automatic Congestion Control (ACC) is used when a CSF is in an overload condition (see also ITU-T Q.542). Two levels of congestion are distinguished, a less severe congestion threshold (congestion level 1) and a more severe congestion threshold (congestion level 2). If either of the two congestion thresholds are reached, an Automatic Congestion Level parameter is added to all REL messages generated by the CSF. This parameter indicates the level of congestion (congestion level 1 or 2) to the adjacent CSFs. The adjacent CSFs, when receiving a REL containing an Automatic Congestion Level parameter should reduce their traffic to the overload affected CSF. If the overloaded CSF returns to a normal traffic load it will cease including Automatic Congestion Level parameters in RELs. The adjacent CSFs then, after a predetermined time, automatically return to their normal status.
Receipt of a release message containing an automatic congestion level parameter

When a CSF receives a REL containing an Automatic Congestion Level parameter, the appropriate information should be passed to the signalling system-independent network management/overload control function within the CSF. This information consists of the received congestion level information and the route identification to which the REL applies. If the automatic congestion level procedure is not implemented, the Automatic Congestion Level parameter is not acted upon and discarded as normal. Automatic congestion level actions are applicable only at CSFs adjacent to the congested CSF. Therefore, a CSF that receives a REL containing an Automatic Congestion Level parameter should discard that parameter after notifying the network management/overload control function.
Actions taken during overload

Whenever a CSF is in an overload state (congestion level 1 or 2), the signalling system independent-network management/overload control function will indicate that the CSF should include an Automatic Congestion Level parameter in every REL transmitted. The network management/overload control function will indicate which congestion level (1 or 2) to code in the Automatic Congestion Level parameter. When the overload condition has ended the network management/overload control function will indicate that the CSF should cease including Automatic Congestion Level parameters in the transmitted RELs.

13-459939 Issue 1.0 en

Nokia Networks Oy

63 (65)

Appendix: BICC timers

Symbol T1 T5 Time-out value 15 - 60 seconds 5 - 15 minutes Cause for initiation When release message is sent When initial release message is sent Normal termination At the receipt of release complete message At receipt of release complete message At expiration Retransmit release message and start timer T1. Send reset circuit message, alert maintenance personnel and remove the CIC from service, stop T1, start T17. Procedure continues until maintenance intervention occurs. Initiate release procedure.

T6

Covered in Rec. Q.118 20 - 30 seconds

When controlling CSF receives suspend (network) When the latest address message is sent

At receipt of resume (network) message or release message

T7

When the condition for Release all equipment and normal release of connection (send release address and routing message). information is met (receipt of ACM, CON messages) At receipt of continuity message At the receipt of answer Release all equipment and connection into the network (send release message). Initiate release procedure

T8

10 - 15 seconds

When the CSF receives IAM indicating that COT is to be expected

T9

Interval When national controlling or specified in Rec. outgoing international CSF Q.118 receives ACM 15 - 60 seconds When reset circuit message is sent not due to expiration of T5 When initial reset circuit message is sent

T16

At the receipt of the acknowledgement (RLC message) At the receipt of the acknowledgement

Retransmit reset circuit message and start T16. Alert maintenance personnel, retransmit reset circuit message. Start T17, stop T16. Procedure continues until maintenance intervention occurs. Retransmit group blocking message and start T18. Retransmit group blocking message, alert maintenance personnel. Start T19, stop T18. Procedure continues until maintenance intervention occurs. Retransmit group unblocking message and start T20. Retransmit group unblocking message, alert maintenance personnel. Start T21, stop T20. Procedure continues until maintenance intervention occurs.

T17

5 - 15 minutes

T18

15 - 60 seconds

When group blocking message is sent When initial group blocking message is sent

At receipt of group blocking acknowledgement At receipt of group blocking acknowledgement

T19

5 - 15 minutes

T20

15 - 60 seconds

When group unblocking message is sent When initial group unblocking message is sent

At receipt of group unblocking acknowledgement At receipt of group unblocking acknowledgement

T21

5 - 15 minutes

Symbol T22 T23

Time-out value 15 - 60 seconds 5 - 15 minutes

Cause for initiation When circuit group reset message is sent When initial circuit group reset message is sent

Normal termination At receipt of the acknowledgement At the receipt of the acknowledgement

At expiration Retransmit circuit group reset message and start T22. Alert maintenance personnel and start T23. Retransmit circuit group reset message, stop T22. Procedure continues until maintenance intervention occurs. Alert maintenance. New congestion indication is taken into account. Release call and alert maintenance personnel. Proceed with call.

T28 T29

10 seconds 300 - 600 ms

When send CQM Congestion indication received when T29 not running When send INR When indication of a segmented message is received on an IAM, ACM, CPG, ANM or CON message At receipt of the latest digit (< >ST) and before the minimum or fixed number of digits have been received

At receipt of CQR

T33 T34

12 - 15 seconds 2 - 4 seconds

On receipt of INF At receipt of a segmentation message

T35

15 - 20 seconds

At receipt of ST or when the minimum or fixed number of digits have been received At receipt of resume (network) or release message

Send release message (cause 28).

T38

Interval When the incoming specified in Rec. international gateway SCF Q.118 sends to the preceding SCF a suspend (network) message 10 seconds

Send release message (cause 102).

T40

When out-of-band start signal (DTMF or tone) is sent and notification is requested When out-of-band stop signal (DTMF or tone) is sent and notification is requested When a modification is initiated during codec modification or mid-call codec negotiation procedures When a mid-call codec negotiation is initiated

At receipt of positive or Send notification to requesting negative notification side

T41

10 seconds

At receipt of notification

"No action"

T42

5-30 seconds

At receipt of indication of successful or failed codec modification

Initiate release procedure

T43

5-30 seconds

At receipt of successful Notify mid-call codec or failed mid-call codec negotiation nodal functions negotiation

13-459939 Issue 1.0 en

Nokia Networks Oy

65 (65)