3.1 BSSMAP Procedures

08.083GPPMobile-services Switching Centre - Base Station system (MSC-BSS) Interface Layer 3 SpecificationRelease 1999TS

This sub-clause describes the procedures used in the BSS Management Application Part. There are the following main procedures:

*

Assignment

figure 2

#

Blocking

figure 10 and 25

#

Resource indication

figure 12

#

Reset

figure 11

*

Handover required indication

figure 4

*

Handover resource allocation

figure 5

*

Handover execution

figure 3

#

Handover candidate enquiry

figure 13

*

Release

figures 6 and 7

#

Paging

figure 15

#

Flow control

figure 14

*

Classmark update

figure 9

*

Cipher mode control

figure 17

*

Trace invocation

*

Initial MS message

*

Queuing indication

*

Data link control SAPI not

equal to 0

figure 18

#

Reset circuit

*

PDSS1 flow control

*

Circuit re-selection

figure 26

*

Location Aquisition

#

Connectionless Information Transfer

*

Commen ID

These procedures are documented separately and are intended to be used by the operators/manufacturers to build up complete call sequences, in a flexible manner. Any sequences given where more than one procedure is shown concatenated are only for illustrative purposes.

Each of the above procedures is qualified by either an asterisk (*) or a hash symbol (#). The hash symbol (#) denotes a global procedure which concerns a complete cell or BSS, or specific terrestrial circuits. The asterisk symbol (*) denotes a dedicated procedure which concerns a single dedicated radio resource on the radio interface, or in the case of a multislot configuration, all radio resources allocated to one mobile station.

Messages used to support global procedures are sent using the connectionless services of the SCCP.

Messages used to support dedicated procedures are sent using the connection oriented services of the SCCP, on the connection which has been set up to support that call or transaction. The establishment of SCCP connections is detailed in 3GPP TS 08.06.

In the following description of each procedure it is explicitly stated whether the procedure is global or not, and hence the type of SCCP service used to support the procedure is defined.

The handling of unknown terrestrial circuits is defined in sub-clause 3.1.19.6 and the procedures of sub-clause 3.1.19.6 take precedence over those of the rest of sub-clause 3.1. The procedures of the rest of sub-clause 3.1 assume that the terrestrial circuit is known by the entity concerned.

3.1.1 Assignment

The purpose of the assignment procedure is to ensure that the correct dedicated radio resource(s) can be allocated or reallocated to a MS that requires it. However, the initial random access by the MS and "Immediate Assignment" to a DCCH is handled autonomously by the BSS without reference to the MSC.

3.1.1.1 Successful Operation

The initial conditions are assumed to be that the MS is in contact with the fixed infrastructure of a PLMN by means of one or more dedicated radio resources (and possibly a terrestrial resource) and that the MSC has analysed any relevant call control information and wishes to allocate or reallocate to the MS one or more radio resources (and possibly a terrestrial resource).

The MSC is the entity that carries out the necessary analysis on the call control information received from the MS or fixed network customer.

On the basis of this analysis a resource request is made to the appropriate BSS by sending it an ASSIGNMENT REQUEST message. This message contains details of the resource(s) required (for instance channel rate, channel type, data adaptation, priority level etc.). If the requested resource(s) is/are for speech or data it also may indicate the terrestrial circuit that shall be used between the MSC and BSS. The description of the resource(s) can either be a complete specification, or give the BSS some freedom in the selection (for instance channel rate selection, speech version selection etc.). The ASSIGNMENT REQUEST message may also contain CLASSMARK information in case such information is available in the MSC, but assumed not to be available in the BSS. A full description of the message is given in sub-clause 3.2.1.1.

In this specification a "pool" is a group of circuits supporting the same channel types.

The ASSIGNMENT REQUEST message is sent via the BSSMAP and is analysed within the BSS. Based on this analysis, which is not defined further in this Technical Specification, the BSS chooses the appropriate radio resource(s) and allocates the appropriate resources for transcoding, rate adaptation etc. On the terrestrial route connecting the BSS and MSC, certain circuits can be used for different combinations of bearer capabilities. This can be modelled by grouping the circuits into "pools" supporting the same channel types. The MSC holds this information as route data. If the MSC allocates an A interface circuit, it should only ever ask for resources from the BSS that it knows are not totally incompatible with the nominated circuit. The BSS will construct and send the appropriate radio assignment messages, if required (i.e., if the radio resource(s) has/have to be changed), as described in 3GPP TS 04.18, and start timer T10. The ASSIGNMENT REQUEST message includes sufficient information to allow the BSS to construct the necessary layer 3 radio messages. If the BSS allocates the A interface circuits, and such a circuit is needed, the BSS shall allocate a circuit.

In the case where several circuit pools (groups of circuits supporting the same channel types) are available on the BSS MSC interface, the terrestrial circuit allocated by the MSC, if any, is chosen taking into account the circuit pool the circuit belongs to and the required channel type.

The management of priority levels is implementation dependent, under operator control.

If queuing is managed, new requests which cannot be served immediately are put in the queuing file according to the indicated priority levels.

The priority levels and the preemption indicators may (singularly or in combination) be used to determine whether the assignment has to be performed unconditionally and immediately. This would lead to triggering of the preemption procedure which may then cause the forced release or forced handover of a lower priority connection if no free resource is immediately available.

Whilst the process and the extent of the preemption procedure is operator dependent, the preemption indicators (refer to sub-clause 3.2.2.18.), if given in the ASSIGNMENT REQUEST, shall be treated on a per connection basis as follows:

– the last received "Preemption Vulnerability indicator" and priority levels shall prevail.

– if the "Preemption Capability indicator" bit is set to 1, then this allocation request can trigger the running of the preemption procedure.

– if the "Preemption Capability indicator" bit is set to 0, then this allocation request cannot trigger the preemption procedure.

– if the "Preemption Vulnerability" bit is set to 1, then this connection is vulnerable and shall be included in the preemption process or procedure and as such may be subject to forced release or forced handover.

– if the "Preemption Vulnerability" bit is set to 0, then this connection is not vulnerable to preemption and shall not be included in the preemption process and as such may not be subject to forced release or forced handover.

– if no priority Information Element has been received, both "Preemption Capability" and "Preemption Vulnerability" bits shall be regarded as set to 0.

The BSS shall ignore the classmark information included in the ASSIGNMENT REQUEST message if such information has already been received from the MS.

The radio assignment procedure on the radio path is described in 3GPP TS 04.18. When the BSS is satisfied that the radio assignment procedure has been successfully accomplished (e.g. by receipt of a radio interface ASSIGNMENT COMPLETE message) it will stop timer T10 and return an ASSIGNMENT COMPLETE message over the BSS MSC interface. This will implicitly release the old dedicated radio resource(s) at the BSS. If an intra-BSS cell change has occurred during the assignment, the new cell identity is included in the ASSIGNMENT COMPLETE message and a HANDOVER PERFORMED message is not required. If the MSC gave the BSS some freedom in resource type selection, the choices made by the BSS are indicated in the ASSIGNMENT COMPLETE message. If the BSS has to allocate a circuit, the ASSIGNMENT COMPLETE message includes the identity of the circuit allocated by the BSS.

When several circuit pools are present on the BSS MSC interface, and when the circuit is allocated by the MSC, the "circuit pool" information element shall be included in the ASSIGNMENT COMPLETE. The "circuit pool" field will indicate to the MSC the circuit pool of the CIC given in the ASSIGNMENT REQUEST message.

If the assignment did not require a change of radio resource(s), and consequently no 3GPP TS 04.18 radio assignment procedure had been invoked, then the ASSIGNMENT COMPLETE message shall be returned to the MSC as soon as the requested resources have been allocated within the BSS.

If the assignment requires a change of terrestrial circuit or in the case of assignment for signalling the release of a previously used terrestrial circuit, the change or release shall be performed before the ASSIGNMENT COMPLETE message is sent and the BSS shall consider that the old terrestrial circuit is idle.

After the completion of the assignment procedure, until the connection is released or the MSC performs a new assignment, any dedicated resource assigned to the mobile station, e.g. at internal handover, must be in accordance with the description in the ASSIGNMENT REQUEST message.

In the case of voice group calls the MSC may inform the BSS to which voice group call an MS belongs to and whether the MS is a talker or listener in the voice group call, the BSS may decide to allocate and assign a voice group call channel relating to the group call reference. If the BSS allocates a voice group call channel it will send the ASSIGNMENT COMPLETE message and then immediately afterwards send a CLEAR REQUEST cause "Joined group call channel".

In the case where localised service area is supported the MSC may inform the BSS as to which LSA identities that the mobile has preferences by sending the LSA INFORMATION message. The BSS stores this information and uses it when determining the target cell list for handover. The algorithm for determining the target cell list for handover is not defined further in this technical specification. The reception of another message containing LSA identities for the connection will replace the LSA identities previously received. The BSS, in the case where localised service area is supported, will indicate the LSA identity of the serving cell in the ASSIGNMENT COMPLETE if it corresponds to one of the LSA identities received in the latest LSA INFORMATION or the HANDOVER REQUEST messages.

In the case where Intersystem handover to other RAT’s is supported, the MSC may inform the BSS, if preference for other radio access technologies (Service based handover) shall be applied to the MS connection. In such cases the MSC sets the Service Handover Information Element accordingly in the ASSIGNMENT REQUEST message. The Service Handover information is stored in the BSS throughout the connection and is used in the Handover evaluation process.

3.1.1.2 Assignment Failure

The following failure conditions may occur:

The BSS may not be able to use the terrestrial resource that the MSC has indicated in which case an ASSIGNMENT FAILURE message will be returned to the MSC with the cause set to "requested terrestrial resource unavailable".

If the requested channel type or resource (e.g. channel rate, speech version, etc.) indicated in the ASSIGNMENT REQUEST message is not available in the BSS, then an ASSIGNMENT FAILURE message shall be returned to the MSC. The appropriate failure cause will be included in the message (Cause value: "requested transcoding/rate adaptation unavailable" or "requested speech version unavailable").

If, on reception by the BSS of an ASSIGNMENT REQUEST message allocating a circuit, the circuit pool implied by the CIC information element is incompatible with the channel type indicated (that is, the pool does not support any of the radio resources indicated by the channel type) an ASSIGNMENT FAILURE shall be returned to the MSC with the failure cause set to "circuit pool mismatch".

If, on reception by the BSS of an ASSIGNMENT REQUEST message allocating a circuit, the circuit pool implied by the CIC is compatible with the channel type indicated (that is, the pool supports at least one of the radio resource types indicated by the channel type), but the BSS still wishes to change the circuit pool, it sends an ASSIGNMENT FAILURE with the cause "switch circuit pool" and the "circuit pool list" information element.

The "circuit pool" information element, when present in the ASSIGNMENT FAILURE, indicates to the MSC which circuit pool the CIC indicated in the ASSIGNMENT REQUEST belongs to. This can be used by the MSC to correct its tables (CIC/circuit pool). The "circuit pool list" information element, when present in the ASSIGNMENT FAILURE, is used when the BSS wishes to indicate to the MSC its preferred circuit pools. The circuit pools in the "circuit pool list" information element shall be given in order of preference. In the case of an ASSIGNMENT FAILURE with the cause "circuit pool mismatch", the MSC may decide to block the circuit and to send an O & M notification.

The BSS may not receive a radio interface ASSIGNMENT COMPLETE message from the MS in which case the timer T10 will expire. In this case an ASSIGNMENT FAILURE message is returned to the MSC and the assignment procedure is terminated (cause value: radio interface message failure).

If the cell for which the assignment is intended is congested, the BSS may indicate an impending directed retry attempt by sending ASSIGNMENT FAILURE (Cause value: directed retry).

If the radio channel assignment fails for any other reason then an ASSIGNMENT FAILURE message will be returned to the MSC, the procedure will terminate, and the associated references concerning the old dedicated resource(s) should be maintained until explicitly released by the MSC. It should be noted that if the MS fails to assign after receiving a radio interface ASSIGNMENT COMMAND and returns to the old channels as detailed in 3GPP TS 04.08, then the radio interface ASSIGNMENT FAILURE message received from the MS will cause an ASSIGNMENT FAILURE message to be returned to the MSC (cause value: "Radio interface failure, reversion to old channel").

If the BSS has received LSA INFORMATION or HANDOVER REQUEST message indicating LSA only access and all available radio resources are outside the allowed LSAs, assignment may fail and ASSIGNMENT FAILURE message may be sent to the MSC (cause value: "LSA not allowed").

If all available radio resources are defined for exclusive access and the connection is not allowed to access these resources, assignment may fail and ASSIGNMENT FAILURE message may be sent to the MSC (cause value: "LSA not allowed").

Other possible Cause values which may be returned with the ASSIGNMENT FAILURE message are: "equipment failure", "no radio resource available", "O&M intervention". If an unrecognised cause value is received, the Class of the cause value should be used to determine the MSC’s action.

In the case where the MSC has attempted to assign a terrestrial circuit and an ASSIGNMENT FAILURE message has been returned then both the MSC and the BSS shall consider that the terrestrial circuit is idle (except as described below in sub-clause 3.1.1.3) and therefore no explicit clearing sequence is needed.

The MSC may not be able to use the terrestrial resource that the BSS has indicated. In this case, the procedure is nevertheless considered terminated successfully, and it is up to the MSC to correct the situation, e.g., by a circuit re-selection procedure.

All messages concerned with an assignment are sent using the connection oriented mode of the SCCP.

3.1.1.3 Abnormal Conditions

If the BSS receives an ASSIGNMENT REQUEST message calling up a terrestrial circuit that is already assigned to another call then an ASSIGNMENT FAILURE message will be returned with a Cause value of: "terrestrial circuit already allocated" and no action will be taken on the radio interface.

If the BSS receives an ASSIGNMENT REQUEST message allocating a terrestrial circuit which has been blocked by a global block message, then an ASSIGNMENT FAILURE message shall be sent (Cause value: "requested terrestrial resource unavailable"). A single global BLOCK message (not repeated and not guarded by timer T1) shall be sent for that concerned terrestrial circuit.

If an external handover becomes necessary during an assignment, for reasons of radio conditions or congestion (directed retry), the BSS may initiate the handover whilst the assignment is in progress. In this situation, if a HANDOVER COMMAND is received by the BSS, it must not be ignored.

3.1.2 Blocking and Unblocking

As described in sub-clause 3.1.1 the assignment procedure depends upon one side, the MSC or the BSS, choosing the terrestrial resource to be used. If the entity on one side puts out of service any terrestrial circuit, it needs to inform the peer entity on the other side of the interface. This is performed by using a simple blocking/unblocking procedure. The block messages used to support this procedure are sent as global messages (i.e. using the SCCP connectionless mode). Each message refers to one or more terrestrial circuits accessed through the BSS MSC interface. The circuit is identified by its Circuit Identity Code.

The support of blocking/unblocking procedures is dependent on which side allocates the circuits.

A circuit is said to be « locally blocked » on a given side if it has been put out of service for a local reason, and to be « remotely blocked » if a BLOCK message about this circuit has been received from the peer entity.

3.1.2.1 Successful Operation

The procedure operates as follows:

Initial conditions are assumed to be that all circuits are remotely unblocked.

An entity may locally block a terrestrial circuit because:

– Operation and Maintenance intervention makes the circuit unavailable for use (Cause value: "O and M intervention").

– An equipment failure makes the circuit unavailable (Cause value: "equipment failure").

– Radio resource is not accessible from the terrestrial circuit (Cause value: "no radio resource available").

When and if the party that does not allocate the circuits (the Circuit Slave) decides to locally block a terrestrial circuit, it shall immediately mark that terrestrial circuit as "blocked" (to stop any future allocation of that terrestrial circuit) and shall then send a block message to the peer entity allocating the circuits (the Circuit Master) and start timer T1 (T20, T21, T22).

The BLOCK message contains the Circuit Identity Code indicating the terrestrial circuit that is to be remotely blocked and a Cause Information Element indicating the reason for blocking. Typical Cause values are: "no radio resources available", "O and M intervention", "equipment failure".

A BLOCK message in the MSC to BSS direction may also contain an indication that the connection using the circuit, if any, must be released ; in such a case the circuit master shall check if the circuit is in use and shall release the connection that uses it.

NOTE: This allows the MSC to simultaneously block the circuit and to release the connection using the circuit, if any, and then to prevent use of the circuit by the BSS between connection release and blocking.

If the CIRCUIT GROUP BLOCK message is applied by the circuit slave the circuits to be remotely blocked are indicated in the status field of the Circuit Identity Code List (3.2.2.31).

Receipt of a block message (BLOCK or CIRCUIT GROUP BLOCK) at the circuit master from the circuit slave will indicate to the circuit master that the identified circuits are unavailable for reselection. If a call is in progress on any of the identified terrestrial circuits then it will be unaffected by this procedure unless explicitly requested, the circuits will however be "camp on blocked". Such circuits shall be remotely blocked as soon as that call is no longer in progress, or active.

On receipt of a BLOCK message asking for the release of the connection using the circuit if any, and if the BSS detects that there exists a connection using the indicated circuit, the BSS shall attempt to release that connection, e.g., by sending a CLEAR REQUEST message on the corresponding SCCP connection. As specified in sub-clause 3.1.17, if the SCCP connection has been lost, the BSS will detect it when attempting to release the connection and the whole connection is released as a consequence.

An appropriate blocking acknowledge message (BLOCKING ACKNOWLEDGE or CIRCUIT GROUP BLOCKING ACKNOWLEDGE) will be returned to the circuit slave by the circuit master to acknowledge receipt of the block message and to indicate that any necessary action has been taken.

The CIRCUIT GROUP BLOCKING ACKNOWLEDGEMENT message is accepted as the appropriate acknowledgement only if the indicated Circuit Identity Code and the returned Range field of the Circuit Identity Code List match the corresponding parameter values of the respective initiating message. Otherwise the message is considered as not expected.

On receipt of the blocking acknowledge the circuit slave shall stop timer T1 (T20, T21, T22).

The resource involved will be assumed to be remotely blocked by the circuit master until either an unblock (UNBLOCK or CIRCUIT GROUP UNBLOCK) or RESET message is received relevant to that resource.

If the circuit slave wishes to unblock a blocked circuit and return it to service then it shall immediately mark the circuit as "locally unblocked" and then send an unblock message, and start timer T1 (T20, T21, T22).

If an unblock message (UNBLOCK or CIRCUIT GROUP UNBLOCK) is received at the circuit master for a blocked resource then the resource will be marked as not remotely blocked and an unblocking acknowledge message (UNBLOCKING ACKNOWLEDGE or CIRCUIT GROUP UNBLOCKING ACKNOWLEDGE) will be returned to the circuit slave. The circuit slave shall stop timer T1 (T20, T21, T22) on receipt of this unblocking acknowledge.

The CIRCUIT GROUP UNBLOCKING ACKNOWLEDGEMENT message is accepted as the appropriate acknowledgement only if the indicated Circuit Identity Code and the returned Range field of the Circuit Identity Code List match the corresponding parameter values of the respective initiating message. Otherwise the message is considered as not expected.

Figure 10 shows an overview of the blocking procedure in the case the circuit slave is the BSS.

NOTE: Timer T1 is used to supervise a single circuit block/unblock procedure on the BSS side, whilst T20 is used to supervise the circuit group block/unblock procedure on the BSS side, timer T21 is used to supervise a single circuit block/unblock procedure on the MSC side, and T22 is used to supervise the circuit group block/unblock procedure on the MSC side.

3.1.2.2 Abnormal Conditions

If a blocking acknowledge message is not received for a block message within T1 (T20, T21, T22) seconds then the block message will be repeated. If this occurs a second time the circuits will be kept marked as locally blocked, and the situation must then be resolved internally within the circuit slave or by O&M procedures.

If an unblocking acknowledge message is not received for an unblock message before expiry of timer T1(T20, T21, T22) then the unblock message will be repeated. If this occurs a second time, this situation may be reflected to the O&M, which shall resolve the possible conflict. The unblock message is repeated at most one time. Whatever the outcome of possible repetitions, the concerned circuits remain locally "unblocked".

If the MSC allocates the circuits, and an ASSIGNMENT REQUEST or HANDOVER REQUEST message is received by the BSS allocating a circuit which is marked at the BSS as blocked then an ASSIGNMENT FAILURE message or a HANDOVER FAILURE message (respectively) followed by a BLOCK message shall be sent to the MSC.

If the BSS allocates the circuits, and an ASSIGNMENT COMPLETE, HANDOVER REQUEST ACKNOWLEDGE or CHANGE CIRCUIT ACKNOWLEDGE message is received by the MSC allocating a circuit which is marked at the MSC as blocked, it is up to the MSC how to correct the situation, e.g., by performing a circuit re-selection procedure and sending a BLOCK message.

3.1.2.2.1 Applying to the Single Circuit Block Procedure

i) If a BLOCK message is received for a circuit already remotely blocked, a BLOCKING ACKNOWLEDGE message will be sent.

ii) If an UNBLOCK message is received for a remotely unblocked circuit, an UNBLOCKING ACKNOWLEDGE message will be sent.

iii) If a BLOCKING ACKNOWLEDGE message, which is not expected as an acknowledgement for a BLOCK message, is received:

a) relating to a circuit which is locally blocked, the BLOCKING ACKNOWLEDGE message is discarded.

b) relating to a circuit, which is not locally blocked, then an UNBLOCK message will be sent.

iv) If an UNBLOCKING ACKNOWLEDGE message, which is not expected as an acknowledgement for an UNBLOCK message, is received:

a) relating to a circuit which is not locally blocked, the received UNBLOCKING ACKNOWLEDGE message is discarded.

b) relating to a circuit, which is locally blocked, then a BLOCK message will be sent.

3.1.2.2.2 Applying to the Circuit Group Block Procedure

v) If a CIRCUIT GROUP BLOCK message is received relating to remotely blocked circuits then blocking acknowledgement indications for those circuits are given in the status field of the corresponding CIRCUIT GROUP BLOCKING ACKNOWLEDGE message which will be sent in response.

vi) If a CIRCUIT GROUP UNBLOCK message is received relating to circuits which are not remotely blocked then unblocking acknowledgement indications for those circuits are given in the status field of the corresponding CIRCUIT GROUP UNBLOCKING ACKNOWLEDGE message which will be sent in response.

vii) When the circuit master upon receipt of a CIRCUIT GROUP BLOCK (UNBLOCK) message is not able to give an appropriate blocking (unblocking) acknowledgement indication for each Circuit Identification Code (e.g. because that/those Circuit Identification Code(s) is (are) not allocated to any circuit at the receiving entity) for which a block (unblock) indication is given in the status field of the received CIRCUIT GROUP BLOCK (UNBLOCK) message, then no blocking (unblocking) acknowledgement relating to that/those Circuit Identification Code(s) will be given in the status field of the corresponding CIRCUIT GROUP BLOCKING (UNBLOCKING) ACKNOWLEDGE message which will be sent in response.

viii) If a CIRCUIT GROUP BLOCKING ACKNOWLEDGE message in response to a CIRCUIT GROUP BLOCK message is received by the circuit slave containing in the status field no blocking acknowledgement for circuits which are to be blocked due to the previously sent CIRCUIT GROUP BLOCK message, then the CIRCUIT GROUP BLOCK message will be repeated for the circuit(s) concerned.

If this occurs a second time the concerned circuit(s) will be kept marked as locally blocked, and the situation must then be resolved internally within the circuit slave or by O&M procedures.

ix) The same rule applies to the Circuit Group Unblocking procedure with the only difference that the involved terrestrial circuits are kept marked as locally "not blocked".

x) If a CIRCUIT GROUP BLOCKING ACKNOWLEDGE message in response to a CIRCUIT GROUP BLOCK message is received by the circuit slave containing in the status field blocking acknowledgement indications for circuits which are not to be blocked, then an appropriate unblock message will be sent for the circuit(s) concerned.

xi) If a CIRCUIT GROUP UNBLOCKING ACKNOWLEDGE message in response to a CIRCUIT GROUP UNBLOCK message is received by the circuit slave containing in the status field unblocking acknowledgement indications for circuits which have to remain marked as locally blocked then an appropriate block message will be sent for the circuit(s) concerned.

xii) If a CIRCUIT GROUP BLOCKING ACKNOWLEDGE message which is not expected and not accepted as an acknowledgement for a CIRCUIT GROUP BLOCK message is received:

a) relating to circuits which all are in the status locally blocked, then the received CIRCUIT GROUP BLOCKING ACKNOWLEDGE message will be discarded;

b) related to circuits part or all of which are not in the status locally blocked then an appropriate unblock message will be sent for the relevant circuit(s).

xiii) If a CIRCUIT GROUP UNBLOCKING ACKNOWLEDGE message which is not expected and not accepted as an acknowledgement for a CIRCUIT GROUP UNBLOCK message is received:

a) relating to circuits none of which is in the status locally blocked, then the received CIRCUIT GROUP UNBLOCKING ACKNOWLEDGE message will be discarded;

b) related to circuits part or all of which are locally blocked then an appropriate block message will be sent for the relevant circuit(s).

3.1.3 Resource Indication

The purpose of the resource indication procedure is to inform the MSC of:

– the amount of radio resource that is spare at the BSS and available for traffic carrying purposes; and

– of the total amount of the accessible radio resource (i.e. available for service or currently assigned).

This cannot easily be derived from the traffic that the MSC is carrying. The MSC may take these pieces of information into account for the external handover decision.

3.1.3.1 Successful Operation

The procedure relates to a single cell.

The MSC determines the resource information (i.e. the resource available information and optionally the total resource accessible information) and the manner in which the BSS transfers this resource information to the MSC by sending a RESOURCE REQUEST message to the BSS. This message shall contain a Resource Indication Method Information Element which can be set to one of the following values:

i) (Spontaneous resource information expected): The BSS shall send the first RESOURCE INDICATION message without any resource information to the MSC immediately as an acknowledgement to the RESOURCE REQUEST message and then any further RESOURCE INDICATION messages spontaneously every time conditions, defined by O&M, are met in the BSS for the considered cell (e.g. traffic thresholds, or time interval between two messages). If the O&M conditions for sending RESOURCE INDICATION messages are met, the BSS may use the Periodicity IE received in the RESOURCE REQUEST message to determine the time interval between indications, except that, if the MSC sets the Periodicity IE to zero then the BSS shall ignore the Periodicity IE. The BSS stays in this mode until the receipt of a new RESOURCE REQUEST message for the same cell, or a reset occurs;

ii) (One single resource information expected): The BSS shall return a single RESOURCE INDICATION message with some resource information immediately. If the RESOURCE REQUEST message does not contain an Extended Resource indicator IE the BSS shall then cease any resource information transfer related to the cell until the receipt of either a new RESOURCE REQUEST message or a reset. If the RESOURCE REQUEST message contains an Extended Resource Indicator IE the BSS shall obey the ‘Subsequent Mode’ field;

iii) (Periodic resource information expected): The BSS shall return a RESOURCE INDICATION message with some resource information immediately, and then periodically, with a period set by MSC*, until the receipt of either a new RESOURCE REQUEST message for the same cell or a reset.

* (The period shall equal the value of the periodicity parameter times 100 ms. If the value of the periodicity parameter is zero, then the message should be treated as one containing an incorrect value according to sub-clause 3.1.19.4, case 2.)

iv) (No resource information expected): The BSS shall immediately return a single RESOURCE INDICATION message without any resource information as an acknowledgement to the RESOURCE REQUEST message and then the BSS to MSC transfer of resource information related to the cell is disabled until the receipt of either a new RESOURCE REQUEST message for the same cell or a reset.

The default mode is iv); after a reset, this mode is set for all the cells of a BSS.

The transfer of resource information related to a given cell from the BSS to the MSC occurs when the Resource Indication Method Information Element is set to one of the values i) to iii) in the BSS. The BSS sends RESOURCE INDICATION messages to the MSC, under the conditions explained above. The RESOURCE INDICATION message shall contain the Resource Indication Method Information Element with the same value as it was requested by the MSC, i.e. the BSS is not allowed to select a method different from the one requested by the MSC.

Furthermore, the RESOURCE INDICATION message may contain the Resource Available IE and the Total Resource Accessible IE dependent on the selected method and, in case of the Total Resource Accessible IE, also dependent on the request from the MSC. If the RESOURCE INDICATION message is just taken as a simple acknowledgement as stated in method i) and iv), the Total Resource Accessible IE shall not be returned independent of whether it was requested by the MSC or not.

For each idle channel the level of interference will be averaged over a period of Intave. (Intave is a parameter set by O&M command on a per cell basis). This averaging will be performed immediately before the transmission of the RESOURCE INDICATION message. The result of this averaging will be used to classify the average interference level on the idle channels into five interference bands.

The Resource Available Information Element contains two pieces of information for each of the five interference bands:

– The number of half rate TCHs available in that band.

– The number of full rate TCHs available in that band.

The levels of the five bands are defined by O&M.

3.1.4 Reset

3.1.4.1 Global Reset Procedure

The purpose of the reset procedure is to initialise the BSS and MSC in the event of a failure. The procedure is a global procedure applying to a whole BSS, and therefore all messages relating to the reset procedure are sent as global messages using the connectionless mode of the SCCP.

If only a limited part of the MSC or BSS has suffered a failure then clearing procedures can be used to clear only those affected calls.

3.1.4.1.1 Reset at the BSS

In the event of a failure at the BSS which has resulted in the loss of transaction reference information, a RESET message is sent to the MSC. This message is used by the MSC to release affected calls and erase all affected references, and to put all circuits into the idle state.

After a guard period of T2 seconds a RESET ACKNOWLEDGE message is returned to the BSS indicating that all references have been cleared.

After the sending of the RESET to the MSC a BSS that does not allocate the circuits shall initiate blocking procedures (Block or Circuit group block procedures) for all circuits that are locally blocked on the BSS side, the MSC shall respond as specified in sub-clause 3.1.2. The sending of block messages shall be done without waiting for the acknowledgement to the RESET message.

Upon receipt of a RESET message from the BSS an MSC that does not allocate the circuits shall send block messages (BLOCK or CIRCUIT GROUP BLOCK) for all circuits that are locally blocked on the MSC side, the BSS shall respond to these with blocking acknowledge messages as described in sub-clause 3.1.2.

3.1.4.1.2 Reset at the MSC

In the event of a failure at the MSC which has resulted in the loss of transaction reference information, a RESET message is sent to the BSS. This message is used by the BSS to release affected calls and erase all affected references.

After the sending of the RESET to the BSS, an MSC that does not allocate the circuits shall initiate blocking procedures (Block or Circuit group block procedures) for all circuits that are locally blocked on the MSC side, the BSS shall respond as specified in sub-clause 3.1.2. The sending of block messages shall be done without waiting for the acknowledgement to the RESET message.

Upon receipt of a RESET message from the MSC a BSS that does not allocate the circuits shall send block messages (BLOCK or CIRCUIT GROUP BLOCK) for all circuits that were previously locally blocked on the BSS side, the MSC shall respond to these with blocking acknowledge messages as described in sub-clause 3.1.2.

After a guard period of T13 seconds a RESET ACKNOWLEDGE message is returned to the MSC, indicating that all MSs which were involved in a call are no longer transmitting and that all references at the BSS have been cleared.

3.1.4.1.3 Abnormal Conditions
3.1.4.1.3.1 Abnormal Condition at the BSS

If the BSS sends a RESET message to the MSC and receives no RESET ACKNOWLEDGE message within a period T4 then it shall repeat the entire reset procedure. The sending of the RESET message is repeated a maximum of "n" times where n is an operator matter. After the n-th unsuccessful repetition the procedure is stopped and the maintenance system is informed.

3.1.4.1.3.2 Abnormal Condition at the MSC

If the MSC sends a RESET message to the BSS and receives no RESET ACKNOWLEDGE message within a period T16 then it shall repeat the entire reset procedure. The sending of the RESET message is repeated a maximum of "n" times where n is an operator matter. After the nth unsuccessful repetition the procedure is stopped and the maintenance system is informed.

3.1.4.2 Reset Circuit

The purpose of the reset circuit procedure is to restore the information in MSC/BSS in the case of a failure which has affected only a small part of the equipment (e.g. abnormal SCCP connection release).

3.1.4.2.1 Reset Circuit at the BSS

If a circuit has to be put to idle at the BSS due to an abnormal SCCP-connection release, a RESET CIRCUIT message will be sent to the MSC. When the MSC receives this message, it clears the possible call and puts the circuit, if known, to the idle state. If the circuit is known, a RESET CIRCUIT ACKNOWLEDGE message is returned to the BSS. If circuit allocation is done by the BSS and if the circuit is locally blocked at the MSC a BLOCK message shall be returned to the BSS. The BSS shall then respond with a BLOCKING ACKNOWLEDGE message, as described in sub-clause 3.1.2. If the circuit is unknown in the MSC, an UNEQUIPPED CIRCUIT message is returned to the BSS.

Timer T19 is used at the BSS to supervise the reset circuit procedure. If the timer elapses before a response (RESET, RESET CIRCUIT ACKNOWLEDGE or UNEQUIPPED CIRCUIT) is returned to the BSS, the procedure is repeated.

3.1.4.2.2 Reset Circuit at the MSC

If a circuit has to be put to idle at the MSC due to an abnormal SCCP-connection release, a RESET CIRCUIT message will be sent to the BSS. When the BSS receives a RESET CIRCUIT message, it shall respond with a RESET CIRCUIT ACKNOWLEDGE message in case the circuit can be put to idle. If circuit allocation is done by the MSC and if the circuit is locally blocked at the BSS a BLOCK message shall be returned to the MSC. The MSC shall then respond with a BLOCKING ACKNOWLEDGE message, as described in sub-clause 3.1.2. If the circuit is unknown at the BSS, the BSS shall return an UNEQUIPPED CIRCUIT message to the MSC.

Timer T12 is used at the MSC to supervise the reset circuit procedure. If the Timer elapses before a response (RESET, RESET CIRCUIT ACKNOWLEDGE, UNEQUIPPED CIRCUIT or BLOCK) the reset circuit procedure is repeated.

3.1.4.2.3 Abnormal conditions

If a RESET message is received after sending of a RESET CIRCUIT message and before receipt of the corresponding response the respective reset circuit procedure is stopped, i.e. reception of the corresponding RESET CIRCUIT ACKNOWLEDGE message is not required and no repetition is necessary.

If a RESET CIRCUIT message is received immediately after a RESET CIRCUIT message has been sent for the same circuit, the corresponding acknowledgement messages are returned.

The sending of the RESET CIRCUIT message is repeated a maximum of "n" times where n is an operator matter. After the n-th unsuccessful repetition the procedure is stopped and the maintenance system is informed.

3.1.5 External Handover

The details of the radio information as far as handover is concerned are given in 3GPP TS 04.08. The relevant network information is given in 3GPP TS 03.09.

Using this protocol the BSS should support handover transitions to and from any combinations of the following:

– Channel

– SDCCH

– Full Rate TCH

– Half Rate TCH

– Multiple Full Rate TCHs

In this specification three procedures are defined which can be used for handover. They are:

– Handover Required Indication;

– Handover Resource Allocation;

– Handover Execution.

(Figure 16 shows an example of a complete handover procedure)

For any HANDOVER REQUIRED message at most one HANDOVER COMMAND message may be sent.

In the case of inter-MSC handover the term "the MSC" in this sub-clause is taken to mean the relevant MSC in the handover operation.

The handover procedures are specified in the following sub-clauses.

All messages concerned with handover, with the exception of HANDOVER CANDIDATE ENQUIRE and HANDOVER CANDIDATE RESPONSE messages, are sent using the connection oriented mode of the SCCP.

3.1.5.1 Handover Required Indication

The handover required indication procedure allows a BSS to request that a handover is to be carried out for a particular MS, currently allocated one or more dedicated resources. This is done by generating a HANDOVER REQUIRED message and sending it from the BSS to the MSC. If so required by the BSS, the MSC informs the BSS if the handover cannot be carried out. This is done by a HANDOVER REQUIRED REJECT message. The HANDOVER REQUIRED message is sent using the BSSAP SCCP connection already set up for that transaction. As part of the BSS’s functions, the BSS continually monitors all radio information and compares it with parameters such that if the transmission quality of a given parameter (or set of parameters) passes a predetermined threshold (set by O&M) then a HANDOVER REQUIRED message is generated and sent to the MSC.

3.1.5.1.1 Generation of the HANDOVER REQUIRED message

Generation of the HANDOVER REQUIRED message can be for the following reasons:

– The BSS has detected that a radio reason exists for a handover to occur.

– The MSC has initiated a handover candidate enquiry procedure, and this MS is currently a candidate.

– A cell change is required at call setup due to congestion, e.g. directed retry.

The HANDOVER REQUIRED message contains the following information elements:

– Message Type;

– Cause;

– Cell Identifier List (preferred).

It should also contain the information elements: "Current channel type 1", "Old BSS to New BSS information" and, in case the current channel mode is speech, "Speech version (used)".

The "Old BSS to New BSS information" is used to pass Field Elements from the old BSS to the new BSS. The information in the "Old BSS to New BSS information" is transparent for the MSC. When the "Old BSS to New BSS information" is present in the HANDOVER REQUIRED message the MSC shall pass it unchanged to any BSS associated to "Cell Identifier List (preferred)" when initiating the Handover resource allocation procedure. The old BSS must ensure that the information contained in the "Old BSS to New BSS information" information element is valid for all cells in the "Cell Identifier List (preferred)".

Section 3.2.1.9 gives coding details of the above message.

The "Cause" field indicates the reason for the HANDOVER REQUIRED message e.g. "uplink quality poor" or "response to MSC invocation" in the case of traffic reasons indicated by the MSC.

The Cause value sent should be an indication which can be taken into account at the target BSS in future handover decision processes, e.g. to reduce oscillations between BSSs due to the fact that some information (on which the old BSS decided to initiate the handover) is not available at the target BSS (e.g. distance, traffic…).

If present the "Response Request" Information Element indicates, that the BSS requires an indication if the HANDOVER REQUIRED message does not result in a HANDOVER COMMAND message.

If the BSS wants to change the CIC due to a channel change, the BSS sends a HANDOVER REQUIRED message with the cause "switch circuit pool" and the "circuit pool list" information element. The "circuit pool list" information element will allow the BSS to indicate to the MSC from which circuit pool or pools the new CIC should be chosen.

The "Cell Identifier List (preferred)" shall identify "n" preferred cells. The identified cells are given in order of preference. The algorithm by which the BSS produces this list is Operator dependent and is not addressed in this Technical Specification. The "n" number of preferred cells is a parameter set by O&M and shall range from 1 to 16. If "n" number of cells cannot be identified, then only as many as are available shall be encoded and sent (as specified in sub-clause 3.2.2.27). If a LSA information element has been received for a mobile subscriber indicating LSA only access, the "Cell Identifier List" shall contain only cells that are allowed for the subscriber. Exclusive access cells are included into the "Cell Identifier List (preferred)" only if they are allowed for the subscriber or if the connection is an emergency call.

It is mandatory for the BSS to be able to produce this "Cell Identifier List (preferred)". The sending of this list is controlled by the O&M parameter "n". It is mandatory for the MSC to be able to receive and interpret this Information Element.

The BSS may recommend to the MSC to allow queuing or not in the handover resource allocation procedure by indication in the "Queuing indicator" information element within the HANDOVER REQUIRED message.

The old BSS may inform the new BSS of the presently configured channel in the Current Channel Type 1 information element and in the Current Channel type 2 Field Element. The information contained may be used by the new BSS (e.g. when building the radio interface HANDOVER COMMAND message). Where discrepancies occur between the Current Channel Type 1 and the Current Channel Type 2 then the information in the Current Channel Type 2 shall take precedence if understood by the new BSS.

If, for this mobile station, the old BSS has received a Gb interface SUSPEND ACK PDU, then the old BSS shall include the GPRS Suspend information field in the Old BSS to New BSS IE in the HANDOVER REQUIRED message.

If the old BSS received a GPRS Suspend information field in the Old BSS to New BSS IE in any preceding HANDOVER REQUEST message received by the old BSS, then, the old BSS shall include the GPRS Suspend information field in the Old BSS to New BSS IE in the HANDOVER REQUIRED message.

The old BSS may recommend to the new BSS to allow pre-emption or not allow pre-emption by sending the "prec" bit. The new BSS may take this information into account when performing the Handover resource allocation procedure.

The old BSS may inform the new BSS of radio information pertaining to the target cell in the "Target cell radio information" field element. The old BSS shall only send the "Target cell radio information" field element when it sends a single cell in the "Cell Identifier List (preferred)". This field element may be used by the new BSS (e.g. for radio channel selection).

NOTE: It is not recommended that this information element is included if more than one cell is sent in the "Cell Identifier List (preferred)".

The old BSS may inform the new BSS of the presently configured channel in the Current Channel Type 1 information element and in the Current Channel type 2 Field Element. The information contained may be used by the new BSS (e.g. when building the radio interface HANDOVER COMMAND message). Where discrepancies occur between the Current Channel Type 1 and the Current Channel Type 2 then the information in the Current Channel Type 2 shall take precedence if understood by the new BSS.

If the present speech codec is a multi-rate speech codec, the old BSS may inform the new BSS of the current multi-rate codec configuration by including the MultiRate configuration information Field Element in the "Old BSS to New BSS information" information element. If the new BSS assigns a multi-rate speech codec this information may be used by the new BSS, to determine whether or not to include an MultiRate Configuration IE when building the radio interface HANDOVER COMMAND message.

If the old BSS support dual transfer mode and the mobile station is in dual transfer mode in the old cell, the old BSS may provide information about the current resources by including the Dual Transfer Mode information field element in the Old BSS to New BSS information information element. The new BSS may use this information to determine the resources for the mobile station in the new cell (e.g. half rate traffic channel, adjacent resources available, EGPRS-capable resource).

The HANDOVER REQUIRED message shall be updated and repeated by the BSS with a periodicity of T7 until:

– A HANDOVER COMMAND message is received from the MSC, or;

– A RESET message is received, or;

– The reason for the original HANDOVER REQUIRED message disappears e.g. the MS transmission improves, or;

– All communication is lost with the MS as defined in 3GPP TS 04.08, and the transaction is abandoned, or;

– The transaction ends, e.g., call clearing.

3.1.5.2 Handover Resource allocation

This procedure has been defined to allow the MSC to request resources from a BSS in a manner similar to that used for the assignment case. However it does not result in the transmission of any messages over the radio interface, only in the reservation of the resource(s) identified at the BSS, which awaits access of a MS on the reserved channel(s). These reserved resources are then indicated back to the MSC.

In order to support this procedure the MSC sets up a BSSAP SCCP connection to the BSS. This connection is then used to support all BSSAP messages related to the dedicated resource(s).

In case of Voice Group Call, the MSC may reuse the existing Resource Controlling SCCP connection which has been previously set-up with the new BSS.

3.1.5.2.1 Operation of the procedure

The correct operation of the handover resource allocation procedure is as follows:

The MSC sends a HANDOVER REQUEST message to the new BSS (note) from which it requires radio resources. This message contains details of the resource(s) required. If the MSC allocates the A interface circuits, and if the requested resource(s) is/are for speech or data the message also indicates the terrestrial resource that shall be used between the MSC and the BSS. The MSC should only ever ask for resources from the BSS that it knows are not totally incompatible with the nominated circuit. The type of channel(s) required can be different from the type of channel(s) in use, e.g. in the case of directed retry. The description of the resource(s) can either be a complete specification, or give the BSS some freedom in the selection (for instance channel rate selection, speech version selection etc.). The message may also specify the channel(s) in use, and, in case current channel mode is speech, the speech version used.

In case of Voice Group Call, the MSC need not to allocate a new A interface circuit. In such a case, the terrestrial resource which has been allocated during the VBS/VGCS assignment procedure is used as the new terrestrial resource.

On receipt of this message the new BSS shall choose suitable idle radio resources and, if the BSS allocates the A interface circuits and if needed, a terrestrial resource.

In case of Voice Group Call, the new BSS need not to allocate new radio resources. In such a case, the radio resource which has been allocated during the VBS/VGCS assignment procedure is used as the new radio resource.

The management of priority levels – relating to the Information Element "Priority" within the HANDOVER REQUEST message – is implementation dependent, under operator control.

If queuing is managed, new requests which cannot be served immediately are put in the queuing file according to the indicated priority levels.

(Refer to sub-clause 3.1.17 for Queuing Procedure)

As a further operator option, the pre-emption indicators may (alone or along with the priority levels) be used to manage the pre-emption process, which may lead to the forced release or forced handover of lower priority connections.

However, the pre-emption indicators (refer to sub-clause 3.2.2.18), if given in the HANDOVER REQUEST, shall be treated on a per connection basis as follows:

– the last received "Pre-emption Vulnerability" indicator and priority levels shall prevail.

– if the "Pre-emption Capability" bit is set to 1, then this allocation request can trigger the running of the pre-emption procedure.

– if the "Pre-emption Recommendation" bit indicates that pre-emption is recommended by the old BSS, then the new BSS may obey the recommendation and act appropriately based on "Pre-emption Capability Indication" bit.

– if the "Pre-emption Recommendation" bit indicates that pre-emption is not recommended by the old BSS, then the new BSS may obey this recommendation and ignore the "Pre-emption Capability" bit if it is set to 1.

– if the "Pre-emption Recommendation" bit is not present then the pre-emption procedure can be run.

– if the "Pre-emption Capability" bit is set to 0, then this allocation request cannot trigger the pre-emption procedure.

– if the "Pre-emption Vulnerability" bit is set to 1, then this connection is vulnerable and shall be included in the pre-emption process or procedure and as such may be subject to forced release or forced handover.

– if the "Pre-emption Vulnerability" bit is set to 0, then this connection is not vulnerable to pre-emption and shall not be included in the pre-emption process and as such may not be subject to forced release or forced handover.

– if no Priority Information Element has been received, both "Pre-emption Capability" and "Pre-emption Vulnerability" bits shall be regarded as set to 0.

In the case where localised service area is supported, the MSC may inform the BSS as to which LSA identities that the mobile has preferences by sending the LSA INFORMATION message. The BSS stores this information and uses it when determining the target cell list for handover. The algorithm for determining the target cell list for handover is not defined further in this technical specification.

In the case where Intersystem handover to other RAT’s is supported, the MSC may inform the target BSS, if preference for other radio access technologies (Service based handover) shall be applied to the MS connection. In such cases the MSC sets the Service Handover Information Element accordingly in the HANDOVER REQUEST message.The Service Handover information is stored in the BSS throughout the connection and is used in Handover evaluation process.

If a radio resource is available then this will be reflected back to the MSC in a HANDOVER REQUEST ACKNOWLEDGE message. If the MSC gave the BSS some freedom in resource type selection, the choices made by the BSS are indicated in the HANDOVER REQUEST ACKNOWLEDGE message. If the BSS allocates the A interface circuits and such a circuit is needed, the circuit allocated by the BSS is indicated in the HANDOVER ACKNOWLEDGE message. The HANDOVER REQUEST ACKNOWLEDGE message sent by the new BSS shall contain the radio interface message HANDOVER COMMAND within its "Layer 3 Information" Information Element. This "Layer 3 Information" (which is in fact the RR-Layer 3 HANDOVER COMMAND) is transferred by the controlling MSC to the old BSS using the BSSMAP message HANDOVER COMMAND also within the Information Element "Layer 3 Information" of that BSSMAP message. The old BSS then sends to the MS over the radio interface the RR-Layer 3 HANDOVER COMMAND message. Information about the appropriate new channels and a handover reference number chosen by the new BSS are contained in the HANDOVER COMMAND. Knowledge of the channel in use at the old BSS allows the new BSS to minimize the size of the HANDOVER COMMAND message (i.e. to decide whether the mode of the first channel IE need not be included in the HANDOVER COMMAND).

NOTE: The new BSS and the old BSS may be the same.

In the case of external handover the BSS, when localised service area is supported, will indicate the LSA identity of the target cell in the HANDOVER REQUEST ACKNOWLEDGE message if it corresponds to one of the LSA identities received in the HANDOVER REQUEST message.

When several circuit pools are present on the BSS MSC interface, and a circuit has been allocated by the HANDOVER REQUEST message, the "circuit pool" information field shall be included in the HANDOVER REQUEST ACKNOWLEDGE. The "circuit pool" field will indicate to the MSC the circuit pool of the CIC given in the HANDOVER REQUEST message.

The sending of the HANDOVER REQUEST ACKNOWLEDGE by the new BSS to the MSC ends the Handover Resource Allocation procedure. The Handover Execution procedure can now proceed and this is given in sub-clause 3.1.5.3.

The new BSS shall then take all necessary action to allow the MS to access the radio resource(s) that the new BSS has chosen, this is detailed in the 3GPP TS 05 series of Technical Specifications. If the radio resource(s) is a traffic channel or a group of traffic channels, then the new BSS shall at this point switch it through to the terrestrial resource indicated in the HANDOVER REQUEST message, and the necessary transcoding/rate adaption/encryption equipment enabled as detailed in 3GPP TS 04.08.

The optimum procedure for switching through to the target cell at the MSC is not defined in these Technical Specifications.

3.1.5.2.2 Handover Resource Allocation Failure

The following failure conditions of this procedure may occur:

The BSS may not be able to use the terrestrial resource that the MSC has indicated in which case a HANDOVER FAILURE message will be returned with the Cause value set to: "requested terrestrial resource unavailable".

The BSS may not be able to support the requested ciphering algorithm and in this case a HANDOVER FAILURE message shall be returned to the MSC with the Cause value "Ciphering algorithm not supported".

If the requested channel type or resource (e.g. channel rate, speech version, etc.) indicated in the HANDOVER REQUEST message is not available in the BSS, then a HANDOVER FAILURE message shall be returned to the MSC. The appropriate failure cause will be included in the message (Cause value: "requested transcoding/rate adaptation unavailable" or "requested speech version unavailable").

The generation of the HANDOVER FAILURE message terminates the procedure and allows all references in the new BSS to be released.

If, on reception of the HANDOVER REQUEST by the BSS, the circuit pool implied by the CIC information element is incompatible with the channel type indicated (that is, the pool does not support any of the radio resources indicated by the channel type) a HANDOVER FAILURE shall be returned to the MSC with the failure cause set to "circuit pool mismatch".

If, on reception of the HANDOVER REQUEST by the BSS, the circuit pool implied by the CIC is compatible with the channel type indicated (that is, the pool supports at least one of the radio resource types indicated by the channel type), but the BSS still wishes to change the circuit pool, it sends a HANDOVER FAILURE with the cause "switch circuit pool" and the "circuit pool list" information element.

The "circuit pool" information element, when present in the HANDOVER FAILURE, indicates to the MSC which circuit pool the CIC indicated in the HANDOVER REQUEST belongs to. This can be used by the MSC to correct its tables (CIC/circuit pool). The "circuit pool list" information element, when present in the HANDOVER FAILURE, is used when the BSS wishes to indicate to the MSC its preferred circuit pools. The circuit pools in the "circuit pool list" information element shall be given in order of preference. In the case of a HANDOVER FAILURE with the cause "circuit pool mismatch", the MSC may decide to block the circuit and to send an O & M notification.

Other possible cause values which may be returned with the HANDOVER FAILURE message are: "equipment failure", "no radio resource available", "O&M intervention".

The MSC may not be able to use the terrestrial resource that the BSS has indicated. In this case, the procedure is nevertheless considered terminated successfully, and it is up to the MSC to correct the situation, e.g., by a circuit re-selection procedure.

Further actions in the MSC concerning handover depend upon the handover algorithm which is operator dependent. If an unrecognised Handover Failure cause value is received, the Class of the cause value should be used to determine the MSC’s action.

3.1.5.2.3 Abnormal conditions

If after receipt of a HANDOVER REQUEST message, the new BSS receives another HANDOVER REQUEST message on the same SCCP connection, then the later message will be discarded.

If the BSS receives a HANDOVER REQUEST allocating a terrestrial circuit which the BSS has marked as blocked by a previous blocking procedure, then a HANDOVER FAILURE shall be returned to the MSC with the Cause set to "requested terrestrial resource unavailable". A single global BLOCK message (not repeated and not guarded by timer T1) shall be sent for that concerned terrestrial circuit.

If the BSS receives a HANDOVER REQUEST message indicating a target cell which is not controlled by the BSS, then a HANDOVER FAILURE message shall be returned to the MSC with the cause set to "invalid cell".

3.1.5.3 Handover execution

Handover execution in the context of the BSS/MSC interface is the process whereby an MSC instructs an MS to tune to a new dedicated radio resource or to a group of radio resources, which may be on a different cell.

3.1.5.3.1 Operation of the procedure

The correct operation of the procedure is as follows:

The BSSMAP HANDOVER COMMAND message is generated by the MSC and transmitted over the BSSAP connection to the old BSS which is currently supporting the concerned MS. At the old BSS timer T8 is started on the receipt of the BSSMAP HANDOVER COMMAND message. A radio interface HANDOVER COMMAND message is then sent by the old BSS, to the concerned MS. The message contains a handover reference number, previously allocated by the new BSS.

The BSSMAP HANDOVER COMMAND message generated by the MSC may optionally contain a Cell Identifier IE which indicates to the old BSS the target cell identity to which the handover is to be performed. In case of failure, this information allows the old BSS to know on which cell the handover failed.

When the MS accesses the radio resource(s) of the new BSS with a HANDOVER ACCESS burst which contains the received handover reference number then:

– The new BSS checks the handover reference number to ensure that it is the same as expected, and hence that there is a high probability that the correct MS has been captured (if the handover reference is not as expected then the new BSS shall wait for an access by the correct MS);

– If the handover reference number is as expected, the new BSS shall send a HANDOVER DETECT message to the MSC;

– When the MS is successfully in communication with the network, i.e. the RR message HANDOVER COMPLETE has been received from the MS, then the new BSS will immediately send a BSSMAP message HANDOVER COMPLETE to the MSC and terminate the procedure.

In the case where the new BSS hands the MS to a Group call channel, the BSS shall send a CLEAR REQUEST with cause "Joined group call channel" directly after having sent the HANDOVER COMPLETE message.

In the case of point to point calls the MSC shall terminate the procedure with the old BSS by sending a CLEAR COMMAND with cause "Handover successful".

In the case of a handover from a Group call channel the MSC shall terminate the procedure by sending a HANDOVER SUCCEEDED message. On receipt of a HANDOVER SUCCEEDED from the MSC, the old BSS shall stop timer T8.

The old dedicated radio resource(s) and connected terrestrial resource shall remain assigned until either the MSC instructs the old BSS to release the resource(s) by a CLEAR COMMAND or a reset occurs.

After the completion of the handover procedure, until the connection is released or the MSC performs an assignment, any dedicated resource assigned to the mobile station, e.g. at internal handover, must be in accordance with the description in the HANDOVER REQUEST message.

If either:

a CLEAR COMMAND is received from the MSC;

or

a reset is received from the MSC,

before a MS with the correct handover reference accesses the new BSS then the radio resources shall be released and the terrestrial resources marked as idle

The relevant radio interface layer 3 procedures are described in 3GPP TS 04.08.

The MSC always terminates this procedure by use of a clear sequence as follows:

The MSC sends a CLEAR COMMAND to the old BSS. On receipt of a CLEAR COMMAND from the MSC the old BSS shall stop timer T8 and release all involved resources that were allocated to the MS that had been handed over and returns a CLEAR COMPLETE message to the MSC.

On receipt of the CLEAR COMPLETE, the MSC shall initiate the release of the SCCP connection to the old BSS and thereby terminate association with the old BSS for this process.

3.1.5.3.2 Handover Failure

If a HANDOVER FAILURE radio interface message is received from the MS on the old (main) channel by the old BSS, the old BSS shall then send to the MSC the BSSMAP message HANDOVER FAILURE. If the radio interface HANDOVER FAILURE message is the result of the MS returning to the old BSS after failing to establish on the new BSS, then the cause value "radio interface failure, reversion to old channel" shall be included in the BSSMAP message HANDOVER FAILURE. Furthermore, it is recommended that the air interface RR cause be included as well in this message.

If the MSC receives the BSSMAP HANDOVER FAILURE message from the old BSS (with any cause value) and if the target channel is not a Group Call Channel, the handover procedure at the target new BSS is then terminated by the MSC using a clear sequence as follows:

The MSC sends a CLEAR COMMAND cause "Radio interface failure, reversion to old channel" to the new BSS. On receipt of a CLEAR COMMAND from the MSC the new BSS shall release all involved resources that were allocated during the handover resource allocation procedure and returns a CLEAR COMPLETE message to the MSC.

On receipt of the CLEAR COMPLETE, the MSC shall initiate the release of the SCCP connection to the new BSS and thereby terminate association with the new BSS for this process.

The call between the MS and the old BSS and between the old BSS and the MSC shall continue as if there had been no handover attempt.

Further actions in the MSC concerning handover depends on the handover algorithm which is operator dependent.

In the case of a talker on a group call channel the MS may release the uplink whilst the handover is being performed, in this case the old BSS shall cancel the handover internally, the MSC should cancel the handover and initiate the release of the A interface resources allocated in the new BSS.

3.1.5.3.3 Abnormal Conditions

Whilst the handover execution procedure is in operation, any other messages received at the old BSS relating to this connection and concerning assignment, handover, or cipher mode control should be discarded.

Whilst the handover execution procedure is in operation the old BSS should not attempt to invoke any other procedure related to this call e.g. handover required indication.

If at the old BSS a CLEAR COMMAND message from the MSC or a HANDOVER FAILURE message from the MS is not received before the expiry of timer T8 then the old BSS shall release the dedicated radio resources. A BSSMAP message CLEAR REQUEST is also sent to the MSC with a cause "Radio Interface Message Failure". The terrestrial resource in the old BSS shall remain assigned until a CLEAR COMMAND is received from the MSC, at which point the old BSS shall mark the terrestrial resources as IDLE and return a CLEAR COMPLETE message to the MSC. The MSC shall subsequently release the SCCP connection to the old BSS and thereby terminate association with the old BSS for this process.

In the case of a handover from a Group call channel, if at the old BSS a CLEAR COMMAND or HANDOVER SUCCEEDED message from the MSC or a HANDOVER FAILURE message from the MS is not received before the expiry of timer T8 then the old BSS shall release the uplink and send a UPLINK RELEASE INDICATION to the MSC.

The MSC shall also initiate release of the resources allocated by the new BSS during the handover resource allocation procedure by sending a CLEAR COMMAND to the new BSS. The new BSS shall release all the resources that were assigned for that aborted handover and return a CLEAR COMPLETE to the MSC. The MSC shall subsequently release the SCCP connection to the new BSS and thereby terminate association with the new BSS for this process.

3.1.5a Handover from GSM to another System

Using this protocol the BSS should support handover transitions to other systems from an SDCCH, a Full Rate TCH a Half Rate TCH and Multiple Full Rate TCHs.

There are three procedures which are used for inter-system handover. They are:

– Inter-System Handover Required Indication;

– Inter-System Handover Resource Allocation;

– Inter-System Handover Execution.

The first and part of the third of these procedures are specified in this specification. The second and other part of the third procedures are specified in the relevant specification of the target system.

For any HANDOVER REQUIRED message at most one HANDOVER COMMAND message may be sent.

If so required by the BSS, the MSC shall inform the BSS if the handover cannot be carried out. This is done by a HANDOVER REQUIRED REJECT message.

In the case of inter-MSC handover the term "the MSC" in this sub-clause is taken to mean the relevant MSC in the handover operation.

The inter-system handover procedures are specified in the following sub-clauses.

All messages concerned with inter-system handover are sent using the connection-oriented mode of the SCCP.

3.1.5a.1 Generation of the HANDOVER REQUIRED message for intersystem handover

The HANDOVER REQUIRED message contains the following information elements:

– Message Type;

– Cause;

– Cell Identifier List

In case of Inter System Handover it contains the information element: "Source RNC to target RNC transparent information".

The "Source RNC to target RNC transparent information" is used to pass information from the old BSS to the target RNC. The information in the "Source RNC to target RNC transparent information" is transparent for the MSC. At presence of the "Source RNC to target RNC transparent information" in the HANDOVER REQUIRED message the MSC shall pass it unchanged to the Target RNC when initiating the Handover resource allocation procedure. The Target RNC is identified by the Target ID information contained in the Cell Identifier List IE. The Target ID information is structured routing information as required by the core network [31].The information contained in the "Source RNC to target RNC transparent information" information element is coded as required by the target system [31].

Sub-clause 3.2.1.9. gives coding details of the above message.

The "Cause" field indicates the reason for the HANDOVER REQUIRED message e.g. "downlink quality".

The Cell Identification Discriminator field within the Cell Identifier List IE in the HANDOVER REQUIRED message can be used to deduce that this is an intersystem handover.

If present the "Response Request" Information Element indicates, that the BSS requires an indication if the HANDOVER REQUIRED message does not result in a HANDOVER COMMAND message.

The Cell Identifier List IE contains the RNC-ID (and additionally the LAC or LAC and PLMN-ID depending on the configuration of the network) of the target for intersystem handover

It is mandatory for BSS to produce the RNC-ID. It is mandatory for the MSC to be able to receive and interpret this Information Element for routing purpose.

The BSS may recommend to the target RNC to allow pre-emption or not allow pre-emption by sending the "prec" bit. The target RNC may take this information into account when performing the Handover resource allocation procedure.

The HANDOVER REQUIRED message shall be updated and repeated by the BSS with a periodicity of T7 until:

– A HANDOVER COMMAND message is received from the MSC, or;

– A RESET message is received, or;

– The reason for the original HANDOVER REQUIRED message disappears e.g. the MS transmission improves, or;

– All communication is lost with the MS as defined in 3GPP TS 04.18, and the transaction is abandoned, or;

– The transaction ends, e.g., call clearing.

3.1.5a.2 Inter-System Handover Resource Allocation Failure

If the MSC receives a HANDOVER REQUIRED message indicating an unknown target RNC then, if so required by the BSS, the MSC shall send a HANDOVER REQUIRED REJECT message to the old BSS with a cause value indicating ‘invalid cell’

If the MSC or the target system is unable to allocate resources for the handover attempt then, if so required by the BSS, the MSC shall send a HANDOVER REQUIRED REJECT message to the old BSS with an appropriate cause value.

3.1.5a.3 Intersystem handover Execution

The correct operation of the procedure is as follows:

The BSSMAP HANDOVER COMMAND message is generated by the MSC and transmitted over the BSSAP connection to the old BSS which is currently supporting the concerned MS. At the old BSS timer T8 is started on the receipt of the BSSMAP HANDOVER COMMAND message which contains the Layer 3 Information IE including radio interface handover command message. A radio interface INTER SYSTEM HANDOVER COMMAND message is then sent by the old BSS, to the concerned MS.

When the MS accesses the radio resource(s) of the new RNC then:

the new RNC shall cause a Handover Detect indication to be sent to the MSC;

When the MS is successfully in communication with the network, then the new RNC shall cause a Handover Complete indication to be sent to the MSC and terminate the procedure.

The relevant radio interface layer 3 procedures are described in UMTS 25.331 [33] and GSM TS 04.18.

The MSC always terminates this procedure by use of a clear sequence as follows:

The MSC sends a CLEAR COMMAND to the old BSS. On receipt of a CLEAR COMMAND from the MSC the old BSS shall stop timer T8 and release all involved resources that were allocated to the MS that had been handed over and returns a CLEAR COMPLETE message to the MSC.

On receipt of the CLEAR COMPLETE, the MSC shall initiate the release of the SCCP connection to the old BSS and thereby terminate association with the old BSS for this process.

3.1.5a.4 Inter System Handover Failure

If a HANDOVER FAILURE radio interface message is received from the MS on the old (main) channel by the old BSS, the old BSS shall then send to the MSC the BSSMAP message HANDOVER FAILURE. If the radio interface HANDOVER FAILURE message is the result of the MS returning to the old BSS after failing to establish on the new BSS, then the cause value "radio interface failure, reversion to old channel" shall be included in the BSSMAP message HANDOVER FAILURE. Furthermore, it is recommended that the air interface RR cause be included as well in this message.

If the MSC receives the BSSMAP HANDOVER FAILURE message from the old BSS (with any cause value, the handover procedure at the target is then terminated by the MSC.

The call between the MS and the old BSS and between the old BSS and the MSC shall continue as if there had been no handover attempt.

3.1.5a.5 Abnormal Conditions

Whilst the handover execution procedure is in operation, any other messages received at the old BSS relating to this connection and concerning assignment, handover, or cipher mode control should be discarded.

Whilst the handover execution procedure is in operation the old BSS should not attempt to invoke any other procedure related to this call e.g. handover required indication.

If at the old BSS a CLEAR COMMAND message from the MSC or a HANDOVER FAILURE message from the MS is not received before the expiry of timer T8 then the old BSS shall release the dedicated radio resources. A BSSMAP message CLEAR REQUEST is also sent to the MSC with a cause "Radio Interface Message Failure". The terrestrial resource in the old BSS shall remain assigned until a CLEAR COMMAND is received from the MSC, at which point the old BSS shall mark the terrestrial resources as IDLE and return a CLEAR COMPLETE message to the MSC. The MSC shall subsequently release the SCCP connection to the old BSS and thereby terminate association with the old BSS for this process.

In the case of a handover from a Group call channel, if at the old BSS a CLEAR COMMAND or HANDOVER SUCCEEDED message from the MSC or a HANDOVER FAILURE message from the MS is not received before the expiry of timer T8 then the old BSS shall release the uplink and send a UPLINK RELEASE INDICATION to the MSC.

The MSC shall also initiate release of the resources allocated by the new BSS during the handover resource allocation procedure by sending a CLEAR COMMAND to the new BSS. The new BSS shall release all the resources that were assigned for that aborted handover and return a CLEAR COMPLETE to the MSC. The MSC shall subsequently release the SCCP connection to the new BSS and thereby terminate association with the new BSS for this process.

3.1.6 Internal Intra-Cell Handover Procedure

The definition of internal intra cell handover is given in sub-clause 5.

It is optional that a BSS support internal intra-cell handover. However if it is supported, it should be as follows:

It should be possible to inhibit internal intra-cell handover at an BSS that supports it by operation and maintenance command.

Internal intra-cell handover occurs between channels on the same cell. It is decided and executed autonomously by the BSS, so that no message is generated at the BSS-MSC interface, until the completion of the handover execution, when the BSS sends a HANDOVER PERFORMED message over the SCCP and terrestrial resources that are presently assigned to that call. Changes in type of resources (for instance channel rate change, speech version change, ciphering algorithm change) are indicated in the HANDOVER PERFORMED message.

The decision process in the BSS is based on the internally available radio and resource parameters taking into account the previously received information from the MSC in the ASSIGNMENT REQUEST or HANDOVER REQUEST.

The relevant radio interface layer 3 procedures (dedicated channel assignment) are described in 3GPP TS 04.08.

In the case of group calls the BSS may perform an intra-cell handover for a talker from a dedicated channel to a group call channel, in this case the HANDOVER PERFORMED message is sent by the BSS over the SCCP connection that was previously assigned to the talker, followed by a CLEAR REQUEST with the cause "Joined group call channel", the MSC shall release the dedicated A interface resources.

In the case of group calls the BSS may perform an Intra-cell handover for a talker from a Group call channel to a dedicated channel, in this case the BSS performs external handover.

3.1.7 Internal Inter-Cell Handover Procedure

The definition of internal inter-cell handover is given in sub-clause 5.

It should be possible to inhibit internal inter-cell handover at a BSS that supports it by operation and maintenance command.

Multi cell BSSs would normally be expected to support internal inter-cell handover, however it is optional that they do so. However if it is supported, it should be as follows:

Internal inter-cell handover occurs between channels pertaining to different cells of the same BSS. It is decided and executed autonomously by the BSS, so that no message is generated at the BSS-MSC interface, until the completion of the handover execution, when the BSS sends a HANDOVER PERFORMED message over the SCCP and terrestrial resources that are presently assigned to that call. Changes in type of resources (for instance channel rate change, speech version change, ciphering algorithm change) are indicated in the HANDOVER PERFORMED message.

A special case of internal handover occurs when the handover is triggered by the assignment procedure, e.g. directed retry. In this case the HANDOVER PERFORMED message need not be sent as the equivalent response is provided by the ASSIGNMENT COMPLETE message.

The decision process in the BSS is based on the internally available radio and resource parameters taking into account the previously received information from the MSC in the ASSIGNMENT REQUEST or HANDOVER REQUEST.

The relevant radio interface layer 3 procedures (for handover) are described in 3GPP TS 04.08.

Internal inter-cell handover for group calls may be performed from either dedicated to dedicated channels, or dedicated to group call channels, or group call to group call channels.

In the case of group calls, the BSS may perform an internal inter-cell handover for a talker from a dedicated channel to a Group call channel, in this case the HANDOVER PERFORMED message is sent by the BSS over the SCCP connection that was previously assigned to the talker. The BSS will send a CLEAR REQUEST with the cause "Joined group call channel".

In the case of group calls, the BSS may perform an internal inter-cell handover for a talker from a group call channel to a Group call channel, in this case the HANDOVER PERFORMED message is sent by the BSS over the SCCP connection that was previously assigned to the talker.

In the case of internal inter-cell handover the BSS, when localised service area is supported, will indicate the LSA identity of the target cell in the HANDOVER PERFORMED message if it corresponds to one of the LSA identities received in the latest LSA INFORMATION or the HANDOVER REQUEST messages.

3.1.8 Handover Candidate Enquiry

The purpose of this procedure is to allow the MSC to ascertain if it is possible to handover any MSs that are currently being served by a particular cell to another nominated cell. The procedure uses both global and dedicated resource messages, and is relevant to an individual cell.

The algorithm in which a MSC decides on starting a handover enquiry procedure is operator dependent.

3.1.8.1 Successful Operation

The procedure operates as follows:

The MSC sends a HANDOVER CANDIDATE ENQUIRE message to a BSS. The message indicates that the MSC wishes the BSS to identify handover candidates in a particular cell, that can be handed over to other nominated cells. The maximum number of candidates is also indicated to the BSS.

For each selected MS candidate the BSS will send to MSC a single, once only, HANDOVER REQUIRED message (not guarded by timer T7), over each of the appropriate SCCP connections. If the BSS was already generating HANDOVER REQUIRED messages for a selected MS then the BSS will continue to do so. However the Cause IE of the next HANDOVER REQUIRED message (at the expiry of timer T7) will be set to "Response to MSC invocation" to indicate that the message is generated in response to a HANDOVER CANDIDATE ENQUIRE message. But as this HANDOVER REQUIRED was already being generated before the handover enquiry procedure was started, that HANDOVER REQUIRED would be guarded by timer T7. So in the instance of next expiry of timer T7, the BSS shall continue sending HANDOVER REQUIRED message but the Cause IE value shall revert back to the original Cause IE value.

When the last HANDOVER REQUIRED message has been sent for all the selected MS candidates, the BSS returns to the MSC a HANDOVER CANDIDATE RESPONSE message giving the number of candidates identified, and terminating the handover enquiry procedure.

Only one handover enquiry procedure may be invoked on any given cell at any one time.

3.1.8.2 Abnormal conditions

If at the BSS a HANDOVER CANDIDATE ENQUIRE message is received when a handover enquiry procedure has already been invoked then the new HANDOVER CANDIDATE ENQUIRE message shall be discarded.

3.1.9 Release of Radio Resource And Terrestrial Resource

3.1.9.1 Release Due To Transaction Completion

The release of assigned radio resources at the end of a transaction will take place as follows:

Release negotiation will take place directly between the MS and MSC using transparent messages via the DTAP in the BSS (see 3GPP TS 04.08). The MSC will then send a BSSMAP CLEAR COMMAND, indicating that the radio resource(s) should be released. After the BSSMAP CLEAR COMMAND has been sent, the MSC shall not send further BSSAP connection oriented messages on this particular connection, except CLEAR COMMAND.

If the BSS allocates the A interface circuits, the MSC shall release the circuit allocated to the connection, if any, before sending the CLEAR COMMAND.

When the BSS receives the CLEAR COMMAND:

the guard timer defined in 3GPP TS 04.08 is started and clearing on the radio interface initiated.

the BSS marks any assigned terrestrial resources as idle and returns a CLEAR COMPLETE message to the MSC. (The BSS need not wait for the radio channel release to be completed or for the guard timer to expire before returning the CLEAR COMPLETE message.)

If the MSC allocates A interface circuits, on receipt of CLEAR COMPLETE, the MSC releases any assigned terrestrial resources.

3.1.9.2 Release due to BSS generated reason

If a radio channel release is required because of a BSS generated reason (e.g. "O and M intervention", "equipment failure") then, the BSS shall generate a CLEAR REQUEST message towards the MSC. This message shall include a Cause Information Element, indicating the reason for the failure.

If transmission from the MS is lost then a CLEAR REQUEST message shall be sent to the MSC.

On receipt of a CLEAR REQUEST the MSC shall initiate the release, as defined above, by sending a CLEAR COMMAND message. On receipt of this message the BSS shall, if the resources are not already internally released, release the resources in the normal way. The procedure is always terminated with a CLEAR COMPLETE to the MSC.

In case of a group call talker on a dedicated channel or group call channel, the BSS shall indicate to the MSC that the uplink is released and that a radio channel release is required because of a BSS generated reason by sending an UPLINK RELEASE INDICATION message with an appropriate cause value. On receipt of an UPLINK RELEASE INDICATION message with a cause value different from "Call control" or "Radio interface failure", the MSC shall initiate the release of the radio and terrestrial resources by sending a CLEAR COMMAND message

  • on the dedicated SCCP connection, if the talker was on a dedicated channel; or
  • on the VGCS/VBS resource controlling SCCP connection, if the talker was on a group call channel.

If transmission from a group call talker is lost then the BSS shall indicate the uplink being released by sending an UPLINK RELEASE INDICATION message with cause value "Radio interface failure". If the talker was on a dedicated connection, the MSC shall initiate the release of the radio and terrestrial resources associated with the talker by sending a CLEAR COMMAND message. If the talker was on a group call channel, the MSC shall not start the clearing sequence, and the resources at the BSS are not released.

In the case of a group call talker the BSS may move the mobile on to a group call channel, in this case the BSS shall initiate a release of A interface resources by sending a CLEAR REQUEST with the cause "Joined group call channel". The MSC in its turn shall release the dedicated resources associated with the talker.

If the BSS sends a CLEAR REQUEST with the cause different from "Joined group call channel" for resources associated with the uplink, then the MSC shall assume uplink indicated as released.

3.1.9.3 Release due to successful handover

If a radio channel release is required because of a handover being successfully completed on another BSS, then the resources at the old BSS are released by the MSC using the clearing sequence with a Cause value; "handover successful".

In the case of handover of a group call talker from a group call channel the MSC shall send a HANDOVER SUCCEEDED message to the old BSS.

3.1.9.4 Release due to uplink release

If a talker on a dedicated channel releases its uplink, the BSS shall inform the MSC by an UPLINK RELEASE INDICATION message with cause value "Call control". Then the resources at the BSS shall be released by the MSC using the clearing sequence. The BSS is allowed to release the radio resources before the MSC initiates the clearing procedure.

If a talker on a group call channel releases its uplink, the BSS shall inform the MSC by an UPLINK RELEASE INDICATION message with cause value "Call control". In this case the MSC shall not start the clearing sequence, and the resources at the BSS are not released. The BSS shall initiate the radio interface uplink free procedure.

3.1.10 Paging

PAGING messages for all MSs shall be sent via the BSSMAP as a connectionless message. These will include the IMSI of the MS to allow derivation of the paging population number; they may also include an indication of which combination of channels will be needed for the subsequent transaction related to the paging. This type of PAGING message will then be stored and a corresponding radio interface paging message transmitted over the radio interface at the appropriate time.

It should be noted that each PAGING message on the MSC-BSS interface relates to only one MS and therefore the BSS has to pack the pages into the relevant 3GPP TS 04.08 radio interface paging message.

If a radio interface PAGING RESPONSE message is received then the relevant connection is set up towards the MSC as described in 3GPP TS 08.06 and the radio interface PAGING RESPONSE message is passed to the MSC in a COMPLETE LAYER 3 INFORMATION message.

A single PAGING message across the MSC to BSS interface contains information on the cells in which the page shall be broadcast.

3.1.11 Trace Invocation

The purpose of the trace invocation procedure is to inform the receiving entity that it should begin producing a trace record on this particular transaction.

The trace is invoked either by the MSC sending a MSC INVOKE TRACE message to the BSS or by the BSS sending a BSS INVOKE TRACE message.

The events and parameters to be recorded are indicated in the "Trace type" information element.

A "Forwarding indicator" element may be used in the BSS INVOKE TRACE to indicate if the trace is to be continued after handover to another BSS. If thus indicated, The MSC should forward the BSS INVOKE TRACE to the BSS-B and also store it to send to any subsequent BSS during the lifetime of the call.

The remaining elements, when received, are to be passed transparently to the OMC receiving the trace record.

The element "OMCId", if present, indicates the OMC to which the record is destined.

In sending the BSS INVOKE TRACE message, the BSS may allocate and include a "BSS transaction reference". Similarly in the MSC INVOKE TRACE message, the MSC may allocate and include an "MSC transaction reference" (typically a call reference). The transaction reference is contained in the information element "TransactionId".

The message includes a trace reference which is allocated by the entity which triggered the trace.

The element "TriggerId", if present, indicates the entity which triggered the trace.

The trace reference, triggerId and transactionId Information Elements are used to tag the trace record to allow simpler construction of the total record by the entity which combines trace records.

The messages are not acknowledged and are sent as a connection oriented message on the connection on which a trace is required.

3.1.12 Flow Control

These procedures are defined to give some degree of flow control. At the BSS processor overload and CCCH scheduler overload are catered for, and at the MSC processor overload is catered for.

3.1.12.1 Philosophy

The philosophy used is to stem the traffic at source with known effect on the service. The algorithm used is:

– On receipt of the first OVERLOAD message or signalling point congested information, the traffic is reduced by one step. At the same time, timers T5(T17) and T6(T18) are started. During T5(T17) all received overload messages or signalling point congested information are ignored in order not to reduce the traffic too rapidly. Reception of an OVERLOAD message or signalling point congested information after expiry of T5(T17) but still during T6(T18) , will decrease the traffic load by one more step, and restart T5(T17) and T6(T18).

– This step by step reduction of traffic is continued until maximum reduction is obtained by arriving at the last step. If T6(T18) expires (i.e. no OVERLOAD message or signalling point congested information is received during T6(T18)) the traffic will be increased by one step and T6(T18) will be started, unless full load has been resumed.

NOTE: Timers T5 and T6 are running in the MSC whilst Timers T17 and T18 are running in the BSS.

– The number of steps and the method of reducing the load is considered to be an implementation specific function.

There may be other traffic control mechanisms from O and M activities occurring simultaneously.

3.1.12.2 Processor Overload at the MSC

The MSC can indicate to the BSS that it is in a congested state by sending an OVERLOAD message. This is sent as a connectionless global message.

At the BSS receipt of this message causes the reduction of random access traffic using the method described in sub-clause 3.1.12.1.

For example, the amount of random access traffic could be reduced by using the access control class in the system information message of 3GPP TS 04.08.

3.1.12.3 Processor/CCCH overload at the BSS

If the CCCH scheduler at the BSS is overloaded (queue passed a predefined threshold) then the BSS sends an OVERLOAD message to the MSC with the appropriate cause (Cause value: "CCCH overload") and indicating the cell in question.

If the BSS processing is overloaded then the BSS sends an OVERLOAD message with the Cause value: "processor overload".

The MSC originated traffic is reduced in accordance with the method described in sub-clause 3.1.12.1.

3.1.12.4 Message throughput congestion

If the lower layers of the protocol become congested then it is assumed that the MTP congestion indication will take place (see 3GPP TS 08.06) and the source of the traffic will receive primitives from the transport protocols resulting in it reducing the generated load.

A suitable method to achieve this reduction could be based on that given in sub-clause 3.1.12.1.

3.1.13 Classmark Handling Procedures

3.1.13.1 Classmark request procedure

The purpose of this procedure is to allow the MSC to trigger a classmark updating procedure. This is done by sending a CLASSMARK REQUEST message to the BSS on the appropriate SCCP connection. When receiving this message the BSS shall initiate the appropriate actions on the radio path.

3.1.13.2 Classmark updating procedure

The purpose of the classmark updating procedure is to inform the receiving entity about classmark information received from the MS.

At any point when an SCCP connection has been established for BSSAP messages, the BSS must be able to send to the MSC a CLASSMARK UPDATE message if a classmark update is received from the MS. This message contains information on several transmission parameters relevant to the MS in communication with the network.

If the MSC has already initiated a handover for the concerned MS by sending a HANDOVER REQUEST message when the CLASSMARK UPDATE message is received, the MSC shall send a CLASSMARK UPDATE message to the target BSS when the MS is successfully in communication with the network on the new (main) channel. If this CLASSMARK UPDATE message is received in the target BSS after a new classmark has been received from the Mobile Station the CLASSMARK UPDATE message from the MSC shall be ignored.

This message is sent as a BSSAP message over the appropriate SCCP connection

This procedure will be used where the power class of the MS changes or if the network requests the MS to send the classmark information whilst the MS has one or more dedicated resources.

The procedure will also be used to send classmark information to the MSC if the MS immediately after initial L3 message sends additional classmark information. In this case the BSS may as an option suppress or delay the sending of the CLASSMARK UPDATE message to the MSC. However, if the MSC supports LCS and the BSS is not associated with a BSS based SMLC, the BSS shall send the CLASSMARK UPDATE message to the MSC as soon as the BSS has received the additional classmark information.

3.1.14 Cipher Mode Control

3.1.14.1 Successful Operation

The cipher mode control procedure allows the MSC to pass cipher mode information to the BSS to select and load the user data and signalling encryption device with the appropriate key.

This is achieved by sending the BSS a CIPHER MODE COMMAND message. Receipt of the message at the BSS will cause the generation of a radio interface CIPHERING MODE COMMAND message and, if applicable, invoke the encryption device and start stream ciphering as described in 3GPP TS 04.08 and 3GPP TS 03.20.

If within the CIPHER MODE COMMAND, the signalling element "Cipher response mode" is present and indicates "IMEI must be included by the Mobile Station", then the BSS shall request in the radio interface message CIPHERING MODE COMMAND the Mobile Station to include its IMEI in the radio interface CIPHERING MODE COMPLETE message (see 3GPP TS 04.08, sub-clause ‘Ciphering mode setting initiation’ ).

In the CIPHER MODE COMMAND the MSC specifies which of the ciphering algorithms may be used by the BSS. The BSS then selects an appropriate algorithm, taking into account the MS ciphering capabilities. The CIPHER MODE COMPLETE message returned to the MSC indicates the chosen ciphering algorithm. The set of permitted ciphering algorithms specified in the CIPHER MODE COMMAND shall remain applicable for subsequent Assignments and Intra-BSS Handovers.

The CIPHER MODE COMMAND and CIPHER MODE COMPLETE messages are sent as connection oriented messages via the appropriate SCCP connection.

Receipt of the radio interface CIPHERING MODE COMPLETE message (or other correctly deciphered layer 2 frame) from the radio interface is used internally within the BSS to achieve radio interface ciphering synchronisation (see 3GPP TS 04.08). When the BSS receives the radio interface CIPHERING MODE COMPLETE from the MS a CIPHER MODE COMPLETE message is returned to the MSC. If the CIPHERING MODE COMPLETE message received on the radio interface contained more than two octets, then the BSS shall include in the BSSMAP CIPHER MODE COMPLETE message a "Layer 3 message contents" signalling element containing octets 3 up to n (where n is the length of that CIPHERING MODE COMPLETE radio interface message) of that radio interface CIPHERING MODE COMPLETE message.

3.1.14.2 Abnormal Conditions

If the BSS is unable to support the ciphering algorithm specified in the CIPHER MODE COMMAND message then it shall return a CIPHER MODE REJECT message with Cause value "Ciphering algorithm not supported". A CIPHER MODE REJECT message shall also be returned if the MSC requests a change of ciphering algorithm when ciphering is already active.

3.1.15 General SCCP Abnormal Conditions

If a user-out-of-service information or signalling-point-inaccessible information is received by the BSSAP or BSSOMAP no new attempt to establish SCCP connections towards the affected point code will be started until the corresponding user-in-service information or signalling-point-accessible information is received.

When a user-out-of-service information or signalling-point-inaccessible is received by the BSS an optional timer may be started. When the timer expires all the SCCP connections towards the affected point code will be released. When the user-in-service or signalling-point-accessible is received, the timer is stopped.

If for any reason an SCCP connection is released, the optional timer expires or a connection refusal is received while any of the BSSAP procedures are being performed or while a dedicated resource is still allocated the following actions are taken:

At BSS:

The radio resources associated with the SCCP connection are cleared by an appropriate radio procedure.

Any BSS procedure relating to that connection is abandoned.

The resources allocated to the call associated to the connection are released.

At MSC:

The call associated with the SCCP connection is cleared as soon as possible.

At the BSS, communication over assigned radio channels shall be assumed to be continuing until either the SCCP connection is lost, a clearing sequence is received, or no signal is received from an MS for longer than the guard time defined in 3GPP TS 04.08. If the BSS recognises that a call has terminated then a CLEAR REQUEST message should be generated.

If a 2Mbit/s system fails and one of the standard alarms is received, no action is taken at the BSS on the calls associated with the traffic channels involved.

At the MSC, calls should be cleared if either subscriber clears, or if the BSS sends a CLEAR REQUEST message. Clearing of affected calls by the MSC may take place after loss of the traffic channels for a period defined by the operator.

For the procedures controlled by the MSC, and in particular procedures where the MSC sends a request for resources at the BSS and waits for an acknowledge, the implementation in the MSC must provide means for avoiding deadlock situations at the BSS as e.g. hanging resources.

3.1.16 Initial MS message

When the SCCP connection establishment is performed by the BSS, the radio interface initial L3 message received from the MS (piggybacked on the SABM frame) is processed as follows:

The BSS shall analyse the protocol discriminator of the message.

If the BSS does not support the protocol, reactions of the BSS are specified in 3GPP TS 04.08. If the BSS supports the protocol, it shall analyse the message to a level which allows the extraction by the BSS of the Classmark information. However, except for the NOTIFICATION RESPONSE, the entire radio interface initial L3 message (e.g. CM SERVICE REQUEST, PAGING RESPONSE, CM REESTABLISHMENT REQUEST, LOCATION UPDATING REQUEST, IMSI DETACH, IMMEDIATE SETUP) is also passed to the MSC, using a COMPLETE LAYER 3 INFORMATION message. The BSS does not analyse the contents of the initial layer 3 message, other than the Classmark information.

The BSS may also give the MSC a description of the channel on which the initial layer 3 message was received.

3.1.17 Queuing Indication

The purpose of the QUEUING INDICATION message is t inform the MSC about a delay in the allocation of the necessary dedicated radio resources. The procedure is only relevant if the system is using a queuing procedure for traffic channels in the BSS, (sub-clause 3.1.17.1) and/or for handover of traffic channels (sub-clause 3.1.17.2)

3.1.17.1 Operation of the procedure in case of assignment procedure

After the ASSIGNMENT REQUEST message without having the necessary TCH available the ASSIGNMENT REQUEST message shall be put into a queue; the QUEUING INDICATION message shall be returned to the MSC and the timer T11 shall be started. The timer value T11 specifies the maximum queuing delay and is determined by the operator.

The procedure shall be terminated with a successful or unsuccessful assignment of the required traffic channel(s) by sending an ASSIGNMENT COMPLETE or an ASSIGNMENT FAILURE message, respectively, to the MSC.

If the timer T11 expires the ASSIGNMENT REQUEST message shall be removed from the queue and a CLEAR REQUEST message shall be sent to the MSC, with the Cause "no radio resource available".

3.1.17.2 Operation of the procedure in case of hand-over resource allocation procedure

After the HANDOVER REQUEST message without having the necessary TCH available the HANDOVER REQUEST shall be put into a queue; the QUEUING INDICATION message shall be returned to the MSC and the timer Tqho shall be started. The timer value Tqho specifies the maximum queuing delay and is determined by the operator.

The procedure shall be terminated with a successful or unsuccessful reservation of the required traffic channel(s) by sending a HANDOVER REQUEST ACKNOWLEDGE or a HANDOVER FAILURE message, respectively, to the MSC.

If the timer Tqho expires the HANDOVER REQUEST shall be removed from the queue and a HANDOVER FAILURE message shall be sent to the MSC with the Cause value "no radio resource available".

3.1.18 Data Link Control SAPI not Equal to "0"

The radio interface can support data links with the SAPI not equal to "0".

3.1.18.1 Data link set up across the radio interface

This sub-clause deals with the impact of data link establishment (SAPI not equal to "0") on the MSC to BSS interface.

3.1.18.1.1 MS to MSC direction

In the MS to MSC direction the receipt of a layer 3 message via a data link where SAPI does not equal "0" at the BSS will be transferred to the MSC as a DTAP message with the DLCI (Data Link Connection Identification) octet set appropriately.

3.1.18.1.2 MSC to MS Direction

Receipt of a layer 3 (DTAP) message from the MSC with the SAPI (indicated in the DLCI) not equal to "0" will cause one of the following actions:

– the triggering of a data link set up to support the message transfer across the radio interface if no suitable link exists;

– the transmission of the message to the MS if a suitable link has already been established;

– the sending of a BSSMAP SAPI "N" REJECT message to the MSC if for any reason the data link cannot be established, A Cause Information Element is included; typical Cause values are: "O&M intervention", "processor overload", "BSS not equipped", "MS not equipped".

3.1.18.2 Choice of the signalling link

When the BSS relays a message of the PDSS1 protocol received on the air interface to the MSC, it shall indicate in the DLCI (see 3GPP TS 08.06) on which control channel and SAPI the message was received.

When the MSC sends a DTAP message to the BSS, it shall,

– if the protocol of the corresponding air interface layer 3 message is PDSS1, specify on which control channel and SAPI of the air interface the L3 message shall be sent

– otherwise not further specify the control channel on the air interface.

When the BSS relays an air interface L3 message received in a DTAP message on the A interface to the MS, it shall

– if the DLCI does not further specify the signalling channel of the air interface, send it on the appropriate signalling link

– if the BSS supports PDSS1 and the DLCI specifies which control channel is to be used for transmission on the air interface, the BSS shall transfer the air interface L3 message on the specified control channel.

NOTE: If the BSS does not support PDSS1, it considers the part of the DLCI possibly indicating the control channel to be used on the air interface as spare bits, see 3GPP TS 08.06.

3.1.19 BSSMAP Error Handling

To allow for the introduction of new functions the following rules shall be used to determine the actions of a receiving entity when it receives a message, part or all of which it is unable to understand. As the recipient is unable to tell the difference between a new, previously unspecified coding and an erroneous coding, the recipient also uses the same rules for error handling.

The robustness of a recipient in handling erroneous messages does not relax the requirement that the transmitter shall obey this Technical Specification. However, it is intended that functionality can be gradually added to an entity, and no obstacle to intermediate phase equipment is intended.

With the exception of sub-clause 3.1.19.6, the specific ‘abnormal case’ handling in other sub-clauses of 08.08 take precedence over this sub-clause.

3.1.19.1 Definitions of Types of Information Elements

The following definitions shall be used in sub-clause 3.1.19 and only in this sub-clause.

Essential Elements

These are the conditional elements when the condition for their reception is fulfilled, plus the Mandatory elements excluding the Cause value information element (3.2.2.5).

Mandatory Elements

These are the Information Elements marked as ‘M’ in sub-clause 3.2.1.

Non-Essential Elements

Non-essential elements are all the information elements that are not defined as essential.

Conditional Elements

In the indicated messages the following elements are conditional:

Circuit identity code in 3.2.1.1 and 3.2.1.8.

Circuit pool list in 3.2.1.3, 3.2.1.9, 3.2.1.16, and 3.2.1.55.

NOTE: A conditional IE is an IE whose presence or absence in a message can be determined by information contained in the rest of the message.

Transparent Elements

The following elements are defined as transparent:

for the BSS: TMSI;

– RR cause;
– Layer 3 information in the BSSMAP HANDOVER COMMAND message; and
– Layer 3 message contents; and for the MSC: Resource situation.
– Layer 3 information in the BSSMAP HANDOVER REQUEST ACKNOWLEDGE message; and

"Old BSS to new BSS information" in the BSSMAP HANDOVER REQUIRED message

"Source RNC to target RNC information (UMTS)" in the BSSMAP HANDOVER REQUIRED message

"Source RNC to target RNC information (cdma2000)" in the BSSMAP HANDOVER REQUIRED message

Non-Transparent Elements

Non-transparent elements are all the information elements that are not defined as transparent.

3.1.19.2 Erroneous Events

The following events shall be regarded as errors by the recipient:

1 a message whose type is non-existent, unrecognisable, not consistent with the recipient’s state, or, that is sent in the wrong direction. This includes messages that should use the SCCP connectionless service but that are received on an SCCP connection, and vice versa;

2 a missing essential information element;

3 use of a reserved codepoint in an information element that is both essential and non-transparent; and

4 an essential and non-transparent information element which is too short (the contents of any ‘Length’ octet shall be used to determine the boundary of the element).

When a recipient detects one or more of these events it shall return the appropriate error message with a suitable Cause value and the message shall be discarded.

3.1.19.3 Non-erroneous Events

The following events shall not be regarded as errors by the recipient:

1 spare bits with an unexpected value in any information element;

2 the use of additional octets in any information element with a length octet;

3 a missing non-essential information element;

4 use of reserved codepoints in any non-essential information element or in any transparent information element; and

5 a non-essential information element or a transparent information element whose length is too short.

When the recipient detects one or more of these events the receiving entity shall ignore the information that it is unable to understand and treat the message on the basis of the information that remains.

Additionally,

all information in a message that is received after the start of an information element with an unrecognisable identifier shall be ignored. The message shall be accepted or rejected solely on the basis of the information received before the start of the unrecognisable element;

and,

when more information elements of a particular type are received than are expected, the last one(s) shall be ignored.

3.1.19.4 Other Events

The following events should be treated on a case by case basis and the outcome may depend upon the capabilities of the recipient.

1 The recipient may accept messages that contain information elements that do not appear to be in the correct sequence. Elements that occur more than once in a message shall be assumed to have been transmitted in the correct order. Recipients that do not accept out of sequence information elements shall regard the message as containing unexpected and/or missing information elements and follow the procedures of sub-clauses 3.1.19.1 and/or 3.1.19.2.

2 Where a field in an information element contains a value, which the recipient knows to be incorrect, the recipient shall either reject the message or it shall ignore that field, and treat the information that remains in the message.

(e.g. if the ‘Number of MSs’ in a Handover Candidate Response message is greater than the number of Handover Required messages received).

3.1.19.5 Appropriate Error Message and Cause Value

The choice of error message depends upon the received message type:

Received message type  Error Message

ASSIGNMENT REQUEST ASSIGNMENT FAILURE

HANDOVER REQUEST HANDOVER FAILURE

HANDOVER REQUIRED

if "Response Request" i.e. is present  HANDOVER REQUIRED REJECT

if "Response Request" i.e. is not present CONFUSION

CIPHER MODE COMMAND CIPHER MODE REJECT
VGCS/VBS SETUP VGCS/VBS SETUP REFUSE
VGCS/VBS ASSIGNMENT REQUEST VGCS/VBS ASSIGNMENT FAILURE
CONFUSION an error message shall not be used
all other message types CONFUSION

When a problem is experienced with a message sent over an SCCP connection, the error message is returned over that connection. When a problem occurs in a message sent using the SCCP connectionless service, the error message is returned using the SCCP connectionless service.

To avoid overload of the A-interface, transmission of error messages may be inhibited. (However, the transmission of Assignment Failure, Handover Failure, Handover Required Reject and Cipher Mode Reject messages in the cases required by 3.1.1, 3.1.5, 3.1.5a and 3.1.14 shall not be inhibited.) When the transmission of error messages is inhibited, they shall be replaced by some kind of notification to O&M. Several settings may be used to allow various subsets of ‘error events’ to trigger error messages while the remaining events only lead to O&M notification.

The Error pointer in the Diagnostics information element should be used to indicate the position of a detected error in the received message. Typical Causes are:

Cause

Usage

Invalid cell

Indicated cell not controlled by the BSS or not reachable through the MSC.

Invalid message contents

May be used in any error message.

Protocol error between BSS and MSC

The received message is not consistent with the receiver’s state, or the message has been sent in the wrong direction, or the message uses the wrong SCCP service (connection oriented instead of connectionless or vice versa).

Information element or field missing

Data missing from the area indicated by the error pointer.

Incorrect value

A field (that should be indicated by the error pointer) contains an incorrect or incompatible value, or uses a reserved codepoint.

Unknown message type

The received message was of an unknown type.

Unknown information element

An information element identifier (that should be indicated by the error pointer) contains an unknown value.

3.1.19.6 Unequipped Circuit Identification Code

If a MSC or BSS receives a message indicating one or more circuit which are unknown the following actions shall be taken:

– If an ASSIGNMENT REQUEST, a VGCS/VBS ASSIGNMENT REQUEST or a HANDOVER REQUEST message is received containing a circuit identity code which is unknown to the BSS the appropriate failure message is returned to the MSC. In addition the UNEQUIPPED CIRCUIT message is sent to the MSC for the circuit concerned.

– If an ASSIGNMENT COMPLETE, a VGCS/VBS ASSIGNMENT RESULT, a HANDOVER REQUEST ACKNOWLEDGE or a CHANGE CIRCUIT ACKNOWLEDGE Message is received containing a circuit identity code which is unknown to the MSC, it is up to the MSC to correct the situation, e.g. by performing a circuit re-selection procedure and sending an UNEQUIPPED CIRCUIT Message to the BSS.

– If a circuit supervision message (BLOCK, UNBLOCK or RESET CIRCUIT) is received containing a circuit identity code which is not known no respective acknowledgement is returned. Instead an UNEQUIPPED CIRCUIT Message is sent to the peer entity for the circuit concerned.

– If a circuit supervision acknowledgement message (BLOCKING ACKNOWLEDGE, UNBLOCKING ACKNOWLEDGE or RESET CIRCUIT ACKNOWLEDGE) is received containing a circuit identity code which is not known, an UNEQUIPPED CIRCUIT message is sent to the peer entity for the circuit concerned.

– If a circuit group supervision message (GROUP BLOCK, GROUP UNBLOCK) is received which affects one or more circuits which are unknown to the own entity the returned acknowledgement message shall not contain any information about these circuit(s), i.e. the respective status bit(s) in the status field shall not be set. Instead an UNEQUIPPED CIRCUIT Message is sent to the peer entity for the circuit(s) concerned.

– If a circuit group supervision acknowledgement message (CIRCUIT GROUP BLOCKING ACKNOWLEDGE or CIRCUIT GROUP UNBLOCKING ACKNOWLEDGE) is received which affects one or more circuits which are unknown to the own entity an UNEQUIPPED CIRCUIT message is sent to the peer entity for the circuit(s) concerned.

– If an UNEQUIPPED CIRCUIT Message is received indicating a circuit which is unknown in the own entity no UNEQUIPPED CIRCUIT Message will be returned.

If an UNEQUIPPED CIRCUIT Message is received indicating a circuit(s) that is known to the recipient, the indicated circuit(s) should be removed from service and the situation should be reported to the maintenance system for further intervention. The UNEQUIPPED CIRCUIT message is not to be acknowledged by the recipient.

3.1.19.7 Field Elements

This sub-clause defines the generic error handling to be applied to the field elements found in the "Old BSS to new BSS information" information element.

All field elements shall be treated as non-essential.

The following events shall not be regarded as errors by the recipient:

1 spare bits with an unexpected value in any field element;

2 the use of additional octets in any field element;

3 a missing field element;

5 a field element whose length is either too short or too long

When the recipient detects one or more of these events the receiving entity shall ignore the information that it is unable to understand and treat the message on the basis of the information that remains.

Additionally,

When an unknown field element identifier is encountered, the unknown field element shall be skipped and the receiver shall continue processing any remaining field elements;

and,

when more field elements of a particular type are received than are expected, the last one(s) shall be ignored;

and,

when a sub-field in a field element contains a value, which the recipient knows to be incorrect, the recipient shall either ignore that sub-field or ignore the entire field (treating it as if the field element had not been received).

and,

when a sub-field in a field element contains a reserved value, the recipient shall ignore the entire field element (treating it as if the field element had not been received).

3.1.20 Load Indication Procedure

The purpose of the load indication procedure is to inform all neighbour BSS’s about the traffic situation of a cell.

The philosophy is to control the incoming handover traffic at the source, i.e. the BSS of the concerned cell informs all of its neighbour BSS’s about the load situation. This is achieved by sending a LOAD INDICATION message to the neighbour BSS’s. On receipt of the LOAD INDICATION message the BSS may analyse the load information and take the traffic load into consideration when deciding a handover.

The algorithm in which the BSS decides on starting a Load Indication procedure is operator dependent.

The implementation of the Load Indication procedure shall be regarded as optional, that means, if this procedure is not used, the Load Indication message may be ignored by these network elements.

3.1.20.1 Operation of the procedure

The procedure operates as follows:

The BSS shall send the LOAD INDICATION message to the MSC with the following information:

– Cell Identifier of the cell where the traffic load situation takes place (Cell Identifier information element).

– The Time indication information element contains the time where the traffic load information shall be valid on the receiving side.

– The Cell identifier list information element contains the cell identifier of the affected neighbour cells.

– The information about the total number of channels accessible or in use, and the information about the current number of channels available for each reported channel type on the indicated cell (Resource situation information element).

– The reason for sending this message (Cause information element).

On receipt of the LOAD INDICATION message, the MSC transmits this message to all BSS’s as derived from the Cell identifier list Information Element.

NOTE: In the case where more than one indicated cells in the cell identifier list IE belong to the same BSS, the MSC should try to send the LOAD INDICATION message only once to this BSS.

With each reception of a LOAD INDICATION message from the MSC the target BSS shall analyse the resource information and adapt the handover traffic either from all cells of the BSS-area or only from the cells contained in the Cell identifier list Information Element to the cell indicated in the Cell identifier Information Element. The BSS shall ignore all Cell identifiers for cells which do not belong to its area.

In the case where the BSS receives a LOAD INDICATION message without the Resource situation information element, that means the indicated cell is not able to perform incoming handover requests and the receiving BSS may stop the whole handover traffic to this cell.

The traffic load information shall only be valid the time as indicated in the Time indication Information Element. The control timer shall be stopped with the receipt of a new LOAD INDICATION message and restarted with the new value. If the Time field contains the value 0, the load information is no longer valid.

3.1.21 Voice group call service and voice broadcast service call set-up and resource assignment

To set-up a VGCS/VBS call the MSC initiates the VGCS/VBS set-up procedure to the BSS. The MSC can then allocate resources to the VGCS/VBS call by initiating the VGCS/VBS Assignment procedure.

3.1.21.1 Successful operation

To initiate a VGCS/VBS call set-up procedures the MSC sends to the BSS a VGCS/VBS SETUP message across VGCS/VBS call controlling SCCP connection. This connection is established for the life time of the VGCS/VBS call.

The BSS allocates resources to the call and returns VGCS/VBS SETUP ACK message to the MSC.

3.1.21.2 VGCS/VBS call set-up abnormal cases

If the BSS detects that the VGCS/VBS call is already set-up it will clear all resources associated with the previous call and proceed with the new call.

3.1.21.3 VGCS/VBS call set-up failure

If the BSS can not set-up the VGCS/VBS call then it will send an VGCS/VBS SETUP REFUSE message to the MSC.

3.1.22 Voice group call service and voice broadcast service Assignment procedure

The purpose of the VGCS/VBS Assignment procedure is to ensure that the correct dedicated radio resources are allocated to the VGCS/VBS call on a per cell basis. The VGCS/VBS Assignment procedure is performed on a VGCS/VBS resource controlling SCCP connection.

The MSC can command that the radio resources are either allocated immediately or delayed.

3.1.22.1 Successful operation

It is assumed that the VGCS/VBS controlling SCCP connection and the VGCS/VBS resource controlling SCCP connection(s) have been set-up before the VGCS/VBS Assignment procedure takes place.

The MSC initiates the VGCS/VBS Assignment procedure to the BSS by sending an VGCS/VBS ASSIGNMENT REQUEST on a VGCS/VBS resource controlling SCCP connection.

The BSS will return VGCS/VBS ASSIGNMENT RESULT to the MSC to inform the MSC of the resources allocated by the BSS for the concerned cell.

The BSS shall initiate the radio interface notification procedure on the NCH of the cell in which the call is to take place, this may continue at regular intervals until the call is released. The BSS may on SACCH indicate that a change of notification has occurred and/or initiate notification on FACCH.

In the case where the BSS deallocates/allocates resources to the cell, the BSS sends an VGCS/VBS ASSIGNMENT RESULT message on the VGCS/VBS resource controlling SCCP connection associated to the cell.

3.1.22.2 VGCS/VBS Assignment abnormal cases

In the abnormal case, where a BSS detects that a voice broadcast or voice group call already exists with the same group call reference in a cell (this may occur due to SCCP problems), the BSS shall release the radio resources associated with the cell for the present existing voice broadcast or voice group call and shall allocate resources to the new call.

If the BSS receives a VGCS/VBS ASSIGNMENT REQUEST message calling up a terrestrial circuit that is already assigned to another call then a VGCS/VBS ASSIGNMENT FAILURE message will be returned with a Cause value of: "terrestrial circuit already allocated" and no action will be taken on the radio interface.

If the BSS receives a VGCS/VBS ASSIGNMENT REQUEST message allocating a terrestrial circuit which has been blocked by a previous blocking procedure, then an VGCS/VBS ASSIGNMENT FAILURE message shall be sent (Cause value: "requested terrestrial resource unavailable"). A BLOCK message (not repeated and not guarded by timer T1) shall be sent for that concerned terrestrial circuit.

3.1.22.3 VGCS/VBS Assignment failure

In the case were the VGCS/VBS call is unknown by the BSS, the BSS shall return the VGCS/VBS ASSIGNMENT FAILURE message (cause "VGCS/VBS call non existent").

In the case where no radio resource can be allocated to the VGCS/VBS call, the BSS shall return the VGCS/VBS ASSIGNMENT FAILURE message (cause "No radio resource available").

In the case where the MSC has attempted to assign a terrestrial circuit and an VGCS/VBS ASSIGNMENT FAILURE message has been returned then both the MSC and the BSS shall consider that the terrestrial circuit is idle (except already allocated or blocked terrestrial circuit) and therefore no explicit clearing sequence is needed.

3.1.23 (void)

3.1.24 Voice group call uplink control procedure

In the case of voice group calls the uplink resource allocated to the call is controlled by the uplink control procedure. The uplink control procedure uses messages sent on the VGCS/VBS controlling SCCP connection set-up by the VGCS/VBS call set-up procedure.

The procedure is split into three procedures: uplink allocation; uplink release; & uplink seize.

The uplink allocation is controlled by the BSSs and group call anchor MSC. The BSS controls the uplink access for the cells in the group call area which are under its control. The group call anchor MSC controls the uplink access for the complete service area. Any allocation of the uplink access by a BSS may be refused later by the group call anchor MSC (due to the allocation of the uplink by other BSSs involved in the same voice group call).

The uplink release & uplink seize procedure is controlled and initiated by the MSC, the BSS obeys the MSC’s requests.

When the voice group call is initially set-up the state of the uplink in each BSS is such that the uplink is seized. The MSC will control the state of the uplink in each BSS by use of the uplink release and uplink seize procedures. Before an uplink may be allocated by the BSS, the MSC must have released the uplink by initiating the uplink release procedure.

3.1.24.1 Uplink allocation procedure

The uplink allocation procedure allows a listening user in a voice group call to talk on the uplink of the TCH dedicated to the voice group call in the cell.

The uplink allocation procedure can only occur once the group call anchor MSC has released the uplink (by use of the uplink release procedure).

When a mobile relinquishes the uplink or the BSS detects that the MS is no longer connected, the BSS sends to the MSC an UPLINK RELEASE INDICATION message with cause value "Call control" or "Radio interface failure" respectively. Then the BSS shall initiate the radio interface uplink free procedure.

3.1.24.1.1 Successful uplink allocation operation

On reception of a request to talk, the BSS sends an UPLINK REQUEST message to the MSC. The MSC sends the UPLINK REQUEST ACKNOWLEDGE message to confirm to the BSS that the uplink is granted to the requesting MS. The MSC also sends to all the other BSSs in the voice group call an UPLINK SEIZED COMMAND message.

The BSS sends UPLINK REQUEST CONFIRMATION message with the complete layer information, once the radio link has been established.

3.1.24.1.2 Unsuccessful uplink allocation operation

In the case that the radio link could not be established the BS sends the Uplink release indication with the cause "Radiolink interface message failure".

In the case the MSC does not want to grant the uplink, the MSC will send an UPLINK REJECT COMMAND message to the appropriate BSS. On reception of this the BSS will release the uplink for the requesting MS.

3.1.24.2 Uplink release procedure

This procedure shall be used in one of the following cases:

– the group call anchor MSC detects that none of the parties involved in a voice group call are talking . The Uplink release procedure is then used to allow the listening subscribers to talk

– the group call anchor or relay MSC detects that the talker has left the Group Call Area

To initiate this procedure the group call anchor MSC sends the UPLINK RELEASE COMMAND message to each BSS involved in the voice group call. When the BSS receives the Uplink release request command, the BSS shall initiate the radio interface uplink release procedure.

3.1.24.3 Uplink seize procedure

Once the group call anchor MSC has released the uplink it may detect speech on dedicated channel(s), in this case the MSC will send to all BSSs involved in the voice group call an UPLINK SEIZED COMMAND message. On reception of the UPLINK SEIZED COMMAND message the BSS will initiate the radio interface uplink busy procedure.

3.1.25 PDSS1 flow control

The purpose of the PDSS1 flow control procedure is to inform the MSC that it should stop or resume transmission of PDSS1 data on this particular transaction.

The BSS may on the relevant SCCP connection associated with an MS transaction send a SUSPEND message to the MSC to ask the MSC not to transmit DTAP messages carrying air interface layer 3 messages of the PDSS1 protocol. A typical reason is that too many messages are scheduled for transmission on the air interface.

The BSS may on the relevant SCCP connection associated with an MS transaction send a RESUME message to the MSC to indicate to the MSC that DTAP messages carrying air interface layer 3 messages of the PDSS1 protocol may be transmitted (the typical reason is that congestion on the air interface signalling channel does no more exist).

3.1.26 Circuit re-selection procedure

This procedure has to be supported by a BSS if and only if it allocates the A interface circuits.

The MSC can request the BSS to change the circuit allocated to a connection by sending a CHANGE CIRCUIT message to the BSS on the corresponding SCCP connection. The MSC releases the allocated circuit at the sending of the CHANGE CIRCUIT message.

The MSC shall not start the circuit re-selection procedure if another procedure is on-going that may result in the change of the circuit (e.g., circuit re-selection, handover or clearing).

At the reception of a CHANGE CIRCUIT message, and if the BSS is not already engaged in a procedure that normally results in the release of the allocated circuit (e.g., handover or clearing), the BSS allocates a new circuit and indicates it in CHANGE CIRCUIT ACKNOWLEDGE message sent back to the MSC. The BSS releases the previously allocated circuit after the sending of the CHANGE CIRCUIT ACKNOWLEDGE message.

If the MSC receives a message from the BSS indicating the start of a procedure that may result in the change of the circuit (e.g., reception of HANDOVER REQUIRED or CLEAR REQUEST), the MSC shall abort the circuit re-selection procedure.

The MSC may not be able to use the terrestrial resource that the BSS has indicated. In this case, the procedure is nevertheless considered terminated successfully, and it is up to the MSC to correct the situation, e.g., by a new circuit re-selection procedure.

3.1.27 LSA handling

The MSC may send the LSA INFORMATION message at any time during the lifetime of the relevant SCCP connection. The message is not acknowledged…

The BSS shall store the LSA identity list internally for the connection and use it for the control of internal and external handover.

In the case of overlapping LSAs, the LSA identity signalled in messages by the BSS towards the MSC shall be the LSA identity with the highest priority.

Upon reception of a new lists of LSA identities the BSS will discard the previous LSA identity list and use the new LSA identity list. The BSS shall always accept the LSA identity list, but shall ignore LSA identities, which are not known.

If the subscriber has LSA only access this has to be taken into account in the "Cell Identifier List (preferred)" in the HANDOVER REQUIRED message (see sub-clause "Generation of the HANDOVER REQUIRED message").If the subscriber has LSA only access the LSA only access indicator is set to zero at an emergency call.

Exclusive access cells may be included into "Cell Identifier List (preferred)" in the HANDOVER REQUIRED message (see sub-clause "Generation of the HANDOVER REQUIRED message") if at least one LSA identity defined in the exclusive access cell corresponds to any LSA identity received in the HANDOVER REQUEST or the latest LSA INFORMATION message. Exclusive access cells may also be included if the connection is an emergency call.

3.1.28 Location Acquisition

This procedure is utilized to support Location Services (see 3GPP TS 03.71). It is used to pass information transparently between the SMLC and BSS and request location of the target MS from the BSS.

3.1.28.1 Information transfer between SMLC and BSS

3.1.28.1.1 Successful Operation

MSC sends a CONNECTION ORIENTED INFORMATION message to BSS. This message contains Location Services related information whose content is defined in 3GPP TS 09.31 and 08.71.

The CONNECTION ORIENTED INFORMATION message is analyzed within BSS. BSS returns the CONNECTION ORIENTED INFORMATION message which contains Location Services related information. The content is defined in 3GPP TS 09.31 and 08.71.

3.1.28.1.2 Abnormal cases

Abnormal cases are specified within Connection Oriented Information Transfer procedure in 3GPP TS 09.31

3.1.28.1.3 Segmentation

If the size of an embedded BSSLAP message is too large to fit into one CONNECTION ORIENTED INFORMATION message, the sending entity divides the BSSLAP message to a necessary number of CONNECTION ORIENTED INFORMATION messages. In the APDU IE it includes as many octets as possible.

The segmentation IE in the CONNECTION ORIENTED INFORMATION message shall be included to provide segmentation identification but not message identification for a segmented BSSLAP message as defined in 3GPP TS 09.31. The segmentation IE shall not be included for a non-segmented BSSLAP message.

In case of handover interrupting the information transfer procedure, the exception procedures described in 3GPP TS 03.71 shall be used.

3.1.28.2 Location request

3.1.28.2.1 Successful Operation

PERFORM LOCATION REQUEST message may be sent in order to perform location procedure for the target MS. This message may be sent either from the MSC to the BSS or from the BSS to the MSC (towards NSS based SMLC). This message contains following information:

– Location type

– Cell Identifier

– Classmark Information Type 3

– LCS Client Type

– Chosen Channel

– LCS Priority

– Quality of service

– GPS Assistance Data

– APDU, variable length octet string of which content is defined in 09.31 and 08.71.

On receipt of the PERFORM LOCATION REQUEST message for positioning of the target MS, the BSS transfers the positioning request to the SMLC according to the procedures defined in 3GPP TS 03.713GPP TS 03.71 and 09.31 and awaits the result. The BSS then returns the result of positioning to the MSC in the PERFORM LOCATION RESPONSE message. This message contains following information:

– Location estimate

– Positioning data

If assistance data was instead requested by the MSC for an MS, the BSS transfers the request to the SMLC according to the procedures defined in 3GPP TS 03.713GPP TS 03.71 and 09.31 and awaits the result. If the SMLC was able successfully to transfer this to the MS, the BSS shall return a PERFORM LOCATION RESPONSE message to the MSC. This message shall contain no parameters. The absence of an LCS Cause parameter in this case implies that the transfer was successful.

Otherwise, if a deciphering keys were requested for LCS broadcast assistance data, the BSS transfers the request to the SMLC according to the procedures defined in 3GPP TS 03.713GPP TS 03.71 and 09.31 and awaits the result. If the SMLC has access to the appropriate keys, the BSS shall return a PERFORM LOCATION RESPONSE message to MSC. This message contains following information:

– Deciphering Keys

On receipt of the PERFORM LOCATION REQUEST message, the MSC forwards location request to the NSS based SMLC as a BSSMAP-LE PERFORM LOCATION REQUEST message defined in 3GPP TS 09.31. The NSS based SMLC returns the result of positioning to the MSC in the BSSMAP-LE PERFORM LOCATION RESPONSE message defined in 3GPP TS 09.31. The MSC forwards the result of positioning in PERFORM LOCATION RESPONSE message to the BSS.

3.1.28.2.2 Unsuccessful Operation

If the BSS fails to respond to the PERFORM LOCATION REQUEST message it returns a PERFORM LOCATION RESPONSE message with a LCS cause value indicating the failure cause. Possible failure causes are listed in 3GPP TS 09.31.

3.1.28.2.3 Abnormal cases

The following condition may occur:

If the MSC needs to abort previously initiated location request, it shall send the PERFORM LOCATION ABORT message to the BSS. As a result of reception of this message the BSS shall abort activities related to positioning of the target MS or assistance data delivery. The BSS shall return a PERFORM LOCATION RESPONSE with a cause value indicating the abortion of location request.

3.1.28.2.4 Overload

For location requests initiated by the MSC, the BSC may employ the same procedures defined for an SMLC in 3GPP TS 09.31 to alleviate an overload condition in the BSS. For location requests initiated by the BSC, the BSC shall follow the procedures defined in 3GPP TS 09.31 if an overload condition is indicated by the SMLC or MSC.

3.1.29 Connectionless Information Transfer procedure

The SMLC may send information to another SMLC transparently via the BSS, MSC or BSS and MSC.

The CONNECTIONLESS INFORMATION message shall be sent via the BSSMAP as a connectionless message.

The BSS shall send the CONNECTIONLESS INFORMATION message to the MSC with the following information:

– Network Element Identity (source), which define the source SMLC for the message.

– Network Element Identity (target), which define the target SMLC for the message.

– Variable length octet string (APDU IE), of which content is defined in 09.31

– Segmentation IE containing segmentation and message identification: included only with a segmented APDU

– The Return Error Request may be included to request notification in the event of unsuccessful transfer.

On receipt of the CONNECTIONLESS INFORMATION message, the MSC transmits this message to the target SMLC itself if reachable directly or to another MSC or BSS on a direct path to the target SMLC, as derived from the Network Element Identity (target) IE. The contents of APDU IE is transparent to the MSC.

If the source SMLC and the target SMLC are associated with different MSCs, then the CONNECTIONLESS INFORMATION message shall forwarded between MSCs via the BSSMAP-LE as a connectionless message (see 3GPP TS 09.31).

3.1.29.1 Unsuccessful Operation

Unsuccessful operation is specified within Connectionless Information Transfer procedure in 3GPP TS 09.31.

3.1.29.2 Abnormal cases

Abnormal cases are specified within Connectionless Information Transfer procedure in 3GPP TS 09.31.

3.1.29.3 Segmentation

The Segmentation parameter shall not be included if the APDU is not segmented.

If the size of an embedded SMLCPP message is too large to fit into one CONNECTIONLESS INFORMATION message, the sending entity divides the SMLCPP message to a necessary number of CONNECTIONLESS INFORMATION messages each containing an APDU IE and a Segmentation IE. In the APDU IE it includes as many octets as possible.

The segmentation IE contains a segment number, an indication of the final segment and the message ID. The order number of a segment in the Segment Number field in the SEGMENTATION IE is incremented by one starting from zero, i.e. the value is 0 for the first segment, 1 for the next and so on. The receiving entity recognizes that a segment is missing or duplicated, when

– There is more than one segment with the same segment number and same Message ID.

– The segment number does not increase by steps of one starting from zero.

If the recipient recognizes a missing or duplicated element, it shall discard the entire message (i.e. all received segment with the message ID).

The message identity in the Message ID field in the SEGMENTATION IE is used to recognize a particular message to which the segment belongs. The sending entity can select any of the available values (0-65535) that is not currently used between it and the receiving entity.

If an APDU segment is received with Return Errror cause IE (due to invocation of the return error option), reassembly does not apply and the APDU segment and error cause maybe returned to the original source application.

3.1.30 Common ID

The purpose of the Common ID procedure is to inform the BSC about the IMSI of a user. This may be used by the BSC to create a reference between the user and the RR and SCCP connections of that user for paging co-ordination. The procedure uses connection oriented signalling.

If the MS, the BSS and the MSC support DTM and as soon as the IMSI is available at the MSC, the MSC shall send the COMMON ID message to the BSS.

The BSC associates the permanent identity to the RR and SCCP connections of that user for the duration of the RR connection.