7 Services provided by signalling layer 3 on the Network side
24.0073GPPGeneral AspectsMobile radio interface signalling layer 3Release 17TS
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, LCS, 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 |
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 |
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 3GPP TS 24.011 [8].
7.4 Services provided to SNDCP and SMS entities by GPRS Logical Link Control services
This clause is informative, the service primitives are defined in 3GPP TS 44.064 [11a]. 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 |
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 and MBMS
On the network side Session Management Services are provided at the SNSM-SAP and SMREG-SAP. At the SMREG-SAP, the assumption taken is that the MS initiated primary and secondary PDP context activation, the MS initiated PDP context modification and deactivation, and the MBMS context activation and deactivation are not visible, i.e. the service for these functions on the network side stops in the SM sublayer entity.
7.5.1 Session Management Services for SMREG-SAP
Table 7.5.1: Primitives and Parameters at SMREG-SAP – network side
|
PRIMITIVE |
PARAMETER |
REFERENCE |
|
SMREG-PDP-ACTIVATE-REQ |
PDP address, APN, protocol configuration options |
7.5.1.1 |
|
SMREG-PDP-ACTIVATE-REJ |
Cause, PDP address, APN, protocol configuration options |
7.5.1.2 |
|
SMREG-PDP-DEACTIVATE-REQ |
NSAPI(s), teardown indicator, cause, protocol configuration options, MBMS protocol configuration options |
7.5.1.3 |
|
SMREG-PDP-DEACTIVATE-CNF |
NSAPI(s) , protocol configuration options, MBMS protocol configuration options |
7.5.1.4 |
|
SMREG-PDP-MODIFY-REQ |
QoS, NSAPI, protocol configuration options |
7.5.1.5 |
|
SMREG PDP-MODIFY-CNF |
NSAPI, protocol configuration options |
7.5.1.6 |
|
SMREG PDP-MODIFY-REJ |
NSAPI, protocol configuration options |
7.5.1.7 |
|
SMREG-MBMS-ACTIVATE-REQ |
Multicast address, APN, MBMS protocol configuration options |
7.5.1.8 |
|
SMREG-MBMS-ACTIVATE-REJ |
Cause, multicast address, APN, MBMS protocol configuration options |
7.5.1.9 |
7.5.1.1 SMREG-PDP-ACTIVATE-REQ
The network initiates a PDP context activation. SM is requested to send the REQUEST PDP CONTEXT ACTIVATION message to the MS. The PDP context is pending activation. The network expects that the MS continues with a normal MS initiated PDP 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 REQUEST PDP CONTEXT ACTIVATION REJECT message was received from the MS, or lower layer failure or timer expiry caused abortion of the PDP context activation procedure.
7.5.1.3 SMREG-PDP-DEACTIVATE-REQ
The network initiates a PDP or MBMS context deactivation. SM is requested to send a DEACTIVATE PDP CONTEXT REQUEST message. The PDP context is pending deactivation. Presence of the teardown indicator will lead to deactivation of all PDP contexts coupled to the identified PDP address. NSAPI(s) to be deallocated from the SNDCP entity via the SNSM-SAP for the GSM case, are included in the primitive.
7.5.1.4 SMREG-PDP-DEACTIVATE-CNF
The network initiated PDP or MBMS context deactivation has been concluded. The MS confirmed the PDP context deactivation, i.e. the DEACTIVATE PDP CONTEXT ACCEPT message was received. Then SM ordered SNDCP to locally release LLC link(s) not further needed for the GSM case. In the UMTS case, release of affected GTP-U tunnel(s) towards the RNC has taken place. 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 the PDP context modification, i.e. the MODIFY PDP CONTEXT ACCEPT message was received. Then, for the GSM case, SM ordered SNDCP to adjust the affected LLC link as required. For the UMTS case, RAB properties were updated as required. The PDP context is modified.
7.5.1.7 SMREG-PDP-MODIFY-REJ
The PDP context modification has been rejected. Due to timer expiry or lower layer failure the modification procedure has been aborted.
7.5.1.8 SMREG-MBMS-ACTIVATE-REQ
The network initiates an MBMS context activation. SM is requested to send the REQUEST MBMS CONTEXT ACTIVATION message to the MS. The MBMS context is pending activation. The network expects that the MS continues with the MBMS context activation. Therefore, at the SMREG-SAP no confirmation is provided.
7.5.1.9 SMREG-MBMS-ACTIVATE-REJ
The network initiated MBMS context activation failed. Either the REQUEST MBMS CONTEXT REJECT message was received from the MS, or lower layer failure or timer expiry caused abortion of the MBMS context activation procedure.
7.5.2 Session Management Services for SNSM-SAP
The SNSM-SAP service primitives are defined in 3GPP TS 44.065 [12a].
7.6 Location services at the Network side
The location services (e.g. network initiation of timing related measurements in a type A LMU) are provided at the service access point MNLCS-SAP. The service provided by the CM sublayer to support the location services is defined in 3GPP TS 44.071 [8a] (for communication with a type A LMU only).
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 |
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.