6 Services provided by signalling layer 3 at the MS side
24.0073GPPGeneral AspectsMobile radio interface signalling layer 3Release 17TS
The different classes of services provided by signalling layer 3 at the MS side are accessible at the following service access points:
– registration services at the MMREG-SAP or GMMREG-SAP;
– Call Control services for normal and emergency calls including call related Supplementary Services Support services at the MNCC-SAP;
– Short Message Services Support services at the MNSMS-SAP;
– Call independent Supplementary Services Support services at the MNSS-SAP;
– Location Services Support services at the MNLCS-SAP;
– other services corresponding to further functional blocks of the CM sublayer at the appropriate service access points. These services are not further described in this clause;
– Session Management services at the SMREG-SAP and at the SNSM-SAP;
– Logical Link Control services at the QoS1-SAP, QoS2-SAP, QoS3-SAP and QoS4-SAP.
6.1 Registration services
The registration services (location updating, IMSI attach/detach) are provided at the service access point MMREG‑SAP. As opposed to all other MN‑Services, these services are provided by and can be directly accessed at the Mobility Management sublayer.
6.1.1 Service state diagram for MS not supporting GPRS service
The registration services provided at the service access point MMREG‑SAP are illustrated in the state of figure 6.1 below.
Figure 6.1: Registration services provided at MMREG‑SAP ‑ MS side
6.1.2 Service primitives
Table 6.1: Primitives and Parameters at the MMREG‑SAP ‑ MS side
|
PRIMITIVE |
PARAMETER |
REFERENCE |
|
MMR_REG_REQ |
IMSI |
6.1.2.1 |
|
MMR_REG_CNF |
‑ |
6.1.2.2 |
|
MMR_NREG_REQ |
‑ |
6.1.2.4 |
|
MMR_NREG_IND |
cause |
6.1.2.5 |
6.1.2.1 MMR_REG_REQ
Registration request, triggered by activation of the IMSI, e.g., by activation of the MS with inserted SIM, insertion of the SIM into the activated MS, pressing of a reset button.
6.1.2.2 MMR_REG_CNF
Registration confirmation. Indicates to the user that the MS is ready to start a transaction.
6.1.2.3 Void
6.1.2.4 MMR_NREG_REQ
Request to cancel the registration, stimulated either by removing the SIM or automatically in the power off phase.
6.1.2.5 MMR_NREG_IND
Indication that registration has been cancelled or that registration was not possible. Only emergency services are available to the user.
6.1.3 Registration Services for CTS-Services
The registration services (attach/detach, enrolment/de-enrolment) are provided for CTS services at the service access point MMREG‑SAP.
Table 6.1.3: Primitives and Parameters at the MMREG‑SAP ‑ MS side for CTS
|
PRIMITIVE |
PARAMETER |
REFERENCE |
|
MMR_CTS_ATTACH_REQ |
IMSI |
6.1.3.1 |
|
MMR_CTS_ATTACH_CNF |
‑ |
6.1.3.2 |
|
MMR_CTS_ATTACH_REJ |
IFPSI, cause |
6.1.3.3 |
|
MMR_CTS_DETACH_IND |
‑ |
6.1.3.4 |
|
MMR_CTS_ENROLL_REQ |
IMSI |
6.1.3.5 |
|
MMR_CTS_ENROLL_CNF |
‑ |
6.1.3.6 |
|
MMR_CTS_ENROLL_REJ |
IFPSI, cause |
6.1.3.7 |
|
MMR_CTS_ DE_ENROLL_IND |
‑ |
6.1.3.8 |
6.1.3.1 MMR_CTS _ATTACH_REQ
MS initiates the CTS attach. CTS‑MM is requested to send a CTS ATTACH REQUEST message to the fixed part.
6.1.3.2 MMR_CTS _ATTACH_CNF
The CTS attach was successful. The fixed part confirmed the attach, i.e. the CTS ATTACH ACCEPT message was received by the MS.
6.1.3.3 MMR_CTS _ATTACH_REJ
The CTS attach has failed. The fixed part rejected the attach attempt, i.e. the CTS ATTACH REJECT message was received by the MS.
6.1.3.4 MMR_CTS _DETACH_IND
MS initiates CTS detach. CTS‑MM is requested to send a CTS DETACH INDICATION message. The detach procedure is initiated.
6.1.3.5 MMR_CTS _ENROLL_REQ
MS initiates the CTS enrolment. CTS‑MM is requested to send a CTS ENROLMENT REQUEST message to the fixed part.
6.1.3.6 MMR_CTS _ENROLL_CNF
The CTS enrolment was successful. The fixed part confirmed the enrolment, i.e. the CTS ENROLMENT ACCEPT message was received by the MS.
6.1.3.7 MMR_CTS _ENROLL_REJ
The CTS enrolment has failed. The fixed part rejected the enrolment attempt, i.e. the CTS ENROLMENT REJECT message was received by the MS.
6.1.3.8 MMR_CTS _DE_ENROLL_IND
FP initiates CTS de-enrolment. CTS‑MM is requested to send a CTS DE-ENROLMENT INDICATION message. The de-enrolment procedure is initiated.
6.2 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:
– Mobile originated and Mobile terminated call establishment for normal calls;
– Mobile originated call establishment for emergency calls;
– call maintaining;
– call termination;
– call related Supplementary Services Support.
6.2.1 Service state diagram
The Call Control services provided at the service access point MNCC‑SAP are illustrated in the state diagram of figure 6.2.
Figure 6.2: Service graph of Call Control entity ‑ MS side (page 1 of 2)
Figure 6.2: Service graph of Call Control entity ‑ MS side Active state (page 2 of 2)
6.2.2 Service primitives
Table 6.2: Primitives and parameters at MNCC‑SAP ‑ MS side
|
PRIMITIVE |
PARAMETER |
REFERENCE |
|
MNCC_SETUP_REQ |
SETUP or EMERGENCY SETUP |
6.2.2.1 |
|
MNCC_SETUP_IND |
SETUP |
6.2.2.2 |
|
MNCC_SETUP_RSP |
CONNECT |
6.2.2.3 |
|
MNCC_SETUP_CNF |
CONNECT |
6.2.2.4 |
|
MNCC_SETUP_COMPLETE_REQ |
‑ |
6.2.2.5 |
|
MNCC_SETUP_COMPLETE_IND |
‑ |
6.2.2.6 |
|
MNCC_REJ_REQ |
RELEASE COMPLETE |
6.2.2.7 |
|
MNCC_REJ_IND |
cause |
6.2.2.8 |
|
MNCC_CALL_CONF_REQ |
CALL CONFIRMED |
6.2.2.9 |
|
MNCC_CALL PROC_IND |
CALL PROCEEDING |
6.2.2.10 |
|
MNCC_PROGRESS_IND |
PROGRESS |
6.2.2.11 |
|
MNCC_ALERT_REQ |
ALERTING |
6.2.2.12 |
|
MNCC_ALERT_IND |
ALERTING |
6.2.2.13 |
|
MNCC_NOTIFY_REQ |
NOTIFY |
6.2.2.14 |
|
MNCC_NOTIFY_IND |
NOTIFY |
6.2.2.15 |
|
MNCC_DISC_REQ |
DISCONNECT |
6.2.2.16 |
|
MNCC_DISC_IND |
DISCONNECT |
6.2.2.17 |
|
MNCC_REL_REQ |
RELEASE |
6.2.2.18 |
|
MNCC_REL_IND |
RELEASE |
6.2.2.19 |
|
MNCC_REL_CNF |
RELEASE or RELEASE COMPLETE |
6.2.2.20 |
|
MNCC_FACILITY_REQ |
facility |
6.2.2.21 |
|
MNCC_FACILITY_IND |
facility |
6.2.2.22 |
|
MNCC_START_DTMF_REQ |
START DTMF |
6.2.2.23 |
|
MNCC_START_DTMF_CNF |
START DTMF ACK or START DTMF REJ |
6.2.2.24 |
|
MNCC_STOP_DTMF_REQ |
STOP DTMF |
6.2.2.25 |
|
MNCC_STOP_DTMF_CNF |
STOP DTMF ACK |
6.2.2.26 |
|
MNCC_MODIFY_REQ |
MODIFY |
6.2.2.27 |
|
MNCC_MODIFY_IND |
MODIFY |
6.2.2.28 |
|
MNCC_MODIFY_RES |
MODIFY COMPLETE |
6.2.2.29 |
|
MNCC_MODIFY_CNF |
MODIFY COMPLETE |
6.2.2.30 |
|
MNCC_SYNC_IND |
cause (res. ass., channel mode modify) |
6.2.2.31 |
6.2.2.1 MNCC_SETUP_REQ
Request to send a SETUP or EMERGENCY SETUP message to initiate Mobile originating establishment of either a normal or an emergency call.
6.2.2.2 MNCC_SETUP_IND
Receipt of a SETUP message, the Mobile terminated call establishment has been initiated.
6.2.2.3 MNCC_SETUP_RES
Response to send a CONNECT message to indicate call acceptance by the Mobile terminated user; call control is requested to attach the user connection (if it is not yet attached).
6.2.2.4 MNCC_SETUP_CNF
Receipt of a CONNECT message, the Mobile originated call has been accepted by the remote called user.
6.2.2.5 MNCC_SETUP_COMPL_REQ
Request to send a CONNECT ACKNOWLEDGE message, the mobile originating call has been accepted.
6.2.2.6 MNCC_SETUP_COMPL_IND
Receipt of a CONNECT ACKNOWLEDGE message, the Mobile terminated call establishment has been completed; for a data call, the user is informed that the user connection is attached.
6.2.2.7 MNCC_REJ_REQ
Request to reject a Mobile terminated call if the call is refused or if the call cannot be accepted, e.g., because of missing compatibility.
6.2.2.8 MNCC_REJ_IND
Indication that the Mobile originated call has been rejected, e.g. if the MM connection cannot be provided or if the call establishment initiation has been rejected by the network.
6.2.2.9 MNCC_CALL_CONF_REQ
Request to confirm a Mobile terminated call by sending a CALL CONFIRMED message. A bearer capability different from that given in MNCC_SETUP_IND may be offered to the remote calling user.
6.2.2.10 MNCC_CALL_PROC_IND
Indication to the Mobile originating user that call establishment has been initiated in the Network and no more call establishment information will be accepted by the Network.
6.2.2.11 MNCC_PROGRESS_IND
Indication to the Mobile user that a PROGRESS message or a message containing a progress IE has been received, e.g., because the call is progressing in the PLMN/ISDN environment, or because the call has left the PLMN/ISDN environment, or because in‑band tones/announcement are available.
6.2.2.12 MNCC_ALERT_REQ
Request to send an ALERTING message from the called Mobile user to the remote calling user to indicate that user alerting has been initiated.
6.2.2.13 MNCC_ALERT_IND
Indication of the receipt of an ALERTING message, alerting to the remote called user has been initiated.
6.2.2.14 MNCC_NOTIFY_REQ
Request to send information pertaining to a call, such as user suspended, to the Network by the Mobile user.
6.2.2.15 MNCC_NOTIFY_IND
Indication to the Mobile user that information pertaining to a call, such as remote user suspended, has been received from the Network.
6.2.2.16 MNCC_DISC_REQ
Request to send a DISCONNECT message to the Network in order to clear the end‑to‑end connection.
6.2.2.17 MNCC_DISC_IND
Indication of reception of a DISCONNECT message, by which the Network indicates that the end‑to‑end connection is cleared.
6.2.2.18 MNCC_REL_REQ
Request of the Mobile user to send a RELEASE message to inform the Network that the user intends to release the call reference and the corresponding MM connection so that the Network can release its MM connection and the correspondent call reference.
6.2.2.19 MNCC_REL_IND
Indication to the Mobile originating or terminated user that a RELEASE message has been received and the Network intends to release its MM connection. The Mobile user is requested to release the call reference and the corresponding MM connection.
6.2.2.20 MNCC_REL_CNF
Confirmation of the Mobile user’s request to release the MM connection and call reference in the Network. The Mobile user may release the call reference and the corresponding MM connection.
6.2.2.21 MNCC_FACILITY_REQ
Request to transport a facility IE for a call related supplementary service invocation.
6.2.2.22 MNCC_FACILITY_IND
Indication that a facility IE for a call related supplementary service invocation has been received.
6.2.2.23 MNCC_START_DTMF_REQ
Request to send a START DTMF message in order to start a DTMF control operation.
6.2.2.24 MNCC_START_DTMF_CNF
Confirmation of the receipt of a START DTMF ACKNOWLEDGE or START DTMF REJECT message that the start of a DTMF control operation has been acknowledged or rejected.
6.2.2.25 MNCC_STOP_DTMF_REQ
Request to send a STOP DTMF message in order to stop a DTMF control operation.
6.2.2.26 MNCC_STOP_DTMF_CNF
Confirmation of the receipt of STOP DTMF ACKNOWLEDGE message, the DTMF control operation has been stopped.
6.2.2.27 MNCC_MODIFY_REQ
Request to start Mobile originating in‑call modification by sending a MODIFY message.
6.2.2.28 MNCC_MODIFY_IND
RECEIPT OF A MODIFY message, a Mobile terminating in‑call modification has been initiated.
6.2.2.29 MNCC_MODIFY_RES
Response to send a MODIFY COMPLETE message to indicate Mobile terminating in‑call modification completion by the Mobile user.
6.2.2.30 MNCC_MODIFY_CNF
Receipt of a MODIFY COMPLETE message, the Mobile originating in‑call modification has been completed.
6.2.2.31 MNCC_SYNC_IND
Indication that a dedicated channel assignment has been performed (res. ass. = "resource assigned") and/or the channel mode has been changed.
6.3 Call independent Supplementary Services Support
6.3.1 Service state diagram
The primitives provided by the call independent Supplementary Services Support entity and the transitions between permitted states are shown in figure 6.3.
STATES:
IDLE ‑ No SS signalling transaction pending.
CONN ‑ SS signalling transaction established.
Figure 6.3: Service graph of the call independent Supplementary Services Support entity ‑ MS side
6.3.2 Service primitives
Table 6.3: Primitives and Parameters at MNSS‑SAP ‑ MS side
|
PRIMITIVES |
PARAMETERS |
REFERENCE |
|
MNSS_BEGIN_REQ |
REGISTER |
6.3.2.1 |
|
MNSS_BEGIN_IND |
REGISTER |
6.3.2.2 |
|
MNSS_FACILITY_REQ |
FACILITY |
6.3.2.3 |
|
MNSS_FACILITY_IND |
FACILITY |
6.3.2.4 |
|
MNSS_END_REQ |
REL COMPLETE |
6.3.2.5 |
|
MNSS_END_IND |
REL COMPLETE |
6.3.2.6 |
6.3.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 call independent supplementary service invocation may be included.
6.3.2.2 MNSS_BEGIN_IND
Receipt of a REGISTER message, a signalling transaction is established for the provision of call independent supplementary services after receipt of a REGISTER message. The indication of a supplementary service invocation may be included.
6.3.2.3 MNSS_FACILITY_REQ
Request to send a FACILITY message for the provision of a call independent supplementary service invocation.
6.3.2.4 MNSS_FACILITY_IND
Receipt of a FACILITY message for a call independent supplementary service invocation.
6.3.2.5 MNSS_END_REQ
Request to send a RELEASE COMPLETE message in order to release the signalling transaction. The request for transfer of a supplementary service facility may be included.
6.3.2.6 MNSS_END_IND
Receipt of a RELEASE COMPLETE message, the signalling transaction has been released. The indication of a supplementary service facility may be included.
6.4 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].
6.5 Session Management Services for GPRS-Services
Session Management services are provided at the SMREG-SAP and the SNSM-SAP. The procedures for GPRS Session Management (i.e. PDP context activation, PDP context deactivation and PDP context modification) and MBMS Session Management (i.e. MBMS context activation and MBMS context deactivation) are available at the SMREG-SAP.
Before any user data transfer is initiated (eg.via SNDCP in GSM case), the PDP context activation procedure must be performed. In case of MBMS, the MS must also perform the procedures needed in order to activate a multicast service.
6.5.1 Session Management Services for SMREG-SAP
Table 6.5.1: Primitives and Parameters at SMREG-SAP – MS side
|
PRIMITIVE |
PARAMETER |
REFERENCE |
|
SMREG-PDP-ACTIVATE-REQ |
PDP address, QoS, NSAPI, APN, Protocol configuration options |
6.5.1.1 |
|
SMREG-PDP-ACTIVATE-CNF |
PDP address, QoS, NSAPI, Protocol configuration options |
6.5.1.2 |
|
SMREG-PDP-ACTIVATE-REJ |
Cause, NSAPI, Protocol configuration options |
6.5.1.3 |
|
SMREG-PDP-ACTIVATE-IND |
PDP address, APN, protocol configuration options |
6.5.1.4 |
|
SMREG-PDP-ACTIVATE-REJ-RSP |
Cause, PDP address, APN, protocol configuration options, MBMS protocol configuration options |
6.5.1.14 |
|
SMREG-PDP-DEACTIVATE-REQ |
NSAPI(s) tear down indicator, cause, protocol configuration options, MBMS protocol configuration options |
6.5.1.5 |
|
SMREG-PDP-DEACTIVATE-CNF |
NSAPI(s), protocol configuration options, MBMS protocol configuration options |
6.5.1.6 |
|
SMREG-PDP-DEACTIVATE-IND |
NSAPI(s) (s), tear down indicator, cause, protocol configuration options, MBMS protocol configuration options |
6.5.1.7 |
|
SMREG-PDP-MODIFY-IND |
QoS, NSAPI, protocol configuration options |
6.5.1.8 |
|
SMREG-PDP-MODIFY-REQ |
QoS, NSAPI, TFT, protocol configuration options |
6.5.1.18 |
|
SMREG-PDP-MODIFY-CNF |
QoS, NSAPI, protocol configuration options |
6.5.1.19 |
|
SMREG-PDP-MODIFY-REJ |
Cause, NSAPI, protocol configuration options |
6.5.1.20 |
|
SMREG-PDP-ACTIVATE-SEC-REQ |
QoS, NSAPI, TFT, Primary NSAPI, protocol configuration options |
6.5.1.15 |
|
SMREG-PDP-ACTIVATE-SEC-CNF |
QoS, NSAPI, protocol configuration options |
6.5.1.16 |
|
SMREG-PDP-ACTIVATE-SEC-REJ |
Cause, NSAPI, protocol configuration options |
6.5.1.17 |
|
SMREG-MBMS-ACTIVATE-REQ |
Multicast address, supported MBMS bearer capabilities, NSAPI, APN, MBMS protocol configuration options |
6.5.1.21 |
|
SMREG-MBMS-ACTIVATE-CNF |
Multicast address, NSAPI, MBMS protocol configuration options |
6.5.1.22 |
|
SMREG-MBMS-ACTIVATE-REJ |
Cause, NSAPI, MBMS protocol configuration options |
6.5.1.23 |
|
SMREG-MBMS-ACTIVATE-IND |
Multicast address, APN, MBMS protocol configuration options |
6.5.1.24 |
6.5.1.1 SMREG-PDP-ACTIVATE-REQ
The MS initiates a primary PDP context activation. SM is requested to send the ACTIVATE PDP CONTEXT REQUEST message to the network. The PDP context is pending activation.
6.5.1.2 SMREG-PDP-ACTIVATE-CNF
The MS initiated primary PDP context activation succeeded. The network confirmed the PDP context activation, i.e. the ACTIVATE PDP CONTEXT ACCEPT message was received from the network. In GSM, this implies that SM has ordered SNDCP to establish the needed LLC link. In the UMTS case, this implies that the RLC link towards the RNC has been established and that the SM has been informed about this from the RABM service entity in the MS. (RABM- RAB Management service entity is FFS and could lead to update of the protocol architecture in figure 5.2 and 5.3) The PDP context is active.
6.5.1.3 SMREG-PDP-ACTIVATE-REJ
The PDP primary context activation failed, the PDP context is not activated. One reason for failure is that the network rejected the activation attempt, which means the ACTIVATE PDP CONTEXT REJECT message was received. Another reason is e.g. that it was not possible to establish the needed LLC link in the GSM case.
6.5.1.4 SMREG-PDP-ACTIVATE-IND
The network asked for a PDP context activation. The REQUEST PDP CONTEXT ACTIVATION message was received from the network. The MS reacts either by initiating a new primary PDP context activation or by rejecting the network’s request.
6.5.1.5 SMREG-PDP-DEACTIVATE-REQ
The MS initiates a PDP context deactivation: SM is requested to send a DEACTIVATE PDP CONTEXT REQUEST message to the network. 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.
6.5.1.6 SMREG-PDP-DEACTIVATE-CNF
The MS initiated PDP context deactivation has been done. The network confirmed the PDP context deactivation, i.e. the DEACTIVATE PDP CONTEXT ACCEPT message was received from the network. For GSM SM has ordered SNDCP to locally release not further needed LLC links. In the UMTS case, the release of the RLC link towards the RNC takes place as a result of a RAB release trigger from the network side. SM has been informed about this from the RABM service entity in the MS. (RABM- RAB Management service entity is FFS and could lead to update of the protocol architecture in figure 5.2 and 5.3.) The PDP context has been deactivated.
6.5.1.7 SMREG-PDP-DEACTIVATE-IND
A network initiated PDP context deactivation has been performed. The DEACTIVATE PDP CONTEXT REQUEST message has been received from the network. The MS has acknowledged with the DEACTIVATE PDP CONTEXT ACCEPT message. The PDP context has been deactivated, the related LLC links in GSM or RLC links in UMTS were locally released. Presence of the teardown indicator will lead to deactivation of all PDP contexts coupled to the identified PDP address. NSAPI is included in the primitive to allow identification of the PDP context(s) needing deactivation.
6.5.1.8 SMREG-PDP-MODIFY-IND
A network initiated PDP context modification has been performed. The MODIFY PDP CONTEXT REQUEST message has been received from the network. The modification has been acknowledged by sending the MODIFY PDP CONTEXT ACCEPT message. One PDP context has been modified. LLC links is adjusted.
6.5.1.9 Void
6.5.1.10 Void
6.5.1.11 Void
6.5.1.12 Void
6.5.1.13 Void
6.5.1.14 SMREG-PDP-ACTIVATE-REJ-RSP
The network requested PDP context activation failed.
6.5.1.15 SMREG-PDP-ACTIVATE-SEC-REQ
The MS initiates a secondary PDP context activation. SM is requested to send the ACTIVATE SECONDARY PDP CONTEXT REQUEST message to the network. The PDP context is pending activation.
6.5.1.16 SMREG-PDP-ACTIVATE-SEC-CNF
The MS initiated secondary PDP context activation succeeded. The network confirmed the PDP context activation, i.e. the ACTIVATE SECONDARY PDP CONTEXT ACCEPT message was received from the network. In GSM, this implies that SM has ordered SNDCP to establish the needed LLC link. In the UMTS case, this implies that the RLC link towards the RNC has been established and that the SM has been informed about this from the RABM service entity in the MS. (RABM- RAB Management service entity is FFS and could lead to update of the protocol architecture in figure 5.2 and 5.3) The PDP context connected to the same PDP address as the PDP context identified by the primary NSAPI parameter in SMREG-PDP-ACTIVATE-SEC-REQ is active. (‘Primary NSAPI’ will point to any one of the other established PDP contexts for a given PDP address).
6.5.1.17 SMREG-PDP-ACTIVATE-SEC-REJ
The secondary PDP context activation failed, the PDP context is not activated. One reason for failure is that the network rejected the activation attempt, which means the ACTIVATE SECONDARY PDP CONTEXT REJECT message was received. Another reason is e.g. that it was not possible to establish the needed LLC link in the GSM case.
6.5.1.18 SMREG-PDP-MODIFY-REQ
An MS initiated PDP context modification is requested. The MODIFY PDP CONTEXT REQUEST message is sent to the network and pending acceptance. Affected PDP context is identified via the NSAPI value included in the primitive.
6.5.1.19 SMREG-PDP-MODIFY-CNF
An MS initiated PDP context modification has been accepted by the network. The modification is acknowledged from the network via the MODIFY PDP CONTEXT ACCEPT message. The addressed PDP context has been modified. LLC or RLC link is adjusted according to the QoS returned from the network.
6.5.1.20 SMREG-PDP-MODIFY-REJ
An MS initiated PDP context modification has been rejected by the network. The rejection is signalled from the network via the MODIFY PDP CONTEXT REJECT message with the cause code. The PDP context remains active without change of QoS.
6.5.1.21 SMREG-MBMS-ACTIVATE-REQ
The MS initiates an MBMS context activation as requested by the network. SM is requested to send the ACTIVATE MBMS CONTEXT REQUEST message to the network. The MBMS context is pending activation waiting for the network confirmation.
6.5.1.22 SMREG-MBMS-ACTIVATE-CNF
The MBMS context activation succeeded. The network confirmed the MBMS context activation, i.e. the ACTIVATE MBMS CONTEXT ACCEPT message was received from the network. The MBMS context is active.
6.5.1.23 SMREG-MBMS-ACTIVATE-REJ
The MBMS context activation failed, the MBMS context is not activated.
6.5.1.24 SMREG-MBMS-ACTIVATE-REJ-RSP
The network requested MBMS context activation failed. SM is requested to send the REQUEST MBMS CONTEXT ACTIVATION REJECT message to the network.
6.5.1.25 SMREG-MBMS-ACTIVATE-IND
The network asked for an MBMS context activation. The REQUEST MBMS CONTEXT ACTIVATION message was received from the network. The MS reacts either by initiating the activation of the MBMS context or by rejecting the request from the network.
The Session Management services provided at the service access point SMREG-SAP are illustrated in the state machines of figures 6.4 and 6.5 below. Note, that each state machine describes only one PDP/MBMS context within the SM entity.
Figure 6.4: Session Management service states at the SMREG-SAP for GPRS PDP context handling ‑ MS side
Figure 6.5: Session Management service states at the SMREG-SAP for MBMS context handling ‑ MS side
6.5.2 Session Management Services for SNSM-SAP (GSM only)
The SNSM-SAP service primitives are defined in 3GPP TS 44.065 [12a].
6.5.3 Session Management Services for RABMSM-SAP (UMTS only)
Table 6.5.3: Service primitives and parameters at RABMSM-SAP – MS side
|
PRIMITIVE |
PARAMETER |
Reference |
|
RABMSM-ACTIVATE-IND |
NSAPI, QoS |
6.5.3.1 |
|
RABMSM-ACTIVATE-RSP |
NSAPI |
6.5.3.2 |
|
RABMSM-DEACTIVATE-IND |
NSAPIs |
6.5.3.3 |
|
RABMSM-DEACTIVATE-RSP |
NSAPIs |
6.5.3.4 |
|
RABMSM-DEACTIVATE-REQ |
NSAPI |
6.5.3.5 |
|
RABMSM-MODIFY-IND |
NSAPI, QoS |
6.5.3.6 |
|
RABMSM-MODIFY-RSP |
– |
6.5.3.7 |
|
RABMSM-STATUS-REQ |
– Cause |
6.5.3.8 |
6.5.3.1 RABMSM-ACTIVATE-IND
Indication used by the SM entity to inform the RABM entity that an NSAPI has been activated for data transfer (e.g. an activate PDP Context request has been sent to the network). It also informs the RABM entity about the requested QoS profile for this NSAPI. The indication is sent by SM towards RABM during an ongoing PDP context activation procedure.
6.5.3.2 RABMSM-ACTIVATE-RSP
Response used by the RABM entity to inform the SM entity that the indicated NSAPI is now in use and that a RAB for the indicated NSAPI is established.
6.5.3.3 RABMSM-DEACTIVATE-IND
Indication used by the SM entity to inform the RABM entity that an NSAPIs has been de-allocated and cannot be used by the RABM entity anymore. The request is sent by SM towards RABM during an ongoing MS initiated as well as network initiated PDP context de-activation procedure or during local de-activation of a PDP context.
6.5.3.4 RABMSM-DEACTIVATE-RSP
This message is the response to RABMSM-DEACTIVATE-IND used by the RABM entity to inform the SM entity that the NSAPI indicated is no longer in use. It is either sent immediately when there is no corresponding bearer active or it is sent after reception and processing of RABMAS-RAB-RELEASE-IND from access stratum.
6.5.3.5 RABMSM-DEACTIVATE-REQ
This primitive is used by the RABM entity to inform the SM entity that the RAB for an NSAPI has been released. This primitive is only sent for bearer with a RT-QoS classes.
6.5.3.6 RABMSM-MODIFY-IND
Indication used by the SM entity to indicate the change of the QoS for an NSAPI. The indication is sent by SM towards RABM during an ongoing PDP context modification procedure.
6.5.3.7 RABMSM-MODIFY-RSP
Response used by the RABM entity to inform the SM entity that the indicated NSAPI and QoS profile are now in use and the RAB for the NSAPI is established and/or released, if necessary.
6.5.3.8 RABMSM-STATUS-REQ
This primitive is used by the RABM entity to inform the SM entity that RABM cannot continue its operation due to errors at the lower layer (i.e. Access Stratum) or at the RABM layer. The Cause parameter indicates the cause of the error.
6.6 Registration Services for GPRS-Services
The attach/detach procedures comprise the registration services which are provided at the GMMREG-SAP.
It shall be noted, that the registration services for mobiles of class A or B may depend on the service states for GPRS and non-GPRS services. Therefore the internal access points MMCOORD and the GMMCOORD (see figure 5.3) are used by GMM and MM to inform each other about the relevant conditions. No service primitives between the entities within the same sublayer, i.e. the MM sublayer, are defined in the present document. The Mobility Management for class A and B mobiles is further specified in 3GPP TS 24.008 [6].
6.6.1 Registration Services for GMMREG-SAP
Table 6.6.1: Service primitives and parameters at GMMREG-SAP – MS side
|
PRIMITIVE |
PARAMETER |
REFERENCE |
|
GMMREG-ATTACH-REQ |
attach-type, READY-timer, STANDBY-timer |
6.6.1.1 |
|
GMMREG-ATTACH-CNF |
PLMNs MT-caps, attach-type. |
6.6.1.2 |
|
GMMREG-ATTACH-REJ |
cause |
6.6.1.3 |
|
GMMREG-DETACH-REQ |
detach-type, power-off/normal-detach |
6.6.1.4 |
|
GMMREG-DETACH-CNF |
detach-type |
6.6.1.5 |
|
GMMREG-DETACH-IND |
detach-type |
6.6.1.6 |
6.6.1.1 GMMREG-ATTACH-REQ
MS initiates the GPRS and/or IMSI attach. GMM is requested to send an ATTACH REQUEST message to the network. The attachment is registration pending in the MS.
6.6.1.2 GMMREG-ATTACH-CNF
The attach (either GPRS-attach or IMSI-attach or both) was successful. The network confirmed the attach, i.e. the ATTACH ACCEPT message was received by the MS. The LLC and RR sublayer will be informed by GMM about the TLLI to be used.
6.6.1.3 GMMREG-ATTACH-REJ
The attach (either GPRS-attach or IMSI-attach or both) has failed. The network rejected the attach attempt, i.e. the message ATTACH REJECT was received from the network.
6.6.1.4 GMMREG-DETACH-REQ
MS initiates GPRS and/or IMSI detach: GMM is requested to send a DETACH REQUEST message, the detach procedure is initiated. In case of MS initiated detach at power-off, the procedure is terminated in the MS after sending the DETACH REQUEST message.
6.6.1.5 GMMREG-DETACH-CNF
The MS initiated detach (either GPRS-attach or IMSI-attach or both) has been completed.
The network confirmed the detach, i.e. the message DETACH ACCEPT was received from the network. This finalizes the detach procedure (normal, not at power off). Any PDP context possibly activated before is deactivated.
6.6.1.6 GMMREG-DETACH-IND
A network initiated detach has been performed. Or the detach has been performed locally due to expiration of the standby timer or a failed routing area update. In the first case the DETACH REQUEST message was from the network. Any PDP context possibly activated before is deactivated.
The registration services provided at the service access point GMMREG-SAP are illustrated in the state machine of figure 6.6 below. Note, that in state registered the MS may be suspended from GPRS mobility management due to an ongoing CS connection. The registration procedure Routing Area Updating, which is not provided at the GMMREG-SAP, is not visible within the diagram.
Figure 6.6: Registration services states at GMMREG-SAP for GPRS attach and detach – MS side
6.7 Services provided to SNDCP 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.
Logical Link Control services are provided at the QoS1-SAP – QoS4 SAP towards the SNDCP and at the LLSMS-SAP towards SMS.
6.7.1 Service state diagram for QoS1-SAP, QoS2-SAP, QoS3-SAP and QoS4-SAP
Figure 6.7: States to establish and release ABM mode operation
6.7.2 Service primitives for QoS1-SAP, QoS2-SAP, QoS3-SAP and QoS4-SAP
Table 6.7.2: Service primitives and parameters at QoS1 to QoS4 – MS side
|
PRIMITIVE |
PARAMETER |
REFERENCE |
|
LL-ESTABLISH-REQ |
TLLI, SNDCP requested parameters (XID) |
6.7.2.1 |
|
LL-ESTABLISH-CNF |
TLLI, SNDCP negotiated parameters (XID) |
6.7.2.2 |
|
LL-ESTABLISH-IND |
TLLI, SNDCP requested parameters (XID), N201 |
6.7.2.3 |
|
LL-ESTABLISH-RSP |
TLLI, SNDCP negotiated parameters (XID) |
6.7.2.4 |
|
LL-RELEASE-REQ |
TLLI |
6.7.2.5 |
|
LL-RELEASE-CFN |
TLLI |
6.7.2.6 |
|
LL-RELEASE-IND |
TLLI |
6.7.2.7 |
|
LL-XID-REQ |
TLLI, SNDCP requested parameters (XID) |
6.7.2.8 |
|
LL-XID-IND |
TLLI, SNDCP requested parameters (XID), N201 |
6.7.2.9 |
|
LL-XID-RSP |
TLLI, SNDCP negotiated parameters (XID) |
6.7.2.10 |
|
LL-XID-CNF |
TLLI, SNDCP negotiated parameters (XID), N201 |
6.7.2.11 |
|
LL-DATA-REQ |
TLLI, N-PDU, local reference |
6.7.2.12 |
|
LL-DATA-CNF |
TLLI, local reference |
6.7.2.13 |
|
LL-DATA-IND |
TLLI, N-PDU |
6.7.2.14 |
|
LL-UNITDATA-REQ |
TLLI, N-PDU, protect, cipher |
6.7.2.15 |
|
LL-UNITDATA-IND |
TLLI, N-PDU |
6.7.2.16 |
|
LL-STATUS-IND |
TLLI, cause |
6.7.2.17 |
6.7.2.1 LL-ESTABLISH-REQ
A LLC SABM frame will be sent to establish the LLC ABM mode.
6.7.2.2 LL-ESTABLISH-CNF
A LLC UA frame is received, the LLC ABM mode has been established.
6.7.2.3 LL-ESTABLISH-IND
A LLC SABM frame is received.
6.7.2.4 LL-ESTABLISH-RSP
A LLC UA frame will be sent, the ABM mode is established.
6.7.2.5 LL-RELEASE-REQ
A LLC DISC frame will be sent to change to LLC ADM mode.
6.7.2.6 LL-RELEASE-CNF
The LLC link has been disconnected, LLC is in ADM mode.
6.7.2.7 LL-RELEASE-IND
LLC is in idle mode.
6.7.2.8 LL-XID-REQ
An LLC XID frame will be sent.
6.7.2.9 LL-XID-IND
An LLC XID frame has been received.
6.7.2.10 LL-XID-RSP
An LLC XID frame will be sent as a response to a received XID frame.
6.7.2.11 LL-XID-CNF
An LLC XID frame has been received as a response to a sent XID frame.
6.7.2.12 LL-DATA-REQ
An LLC I frame will be sent to the peer entity.
6.7.2.13 LL-DATA-CNF
Successful reception of an LLC I frame has been acknowledged by the peer entity.
6.7.2.14 LL-DATA-IND
An LLC I frame has been received from the peer entity.
6.7.2.15 LL-UNITDATA-REQ
An LLC UI frame will be sent to the peer entity.
6.7.2.16 LL-UNITDATA-IND
An LLC UI frame has been received from the peer entity.
6.7.2.17 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.
6.8 Location services at the type A LMU side
The location services (e.g. transfer of timing related measurement information by 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].
6.8.1 Service state diagram
The positioning services provided at the service access point MNLCS‑SAP are illustrated in the state diagram of figure 6.8.
STATES:
IDLE ‑ No LCS signalling transaction pending.
CONN ‑ LCS signalling transaction established.
Figure 6.8: Service graph of the Location Services Support entity ‑ type A LMU side
6.8.2 Service primitives
Table 6.8: Primitives and Parameters at MNLCS‑SAP ‑ type A LMU side
|
PRIMITIVES |
PARAMETERS |
REFERENCE |
|
MNLCS_BEGIN_REQ |
REGISTER |
6.8.2.1 |
|
MNLCS_BEGIN_IND |
REGISTER |
6.8.2.2 |
|
MNLCS_FACILITY_REQ |
FACILITY |
6.8.2.3 |
|
MNLCS_FACILITY_IND |
FACILITY |
6.8.2.4 |
|
MNLCS_END_REQ |
RELEASE COMPLETE |
6.8.2.5 |
|
MNLCS_END_IND |
RELEASE COMPLETE |
6.8.2.6 |
6.8.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 transfer of a location service facility may be included.
6.8.2.2 MNLCS_BEGIN_IND
Receipt of a REGISTER message, a signalling transaction is established for the provision of location services after receipt of a REGISTER message. The indication of a location service facility may be included.
6.8.2.3 MNLCS_FACILITY_REQ
Request to send a FACILITY message for the provision of a location service invocation. The request for transfer of a location service facility may be included.
6.8.2.4 MNLCS_FACILITY_IND
Receipt of a FACILITY message, a location service facility has been requested.
6.8.2.5 MNLCS_END_REQ
Request to send a RELEASE COMPLETE message in order to release the signalling transaction. The request for transfer of a location service facility may be included.
6.8.2.6 MNLCS_END_IND
Receipt of a RELEASE COMPLETE message, the signalling transaction has been released. The indication of a location service facility may be included.