9 Interlayer service interfaces on the MS side
24.0073GPPGeneral AspectsMobile radio interface signalling layer 3Release 17TS
In addition to the services described in this clause, the RR entity and MM entity also provide services to CM entities which do not belong to the functional blocks of CC, SMS, and SS. (For example, the RR entity provides service to Group Call and Broadcast Call entities.) These services are not further described in this clause.
9.1 Services provided by the Radio Resource Management entity
The Radio Resource Management (RR) sublayer provides a service to the Mobility Management entity (MM).
The RR services are used for:
– establishing control channel connections;
– releasing control channel connections;
– control-data transfer.
The Radio Resource Management services are represented by the RR‑service primitives.
Figure 9.1: Services provided at RR‑SAP ‑ MS side
9.1.1 Service state diagram
The primitives provided by the Radio Resource Management entity and the transition between permitted states are shown in figure 9.2.
Figure 9.2: Service graph of the Radio Resource Management ‑ MS side
9.1.2 Service primitives
Table 9.1: Primitives and parameters at the RR‑SAP ‑ MS side
|
PRIMITIVES |
PARAMETERS |
REFERENCE |
|
RR_EST_REQ |
Layer 3 message transferred in the SABM frame, CN domain identity |
9.1.2.1 |
|
RR_EST_IND |
‑ |
9.1.2.2 |
|
RR_EST_CNF |
‑ |
9.1.2.3 |
|
RR_REL_IND |
cause |
9.1.2.4 |
|
RR_SYNC_IND |
cause (ciphering, res. ass., channel mode modify), list of (RAB ID, NAS Synchronization Indicator, maximum data rate) |
9.1.2.5 |
|
RR_DATA_REQ |
Layer 3 message, local flow identifier CN domain identity |
9.1.2.6 |
|
RR_DATA_IND |
Layer 3 message, CN domain identity |
9.1.2.7 |
|
RR_UNIT DATA_IND |
Layer 3 message |
9.1.2.8 |
|
RR_ABORT_REQ |
cause |
9.1.2.9 |
|
RR_ABORT_IND |
cause |
9.1.2.10 |
|
RR_ACT_REQ |
reselection mode |
9.1.2.11 |
9.1.2.1 RR_EST_REQ
In A/Gb mode it is used by the Mobility Management entity to request establishment of a Mobile originated RR connection.
The request shall be given only in the IDLE state when the MS listens to the CCCH and the previously selected BCCH.
In Iu mode it is used by the Mobility Management entity to request the establishment of a signalling connection to the CN domain type given in the parameter CN domain identity. The request shall be given only if no signalling connection to the specific CN domain type is established.
9.1.2.2 RR_EST_IND
Indicates to the Mobility Management entity the establishment of a Mobile terminated RR connection. By this indication MM is informed that a transparent connection exists and RR is in the dedicated mode.
9.1.2.3 RR_EST_CNF
Is used by RR to indicate the successful completion of a Mobile originated RR connection establishment. RR connection exists and RR is in the dedicated mode.
9.1.2.4 RR_REL_IND
Is used by RR to indicate to the Mobility Management entity the release of a RR connection when RR has received a CHANNEL RELEASE from the Network and has triggered a normal release of the data link layer. It is also used to indicate that a requested RR connection cannot be established. In both cases, RR returns to IDLE mode.
9.1.2.5 RR_SYNC_IND
Is used for synchronizing RR and the Mobility Management entity after the establishment of a Mobile originated or Mobile terminated RR connection. This indication is provided to MM in the following cases:
– ciphering has been started (ciphering);
– integrity protection has been started (integrity) (UMTS only);
– a traffic channel has been assigned (res. ass. = "resource assigned");
– the channel mode has been modified (channel mode modify).
In Iu mode, in case of a resource assignment or channel mode modification, RR indicates to the Mobility Management entity the list of RAB IDs and, optionally,
– the NAS Synchronization Indicators associated with the assigned or modified radio bearers; or
– the maximum data rate (at RLC layer) associated with the assigned or modified radio bearers, if no NAS Synchronization Indicator is available.
9.1.2.5a Void
9.1.2.5b Void
9.1.2.6 RR_DATA_REQ
Is used by the Mobility Management entity to send control data to its peer entity on the Network side via an existing RR connection.
9.1.2.7 RR_DATA_IND
Is used by RR to indicate control‑data, which has been received from its peer entity on the Network side via an existing RR connection.
For UMTS, RR_DATA_IND is also used to indicate whether control-data has been:
– successfully integrity checked;
– unsuccessfully integrity checked;
– received with no integrity protection.
9.1.2.7a Void
9.1.2.8 RR_UNIT_DATA_IND
Is used by RR to provide MM with system info. The system info is received on the current BCCH if RR is in the IDLE state. If a RR connection has been established, the system info is received on the SACCH.
9.1.2.9 RR_ABORT_REQ
Request to abort an existing RR connection or a RR connection in progress. The data link, if already established, shall be released by a normal release procedure (DISC/UA) initiated by the MS. This is the only way the MS can trigger the release of a RR connection in case of exceptional conditions. The RR returns to the IDLE state.
9.1.2.10 RR_ABORT_IND
Indication that the RR connection has been aborted by a lower layer failure and RR has returned to the IDLE state.
9.1.3 Services provided by the Radio Resource Management entity for CTS
Inside the RR sub-layer, the CTS Radio Resource Management (CTS‑RR) sublayer provides services to the CTS Mobility Management (CTS‑MM) entity.
The CTS-RR services are used for:
– alive check.
The CTS Radio Resource Management services are represented by the CTS‑RR‑service primitives.
Table 9.1.3: Primitives and parameters at the RR‑SAP ‑ MS side for CTS
|
PRIMITIVES |
PARAMETERS |
REFERENCE |
|
CTS_RR_ALIVE_CHECK_IND |
‑ |
9.1.3.1 |
9.1.3.1 CTS_RR_ALIVE_CHECK_IND
Indicates to the CTS Mobility Management entity that an alive check request has been received from the fixed part.
9.2 Services provided by the Mobility Management entity
The Mobility Management (MM) sublayer provides services to the Call Control (CC) entity, the Supplementary Services Support (SS) entity, the Location Services (LCS) entity (only for type A LMU) and the Short Message Service Support (SMS) entity.
The Mobility Management services primitives are discriminated by the MMCC, MMSS, MMLCS and MMSMS prefix.
NOTE: The LCS protocol entities for communication between a type A LMU and the network would be included in the figure in the same manner as the protocol entities for CC, SS and SMS.
Figure 9.3: Services provided at the MMCC‑SAP, MMSS‑SAP, MMLCS-SAP, MMSMS‑SAP ‑ MS side
9.2.1 Service state diagram
The primitives provided by the Mobility Management entity towards Call Control, call independent Supplementary Service Support, Location Services Support for type A LMU and towards Short Messages Service Support and the transition between permitted states are illustrated in figure 9.4.
NOTE 1: MMCC‑primitives only at MMCC‑SAP.
NOTE 2: The prefix MMXX is used for substitution of MMCC, MMSS, MMLCS or MMSMS.
Figure 9.4: Service graph of the Mobility Management entity ‑ MS side
9.2.2 Service primitives
Table 9.2: Primitives and Parameters at MMCC‑SAP, MMSS‑SAP (for type A LMU), MMLCS-SAP or MMSMS‑SAP ‑ MS side
|
PRIMITIVES |
PARAMETERS |
REFERENCE |
|
MMXX_EST_REQ (see note 1) |
Parameters for the appropriate CM SERVICE REQUEST (if any) |
9.2.2.1 |
|
MMXX_EST_IND (see note 1) |
First CM message |
9.2.2.2 |
|
MMXX_EST_CNF (see note 1) |
‑ |
9.2.2.3 |
|
MMXX_REL_REQ (see note 1) |
cause |
9.2.2.4 |
|
MMXX_REL_IND (see note 1) |
cause |
9.2.2.5 |
|
MMXX_DATA_REQ (see note 1) |
Layer 3 message |
9.2.2.6 |
|
MMXX_DATA_IND (see note 1) |
Layer 3 message |
9.2.2.7 |
|
MMXX_UNIT_DATA_REQ (see note 1) |
Layer 3 message |
9.2.2.8 |
|
MMXX_UNIT_DATA_IND (see note 1) |
Layer 3 message |
9.2.2.9 |
|
MMCC_SYNC_IND (see note 2) |
cause: res.ass; list of (RAB ID, NAS Synchronization Indicator, maximum data rate) |
9.2.2.10 |
|
MMXX_REEST_REQ (see note 1) |
9.2.2.11 |
|
|
MMXX_REEST_CNF (see note 1) |
9.2.2.12 |
|
|
MMXX_ERR_IND (see note 1) |
cause |
9.2.2.13 |
|
MMXX_PROMPT_IND (see note 1) |
– |
9.2.2.14 |
|
MMXX_PROMPT_REJ (see note 1) |
– |
9.2.2.15 |
|
NOTE 1: MMXX is used as substitution for MMCC, MMSS, MMLCS or MMSMS. NOTE 2: Only at MMCC‑SAP. |
||
9.2.2.1 MMXX_EST_REQ
Request used by CC, SS, LCS (for type A LMU) and SMS respectively, to request establishment of a MM connection. Several MM connections may be provided in parallel to the requesting entities. The primitive may contain parameters which are relevant for the CM SERVICE REQUEST message, e.g. to distinguish a basic call from an emergency call.
9.2.2.2 MMXX_EST_IND
Indication to CC, SS, LCS (for type A LMU) or SMS that a Mobile terminated MM connection has been established and the first message has been received from the respective peer entity. Several MM connections may be provided in parallel. If a MM connection already exists, a new MM connection using the same RR connection is indicated by this primitive if MM detects a message with a new combination of Protocol Discriminator (PD) and Transaction Identifier (TI).
9.2.2.3 MMXX_EST_CNF
Successful confirmation of the MM connection establishment by the MM sublayer to be given to the appropriate entity which has requested the service.
9.2.2.4 MMXX_REL_REQ
Used by CC, SS, LCS (for type A LMU) or SMS respectively, to request release of the MM connection. The corresponding PD/TI will be released and may be used for a new MM connection.
9.2.2.5 MMXX_REL_IND
Indication of the release of an existing MM connection or a MM connection in progress. This primitive is used in exceptional cases to indicate that the MM connection cannot be established or kept any longer and PD/TI have been released.
9.2.2.6 MMXX_DATA_REQ
Request used by the CC, SS or SMS entities for acknowledged control‑data transmission.
9.2.2.7 MMXX_DATA_IND
Indication used by MM to transfer the received acknowledged control‑data to the CC, SS, LCS (for type A LMU) or SMS entities.
9.2.2.8 MMXX_UNIT_DATA_REQ
Request used by the CC, SS, LCS (for type A LMU) or SMS entities for unacknowledged control‑data transmission.
9.2.2.9 MMXX_UNIT_DATA_IND
Indication used by MM to transfer the received unacknowledged control‑data to the CC, SS, LCS or SMS entities.
9.2.2.10 MMCC_SYNC_IND
Indication that a dedicated channel assignment has been performed and/or the channel mode has been changed (only towards the CC entity).
In Iu mode, MM indicates the list of the RAB IDs and, optionally,
– the NAS Synchronization Indicators associated with the assigned or modified radio bearers; or
– the maximum data rate (at RLC layer) associated with the assigned or modified radio bearers, if no NAS Synchronization Indicator is available.
During a network-initiated in-call modification the CC entity uses the NAS Synchronization Indicator or the maximum data rate to determine whether a suitable channel for the new call mode is available.
9.2.2.11 MMXX_REEST_REQ
Request to establish a MM connection which has been interrupted by a lower layer failure. The interruption must have been indicated by MMXX_ERR_IND.
9.2.2.12 MMXX_REEST_CNF
Confirmation of the successful re‑establishment of the MM connection. The MM connection will continue with PD/TI as it had before.
9.2.2.13 MMXX_ERR_IND
Indication of a lower layer failure interrupting the MM connection. The PD/TI are still kept by MM. In case of parallel transactions this indication is passed to all CM entities for which a MM connection has been established. It is left to the decision of the appropriate CM entity to either request the re‑establishment of the MM connection by MMXX_REEST_REQ or to release it by MMXX_REL_REQ.
9.2.2.14 MMXX_PROMPT_IND
Indication given by MM to inform of the completion of the MM connection to the CC, SS, LCS (for type A LMU) or SMS entities for a mobile station which supports "Network Initiated MO CM Connection Request".
9.2.2.15 MMXX_PROMPT_REJ
Response to the MMXX_PROMPT_IND indication to the MM entity in a mobile station which supports "Network Initiated MO CM Connection Request" in case when it is impossible to establish the prompted CM connection e.g. due to lack of free transaction identifiers.
9.3 Services provided by radio resource management entity for GPRS services
The service primitives for UMTS are defined in the present document. The services provided by the Access Stratum (AS) are specified in 3GPP TS 23.110 [20].
9.3.1 Service primitives for GRR-SAP (GSM only)
The GRR-SAP service primitives are defined in 3GPP TS 44.064 [11a]
[[Table 9.3.1, and chapters 9.3.1.1 – 9.3.1.5 are Void]
9.3.2 Service primitives for GMMRR-SAP (GSM only)
Table 9.3.2: Primitives and Parameters at GMMRR-SAP – MS side
|
PRIMITIVE |
PARAMETER |
REFERENCE |
|
GMMRR-ASSIGN-REQ |
newTLLI |
9.3.2.1 |
|
GMMRR-PAGE-IND |
TLLI |
9.3.2.2 |
9.3.2.1 GMMRR-ASSIGN-REQ
A new TLLI is assigned to the RR sublayer.
9.3.2.2 GMMRR-PAGE-IND
A RR-paging message has been received by the RR sublayer.
9.3.3 Service primitives for RABMAS-SAP (UMTS only)
Table 9.3.3: Primitives and parameters at RABMAS-SAP
|
PRIMITIVE |
PARAMETER |
REFERENCE |
|
RABMAS-RAB-ESTABLISH-IND |
RAB ID list |
9.3.3.1 |
|
RABMAS-RAB-ESTABLISH-RES |
– |
9.3.3.2 |
|
RABMAS-RAB-ESTABLISH-REJ |
9.3.3.3 |
|
|
RABMAS-RAB-RELEASE-IND |
RAB ID list |
9.3.3.4 |
|
RABMAS-RAB-RELEASE-RES |
– |
9.3.3.5 |
|
RABMAS-STATUS-IND |
Cause |
9.3.3.6 |
9.3.3.1 RABMAS-RAB-ESTABLISH-IND
Indication from the Access Stratum layer that radio access bearer setup for the indicated list of RAB IDs (contains NSAPI) has commenced.
9.3.3.2 RABMAS-RAB-ESTABLISH-RES
Response (to RABMAS-RAB-ESTABLISH-IND) used by the RABM entity to inform the Access Stratum sublayer that the indicated NSAPI (in RAB ID) is currently or has been activated by the SM.
9.3.3.3 RABMAS-RAB-ESTABLISH-REJ
Response (to RABMAS-RAB-ESTABLISH-IND) used by the RABM entity to inform the Access Stratum sublayer that all of the NSAPIs, indicated by RAB ID list in the received RABMAS-RAB-ESTABLISH-IND, have not been activated by the SM-layer and the attempt to setup the radio access bearers shall be rejected.
9.3.3.4 RABMAS-RAB-RELEASE-IND
Indication from the Access Stratum layer that a radio access bearer for the indicated NSAPI has been released.
9.3.3.5 RABMAS-RAB-RELEASE-RES
Response used by the RABM entity to inform the Access Stratum sublayer that the indicated RAB ID has been released in the RABM.
9.3.3.6 RABMAS-STATUS-IND
Indication used by the AS sublayer to transfer failures to the RABM.
9.3.4 Service primitives for GMMAS-SAP (UMTS only)
Table 9.3.4: Service primitives and parameters at GMMAS-SAP – MS side
|
PRIMITIVE |
PARAMETER |
REFERENCE |
|
GMMAS-SECURITY-IND |
9.3.4.1 |
|
|
GMMAS-SECURITY-RES |
CK, IK |
9.3.4.2 |
|
GMMAS- ESTABLISH-REQ |
Layer 3-PDU, Establishment cause, Priority, CN Domain Identity, MS Identity, LAI/RAI |
9.3.4.3 |
|
GMMAS- ESTABLISH-CNF |
9.3.4.4 |
|
|
GMMAS- ESTABLISH-REJ |
9.3.4.5 |
|
|
GMMAS- RELEASE-REQ |
CN Domain identity |
9.3.4.6 |
|
GMMAS- RELEASE-IND |
Cause |
9.3.4.7 |
|
GMMAS- DATA-REQ |
Layer 3-PDU, Priority, CN Domain identity |
9.3.4.8 |
|
GMMAS- DATA-IND |
Layer 3-PDU |
9.3.4.9 |
|
GMMAS-PAGE-IND |
MS Identity type, Paging Cause |
9.3.4.10 |
|
GMMAS-STATUS-IND |
Cause |
9.3.4.11 |
9.3.4.1 GMMAS-SECURITY-IND
Indication from the AS sublayer that ciphering (and integrity protection) shall be started. The GMM sublayer uses this primitive as an indication of the completion of the service request procedure.
9.3.4.2 GMMAS-SECURITY-RES
Ciphering and integrity keys are assigned to the AS sublayer to enable ciphering (and integrity protection).
9.3.4.3 GMMAS-ESTABLISH-REQ
To establish a signalling connection and to carry the initial Layer 3-PDU over the radio interface.
9.3.4.4 GMMAS-ESTABLISH-CNF
Confirmation from the AS sublayer that a PS signalling connection has been established.
9.3.4.5 GMMAS-ESTABLISH-REJ
The attempt to establish a PS signalling connection was rejected by the network.
9.3.4.6 GMMAS- RELEASE-REQ
Request used by the MM-sublayer to request the release of the PS signalling connection.
9.3.4.7 GMMAS- RELEASE-IND
Indication from the AS sublayer that the PS signalling connection has been released.
9.3.4.8 GMMAS- DATA-REQ
Request used by the MM-sublayer for transfer of data.
9.3.4.9 GMMAS- DATA-IND
Indication used by the AS sublayer to transfer received data to MM sublayer.
9.3.4.10 GMMAS-PAGE-IND
A paging message has been received by the AS sublayer.
9.3.4.11 GMMAS-STATUS-IND
Indication used by the AS sublayer to transfer failures to the MM sublayer.
9.4 Services provided by the LLC entity for GPRS services (GSM only)
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.
9.4.1 Service primitives for LLGMM-SAP
Table 9.4.1: Primitives and parameters at LLGMM-SAP – MS side
|
PRIMITIVE |
PARAMETER |
REFERENCE |
|
LLGMM-ASSIGN-REQ |
oldTLLI, newTLLI, Kc, RAND, Ciphering Algorithm |
9.4.1.1 |
|
LLGMM-TRIGGER-REQ |
Cause |
9.4.1.2 |
|
LLGMM-SUSPEND-REQ |
TLLI |
9.4.1.4 |
|
LLGMM-RESUME-REQ |
TLLI |
9.4.1.5 |
|
LL-UNITDATA-REQ |
TLLI, GMM-PDU, protect, cipher |
9.4.1.8 |
|
LL-UNITDATA-IND |
TLLI, GMM-PDU, cipher |
9.4.1.9 |
|
LLGMM-STATUS-IND |
TLLI, cause |
9.4.1.10 |
9.4.1.1 LLGMM-ASSIGN-REQ
A new TLLI and/or a ciphering key and/or a ciphering algorithm is assigned to the LLC sublayer.
9.4.1.2 LLGMM-TRIGGER-REQ
Request to send an LLC PDU to the network. Cause indicates if the primitive is sent to trigger an implicit page response.
9.4.1.3 Void
9.4.1.4 LLGMM-SUSPEND-REQ
All LLC links in ABM mode will cease sending PDUs. GMM messages can still be sent and received.
9.4.1.5 Void
9.4.1.6 Void
9.4.1.7 LLGMM-WINDOW-CNF
The actual LLC’s V(R)s for each LLC link in ABM mode are transferred to GMM.
9.4.1.8 LL-UNITDATA-REQ
Request to send a GMM message in unacknowledged mode to the peer entity.
9.4.1.9 LL-UNITDATA-IND
A GMM message in unacknowledged mode has been received from the peer entity.
9.4.1.10 LLGMM-STATUS-IND
Indication used by LLC to transfer LLC failures to the GMM sublayer. The failure may also be caused due to errors at the RLC/MAC layer.
9.4.2 Service primitives for LLSMS-SAP
Table 9.4.2: Service primitives and parameters at LLSMS-SAP – MS side
|
PRIMITIVE |
PARAMETER |
REFERENCE |
|
LL-UNITDATA-REQ |
TLLI, SMS-CP-PDU, protect, cipher |
9.4.2.1 |
|
LL-UNITDATA-IND |
TLLI, SMS-CP-PDU, |
9.4.2.2 |
9.4.2.1 LL-UNITDATA-REQ
An LLC UI frame will be sent to the peer entity.
9.4.2.2 LL-UNITDATA-IND
An LLC UI frame has been received from the peer entity.
9.5 Services provided by the GMM for GPRS services
The GPRS Mobility Management (GMM) sublayer provides services to the Session Management (SM) entity, Supplementary Service (SS) entity and the Short Message Service Support (GSMS) entity for message transfer.
9.5.1 Service primitives for GMMSM-SAP
Session Management services may request GPRS service registration or perform procedures needed to activate a multicast service before activating a PDP or an MBMS context.
Table 9.5.1: Primitives and parameters at GMMSM-SAP – MS side
|
PRIMITIVE |
PARAMETER |
REFERENCE |
|
GMMSM-ESTABLISH-REQ |
– |
9.5.1.1 |
|
GMMSM-ESTABLISH-CNF |
– |
9.5.1.2 |
|
GMMSM-ESTABLISH-REJ |
cause |
9.5.1.3 |
|
GMMSM-RELEASE-IND |
– |
9.5.1.4 |
|
GMMSM-UNITDATA-REQ |
SM-PDU |
9.5.1.5 |
|
GMMSM-UNITDATA-IND |
SM-PDU |
9.5.1.6 |
9.5.1.1 GMMSM-ESTABLISH-REQ
Request from Session Management to send an ATTACH REQUEST message to the network to setup a GMM connection. The request is only performed in case the MS is not already attached. The GPRS attach is then indirectly caused by a request from Session Management, e.g. a requested PDP context activation or MBMS context activation.
9.5.1.2 GMMSM-ESTABLISH-CNF
The network has send the ATTACH ACCEPT message to the MS, the indirect attach was successful. Now, Session Management can proceed with the Session Management request, e.g. the PDP context activation or the MBMS context activation..
9.5.1.3 GMMSM-ESTABLISH-REJ
The network has rejected the attach. The MS has received the ATTACH REJECT message.
9.5.1.4 GMMSM-RELEASE-IND
The GPRS Mobility Management informs the Session Management that the MS has been GPRS detached, e.g. by timer expiry, and therefore, the PDP context(s) and the MBMS context(s), if any, are not valid anymore.
9.5.1.5 GMMSM-UNITDATA-REQ
The GMM is requested to forward a SM PDU to LLC in order to send it in unacknowledged more to the peer entity.
9.5.1.6 GMMSM-UNITDATA-IND
The GMM forwards a SM PDU, which has been received in unacknowledged mode via LLC from the peer entity.
9.5.2 Void
9.5.3 Service primitives for GMMSMS-SAP
The Short Message entity may request from the GMM entity the GMM IMSI registration state before an MO SMS transmission is initiated.
Table 9.5.3: Primitives and parameters at GMMSMS-SAP – MS side
|
PRIMITIVE |
PARAMETER |
REFERENCE |
|
GMMSMS-REG-STATE-REQ |
– |
9.5.3.1 |
|
GMMSM- REG-STATE -RSP |
Registration state |
9.5.3.2 |
9.5.3.1 GMMSMS-REG-STATE-REQ
Request for the current IMSI registration state from the Short Message entity.
9.5.3.2 GMMSM- REG-STATE -RSP
The current IMSI registration state is sent to the Short Message entity.
9.5.4 Service primitives for PMMSMS-SAP
Table 9.5.4: Primitives and Parameters at PMMSMS‑SAP ‑ MS side
|
PRIMITIVES |
PARAMETERS (message, info elements of message, other parameters) |
REFERENCE |
|
PMMSMS_EST_REQ |
Mobile-ID |
9.5.4.1 |
|
PMMSMS_EST_CNF |
– |
9.5.4.2 |
|
PMMSMS_ERROR_IND |
Cause |
9.5.4.3 |
|
PMMSMS_UNITDATA_REQ |
SMS-PDU |
9.5.4.4 |
|
PMMSMS_UNITDATA_IND |
SMS-PDU |
9.5.4.5 |
9.5.4.1 PMMSMS_EST _REQ
The GMM is requested to establish a PS signalling conection.
9.5.4.2 PMMSMS_EST _CNF
The GMM indicates a PS signalling connection is established.
9.5.4.3 PMMSMS_ERROR_IND
The GMM indicates that a PS signalling connection has been released.
9.5.4.4 PMMSMS_UNITDATA_REQ
The GMM is requested to forward a SMS PDU in order to send it to the peer entity.
9.5.4.5 PMMSMS_UNITDATA_IND
Indication used by GMM to transfer the received data to the GSMS entities.
9.5.5 Service primitives for GMMRABM-SAP (UMTS only)
Table 9.5.5: Service primitives and parameters at GMMRABM-SAP – MS side
|
PRIMITIVE |
PARAMETER |
REFERENCE |
|
GMMRABM-REESTABLISH-REQ |
9.5.5.1 |
|
|
GMMRABM-REESTABLISH-RSP |
9.5.5.2 |
|
|
GMMRABM-REESTABLISH-REJ |
Cause |
9.5.5.3 |
NOTE: Confirmation to the RABMGMM-REESTABLISH-REQ is given to the RABM in the form of indications from the AS sublayer that establishment of RABs has commenced or been completed.
9.5.5.1 GMMRABM-REESTABLISH-REQ
This primitive is used by the RABM entity to inform the GMM sublayer that UL user data has been received for an NSAPI without an active RAB. GMM shall initiate a service request procedure to re-establish the RAB for the NSAPI(S).
9.5.5.2 GMMRABM-REESTABLISH-RSP
This primitive is used by the GMM sublayer to inform the RABM entity that the reception of the Service Request message has been acknowledged by the network.
9.5.5.3 GMMRABM-REESTABLISH-REJ
This primitive is used by the GMM sublayer to inform the RABM entity that the re-establishment of RABs by the service request procedure has failed.
9.5.6 Service primitives for GMMSS-SAP
Supplementary Services may request GPRS service registration before sending SS PDU.
Table 9.5.6: Primitives and parameters at GMMSS-SAP – MS side
|
PRIMITIVE |
PARAMETER |
REFERENCE |
|
GMMSS-ESTABLISH-REQ |
– |
9.5.6.1 |
|
GMMSS-ESTABLISH-CNF |
– |
9.5.6.2 |
|
GMMSS-ESTABLISH-REJ |
cause |
9.5.6.3 |
|
GMMSS-RELEASE-IND |
– |
9.5.6.4 |
|
GMMSS-UNITDATA-REQ |
SS-PDU |
9.5.6.5 |
|
GMMSS-UNITDATA-IND |
SS-PDU |
9.5.6.6 |
9.5.6.1 GMMSS-ESTABLISH-REQ
Request from Supplementary Services to send an ATTACH REQUEST message to the network to setup a GMM connection. The request is only performed in case the MS is not already attached. The GPRS attach is then indirectly caused by a sending of SS PDU.
9.5.6.2 GMMSS-ESTABLISH-CNF
The network has send the ATTACH ACCEPT message to the MS, the indirect attach was successful. Now Supplementary Services can proceed with sending SS PDU.
9.5.6.3 GMMSS-ESTABLISH-REJ
The network has rejected the attach. The MS has received the ATTACH REJECT message.
9.5.6.4 GMMSS-RELEASE-IND
The GPRS mobility management informs the Supplementary Services that the MS has been GPRS detached, e.g. by timer expiry.
9.5.6.5 GMMSS-UNITDATA-REQ
The GMM is requested to forward a SS PDU to lower layer in order to send it to the peer entity.
9.5.6.6 GMMSS-UNITDATA-IND
The GMM forwards a SS PDU, which has been received from the peer entity.
9.5.7 Service primitives for GMMSS2-SAP
The Supplementary Service entity may request to the MM and/or GMM entity the MM and/or GMM IMSI registration state before an SS PDU transmission is initiated from the mobile station.
Table 9.5.7: Primitives and parameters at GMMSS2-SAP – MS side
|
PRIMITIVE |
PARAMETER |
REFERENCE |
|
GMMSS2-REG-STATE-REQ |
– |
9.5.7.1 |
|
GMMSS2- REG-STATE -RSP |
Registration state |
9.5.7.2 |
9.5.7.1 GMMSS2-REG-STATE-REQ
Request for the current IMSI registration state from the Supplementary Services entity.
9.5.7.2 GMM SS2- REG-STATE -RSP
The current IMSI registration state is sent to the Supplementary Services entity.