7 Services provided by signalling layer 3 on the Network side

04.073GPPMobile Radio Interface Signalling Layer 3 - General AspectsTS

In this clause, the services provided by signalling layer 3 on the network side are described which belong to the CM sub‑layer functional blocks of CC, SMS, and SS. The services corresponding to further functional blocks of the CM sublayer are not further described in this clause.

7.1 Call control services

The Call Control services are provided by multiple CC entities at the service access point MNCC‑SAP.

The Call Control service class consists of the following services:

‑ call establishment;

‑ call maintaining;

‑ call termination;

‑ call related Supplementary Services Support.

7.1.1 Service state diagram

The Call Control services provided at the service access point MNCC‑SAP are illustrated in figure 7.1.

Figure 7.1: (page 1 of 2) Service graph of Call Control entity ‑ Network side

Figure 7.1: (page 2 of 2) Service graph of Call Control entity ‑ Network side

7.1.2 Service primitives

Table 7.1: Primitives and Parameters at MNCC‑SAP ‑ Network side

PRIMITIVE

PARAMETER
(message, info elements of message, other parameters)

REFERENCE

MNCC_SETUP_REQ

SETUP incl. Mobile ID or EMERGENCY SETUP

7.1.2.1

MNCC_SETUP_IND

SETUP

7.1.2.2

MNCC_SETUP_RSP

CONNECT

7.1.2.3

MNCC_SETUP_CNF

CONNECT

7.1.2.4

MNCC_SETUP_COMPL_REQ

CONNECT ACKNOWLEDGE

7.1.2.5

MNCC_SETUP_COMPL_IND

CONNECT ACKNOWLEDGE

7.1.2.6

MNCC_REJ_REQ

RELEASE COMPLETE

7.1.2.7

MNCC_REJ_IND

cause

7.1.2.8

MNCC_CALL_CONF_IND

CALL CONFIRMED

7.1.2.9

MNCC_CALL PROC_REQ

CALL PROCEEDING

7.1.2.10

MNCC_PROGRESS_REQ

PROGRESS

7.1.2.11

MNCC_ALERT_REQ

ALERTING

7.1.2.12

MNCC_ALERT_IND

ALERTING

7.1.2.13

MNCC_NOTIFY_REQ

NOTIFY

7.1.2.14

MNCC_NOTIFY_IND

NOTIFY

7.1.2.15

MNCC_DISC_REQ

DISCONNECT

7.1.2.16

MNCC_DISC_IND

DISCONNECT

7.1.2.17

MNCC_REL_REQ

RELEASE or DISCONNECT

7.1.2.18

MNCC_REL_IND

RELEASE

7.1.2.19

MNCC_REL_CNF

RELEASE or RELEASE COMPLETE

7.1.2.20

MNCC_FACILITY_REQ

facility

7.1.2.21

MNCC_FACILITY_IND

facility

7.1.2.22

MNCC_START_DTMF_IND

START DTMF

7.1.2.23

MNCC_START_DTMF_RSP

START DTMF ACK or START DTMF REJ

7.1.2.24

MNCC_STOP_DTMF_IND

STOP DTMF

7.1.2.25

MNCC_STOP_DTMF_RSP

STOP DTMF ACK

7.1.2.26

MNCC_MODIFY_REQ

MODIFY or BC‑parameter

7.1.2.27

MNCC_MODIFY_IND

BC‑parameter

7.1.2.28

MNCC_MODIFY RES

MODIFY COMPLETE

7.1.2.29

MNCC_MODIFY_CNF

BC‑parameter

7.1.2.30

7.1.2.1 MNCC_SETUP_REQ

Request to send a SETUP message to initiate Mobile terminated establishment.

7.1.2.2 MNCC_SETUP_IND

Receipt of a SETUP or EMERGENCY SETUP message, the Mobile originating call establishment has been initiated.

7.1.2.3 MNCC_SETUP_RSP

Response to send a CONNECT message to indicate call acceptance by the remote user.

7.1.2.4 MNCC_SETUP_CNF

Receipt of a CONNECT message, the Mobile terminated call has been accepted.

7.1.2.5 MNCC_SETUP_COMPL_REQ

Request to send a CONNECT ACKNOWLEDGE message, the Mobile terminated call establishment has been completed.

7.1.2.6 MNCC_SETUP_COMPL_IND

Indication of the receipt of a CONNECT ACKNOWLEDGE message, the Mobile originating call establishment has been completed.

7.1.2.7 MNCC_REJ_REQ

Reject the Mobile originated call establishment if the call cannot be accepted.

7.1.2.8 MNCC_REJ_IND

A Mobile terminated call was rejected by the MS, e.g. because of missing compatibility.

7.1.2.9 MNCC_CALL_CONF_IND

Receipt of a CALL CONFIRMED message, the Mobile terminated call has been confirmed. A bearer capability different from that given in MNCC_SETUP_REQ may be offered to the remote calling user.

7.1.2.10 MNCC_CALL_PROC_REQ

Request to send a CALL PROCEEDING message to indicate to the Mobile originating user that call establishment has been initiated in the Network and no more call establishment information will be accepted.

7.1.2.11 MNCC_PROGRESS_REQ

Request to send a PROGRESS message or to piggy‑back a progress IE in a suitable CC message in order to give the Mobile user information about the call , e.g., that the call is progressing in the PLMN/ISDN environment, or that the call has left the PLMN/ISDN environment, or that in‑band tones/announcement are available.

7.1.2.12 MNCC_ALERT_REQ

Request to send an ALERTING message to indicate to the Mobile originating user that remote called user alerting has been initiated.

7.1.2.13 MNCC_ALERT_IND

Receipt of an ALERTING message from the Mobile terminated user to be sent to the remote calling user to indicate that user alerting has been initiated.

7.1.2.14 MNCC_NOTIFY_REQ

Request to send information pertaining to a call, such as user suspended, to the Mobile originating or the Mobile terminated user.

7.1.2.15 MNCC_NOTIFY_IND

Indication from the Mobile originating or Mobile terminated user of information pertaining to a call, such as remote user suspended.

7.1.2.16 MNCC_DISC_REQ

Request to send a DISCONNECT message to the MS in order to clear the end‑to‑end connection.

7.1.2.17 MNCC_DISC_IND

Receipt of a DISCONNECT message, the MS indicates that the end‑to‑end connection is cleared.

7.1.2.18 MNCC_REL_REQ

Request to send a RELEASE message to inform the MS that the network intends to release the MM connection and the correspondent call reference.

7.1.2.19 MNCC_REL_IND

Receipt of a RELEASE message, the MS intends to release its MM connection and call reference. The Network is requested to release its call reference and MM connection.

7.1.2.20 MNCC_REL_CNF

The RELEASE COMPLETE message has been received, the MM connection in the MS has been released, the Network itself shall release its MM connection and the corresponding call reference.

7.1.2.21 MNCC_FACILITY_REQ

Request to transport a facility IE for call related supplementary service invocations.

7.1.2.22 MNCC_FACILITY_IND

Indication that a facility IE for call related supplementary service invocations has been received.

7.1.2.23 MNCC_START_DTMF_IND

Indicate the receipt of a START DTMF message in order to start a DTMF control operation.

7.1.2.24 MNCC_START_DTMF_RSP

Request to send a START DTMF ACKNOWLEDGE or START DTMF REJECT message in order to acknowledge or reject the start of a DTMF control operation.

7.1.2.25 MNCC_STOP_DTMF_IND

Indicate the receipt of a STOP DTMF message in order to stop a DTMF control operation.

7.1.2.26 MNCC_STOP_DTMF_RSP

Request to send a STOP DTMF ACKNOWLEDGE message in order to acknowledge the completion of a DTMF control operation.

7.1.2.27 MNCC_MODIFY_REQ

Request to start the Mobile terminating in‑call modification.

7.1.2.28 MNCC_MODIFY_IND

Receipt of a MODIFY message, the Mobile originating in‑call modification has been initiated.

7.1.2.29 MNCC_MODIFY_RES

Response to send a MODIFY COMPLETE to indicate to the Mobile user that the mobile originating in‑call modification procedure has been completed.

7.1.2.30 MNCC_MODIFY_CNF

Confirmation that the Mobile terminating in‑call modification has been completed.

7.2 Call independent Supplementary Services Support

7.2.1 Service state diagram

The primitives provided by the call independent Supplementary Services Support entity and the transitions between permitted states are shown in the service graph of figure 7.2 below.

STATES:

IDLE ‑ No SS signalling transaction pending

CONN ‑ SS signalling transaction established

Figure 7.2: Service graph of the call independent Supplementary Services Support entity ‑ Network side

7.2.2 Service primitives

Table 7.2: Primitives and Parameters at MNSS‑SAP ‑ Network side

PRIMITIVES

PARAMETERS
(Info elements of message)

REFERENCE

MNSS_BEGIN_REQ

REGISTER

7.2.2.1

MNSS_BEGIN_IND

REGISTER

7.2.2.2

MNSS_FACILITY_REQ

FACILITY

7.2.2.3

MNSS_FACILITY_IND

FACILITY

7.2.2.4

MNSS_END_REQ

RELEASE COMPLETE

7.2.2.5

MNSS_END_IND

RELEASE COMPLETE

7.2.2.6

7.2.2.1 MNSS_BEGIN_REQ

Request to send a REGISTER message in order to establish a signalling transaction for the provision of call independent supplementary services. The request for a supplementary service invocation may be included.

7.2.2.2 MNSS_BEGIN_IND

Receipt of a REGISTER message, a signalling transaction is established for the provision of call independent supplementary services. The indication of a supplementary service invocation may be included.

7.2.2.3 MNSS_FACILITY_REQ

Request to send a FACILITY message for the provision of a call independent supplementary service facility.

7.2.2.4 MNSS_FACILITY_IND

Receipt of a FACILITY message, a supplementary service facility has been requested.

7.2.2.5 MNSS_END_REQ

Request to send a RELEASE COMPLETE message in order to release the signalling transaction by sending a RELEASE COMPLETE message. The request for transfer of a supplementary service facility may be included.

7.2.2.6 MNSS_END_IND

Indication that the signalling transaction has been released after receipt of a RELEASE COMPLETE message. The indication of a supplementary service facility may be included.

7.3 Short Message Services Support

The service provided by the CM sublayer to support the short message service are defined in GSM 04.11.

7.4 Services provided to SNDCP and SMS entities by GPRS Logical Link Control services

This section is informative, the service primitives are defined in GSM 04.64 [11]. They are included here to provide a complete overview of the radio interface protocol architecture.

On the network side, Logical Link Control services are provided at the QoS1-SAP – QoS4 SAP towards the SNDCP and at the LLSMS-SAP towards SMS

7.4.1 Service state diagram for QoS1-SAP, QoS2-SAP, QoS3-SAP and QoS4-SAP

The service state diagram is identical on the network side is identical to the one shown in figure 6.7 for the mobile side.

7.4.2 Service primitives for QoS1-SAP, QoS2-SAP, QoS3-SAP and QoS4-SAP

PRIMITIVE

PARAMETER
(message, info elements of message, other parameters)

REFERENCE

LL-ESTABLISH-REQ

TLLI, SNDCP requested parameters (XID)

7.4.2.1

LL-ESTABLISH-CNF

TLLI, SNDCP negotiated parameters (XID), N201

7.4.2.2

LL-ESTABLISH-IND

TLLI, SNDCP requested parameters (XID), N201

7.4.2.3

LL-ESTABLISH-RSP

TLLI, SNDCP negotiated parameters (XID)

7.4.2.4

LL-RELEASE-REQ

TLLI

7.4.2.5

LL-RELEASE-CNF

TLLI

7.4.2.6

LL-RELEASE-IND

TLLI

7.4.2.7

LL-XID-REQ

TLLI, SNDCP requested parameters (XID)

7.4.2.8

LL-XID-IND

TLLI, SNDCP requested parameters (XID), N201

7.4.2.9

LL-XID-RSP

TLLI, SNDCP negotiated parameters (XID)

7.4.2.10

LL-XID-CNF

TLLI, SNDCP negotiated parameters (XID), N201

7.4.2.11

LL-DATA-REQ

TLLI, N-PDU, local reference

7.4.2.12

LL-DATASENT-IND

TLLI, local reference, V(S)

7.4.2.13

LL-DATA-CNF

TLLI, local reference

7.4.2.14

LL-DATA-IND

TLLI, N-PDU

7.4.2.15

LL-UNITDATA-REQ

TLLI, N-PDU, protect, cipher

7.4.2.16

LL-UNITDATA-IND

TLLI, N-PDU

7.4.2.17

LL-STATUS-IND

TLLI, cause

7.4.2.18

7.4.2.1 LL-ESTABLISH-REQ

A LLC SABM frame will be sent to establish the LLC ABM mode.

7.4.2.2 LL-ESTABLISH-CNF

A LLC UA frame is received, the LLC ABM mode has been established.

7.4.2.3 LL-ESTABLISH-IND

A LLC SABM frame is received.

7.4.2.4 LL-ESTABLISH-RSP

A LLC UA frame will be sent, the ABM mode is established.

7.4.2.5 LL-RELEASE-REQ

A LLC DISC frame will be sent to change to LLC ADM mode.

7.4.2.6 LL-RELEASE-CNF

The LLC link has been disconnected, LLC is in ADM mode.

7.4.2.7 LL-RELEASE-IND

LLC is in idle mode.

7.4.2.8 LL-XID-REQ

An LLC XID frame will be sent.

7.4.2.9 LL-XID-IND

An LLC XID frame is received.

7.4.2.10 LL-XID-RSP

An LLC XID frame will be sent as a reply to a received XID frame.

7.4.2.11 LL-XID-CNF

An LLC XID frame has been received as a reply to a sent XID frame.

7.4.2.12 LL-DATA-REQ

An LLC I frame will be sent to the peer entity.

7.4.2.13 LL-DATASENT-IND

The sent LLC frame was sent with the V(S) indicated

7.4.2.14 LL-DATA-CNF

Successful reception of an LLC I frame has been acknowledged by the peer entity.

7.4.2.15 LL-DATA-IND

An LLC I frame has been received form the peer entity.

7.4.2.16 LL-UNITDATA-REQ

An LLC UI frame will be sent to the peer entity.

7.4.2.17 LL-UNITDATA-IND

An LLC UI frame has been received from the peer entity.

7.4.2.18 LL-STATUS-IND

Indication used by LLC to transfer LLC failures to the SNDCP sublayer. The failure may also be caused due to errors at the RLC/MAC layer.

7.5 Session Management Services for GPRS

On the network side Session Management Services are provided only at the SNSM-SAP

7.5.1 Session Management Services for SMREG-SAP

Table 7.5.1: Primitives and Parameters at SMREG-SAP – network side

PRIMITIVE

PARAMETER
(message, info elements of message, other parameters)

REFERENCE

SMREG-PDP-ACTIVATE-REQ

PDP type, PDP address, QoS, NSAPI, APN, Data mode

7.5.1.1

SMREG-PDP-ACTIVATE-REJ

cause

7.5.1.2

SMREG-PDP-DEACTIVATE-REQ

NSAPI(s)

7.5.1.3

SMREG-PDP-DEACTIVATE-CNF

NSAPI(s)

7.5.1.4

SMREG-PDP-MODIFY-REQ

QoS(s), NSAPI(s)

7.5.1.5

SMREG PDP-MODIFY-CNF

server address, QoS(s), NSAPI(s)

7.5.1.6

SMREG PDP-MODIFY-REJ

server address, QoS(s), NSAPI(s)

7.5.1.7

7.5.1.1 SMREG-PDP-ACTIVATE-REQ

The network initiates a PDP context activation. SM is requested to send the ACTIVATE PDP CONTEXT REQUEST message to the MS. The PDP context is pending activation. The network expects that the MS continues with a normal MS initiated context activation. Therefore at the SMREG-SAP no confirmation is provided.

7.5.1.2 SMREG-PDP-ACTIVATE-REJ

The network initiated PDP context activation failed. Either the ACTIVATE PDP CONTEXT FAILURE message was received from the MS, or lower layer failure or timer expiry caused abortion of the activation procedure.

7.5.1.3 SMREG-PDP-DEACTIVATE-REQ

The network initiates a PDP context deactivation. SM is requested to send a DEACTIVATE PDP CONTEXT REQUEST message. The PDP context is pending deactivation.

7.5.1.4 SMREG-PDP-DEACTIVATE-CNF

The network initiated PDP context activation has been concluded. The MS confirmed he PDP context activation, i.e. the DEACTIVATE PDP CONTEXT ACCEPT message was received. Then SM ordered SNDCP to locally release those LLC links not further needed by other PDP contexts. The PDP context is deactivated.

7.5.1.5 SMREG-PDP-MODIFY-REQ

The network initiates a modification of the PDP context. SM is requested to send a MODIFY PDP CONTEXT REQUEST message to the MS. The PDP context is pending modification.

7.5.1.6 SMREG-PDP-MODIFY-CNF

The PDP context modification has been concluded. The MS confirmed he PDP context modification, i.e. the MODIFY PDP CONTEXT ACCEPT message was received. Then SM ordered SNDCP to adjust LLC links as required. The PDP context is modified.

7.5.1.7 SMREG-PDP-MODIFY-REJ

The PDP context modification has been failed. Due to timer expiry or lower layer failure the modification procedure has been aborted.

7.5.2 Session Management Services for SNSM-SAP

Table 7.5.2: Primitives and Parameters at SNSM-SAP – network side

PRIMITIVE

PARAMETER
(message, info elements of message, other parameters)

REFERENCE

SNSM-ACTIVATE-IND

TLLI, NSAPI, QoS, SAPI

7.5.2.1

SNSMM-ACTIVATE-RSP

TLLI,

7.5.2.2

SNSM-DEACTIVATE-IND

TLLI, NSAPI

7.5.2.3

SNSM-DEACTIVATE-RSP

TLLI

7.5.2.4

SNSM-MODIFY-IND

TLLI, NSAPI, QoS, SAPI

7.5.2.5

SNSM-MODIFY-RSP

TLLI

7.5.2.6

SNSM-STATUS-REQ

TLLI, NSAPI, Cause

7.5.2.7

SNSM-WINDOW-IND

TLLI, NSAPI + MS’s V(R)s

7.5.2.8

7.5.2.1 SNSM-ACTIVATE-IND

Indication used by the SM entity to inform the SNDCP entity that an NSAPI has been activated for data transfer. It also informs the SNDCP entity about the negotiated QoS profile and the SAPI assigned for this NSAPI. The request is sent by SM towards SNDCP during an ongoing PDP context activation procedure.

7.5.2.2 SNSM-ACTIVATE-RSP

Response used by the SNDCP entity to inform the SM entity that the indicated NSAPI is now in use and that the acknowledged peer-to-peer LLC operation for the indicated SAPI is established, if necessary.

7.5.2.3 SNSM-DEACTIVATE-IND

Indication used by the SM entity to inform the SNDCP entity that an NSAPI has been de-allocated and cannot be used by the SNDCP entity anymore. The request is sent by SM towards SNDCP during an ongoing PDP context activation procedure, or by SM in the old SGSN during an ongoing inter-SGSN routeing area update procedure.

7.5.2.4 SNSM-DEACTIVATE-RSP

Response used by the SNDCP entity to inform the SM entity that the NSAPI indicated is no longer in use and that the acknowledged peer-to-peer LLC operation for the associated SAPI is released, if necessary.

7.5.2.5 SNSM-MODIFY-IND

Indication used by the SM entity to trigger change of the QoS for an NSAPI and indication of the SAPI to be used. It is also used by the SM entity to inform the SNDCP entity that an NSAPI shall be created, together with the (re-)negotiated QoS profile and the SAPI assigned. The former is used during an ongoing PDP context modification procedure. The latter is used in the new SGSN during an ongoing inter-SGSN routeing area update procedure.

7.5.2.6 SNSM-MODIFY-RSP

Response used by the SNDCP entity to inform the SM entity that the indicated NSAPI and QoS profile are now in use and the acknowledged peer-to-peer LLC operations for the appropriate SAPIs are established and/or released, if necessary.

7.5.2.7 SNSM-STATUS-REQ

This primitive is used by the SNDCP entity to inform the SM entity that SNDCP cannot continue its operation due to errors at the LLC layer (as indicated with LL-Release.indication) or at the SNDCP layer. The Cause parameter indicates the cause of the error.

7.5.2.8 SNSM-WINDOW-IND

This primitive is used in case of inter SGSN routing area updating. The LLC frames confirmed by the MS are indicated to the SNDCP sublayer. The SNDCP sublayer will retransmit an N-PDU again if the MS has not confirmed all LLC PDUs that belong to the possibly segmented N-PDU.

TCP/IP header and V.42bis data compression algorithms shall be reset before N-PDU transmission is resumed.

7.6 Location services at the Network side

The location services (initiation of location measurements at the network) are provided at the service access point MNLCS-SAP. The service provided by the CM sublayer to support the location services is defined in GSM 04.71

7.6.1 Service state diagram

The primitives provided by the call independent Location Services Support entity and the transitions between permitted states are shown in the service graph of figure 7.6 below.

STATES:

IDLE ‑ No LCS signalling transaction pending

CONN ‑ LCS signalling transaction established

Figure 7.6: Service graph of the Location Services Support entity ‑ Network side

7.6.2 Service primitives

Table 7.6: Primitives and Parameters at MNLCS‑SAP ‑ Network side

PRIMITIVES

PARAMETERS
(Info elements of message)

REFERENCE

MNLCS_BEGIN_REQ

REGISTER

7.6.2.1

MNLCS_BEGIN_IND

REGISTER

7.6.2.2

MNLCS_FACILITY_REQ

FACILITY

7.6.2.3

MNLCS_FACILITY_IND

FACILITY

7.6.2.4

MNLCS_END_REQ

RELEASE COMPLETE

7.6.2.5

MNLCS_END_IND

RELEASE COMPLETE

7.6.2.6

7.6.2.1 MNLCS_BEGIN_REQ

Request to send a REGISTER message in order to establish a signalling transaction for the provision of location services. The request for a location service invocation may be included.

7.6.2.2 MNLCS_BEGIN_IND

Receipt of a REGISTER message, a signalling transaction is established for the provision of location services. The indication of a location service invocation may be included.

7.6.2.3 MNLCS_FACILITY_REQ

Request to send a FACILITY message for the provision of a location service facility.

7.6.2.4 MNLCS_FACILITY_IND

Receipt of a FACILITY message, a location service facility has been requested.

7.6.2.5 MNLCS_END_REQ

Request to send a RELEASE COMPLETE message in order to release the signalling transaction by sending a RELEASE COMPLETE message. The request for transfer of a location service facility may be included.

7.6.2.6 MNLCS_END_IND

Indication that the signalling transaction has been released after receipt of a RELEASE COMPLETE message. The indication of a location service facility may be included.