在上一篇《增值类短信业务图文简介》中，我们介绍了什么是增值类短信业务以及增值类短信的收发流程。在这篇中我们将进一步深入介绍增值类短信收发协议的相关内容，不过重点放在短信内容编码对短信呈现的影响。

从近两年大火的5G我们可以看到，在移动通信领域规范和标准先行。虽然第一条短信在1992年在实验室就被发了出来，但是这离真正的短信商用还有很长一段距离。之后作为GSM(Global System for Mobile Communications，全球移动通信系统)技术的一个组成部分，GSM规范中对短信内容编码格式作了进一步说明：

• SMS消息内容的最大长度为160个字符（GSM字符集中的7比特字符）或140个八位字节，也可以支持其他字符集，例如UCS-2的16位编码的字符，最多支持70个UCS-2字符长度的消息。处理SMS消息的应用程序必须确保争取的字符集映射。

• SMS消息的接收者不必是移动电话。它可以是一个可以通过网关来处理SMS消息的服务器。 SMS消息可用于传输几乎任何类型的数据（虽然有一个非常严格的大小限制），唯一标准化的是其基于字符的数据格式，字符按照一定的字符集格式进行编码。SMS消息的最大长度为160个字符 （当使用7位字符编码时）或140 字节。但是，SMS消息可以连接起来以形成更长的消息。但如何连接在此GSM规范中并未规范化的明确描述。

上面GSM规范中关于短信的约束和限制，显然是考虑了短信收发硬件设备、网络带宽等综合因素，但这一约束一直延续至今。当然在短信后续的发展中，通过对短信内容编码格式的扩展，丰富了短信的内容的展现形式，使短信尽可能的满足各种场景的需要。

一. 按短信内容呈现形式分类

短信内容的呈现形式是通过设置短信协议控制字段、短信内容编码和短信内容共同实现的。我们日常常见的三种短信内容形式如下：

• 普通短信

普通短信是指短信内容在70个中文字符以内（含70个字符，采用UCS-2编码或GB2312编码）或160个英文字符以内（含160个字符，采用7比特字符编码）的短信。由于国内工信部要求发送给手机用户的增值类短信必须有“签名”（比如上面截图中的短信开始处的【美团点评】），因此短信实际承载内容要少于70个中文字符或160个英文字符（7bit编码字符）。因此，一旦SP要发送超过如此规定长度的短信，那么普通短信将无法满足,这就有了下面级联短信的需求。

• 级联短信（俗称长短信）

对于普通手机用户来说，你可能不会注意到级联短信和普通短信的差别，因为到达手机后，这两种短信都以一条短信的形式呈现，只是级联短信内容较长罢了。我们看到手机上呈现的级联短信虽然是一条，但是其长度已经远超出上述GSM对短信内容长度的规定，这样的短信其实是在手机侧合成的。当某个SP要给某手机用户发送长度超出单条普通短信内容承载长度的短息时，会将超长内容拆分为多条有一定关联性的短信下发。这批短信被手机用户的终端接收后，终端会根据其关联关系将这批短信合并为一条短信显示出来。具体的细节在下面介绍短信协议内容时会详细说明。

• WAPPUSH短信

注意这是一条垃圾短信。现在通过wappush短信发送垃圾信息也是一种趋势，运营商正在这方面加强防范和堵漏。

WAPPUSH短信是一类特殊格式的短信，它诞生于2.5G时代，那个时候通过手机浏览互联网尚不十分方便，流量贵，带宽还窄。一些服务为了方便手机用户能快速定位到自己的页面，便将携带服务url的内容通过短信下发给手机用户。手机用户点击链接即可打开服务页面。这类短信还可以在用户阅读WAPPUSH短信时自动加载服务页面，而无需用户手动点击内容中的链接。

彩信通知也是通过这种方式下发到手机用户的。这样手机用户既可以在查看短信时自动在手机上下载并查看彩信，也可以手动点击彩信通知短信中的链接，打开存储彩信内容的服务页面查看彩信内容。

上面是目前可以见到的最常见的三类短信形式，当然还有类似闪信等不太常见的短信呈现形式，这里就不重点描述了。

二. 短信相关规范

在上一篇文章中，我们说过SP是通过各大运营商的专用协议连接到运营商的短信网关进行增值类短信下发的，这里就以中国移动的CMPP协议(China Mobile Peer to Peer)为例（版本3.0)进行举例说明。

CMPP是在TCP之上的基于请求-响应的应用层通信协议，从内容上看，它改编自SMPP规范，但对暴露给SP的字段做了进一步约束；增加了运营商对短信计费相关字段。我们要关注的是CMPP协议的submit包。submit包是SP向短信网关发送的承载短信的协议包，一个submit包可以理解为最终到达手机用户的一条短信（当然submit包也支持群发）。

1. tp_udhi（用户数据头指示器）

这里我们重点关注的是协议字段对短信内容呈现的影响。在CMPP submit包中，字段tp_udhi（用户数据头指示器）、msg_fmt（内容编码格式）、msg_length（内容长度）和msg_content（短信内容）对网关解析短信、手机解析并呈现短信起到了至关重要的作用，因为这几个字段将被后续处理短信的各个网元“透传”直至手机上，并影响着手机对所接受到的短信的解析和呈现。

CMPP规范描述tp_udhi字段时提到了参考GSM03.40 中的 9.2.3.23。在《图解3GPP规范文档组织结构与编号规则》一文中，我们提到过03.40中的03系列文档仅适用于早期GSM系统，如今已经进化到4G、5G时代，我们可以直接参考对应该规范的新版规范23.040，你也可以看到23.040和03.40的Title是一致的，都是”Technical realization of the Short Message Service (SMS)”。

我们直接打开23.040（这里使用的版本是v12.2.0)文档，定位到9.2.3.23小节，我们看到的就是对tp_udhi字段的说明。在3GPP规范中，tp_udhi只是短信协议数据单元（PDU）第一个字节中的一个bit位，它只有两个值：0和1。当我们将cmpp submit包中的tp_udhi设置为1时，3GPP中短信PDU中的tp_udhi bit位将被置为1，也就是表明在短信内容中携带有短信头结构。如果为0，则内容里不包含短信头结构：

判断逻辑：

tp_udhi bit位是否置为 1?

    no ->  普通短信；

    yes -> 内容带有短信头结构的短信（可能是级联短信、可能是wappush短信）

对于普通短信，短信接收侧仅需要根据msg_fmt、msg_length对短信内容进行解析呈现即可。但对于带有短信头结构的短信（tp_udhi bit位置1），还需要进一步分析。

2. 短信内容中的用户短信头结构

用户短信头结构是一组类TLV格式的数据段。注意这里明确是一组，也就是说短信内容头中支持放置多个数据段（如下图中的part1~partN)。

如图所示，cmpp submit的msg_length标识了整个短信内容的长度。如果tp_udhi被置为1，即短信内容中包含短信头结构，那么短信内容的第一个字节是UDHL，即后面短信头的长度。短信头可由多个part组成，每个part都是一个类TLV格式的连续数据：IEI、IEIDL、IED。IEI：信息元素标识符，大小为一个字节，相当于TLV中的T(Type)；IEIDL(信息元素数据长度)指示本part中IED的长度，相当于TLV中的L；IED（信息元素数据）是本part中承载的有价值数据，相当于TLV中的V。

3GPP 23.040定义了一组已知的IEI标准值(9.2.3.24)，我们从中取出几个我们关心的：

• 0×00 – Concatenated short messages, 8-bit reference number

• 0×04 – Application port addressing scheme, 8 bit address

• 0×05 – Application port addressing scheme, 16 bit address

• 0×08 – Concatenated short message, 16-bit reference number

其中0×00和0×08对应的是级联短信；0×04、0×05对应的是WAPPUSH消息，下面我们来逐一详细说明。

3. 级联短信

前面对级联短信做了简单的诠释：SP将超出普通短信长度的短信拆分为多条短信（每条短信称为该批次级联短信的一个segment），这些短信之间存在关联，当手机用户收到这些短信后，手机上的短信接收程序会将它们重新组装为一条长长的短信并呈现给用户。这里提到的“短信间的关联”就是通过附着在短信内容中的短信头结构实现的。

3GPP规范定义了将短信连接在一起形成更长短信的标准方式（参考23.040 9.2.3.24.1和9.2.3.24.8）。根23.040规范中的描述，IEI = 0×00和0×08的part是为级联短信服务的。但二者只能选择一种，不能共存。我们分别来说说：

1) IEI = 0×00即reference number为一个字节的级联短信

上图是一个IEI=0×00的级联短信的例子。当短信为IEI=0×00级联短信的一个segment时，短信内容头部的IEIDL为0×03，IED由三部分组成，每个部分一个字节。它们依次是：

• reference number – 该批次级联短信的唯一标识（0~255），手机端重组短信时，就是使用该字段将一批segment重组在一起的；

• max number – 该批次级联短信共多少条（0~255）

• sequence number – 当前短信segment是该批次级联短信的第几条（从1开始）,该字段用于在重组短信时为短信segment排序。（0~255）

2) IEI = 0×08即reference number为两个字节的级联短信

为了减少两条不同的级联短信因reference number的值空间过小导致ref number一致而冲突的情况，3GPP还增加了一个IEI=0×80的增强级联长短信类别。与8bit的ref number相比，仅仅是ref number的长度变长了,由一个字节变为两个字节（值空间由256个变为65536个）。而其他字段的位置和含义完全不变。这里就不赘述了。不过要注意的是打包或解析ref number时要注意字节序转换。

4. 端口应用类短信

很多朋友会提出：上面图中每条消息的内容组成和网络协议栈怎么很相像呢？都是header + payload！没错！基于短信头结构，我们还可以通过在头结构中放置应用端口号，手机收到短信后，会根据目的应用端口将消息发送给对应的应用或启动对应的应用来处理这条短信，而短信的内容(payload)则是应用所需的数据，这类短信我称之为端口应用类短信。在3GPP 23.040的标准IEI定义表中，IEI=0×04和IEI=0×05就是用于在短信头中携带应用端口信息的，两者不同的是端口号所占字节不同，IEI=0×04对应的port占用1个字节（端口号表示的值空间较小，最大255），而IEI=0×05对应的port占用2个字节（扩展了端口号表示的值空间，最大65535）。我们用一幅图来诠释一下IEI=0×04和IEI=0×05时，短信头结构的样式：

由于IEI=0×04对应的port值空间有限，因此在实际使用中并不广泛。更多的采用短信协议承载应用数据的使用的是IEI=0×05，即应用端口采用16bit表示。

WAPPush短信是端口应用类短信的一种，它属于基于短信递送网络(Bearer Network)实现的WAP协议族中的push类应用。所谓Push类应用是用于向驻留在WAP设备（比如手机）上的应用程序传输数据的。这和我们在上面的理解一致，通过短信向手机上的某些应用传递数据，短信内容（去头后）就是应用所需的数据。IANA list一些标准的服务名和端口，可以在这里查询。

下面我们就以WAPPush类短信为例，看看要传输的应用数据是如何打包在一条短信的内容中的。

1) WAP协议栈与短信的映射

我们即将从3GPP规范转换到WAP相关规范。WAP（Wireless Application Protocol）是一套基于无线协议的应用协议栈。在2G或2.5G时代以及3G初期，它是无线网络应用的主流。下面是WAP的完整协议栈示意图(来自网络)，也可参考规范《Wireless Application Protocol Architecture Specification》:wap-210-waparch-20010712-a.pdf中的协议栈全图Figure-7（不过不是很清晰）：

接下来我们要明确WAP协议栈在wappush短信应用时是如何与短信进行映射的：

在图中我们看到了WAP Push应用与短信的映射关系：

• 底层递送网络使用SMS；

• Transport Layer即WDP对应到短信内容头部的一个IE part，在这部分数据中，我们能找到源port和目的port，这与IP网络协议栈中UDP十分类似（参考：《Wireless Datagram Protocol Specification》WAP-259-WDP-20010614-a.pdf 6.3.1和6.3.2）。

• 安全层和Transaction layer被省略了，暂无对应。

• WSP(Session layer)对应到短信内容头之后的第一段自定义数据段。这段数据的形式由Type字段确定。以Push类(type=0×06)为例，这段数据包含：tid, type,headerslen,contenttype,headers和data。而data就是真正应用层的数据。（参考：《Wireless Session Protocol Specification》 WAP-230-WSP-20010705-a.pdf 8.1.2、8.2.1、8.2.4.1、8.4.1)

• WAE（application layer)对应的就是wsp承载的data字段，以push为例，这里存放的是应用所需的数据。这里的数据究竟是什么，要根据wsp层的ContentType确定。如果是 “application/vnd.wap.mms-message”，那么data中存放的就是mms notification(彩信通知短信）。

2) WSP PDU介绍

这里把WSP PDU单独介绍一下，该PDU的字段涉及的内容还是略微复杂的。下面是一个push类的WSP PDU的构成字段示意图：

• TID – Transaction ID uint8类型，标识该PDU所属transaction；

• Type – 标识PDU的类型，uint8类型。该字段直接决定了该PDU后面的数据组成格式。WAP规范定义了标准的Type值列表，可参考：《Wireless Session Protocol Specification》 附录A 表34 PDU Type Assignments；这里我们用push类型举例，因此该字段为0×06。

接下来的数据字段是Push类型wsp pdu特有的，其他type pdu会有不同，但构成类似。熟悉了push类型的pdu字段的解析方式后，其他type的pdu也不是问题了。

• HeadersLen 这个字段指示了push类pdu的header的长度：包括后面的ContentType和Headers的长度之和。值得注意的是该字段是uintvar类型，这是一种带有continue bit的7 bit编码的类型，其解析算法参见《Wireless Session Protocol Specification》 WAP-230-WSP-20010705-a.pdf 8.1.2。uintvar类型在WSP规范中大量出现，可以实现一个独立的函数来读取一个uintvar或写入一个uintvar，便于重用；

• ContentType 指示后面Data中的内容类型。ContentType是一个多字节的数据。它也是WSP PDU头部解析的一个难点。WSP要求客户机和服务器之间交换的信息都采用紧缩的编码格式，很多常见字段的name使用了well-known value作替代了，这样可以压缩存储空间，提高传输效率。ContentType字段本身就支持多种值格式，包括well-known value，变长字节数据(以uintvar开头的)或纯文本字符串形式。在WAP-230-WSP-20010705-a.pdf的 8.4.2.24小节有关于ContentType字段值格式的定义。在8.4.1.2中有关于header中field value第一个octet的值以及对应的含义，以帮助你解析Header field value，ContentType也是一个Header field value。这里摘录如下：

the first octet in all the field values can be interpreted as follows:

Value      Interpretation of First Octet

0 - 30     This octet is followed by the indicated number (0 ¨C30) of data octets

31         This octet is followed by a uintvar, which indicates the number of data octets after it

32 - 127   The value is a text string, terminated by a zero octet (NUL character)

128 - 255  It is an encoded 7-bit value; this header has no more data.

因此，解析ContentType我们要区分多种情况。

3) ContentType解析举例

我们以两种情况为例，一种是Well-known value形式; 另外一种形式是text string形式。

先来看Well-known value形式。如果我们解析到ContentType时遇到一组字节：03AE81EA。

• 0×03在[0,30]范围内，按照WSP规范，这个0×03是一个是一个length，表明后面的三个octets都是ContentType的值。我们看到03后面的三个字节分别为0xAE、0×81和0xEA；

• 按照WSP规范8.2.4.1关于 Short-integer的定义：

Short-integer = OCTET
; Integers in range 0-127 shall be encoded as a one octet value with the most significant bit set ; to one (1xxx xxxx) and with the value in the remaining least significant bits.

位于[0,127]区间的数字，在编码这些数字的时候，需要将字节最高bit置1。因此，我们需要将0xAE、0×81和0xEA还原为原先的值，通过 n & 0x7F计算 还原为0x2E、0×01和0x6A。这三个值都是well-known value，我们需要查表找到其对应的含义。根据content type assignment(WSP 附录Table 40)、parameter(WSP规范 附录Table 38)以及该parameter对应的assignment(WSP规范附录 Table 42)的顺序，我们分别在表中确定三个字节对应的text：

0x2E - "application/vnd.wap.sic"

0x01 -  "Charset"

0x6A - "utf-8"

因此该ContentType的值的文本形式是：”application/vnd.wap.sic; charset=utf-8″。

我们再来看看ContentType直接采用文本形式值的情况，这种情况较为简单：

0x61, 0x70, 0x70, 0x6c, 0x69, 0x63, 0x61 , 0x74 , 0x69, 0x6f, 0x6e, 0x2f, 0x76, 0x6e, 0x64,

0x2e, 0x77, 0x61, 0x70, 0x2e, 0x6d, 0x6d, 0x73 , 0x2d , 0x6d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x00

该段数据的第一个字节为0×61，其值在[32, 127]区间内，表明这是一个以零值结尾的字符串。我们将其以字符形式输出，得到的是：”application/vnd.wap.mms-message”。

得到ContentType数据后，我们再结合HeaderLen字段的值，可以计算出后面的Headers的长度。Headers中可能有多个字段，其构成格式与解析方式与ContentType的类似，这里不赘述了。

3) 应用数据举例：彩信通知消息介绍

在WSP头解析后，我们剩下的就是Data这个字段了。这个字段承载的是应用真正需要的数据。我们以ContentType=”application/vnd.wap.mms-message”为例，即彩信通知短信。来看看wappush承载的彩信通知短信的解析。

在《Multimedia Messaging Service Encapsulation Specification》 wap-209-mmsencapsulation-20020105-a.pdf 7.1 中有关于彩信通知短信字段编码的规则，彩信通知仅仅是包含彩信的Headers字段。因此，我们仅适用mms header的编码规则解析即可，这里摘录如下：

MMS-header = MMS-field-name MMS-value

MMS-field-name = Short-integer

MMS-value =
Bcc-value |
Cc-value | Content-location-value |... ...

彩信通知的字段列表在《Multimedia Messaging Service Encapsulation Specification》规范的6.2小节。

有了之前ContentType的解析经验后，解析这些字段便轻车熟路了。要注意几点：

• header field name的well-known value在《Multimedia Messaging Service Encapsulation Specification》规范的7.3小节表中

• header field name都是short integer，因此要注意与上0x7F的转换，转换后的值与7.3小节表中的值进行比对。

• 某个具体header field的值的形式，是零值结尾字符串、uintvar还是特定值，查看对应header field的具体说明即可。

三. 小结

到这里我们了解了短信协议对短信内容在手机端呈现形式的影响，我们知道了级联短信让我们可以接收到超过70个汉字字符的超长短信，我们知道了通过短信承载wap push协议，我们可以让手机上的应用接收到服务数据（比如一个服务的url或是一条彩信的访问地址）甚至可以在打开短信的时候自动加载彩信，并在手机端呈现彩信内容。

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网上线了，感谢小伙伴们学习支持！

我爱发短信：企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

我的联系方式：

微博：https://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite

微信赞赏：

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

以前一提到短信（Short Message），人们会想到“拇指族（在社交移动APP诞生前，专指用手机高频发短信的一个群体）”、“拜年短信”。现在再提到短信，人们想到的变成了“验证码”、“垃圾短信”以及“我好久不发短信了”。短信这一信息承载的媒介是伴随着移动通信工具一并诞生的，它是“古老的” – 1992年，22岁的加大拿工程师Neil Papworth用电脑给同事Richard Jarvis发出了人类历史上的第一条短信，总共15个字符（包括空格）：“merry christmas”；它也辉煌过，是曾经的“网红” – 2012年根据中国工信部(MIIT)的数据，中国手机用户共发送9000亿条短信，这是中国短信数量的高峰。2013年开始，短信开始走下坡路，社交APP（如微信）的出现，让短信业务出现断崖式下跌，直到2018年短信业务才有了些许恢复性的增长。

一. 什么是增值类短信

不可否认的是短信依旧（至少目前依然）是我们日常生活中不可缺少的信息获取媒介，只是我们不再主动发送（点对点短信: 手机用户A发给手机用户B的短信），而是被动接收（应用发给手机用户的验证码、通知信息以及垃圾短信）。

而这类被动接收的短信，多数都属于我们要重点说明的“增值类短信业务”。所谓增值类短信业务，说白了就是用于应用与用户互动的短信。

在增值类短信最火爆的年代，你一定听说过电台或电视中出现类似：“请发送XXX到YYYYYYY参与平台互动、抽奖、起名、查询天气预报、交通信息甚至是“算命”….”的音频或电视滚动播放的提示文字，这些提供增值类短信应用的商户被称为SP(服务提供商Service Provider)，那个时候各大互联网门户也都是SP，都有自己的短信平台与手机用户互动。在这场以短信为媒介发展起来的增值短信业务市场中，移动运营商（国内的移动、联通、电信）赚的盆满钵满，因为每条发送给SP的短信都要扣费，费用至少包含两部分：通信费和业务费：

• 通信费是使用运营商短信通道的费用，是运营商收取的，好比汽车上高速要缴纳高速服务费，因为我们的车在行驶过程中占用了高速公路一定面积的路面，并造成了一定的高速路面损害；通信费一般是按条收取的，最常见的费用是1角/条；当然运营商最擅长提供“套餐”，套餐中包含一定数量的短信，如果每月发送的短信条数在套餐数量之下，就无需额外付费。

• 业务费是使用这个增值短信业务（比如天气预报）产生的费用。这个费用是否都给SP，要看SP与运营商签订的分成协议。多数情况下，运营商还是要从这个费用中扣除一部分分成后，将剩余的打给SP。比如手机用户发送一条查询天气预报的短信花费的业务费为1元；如果运营商和SP的协议是4:6分成的话，那么这1元中，运营商赚4角，提供天气服务的SP赚6角。业务费还可以按条/次或包月收取。以天气预报服务为例，如果是包月，那么手机用户在当月可以无限次给SP发送短信查询天气预报而不用担心逐条扣费。

我们看到在短信增值业务时代，运营商才是最大赢家，他们既收取通信费，还收取部分业务费。在增值类短信最火的几年中，运营商相继推出了自己的移动数据服务品牌，比如中国移动的移动梦网。当然短信增值业务仅是运营商数据业务的一种而已，他们还提供诸如彩信、wap等数据业务。

2013年及以后，随着移动互联网社交APP（诸如微信、移动QQ）的诞生与迅猛发展，短信作为社交工具的职能被彻底剥夺了，点对点短信彻底没落；随着微博、公众号、服务号等平台工具的推出，短信的互动功能、通知服务功能也被大幅削弱，以前的媒体互动平台几乎全部由短信平台迁移到微信、微博平台，大家日常听到最多的是请关注微信公众号或微博参与互动，互动短信被彻底扔到了历史的垃圾桶中。运营商再也不能像以前那样躺着收取手机用户的通道费和业务费了，这也直接导致了运营商在短信业务营收方面的大幅下降，运营商也要开始学勒紧裤腰带过日子了（当然和普通企业相比，运营商还是有钱人）。

目前让增值类短信业务屹立不倒的是验证码短信，这还多亏了国家出台的手机卡办理实名制，实名制让手机与身份几乎一一对应，也助推了短信成为了现存的、可用的最靠谱的（但不是最先进的）身份识别信息载体。可以说目前人们生活离得开“短信”，但离不开增值类的“验证码短信”。

有人会问全国每年发送的验证码短信没有万亿条，也有千百亿条了，运营商怎么没有以前赚钱了呢？这是因为这种从SP发到手机用户的短信，运营商只能收取SP的通道费，对SP收取的通道费原本就很低廉，且在三大运营商疯狂争夺客户的竞争中，SP的通道费还在逐年下降，直接导致运营商的增值短信业务出现量增但收入反降的局面。

二. 增值类短信是如何发送到你的手机上的

接下来，我们将进入偏技术的领域，我们来看看这类增值类短信是如何发送到用户手机上的。这里我们不会深入到运营商无线网络侧作细致说明，我们关注的更多是IP网络侧。国际上通用的关于SP接入运营商进行短信收发的协议是SMPP协议(Short Message Peer-to-Peer)。在最新的5.0版本协议规范中，我们可以看到一幅网络拓扑图，这里将其简化一下：

我们看到，在国际上通行的组网是这样的：

• SP通过smpp协议与运营商IP侧网络的Routing Entity相连，收发短信；

• Routing Entity这个网元的作用正如其名，它根据短信的相关信息，将短信路由转发到连接对应SMSC的Routing Entity上，然后下一个Routing Entity负责通过SMPP协议将短信下发到后面的SMSC；

• SMSC即短信中心，负责接收Routing Entity的短信，并将短信通过运营商的无线侧发到手机用户。

这已经是一个足够简化的网络拓扑图。

在国内，Routing Entity由各大运营商的短信业务网关(SMS Gateway)充当，原则上每个运营商在每个省份会建立一套短信网关。短信会首先由接收该短信的短信网关进行转发（可通过目的号码路由），将短信转发到目的号码归属省的短信中心(SMSC)，然后由SMSC将短信下发到手机用户。这里省略无线侧网元，可以更清晰看到全国短信网关（SMS Gateway）和短信中心(SMSC)组网(先不考虑不同运营商之间的短信收发)：

我们从图中可以看到，这是一个运营商在A省和B省的短信业务网元网络拓扑。SP从A省接入，因此A省也称为SP的接入省。手机用户A和手机用户B分别归属于A省和B省，因此称A省是手机用户A的归属地；B省市手机用户B的归属地。

我们看到：与国际通用方式不同的是，国内SP不是通过SMPP接入短信网关(SMS Gateway)（在没有短信网关之前，SP是通过SMPP直接接入smsc的），而是使用了运营商的专有协议（中国移动CMPP、中国联通SGIP、中国电信SMGP）；短信网关之间是互联的，通信协议也是运营商专有协议。一个省的短信网关只会连接本省的SMSCs。

当SP下发一条短信给手机用户A时，短信流经的网元如下：

SP -> A省短信网关(SMS Gateway) -> A省某SMSC实例 -> A省基站 -> 手机用户A

当SP下发一条短信给手机用户B时，短信流经的网元如下：

SP -> A省短信网关(SMS Gateway) -> B省短信网关(SMS Gateway) -> B省某SMSC实例 -> B省基站 -> 手机用户B

如果手机用户收到短信后要与SP互动，即手机用户发送一条短信到SP的号码上时，流程是这样的。

当手机用户A给SP发送一条短信，该短信流经的网元如下：

手机用户A -> A省基站 -> A省某SMSC实例 -> A省短信网关(SMS Gateway) -> SP

当手机用户B给SP发送一条短信，该短信流经的网元如下：

手机用户B -> B省基站 -> B省某SMSC实例 -> B省短信网关(SMS Gateway) -> A省短信网关(SMS Gateway)  -> SP

现在我们粗略地知道了我们是如何收到一个SP发送的短信的了以及反向流程了（在同一运营商下面）。

三. 小结

从业增值类短信业务平台开发很多年，这算是第一次写有关短信业务相关的文章。这一篇算是一个科普类的增值类短信业务介绍。接下来，我将继续以图文方式介绍增值类短信的协议与不同类型增值类短信打包和解析的难点。

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网上线了，感谢小伙伴们学习支持！

我爱发短信：企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

我的联系方式：

微博：https://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite

微信赞赏：

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。