GSM规范03.40：3GPP TS SMS短消息服务技术实现

需积分: 9 74 浏览量更新于2024-07-25 收藏 1.09MB PDF 举报

GSM规范0340（3GPP TS ETSI TS V070500）是关于第二阶段加（Phase 2+）移动通信系统的详细技术规格，主要聚焦于短消息服务（SMS）的点对点（Point-to-Point, PP）实现。该标准由欧洲电信标准化协会（ETSI）发布，具体版本为7.5.0，于1998年Release 1998发布，适用于全球系统移动通信（GSM）。文档引用了3GPP Technical Specification (TS) RTS/TSGT-020340Q7R3。 GSM 0340文档的关键点包括： 1. **GSM体系结构**：GSM是早期广泛使用的全球移动通信标准，它定义了数字蜂窝电话系统的架构，强调了语音通话、数据传输以及短信服务的通信协议。 2. **SMS服务实现**：重点在于短信服务的技术实现，这涉及到短信的编码、路由、传输和接收机制，对于当时的移动通信设备制造商和网络运营商来说，这是至关重要的技术指南。 3. **ETSI的角色**：ETSI是一个国际性的标准化组织，其在移动通信标准制定中的角色体现在提供技术规范，确保全球范围内的通信设备和服务能够互操作。 4. **文档来源与获取**：用户可以访问ETSI官方网站http://www.etsi.org下载单份文档，同时提到如有不同版本，以PDF格式的印刷版作为参考，存放在ETSISecretariat的特定网络驱动器上，以解决版本差异争议。 5. **版权与注意事项**：该文档属于非营利性质，应在指定机构的注册下使用，并且声明了版权信息和联系信息，如Sophia Antipolis的地址和联系方式。 GSM spec 0340是移动通信领域的重要参考资料，对于理解早期GSM网络的短信服务技术细节、设备兼容性以及标准化工作流程具有重要意义。它对于通信工程师、网络管理员和设备制造商来说，是进行设计、测试和优化移动通信服务不可或缺的工具。

ETSI

TSI TS 100 901 V7.5.0 (2001

GPP TS 03.40 version 7.5.0 Release 1998

NOTE 2: When a short message delivery attempt fails at the HLR due to Roaming being Restricted, the MS being

deregistered in HLR or the MS being Purged the absent subscriber diagnostic reason is returned to the

SC, however the reason is not stored in the MNRR.

The MWD, MCEF, MNRR, MNRG and MNRF are updated in the following way:

1a) When a mobile terminated short message delivery fails due to the MS being temporarily absent (i.e. either IMSI

DETACH flag is set or there is no response from the MS to a paging request via the MSC), the SC address is

inserted into the MWD list (if it is not already present), the MNRF is set (if it is not already set) and the MNRR

via the MSC is updated (if the information is available), as described in clause 10.

1b) When a mobile terminated short message delivery fails due to the MS being temporarily absent (i.e. either GPRS

DETACH flag is set or there is no response from the MS to a paging request via the SGSN), the SC address is

inserted into the MWD list (if it is not already present), the MNRG is set (if it is not already set) and the MNRR

via the SGSN is updated (if the information is available), as described in clause 10.

1c) When a mobile terminated short message delivery fails due to the MS memory capacity via the MSC being

exceeded, the SC address is inserted into the MWD list (if it is not already present) ,the MCEF is set (if it is not

already set), the MNRF is cleared and the MNRR via the MSC is updated as described in clause 10.

1d) When a mobile terminated short message delivery fails due to the MS memory capacity via the SGSN being

exceeded, the SC address is inserted into the MWD list (if it is not already present), the MCEF is set (if it is not

already set), the MNRG is cleared and the MNRR via the SGSN is updated as described in clause 10.

1e) If the MSIsdn used by the SC to address the recipient MS for alerting purposes is different from the

MSIsdn-Alert of the MS (see subclause 3.2.7), the HLR returns the MSIsdn-Alert to the SC within the failure

report, see "1c Failure report" in figures 03.40/15 and /16.

2a) When either the HLR or VLR detects that the MS (with a non-empty MWD and the MCEF clear in the HLR and

the MNRF set in the VLR) has recovered operation (e.g. has responded to a paging request over MSC), the HLR

directly or on request of the VLR will invoke operations to alert the SCs within the MWD (see subclause 3.2.7

and clause 10). Once the Alert SC operations have been invoked, the MNRF and MNRR via the MSC are

cleared. After each SC is alerted by the HLR, the address for that SC is deleted from the MWD. If the MCEF is

set in the HLR, the HLR clears the MNRF and MNRR via the MSC, but does not invoke operations to alert the

SCs within the MWD and data are not cleared from the MWD.

2b) When either the HLR or SGSN detects that the MS (with a non-empty MWD and the MCEF clear in the HLR

and the MNRG set in the SGSN) has recovered operation (e.g. has responded to a paging request via the SGSN),

the HLR directly or on request of the SGSN will invoke operations to alert the SCs within the MWD (see

subclause 3.2.7 and clause 10). Once the Alert SC operations have been invoked, the MNRG and MNRR via the

SGSN are cleared. After each SC is alerted by the HLR, the address for that SC is deleted from the MWD. If the

MCEF is set in the HLR, the HLR clears the MNRG and MNRR via the SGSN, but does not invoke operations

to alert the SCs within the MWD and data are not cleared from the MWD.

2c) When the HLR receives (via the MSC and the VLR) a notification that the MS (with a non-empty MWD and the

MCEF set in the HLR) has memory capacity available to receive one or more short messages, the HLR will

invoke operations to alert the SCs within the MWD (see subclause 3.2.7 and clause 10). Once the Alert SC

operations have been invoked, the MNRF is cleared in the VLR and the MCEF, MNRF and MNRR via the MSC

are cleared in the HLR. After each SC is alerted by the HLR, the address for that SC is deleted from the MWD.

2d) When the HLR receives (via the SGSN) a notification that the MS (with a non-empty MWD and the MCEF set

in the HLR) has memory capacity available to receive one or more short messages, the HLR will invoke

operations to alert the SCs within the MWD (see subclause 3.2.7 and clause 10). Once the Alert SC operations

have been invoked, the MNRG is cleared in the SGSN and the MCEF, MNRG and MNRR via the SGSN are

cleared in the HLR. After each SC is alerted by the HLR, the address for that SC is deleted from the MWD.

2e) When the HLR receives from the SMS-GMSC a notification that a short message has been successfully

delivered from an SC to an MS via the MSC for which the MCEF is set and the MWD are not empty, the HLR

will invoke operations to alert other SCs within the MWD (see subclause 3.2.7 and clause 10). Once the Alert

SC operations have been invoked, the MCEF, MNRF and MNRR via the MSC are cleared in the HLR. After

each SC is alerted by the HLR, the address for that SC is deleted from the MWD. The SC which successfully

delivered the message is also deleted from the MWD, if present.

ETSI

TSI TS 100 901 V7.5.0 (2001

GPP TS 03.40 version 7.5.0 Release 1998

2f) When the HLR receives from the SMS-GMSC a notification that a short message has been successfully

delivered from an SC to an MS via the SGSN for which the MCEF is set and the MWD are not empty, the HLR

will invoke operations to alert other SCs within the MWD (see subclause 3.2.7 and clause 10). Once the Alert

SC operations have been invoked, the MCEF, MNRG and MNRR via the SGSN are cleared in the HLR. After

each SC is alerted by the HLR, the address for that SC is deleted from the MWD. The SC which successfully

delivered the message is also deleted from the MWD, if present.

2g) When the HLR receives (via the MSC and the VLR, or the SGSN) a notification that the MS has memory

capacity available to receive one or more short messages but the MCEF is not set and the MWD are empty, the

HLR acknowledges the notification but does not alert any service centre.

NOTE 1: The HLR can be in a situation where the MWD list is empty but where either MNRF or MNRG (with the

related MNRR) is still set. This enables the HLR to return the correct address (MSC or SGSN address) at

the next Send Routing Information Request from the SMS-GMSC.

NOTE 2: If the SMS delivery failed on first attempt via the MSC or the SGSN (see cases 1a for IMSI Detach and 1b

for GPRS Detach), and is successful on the second attempt (see cases 2e and 2f), the SC address shall not be

inserted into the MWD list

3.2.7 Alert-SC

The Alert-SC is the service element, which may be provided by some GSM PLMNs, to inform the SC that an MS

1) to which a delivery attempt has failed because the MS is not reachable or because the MS memory capacity was

exceeded;

and

2) which is now recognized by the PLMN:

a) to have resumed operation (e.g. to have responded to a paging request); or

b) to have memory newly available (which implies that the mobile is reachable).

is again ready to receive one or more short messages. The SC may - on reception of an Alert-SC - initiate the delivery

attempt procedure for the queued messages destined for this MS.

To each MS there may be allocated several MSIsdns. When the HLR is to alert an SC that an MS is again attainable it

will use a specific MSIsdn value for this purpose; in the present document called MSIsdn-Alert.

NOTE: Repeated delivery attempts from the SC may be of two types:

i) A repeated delivery attempt because the SC has been informed that the MS is active and available to

receive short messages.

ii) An autonomous repeated delivery attempt by the SC.

The application of these two options is defined by the providers of the SC and the network.

3.2.8 Options concerning MNRG, MNRF, MNRR, MCEF and MWD

Setting the Mobile-Station-Not-Reachable-Flag (MNRF) in the VLR is mandatory. Setting the Mobile-station-Not-

Reachable-for-GPRS (MNRG) in the SGSN is mandatory. It is mandatory for the VLR or the SGSN to send the "MS

Reachable" message (see clause 10) to the HLR when the MS has been detected as becoming active and then to clear

MNRF in the VLR or the MNRG in SGSN.

The Messages-Waiting-Data (MWD), the Mobile-Station-Not-Reachable-Flag (MNRF), the Mobile-station-Not-

Reachable-for-GPRS (MNRG), the Mobile-Station-Not-Reachable-Reason (MNRR) and the

Mobile-Station-Memory-Capacity-Exceeded-Flag (MCEF)) within the HLR are optional, but if one is implemented all

must be implemented (except MNRG if the HLR does not support GPRS). This is linked to the transmission of the

"Alert SC" message.

The following describes what happens when a delivery fails.

ETSI

TSI TS 100 901 V7.5.0 (2001

GPP TS 03.40 version 7.5.0 Release 1998

Case 1: MWD, MNRF, MNRG, MNRR and MCEF are implemented in the HLR

In the case of a delivery failure (to an MS) with cause Absent Subscriber, the SMS-GMSC requests the HLR to

add, if needed, a new entry in the MWD with cause Absent Subscriber. This new entry contains the SC address.

The HLR sets its copy of the MNRF, MNRG or both and updates the MNRR (if the information is available).

The SC is notified of the failure, the reason for the MS being absent and also of the MWD setting in the HLR

within the Report message (see clause 10).

In the case of a delivery failure (to an MS) with cause Mobile Station Memory Capacity Exceeded via the SGSN

or the MSC, the SMS-GMSC requests the HLR to add, if needed, a new entry in the MWD with cause Mobile

Station Memory Capacity Exceeded. This new entry contains the SC address. The HLR sets the MCEF and reset

MNRF or MNRG. The SC is notified of the failure and also of the MWD setting in the HLR within the Report

message (see clause 10).

If the HLR indicates that it is able to store the SC address, then the SC will receive an Alert SC message when

the MS becomes active.

If the HLR indicates that it is unable to store the SC address (e.g. because MWD is full), then the only way to

ensure delivery is for the SC to try to retransmit the message periodically.

When the HLR receives the MS Reachable message, if the MCEF is clear it sends an Alert SC message to the

concerned SC, updates MWD and clears MNRF (if the MS is reachable via the MSC) or MNRG (if the MS is

reachable via the SGSN).

When the HLR receives the MS Memory Capacity Available message, it sends an Alert SC message to the

concerned SC, updates MWD, clears the MCEF and clears MNRF (if the MS is reachable via the MSC) or

MNRG (if the MS is reachable via the SGSN).

Case 2: MWD, MNRF, MNRG, MNRR and MCEF are not implemented in the HLR

In the case of a delivery failure, the SC is notified that the HLR is unable to store its address in the MWD. In

case of a delivery failure (to a MS) with cause Absent Subscriber, the SC is notified of the reason for the MS

being absent (if the information is available). The SC must retransmit the short message periodically in order to

ensure delivery.

The HLR discards the MS Reachable message received from the VLR or SGSN without any failure or error

report.

The HLR discards the MS Memory Capacity Available message received from the MS via the MSC and the

VLR or SGSN without any failure or error report.

3.2.9 Status report capabilities

The SMS also offers to the SC the capabilities of informing the MS of the status of a previously sent mobile originated

short message. The status of the message can be:

- Successfully delivered to the SME;

- The SC was not able to forward the message to the SME. The reason can be an error of permanent or temporary

nature. Permanent errors can be e.g. validity period expired, invalid SME address. Errors of temporary nature

can be e.g. SC-SME connection being down, SME temporarily unavailable.

This is achieved by the SC returning a status report TPDU (SMS-STATUS-REPORT) to the originating MS when the

SC has concluded the status of the short message. The status report may be initiated by a status report request within the

mobile originated short message. The status report TPDU is treated as an SMS-DELIVER TPDU by the SC when it

comes to delivery procedures e.g. the alerting mechanism.

The SC may also return to a non-MS SME the status of a mobile terminated short message. This is however outside the

scope of the present document.

The status report capabilities of the SMS are optional, i.e. the choice of whether to offer status report or not is left to the

SC operator.

For reasons of resilience and/or load sharing architecture of SMSC's by network operators, the SMSC address (the RP-

OA) used by the SMSC to send the Status Report to the MS cannot be guaranteed to be the same SMSC address (RP-

ETSI

TSI TS 100 901 V7.5.0 (2001

GPP TS 03.40 versio

7.5.0 Release 1998

DA) used by the MS to submit the SM to which the Status Report refers. Where an MS wishes to implement a check

that these addresses correlate, a means of disabling the correlation check shall be provided at the MS through MMI.

3.2.10 Reply Path

Reply Path specified in the present document provides a way of both requesting and indicating a service centre's

commitment to deliver a reply from the replying MS to the originating SME.

Annex D deals with MS procedures, which in general are outside the scope of GSM specifications. However, for

advanced use of the SMS, including both application level protocols and human responses, it is of vital importance to

guarantee that a reply-supporting MS is able to reply on every SM, to every SME capable of receiving such reply short

messages.

3.3 Unsuccessful short message TPDU transfer SC -> MS

Unsuccessful message transfer SC -> MS may be caused by a variety of different errors. The description of the

occurrence of the different errors and how to handle and transfer the error indications is given in GSM 04.08,

GSM 04.11 and GSM 09.02.

The different error indications which the SMS-GMSC shall be capable of returning to the SC following an unsuccessful

short message TPDU transfer SC -> MS, are given in table 03.40/1. In some cases, additional diagnostic information

may be provided.

3.3.1 Errors occurring during transfer of TPDU to MS

These errors are generally due to barring or unsupported service in the PLMN or MS. An error indication is returned to

the SC from the SMS-GMSC, but further diagnostic information from the MS will not be available.

3.3.2 Errors occurring after TPDU arrives at MS

These errors may occur due to the MS not supporting optional short message service features, or in connection with a

short message application. An error indication shall be returned to the SC from the SMS-GMSC. Additionally, a TPDU

(SMS-DELIVER-REPORT) containing diagnostic information may be conveyed from the MS to the originating SC,

transparently through the PLMN, by means defined in GSM 04.11 and GSM 09.02. The sending of the diagnostic

information is optional at the MS, but when it is sent, the PLMN shall convey the information to the SC, and the SC

shall support reception of the information.

ETSI

TSI TS 100 901 V7.5.0 (2001

GPP TS 03.40 version 7.5.0 Release 1998

Table 03.40/1: Error indications related to mobile terminated short message transfer which may be

transferred to the originating SC

Error indication

Meaning

Unknown subscriber P The PLMN rejects the short message TPDU because there is not allocated

an IMSI or a directory number for the mobile subscriber in the HLR (see

GSM 09.02).

Teleservice not provisioned P The PLMN rejects the short message TPDU because the recipient MS has

no SMS subscription (see GSM 09.02).

Call barred T The PLMN rejects the short message TPDU due to barring of the MS (see

GSM 09.02, description of the Barring supplementary service, GSM 02.04

and 03.11), description of Call barred due to Unauthorised Message

Originator, GSM 09.02, and description of Operator Determined Barring,

GSM 02.41 and 03.15).

Facility not supported T

he VPLMN rejects the short message TPDU due to no provision of the SMS

in the VPLMN (see GSM 09.02).

Absent subscriber T The PLMN rejects the short message TPDU because

- there was no paging response via the SGSN, MSC or both, (see

GSM 04.08 & GMS 09.02)

- the IMSI GPRS or both records are marked detached (see GSM 09.02),

- the MS is subject to roaming restrictions (see "Roaming not allowed",

GSM 09.02).

- deregistered in the HLR. The HLR does not have an MSC, SGSN or both

numbers stored for the target MS, (see GSM 09.02)

- Unidentified subscriber (see GSM 09.02)

- MS purged, (see GMS 09.02)

(The reasons for absence are assigned integer values in table 03.40/1a. The

appropriate integer value is sent with the absent subscriber error indication

as defined in GSM 09.02)

MS busy for MT SMS T The PLMN rejects the short message TPDU because of congestion

encountered at the visited MSC or the SGSN. Possible reasons include any

of the following events in progress:

- short message delivery from another SC;

- IMSI or GPRS detach

- Location Update or Inter SGSN Routing Area Update;

- paging;

- emergency call;

- call setup.

SMS lower layers

capabilities not provisioned

T The PLMN rejects the short message TPDU due to MS not being able to

support the Short Message Service.

The short message transfer attempt is rejected either due to information

contained in the class-mark, or the MSC not being able to establish

connection at SAPI = 3 (see GSM 04.08 and GSM 09.02).

Error in MS T The PLMN rejects the short message TPDU due to an error occurring within

the MS at reception of a short message, e.g. lack of free memory capacity or

protocol error.

Illegal Subscriber P The PLMN rejects the short message TPDU because the MS failed

authentication

Illegal Equipment P The PLMN rejects the short message TPDU because the IMEI of the MS

was black-listed in the EIR

System failure T The PLMN rejects the short message TPDU due to network or protocol

failure others than those listed above (see GSM 09.02)

Memory Capacity Exceeded T The MS rejects the short message since it has no memory capacity available

to store the message

1) : Status (Permanent or Temporary)

剩余119页未读，继续阅读

lirhett

粉丝: 0
资源: 1

GSM规范03.40：3GPP TS SMS短消息服务技术实现

深入解析GSM11.11-v8.14.0协议规范

GSM 3GPP TS 51.010-1: MS Conformance Specification

MT6225 GSM/GPRS 基带处理器数据手册

GSM SPEC打包下载

GSM spec 0405-802

GSM Basic Spec

GSM规范 spec .pdf

GSM-3GPP-SPEC

GSM11.11-v8.14.0 Spec协议规范

SIM Spec 11.11

最新资源