4.5 Connection management sublayer service provision

04.083GPPMobile radio interface Layer 3 specificationRelease 1998TS

The concept of MM connection is introduced in this sub-clause. This concept is mainly a descriptive tool: The establishment of an MM connection by the network can be local (i.e. it is achieved by the transmission of the first CM layer message and without the transmission of any MM layer messages) or can be achieved by the transmission of a CM SERVICE PROMPT message (eg. in the case of certain ring back services). The release of an MM connection by the network or by the mobile station is always local, i.e. these purposes can be achieved without sending any MM messages over the radio interface. (On the contrary, establishment of an MM connection by the mobile station requires the sending of MM messages over the radio interface. An exception is VGCS, where an MM connection will be established as result of an uplink access procedure (see sub-clause 3.7.2.1.1).)

The Mobility Management (MM) sublayer is providing connection management services to the different entities of the upper Connection management (CM) sublayer (see 3GPP TS 04.07). It offers to a CM entity the possibility to use an MM connection for the exchange of information with its peer entity. An MM connection is established and released on request from a CM entity. Different CM entities communicate with their peer entity using different MM connections. Several MM connections may be active at the same time.

An MM connection requires an RR connection. All simultaneous MM connections for a given mobile station use the same RR connection.

In the following sub-clauses, the procedures for establishing, re-establishing, maintaining, and releasing an MM connection are described, usually separately for the mobile station and the network side.

4.5.1 MM connection establishment

4.5.1.1 MM connection establishment initiated by the mobile station

Upon request of a CM entity to establish an MM connection the MM sublayer first decides whether to accept, delay, or reject this request:

– An MM connection establishment may only be initiated by the mobile station when the following conditions are fulfilled:

– Its update status is UPDATED.

– The MM sublayer is in one of the states MM IDLE, RR CONNECTION RELEASE NOT ALLOWED or MM connection active but not in MM connection active (Group call).

An exception from this general rule exists for emergency calls (see sub-clause 4.5.1.5). A further exception is defined in the following sub-clause.

– If an MM specific procedure is running at the time the request from the CM sublayer is received, and the LOCATION UPDATING REQUEST message has been sent, the request will either be rejected or delayed, depending on implementation, until the MM specific procedure is finished and, provided that the network has not sent a "follow-on proceed" indication, the RR connection is released. If the LOCATION UPDATING REQUEST message has not been sent, the mobile station may include a "follow-on request" indicator in the message. The mobile station shall then delay the request until the MM specific procedure is completed, when it may be given the opportunity by the network to use the RR connection: see sub-clause 4.4.4.6.

In order to establish an MM connection, the mobile station proceeds as follows:

a) If no RR connection exists, the MM sublayer requests the RR sublayer to establish an RR connection and enters MM sublayer state WAIT FOR RR CONNECTION (MM CONNECTION). This request contains an establishment cause and a CM SERVICE REQUEST message. When the establishment of an RR connection is indicated by the RR sublayer (this indication implies that the CM SERVICE REQUEST message has been successfully transferred via the radio interface, see sub-clause 2.2), the MM sublayer of the mobile station starts timer T3230, gives an indication to the CM entity that requested the MM connection establishment, and enters MM sublayer state WAIT FOR OUTGOING MM CONNECTION.

b) If an RR connection is available, the MM sublayer of the mobile station sends a CM SERVICE REQUEST message to the network, starts timer T3230, stops and resets timer T3241, gives an indication to the CM entity that requested the MM connection establishment, and enters:

– MM sublayer state WAIT FOR OUTGOING MM CONNECTION, if no MM connection is active;

– MM sublayer state WAIT FOR ADDITIONAL OUTGOING MM CONNECTION, if at least one MM connection is active;

– If an RR connection exists but the mobile station is in the state WAIT FOR NETWORK COMMAND then any requests from the CM layer that are received will either be rejected or delayed until this state is left.

c) Only applicable for mobile stations supporting VGCS talking:

– If a mobile station which is in the MM sublayer state MM IDLE, service state RECEIVING GROUP CALL (NORMAL SERVICE), receives a request from the GCC sublayer to perform an uplink access, the MM sublayer requests the RR sublayer to perform an uplink access procedure and enters MM sublayer state WAIT FOR RR CONNECTION (GROUP TRANSMIT MODE).

– When a successful uplink access is indicated by the RR sublayer, the MM sublayer of the mobile station gives an indication to the GCC sublayer and enters MM sublayer state MM CONNECTION ACTIVE (GROUP TRANSMIT MODE).

– When an uplink access reject is indicated by the RR sublayer, the MM sublayer of the mobile station gives an indication to the GCC sublayer and enters the MM sublayer state MM IDLE, service state RECEIVING GROUP CALL (NORMAL SERVICE).

– In the network, if an uplink access procedure is performed, the RR sublayer in the network provides an indication to the MM sublayer together with the mobile subscriber identity received in the TALKER INDICATION message. The network shall then enter the MM sublayer state MM CONNECTION ACTIVE (GROUP TRANSMIT MODE).

The CM SERVICE REQUEST message contains the

– mobile identity according to sub-clause 10.5.1.4;

– mobile station classmark 2;

– ciphering key sequence number; and

– CM service type identifying the requested type of transaction (e.g. mobile originating call establishment, emergency call establishment, short message service, supplementary service activation), location services)

A MS supporting eMLPP may optionally include a priority level in the CM SERVICE REQUEST message.

A collision may occur when a CM layer message is received by the mobile station in MM sublayer state WAIT FOR OUTGOING MM CONNECTION or in WAIT FOR ADDITIONAL OUTGOING MM CONNECTION. In this case the MM sublayer in the MS shall establish a new MM connection for the incoming CM message as specified in sub-clause 4.5.1.3.

Upon receiving a CM SERVICE REQUEST message, the network shall analyse its content. The type of semantic analysis may depend on other on going MM connection(s). Depending on the type of request and the current status of the RR connection, the network may start any of the MM common procedures and RR procedures.

The network may initiate the classmark interrogation procedure, for example, to obtain further information on the mobile station’s encryption capabilities.

The identification procedure (see sub-clause 4.3.3) may be invoked for instance if a TMSI provided by the mobile station is not recognized.

The network may invoke the authentication procedure (see sub-clause 4.3.2) depending on the CM service type.

The network decides also if the ciphering mode setting procedure shall be invoked (see sub-clause 3.4.7).

NOTE: If the CM_SERVICE_REQUEST message contains a priority level the network may use this to perform queuing and pre-emption as defined in 3GPP TS 03.67.

An indication from the RR sublayer that the ciphering mode setting procedure is completed, or reception of a CM SERVICE ACCEPT message, shall be treated as a service acceptance indication by the mobile station. The MM connection establishment is completed, timer T3230 shall be stopped, the CM entity that requested the MM connection shall be informed, and MM sublayer state MM CONNECTION ACTIVE is entered. The MM connection is considered to be active.

If the service request cannot be accepted, the network returns a CM SERVICE REJECT message to the mobile station.

The reject cause information element (see sub-clause 10.5.3.6 and Annex G) indicates the reason for rejection. The following cause values may apply:

#4: IMSI unknown in VLR.

#6: Illegal ME.

#17: Network failure.

#22: Congestion.

#32: Service option not supported.

#33: Requested service option not subscribed.

#34: Service option temporarily out of order.

If no other MM connection is active, the network may start the RR connection release (see sub-clause 3.5) when the CM SERVICE REJECT message is sent.

If a CM SERVICE REJECT message is received by the mobile station, timer T3230 shall be stopped, the requesting CM sublayer entity informed. Then the mobile station shall proceed as follows:

– If the cause value is not #4 or #6 the MM sublayer returns to the previous state (the state where the request was received). Other MM connections shall not be affected by the CM SERVICE REJECT message.

– If cause value #4 is received, the mobile station aborts any MM connection, deletes any TMSI, LAI and ciphering key sequence number in the SIM, changes the update status to NOT UPDATED (and stores it in the SIM according to sub-clause 4.1.2.2), and enters the MM sublayer state WAIT FOR NETWORK COMMAND. If subsequently the RR connection is released or aborted, this will force the mobile station to initiate a normal location updating). Whether the CM request shall be memorized during the location updating procedure, is a choice of implementation.

– If cause value #6 is received, the mobile station aborts any MM connection, deletes any TMSI, LAI and ciphering key sequence number in the SIM, changes the update status to ROAMING NOT ALLOWED (and stores it in the SIM according to sub-clause 4.1.2.2), and enters the MM sublayer state WAIT FOR NETWORK COMMAND. The mobile station shall consider the SIM as invalid until switch-off or the SIM is removed.

4.5.1.2 Abnormal cases

Mobile station side:

a) RR connection failure or IMSI deactivation

If an RR connection failure occurs or the IMSI is deactivated during the establishment of an MM connection, the MM connection establishment is aborted, timers T3230 is stopped, and an indication is given to the CM entity that requested the MM connection establishment. This shall be treated as a rejection for establishment of the new MM connection, and the MM sublayer shall release all active MM connections.

b) T3230 expiry

If T3230 expires (i.e. no response is given but a RR connection is available) the MM connection establishment is aborted and the requesting CM sublayer is informed. If no other MM connection exists then the mobile station shall proceed as described in sub-clause 4.5.3.1 for release of the RR connection. Otherwise the mobile station shall return to the MM sublayer state where the request of an MM connection was received, i.e. to MM sublayer state MM connection active. Other ongoing MM connections (if any) shall not be affected.

c) Reject cause values #95, #96, #97, #99, #100, #111 received

The same actions as on timer expiry shall be taken by the mobile station.

d) Random access failure or RR connection establishment failure

If the mobile station detects a random access failure or RR connection establishment failure during the establishment of an MM connection, it aborts the MM connection establishment and gives an indication to the CM entity that requested the MM connection establishment.

NOTE: Further actions of the mobile station depend on the RR procedures and MM specific procedures during which the abnormal situation has occurred and are described together with those procedures.

Network side:

a) RR connection failure

The actions to be taken upon RR connection failure within a MM common procedure are described together with that procedure. A RR connection failure occurring outside such MM common procedures, shall trigger the release of all active MM connections if any.

b) Invalid message or message content

Upon reception of an invalid initial message or a CM SERVICE REQUEST message with invalid content, a CM SERVICE REJECT message shall be returned with one of the following appropriate Reject cause indications:

# 95: Semantically incorrect message

# 96: Mandatory information element error

# 97: Message type non-existent or not implemented

# 99: Information element non-existent or not implemented

# 100: Conditional IE error

# 111: Protocol error, unspecified

When the CM SERVICE REJECT message has been sent, the network may start RR connection release if no other MM connections exist or if the abnormal condition also has influence on the other MM connections.

4.5.1.3 MM connection establishment initiated by the network

4.5.1.3.1 Mobile Terminating CM Activity

When a CM sublayer entity in the network requests the MM sublayer to establish a MM connection, the MM sublayer will request the establishment of an RR connection to the RR sublayer if no RR connection to the desired mobile station exists. The MM sublayer is informed when the paging procedure is finished (see sub-clause 3.3.2) and the mobile station shall enter the MM state WAIT FOR NETWORK COMMAND.

(* editor’s note: this does not appear to be stated any where other than in fig 4.1a. Without this statement, there does not seem to be anything to stop the mobile sending a CM SERVICE REQUEST message which might cross (ambiguously) with a CIPHERING MODE COMMAND message. *)

When an RR connection is established (or if it already exists at the time the request is received), the MM sublayer may initiate any of the MM common procedures (except IMSI detach); it may request the RR sublayer to perform the RR classmark interrogation procedure, and/or the ciphering mode setting procedure.

When all MM and RR procedures are successfully completed which the network considers necessary, the MM sublayer will inform the requesting mobile terminating CM sublayer entity on the success of the MM connection establishment.

If an RR connection already exists and no MM specific procedure is running, the network may also establish a new mobile terminating MM connection by sending a CM message with a new PD/TI combination.

If the MS receives the first CM message in the MM states WAIT FOR NETWORK COMMAND or RR CONNECTION RELEASE NOT ALLOWED, the MS shall stop and reset the timers T3240 and T3241 and shall enter the MM state MM CONNECTION ACTIVE.

If the establishment of an RR connection is unsuccessful, or if any of the MM common procedures or the ciphering mode setting fail, this is indicated to the CM layer with an appropriate error cause.

If an RR connection used for a MM specific procedure exists to the mobile station, the CM request may be rejected or delayed depending on implementation. When the MM specific procedure has been completed, the network may use the same RR connection for the delayed CM request.

Only applicable in case of VGCS talking:

– In the MM CONNECTION ACTIVE (GROUP TRANSMIT MODE) the mobile station is in RR Group transmit mode. There shall be only one MM connection active.

– When in MM CONNECTION ACTIVE (GROUP TRANSMIT MODE) state, the MM sublayer in the network shall reject the request for the establishment of another MM connection by any CM layer.

– If the RR sublayer in the network indicates a request to perform a transfer of the mobile station from RR connected mode to RR Group transmit mode which will result in a transition from MM CONNECTION ACTIVE state to MM CONNECTION ACTIVE (GROUP TRANSMIT MODE) state in the MM sublayer, the MM sublayer shall not allow the transition if more than one MM connection is active with the mobile station.

4.5.1.3.2 Mobile Originating CM Activity $(CCBS)$

When a CM sublayer entity in the network requests the MM sublayer to establish a MM connection, the MM sublayer will request the establishment of an RR connection to the RR sublayer if no RR connection to the desired mobile station exists. The MM sublayer is informed when the paging procedure is finished (see sub-clause 3.3.2) and the mobile station shall enter the MM state WAIT FOR NETWORK COMMAND.

When an RR connection is established (or if it already exists at the time the request is received), the MM sublayer may initiate any of the MM common procedures (except IMSI detach), it may request the RR sublayer to perform the RR classmark interrogation procedure and/or the ciphering mode setting procedure.

The network should use the information contained in the Mobile Station Classmark Type 2 IE on the mobile station’s support for "Network Initiated MO CM Connection Request" to determine whether to:

– not start this procedure (eg if an RR connection already exists); or

– to continue this procedure; or

– to release the newly established RR connection.

In the case of a "Network Initiated MO CM Connection Request" the network shall use the established RR connection to send a CM SERVICE PROMPT message to the mobile station.

If the mobile station supports "Network Initiated MO CM Connection Request", the MM sublayer of the MS gives an indication to the CM entity identified by the CM SERVICE PROMPT message and enters the MM sublayer state PROCESS CM SERVICE PROMPT. In the state PROCESS CM SERVICE PROMPT the MM sublayer waits for either the rejection or confirmation of the recall by the identified CM entity. Any other requests from the CM entities shall either be rejected or delayed until this state is left.

When the identified CM entity informs the MM sublayer, that it has send the first CM message in order to start the CM recall procedure the MM sublayer enters the state MM CONNECTION ACTIVE.

If the identified CM entity indicates that it will not perform the CM recall procedure and all MM connections are released by their CM entities the MS shall proceed according to sub-clause 4.5.3.1.

If the CM SERVICE PROMPT message is received by the MS in MM sublayer states WAIT FOR OUTGOING MM CONNECTION or in WAIT FOR ADDITIONAL OUTGOING MM CONNECTION then the mobile station shall send an MM STATUS message with cause " Message not compatible with protocol state".

A mobile that does not support "Network Initiated MO CM Connection Request" shall return an MM STATUS message with cause #97 "message type non-existent or not implemented" to the network.

If the mobile station supports "Network Initiated MO CM Connection Request" but the identified CM entity in the mobile station does not provide the associated support, then the mobile station shall send an MM STATUS message with cause "Service option not supported". In the case of a temporary CM problem (eg lack of transaction identifiers) then the mobile station shall send an MM STATUS message with cause "Service option temporarily out of order".

If an RR connection already exists and no MM specific procedure is running, the network may use it to send the CM SERVICE PROMPT message.

If the establishment of an RR connection is unsuccessful, or if any of the MM common procedures or the ciphering mode setting fail, this is indicated to the CM layer in the network with an appropriate error cause.

If an RR connection used for a MM specific procedure exists to the mobile station, the "Network Initiated MO CM Connection Request" may be rejected or delayed depending on implementation. When the MM specific procedure has been completed, the network may use the same RR connection for the delayed "Network Initiated MO CM Connection Request".

4.5.1.4 Abnormal cases

The behaviour upon abnormal events is described together with the relevant RR procedure or MM common procedure.

4.5.1.5 MM connection establishment for emergency calls

A MM connection for an emergency call may be established in all states of the mobility management sublayer which allow MM connection establishment for a normal originating call. In addition, establishment may be attempted in all service states where a cell is selected (see sub-clause 4.2.2) but not in the MM CONNECTION ACTIVE state (GROUP TRANSMIT MODE) state. However, as a network dependent option, a MM connection establishment for emergency call may be rejected in some of the states.

When a user requests an emergency call establishment the mobile station will send a CM SERVICE REQUEST message to the network with a CM service type information element indicating emergency call establishment. If the network does not accept the emergency call request, e.g., because IMEI was used as identification and this capability is not supported by the network, the network will reject the request by returning a CM SERVICE REJECT message to the mobile station.

The reject cause information element indicates the reason for rejection. The following cause values may apply:

#3 "Illegal MS";

#4 "IMSI unknown in VLR";

#5 "IMEI not accepted";

#6 "Illegal ME";

#17 "Network failure";

#22 "Congestion";

#32 "Service option not supported";

#34 "Service option temporarily out of order".

With the above defined exceptions, the procedures described for MM connection establishment in sub-clause 4.5.1.1 and sub-clause 4.5.1.2 shall be followed.

NOTE: Normally, the mobile station will be identified by an IMSI or a TMSI. However, if none of these identifiers is available in the mobile station, then the mobile station shall use the IMEI for identification purposes. The network may in that case reject the request by returning a CM SERVICE REJECT message with reject cause:

#5 "IMEI not accepted".

4.5.1.6 Call re-establishment

The re-establishment procedure allows a MS to resume a connection in progress after a radio link failure, possibly in a new cell and possibly in a new location area. The conditions in which to attempt call re-establishment or not depend on the call control state, see sub-clause 5.5.4 and, whether or not a cell allowing call re-establishment has been found (as described in 3GPP TS 05.08). MM connections are identified by their protocol discriminators and transaction identifiers: these shall not be changed during call re-establishment.

The re-establishment takes place when a lower layer failure occurs and at least one MM connection is active (i.e. the mobile station’s MM sublayer is either in state 6 "MM CONNECTION ACTIVE" or state 20 "WAIT FOR ADDITIONAL OUTGOING MM CONNECTION").

NOTE: During a re-establishment attempt the mobile station does not return to the MM IDLE state; thus no location updating is performed even if the mobile is not updated in the location area of the selected cell.

No call re-establishment shall be performed for voice group and broadcast calls.

4.5.1.6.1 Call re-establishment, initiation by the mobile station

NOTE: The network is unable to initiate call re-establishment.

If at least one request to re-establish an MM connection is received from a CM entity as a response to the indication that the MM connection is interrupted (see sub-clause 4.5.2.3.) the mobile station initiates the call re-establishment procedure. If several CM entities request re-establishment only one re-establishment procedure is initiated. If any CM entity requests re-establishment, then re-establishment of all transactions belonging to all Protocol Discriminators that permit Call Re-establishment shall be attempted.

Upon request of a CM entity to re-establish an MM connection the MM sublayer requests the RR sublayer to establish an RR connection and enters MM sublayer state WAIT FOR REESTABLISH. This request contains an establishment cause and a CM RE-ESTABLISHMENT REQUEST message. When the establishment of an RR connection is indicated by the RR sublayer (this indication implies that the CM RE-ESTABLISHMENT REQUEST message has been successfully transferred via the radio interface, see sub-clause 2.2), the MM sublayer of the mobile station starts timer T3230, gives an indication to all CM entities that are being re-established, and remains in the MM sublayer state WAIT FOR REESTABLISH.

The CM RE-ESTABLISHMENT REQUEST message contains the:

– mobile identity according to sub-clause 10.5.1.4;

– mobile station classmark 2;

– ciphering key sequence number.

NOTE: Whether or not a CM entity can request re-establishment depends upon the Protocol Discriminator. The specifications for Short Message Service (3GPP TS 04.11), Call Independent Supplementary Services (3GPP TS 04.10) and Location Services (3GPP TS 04.71) do not currently specify any re-establishment procedures.

Upon receiving a CM RE-ESTABLISHMENT REQUEST message, the network shall analyse its content. Depending on the type of request, the network may start any of the MM common procedures and RR procedures.

The network may initiate the classmark interrogation procedure, for example, to obtain further information on the mobile station’s encryption capabilities.

The identification procedure (see sub-clause 4.3.3) may be invoked.

The network may invoke the authentication procedure (see sub-clause 4.3.2).

The network decides if the ciphering mode setting procedure shall be invoked (see sub-clause 3.4.7).

An indication from the RR sublayer that the ciphering mode setting procedure is completed, or reception of a CM SERVICE ACCEPT message, shall be treated as a service acceptance indication by the mobile station. The MM connection re-establishment is completed, timer T3230 shall be stopped, all CM entities associated with the re-establishment shall be informed, and MM sublayer state MM CONNECTION ACTIVE is re-entered. All the MM connections are considered to be active.

If the network cannot associate the re-establishment request with any existing call for that mobile station, a CM SERVICE REJECT message is returned with the reject cause:

#38 "call cannot be identified".

If call re-establishment cannot be performed for other reasons, a CM SERVICE REJECT is returned, the appropriate reject cause may be any of the following (see annex G):

# 4 "IMSI unknown in VLR";

# 6 "illegal ME";

#17 "network failure";

#22 "congestion";

#32 "service option not supported";

#34 "service option temporarily out of order".

Whatever the reject cause a mobile station receiving a CM SERVICE REJECT as a response to the CM RE-ESTABLISHMENT REQUEST shall stop T3230, release all MM connections and proceed as described in sub-clause 4.5.3.1. In addition:

– if cause value #4 is received, the mobile station deletes any TMSI, LAI and ciphering key sequence number in the SIM, changes the update status to NOT UPDATED (and stores it in the SIM according to sub-clause 4.1.2.2), and enters the MM sublayer state WAIT FOR NETWORK COMMAND. If subsequently the RR connection is released or aborted, this will force the mobile station to initiate a normal location updating). The CM re-establishment request shall not be memorized during the location updating procedure.

– if cause value #6 is received, the mobile station deletes any TMSI, LAI and ciphering key sequence number in the SIM, changes the update status to ROAMING NOT ALLOWED (and stores it in the SIM according to sub-clause 4.1.2.2), and enters the MM sublayer state WAIT FOR NETWORK COMMAND. The MS shall consider the SIM as invalid until switch-off or the SIM is removed.

4.5.1.6.2 Abnormal cases

Mobile station side:

a) Random access failure or RR connection establishment failure

If the mobile station detects a random access failure or RR connection establishment failure during the re-establishment of an MM connection, the re-establishment is aborted and all MM connections are released.

b) RR connection failure

If a RR connection failure occurs, timer T3230 is stopped, the re-establishment is aborted and all active MM connections are released.

c) IMSI deactivation

If the IMSI deactivated during the re-establishment attempt then timer T3230 is stopped, the re-establishment is aborted and all MM connections are released.

d) T3230 expires

If T3230 expires (i.e. no response is given but a RR connection is available) the re-establishment is aborted, all active MM connections are released and the mobile station proceeds as described in sub-clause 4.5.3.1.

e) Reject causes #96, #97, #99, #100, #111 received

The mobile station shall perform the same actions as if timer T3230 had expired.

Network side:

a) RR connection failure

If a RR connection failure occurs after receipt of the CM RE-ESTABLISHMENT REQUEST the network shall release all MM connections.

b) Invalid message content

Upon reception an invalid initial of message or a CM RE-ESTABLISHMENT REQUEST message with invalid content, a CM SERVICE REJECT message shall be returned with one of the following appropriate Reject cause indications:

#96: Mandatory information element error

#99: Information element non-existent or not implemented

#100: Conditional IE error

#111: Protocol error, unspecified

When the CM SERVICE REJECT message has been sent, the network shall release the RR connection.

4.5.1.7 Forced release during MO MM connection establishment

If the mobile station’s CM layer initiated the MM connection establishment but the CM layer wishes to abort the establishment prior to the completion of the establishment phase, the mobile station shall send a CM SERVICE ABORT message any time after the completion of the RR connection and not after the first CM message (e.g. SETUP) is sent.

If the first CM message has already been sent, the normal release procedure defined by the appropriate CM protocol applies and the CM SERVICE ABORT shall not be sent.

Sending of the CM SERVICE ABORT message is only allowed during the establishment of the first MM connection, where no other MM connection exists in parallel. If parallel MM connections exist already, a new connection establishment cannot be aborted and normal MM connection release according to 4.5.3 applies after MM connection establishment.

Upon transmission of the CM SERVICE ABORT message the mobile station shall set timer T3240 and enter the state WAIT FOR NETWORK COMMAND, expecting the release of the RR connection.

Upon receipt of the CM SERVICE ABORT message the network shall abort ongoing processes, release the appropriate resources, and unless another MM connection establishment is pending, initiate a normal release of the RR connection.

If the RR connection is not released within a given time controlled by timer T3240, the mobile station shall abort the RR connection. In both cases, either after a RR connection release triggered from the network side or after a RR connection abort requested by the mobile station side the mobile station shall return to state MM IDLE; the service state depending upon the current update status as specified in sub-clause 4.2.3.

4.5.2 MM connection information transfer phase

After the MM connection has been established, it can be used by the CM sublayer entity for information transfer. According to the protocol architecture described in 3GPP TS 04.07, each CM entity will have its own MM connection. These different MM connections are identified by the protocol discriminator PD and, additionally, by the transaction identifier TI.

All MM common procedures may be initiated at any time while MM connections are active. Except for Short Message Control which uses a separate layer 2 low priority data link, no priority mechanism is defined between the CM, MM and RR sublayer messages.

4.5.2.1 Sending CM messages

A CM sublayer entity, after having been advised that a MM connection has been established, can request the transfer of CM messages. The CM messages passed to the MM sublayer are then sent to the other side of the interface with the PD and TI set according to the source entity.

4.5.2.2 Receiving CM messages

Upon receiving a CM message, the MM sublayer will distribute it to the relevant CM entity according to the PD value and TI value. However, if the received CM message is the first for the MM connection (identified by PD and TI), the MM sublayer will in addition indicate to the CM entity that a new MM connection has been established.

4.5.2.3 Abnormal cases

RR connection failure:

– If the RR connection failure occurs during a RR or MM common procedure, the consequent actions are described together with that procedure.

– In other cases, the following applies:

– Mobile station:

– The MM sublayer shall indicate to all CM entities associated with active MM connections that the MM connection is interrupted, the subsequent action of the MM sublayer (call re-establishment, see 4.5.1.6, or local release) will then depend on the decisions by the CM entities.

– Network:

– The MM sublayer shall locally release all active MM connections. As an option the network may delay the release of all or some of the MM connections to allow the mobile station to initiate call re-establishment

4.5.3 MM connection release

An established MM connection can be released by the local CM entity. The release of the CM connection will then be done locally in the MM sublayer, i.e. no MM message are sent over the radio interface for this purpose.

4.5.3.1 Release of associated RR connection

If all MM connections are released by their CM entities, and no RRLP procedure (see 3GPP TS 04.31 [23b]) is ongoing, the mobile station shall set timer T3240 and enter the state WAIT FOR NETWORK COMMAND, expecting the release of the RR connection.

If all MM connections are released by their CM entities and an RRLP procedure is ongoing, the MS shall start the timer T3241 and enter the state RR CONNECTION RELEASE NOT ALLOWED.

If the MS is expecting the release of the RR connection in MM state WAIT FOR NETWORK COMMAND and an RRLP procedure is started, the MS shall stop the timer T3240, start the timer T3241 and enter the state RR CONNECTION RELEASE NOT ALLOWED.

If the MS is in MM state RR CONNECTION RELEASE NOT ALLOWED and the ongoing RRLP procedure is finished, the MS shall stop the timer T3241, reset and start the timer T3240 and shall enter the state WAIT FOR NETWORK COMMAND.

In the network, if the last MM connection is released by its user, the MM sublayer may decide to release the RR connection by requesting the RR sublayer according to sub-clause 3.5. The RR connection may be maintained by the network, e.g. in order to establish another MM connection.

If the RR connection is not released within a given time controlled by the timer T3240 or T3241, the mobile station shall abort the RR connection. In both cases, either after a RR connection release triggered from the network side or after a RR connection abort requested by the MS-side, the MS shall return to MM IDLE state; the service state depending upon the current update status as specified in sub-clause 4.2.3.

4.5.3.2 Uplink release in a voice group call

(Only applicable for mobile stations supporting VGCS talking:)

If a mobile station which is in the MM sublayer state MM CONNECTION ACTIVE (GROUP TRANSMIT MODE) receives a request from the GCC sublayer to perform an uplink release, the MM sublayer requests the RR sublayer to perform an uplink release procedure and enters the MM sublayer state RECEIVING GROUP CALL (NORMAL SERVICE).