码厩技术博客

#7 移动通信技术

• 0G 大概是那种内部无线通信网络，对讲机？
• 60 年代出现。
• 1G 蜂窝技术，模拟信号。
• 80 年代出现，2000 年左右被淘汰。
• 2G
• 主要的第二代手机通信技术规格标准有：
  • GSM：以 TDMA 为基础所发展、源于欧洲、目前已全球化。
  • IDEN：以TDMA为基础所发展、美国独有的系统。被美国电信系统商Nextell使用。
  • IS-136﹙也叫做D-AMPS﹚：基于TDMA所发展，是美国最简单的TDMA系统，用于美洲。
  • IS-95﹙也叫做cdmaOne﹚：基于CDMA所发展、是美国最简单的CDMA系统、用于美洲和亚洲一些国家。
  • PDC﹙Personal Digital Cellular﹚：基于TDMA所发展，仅在日本普及。
• 3G 国际电信联盟（ITU）所制定的 IMT-2000 规范
• 支持六种无线电接口，可能就是子标准。在我们国内，三大运营商分别采用的是：
  • 中国电信 CDMA2000
  • 中国联通 WCDMA
  • 中国移动 TD-SCDMA (这套标准仅中国使用)
• 4G
• 技术标准：
  • LTE-Advanced（长期演进技术升级版）（三大运营商都有这两种标准的经营许可牌照）：
  • LTE FDD（频分双工长期演进技术）
  • LTE TDD（时分双工长期演进技术），又称 TD-LTE，不少中国公司参与研发。
  • WirelessMAN-Advanced（无线城域网升级版）：又称 WiMAX-Advanced、WiMAX 2，即IEEE 802.16m，是 WiMAX 的升级演进，由 IEEE 所主导制定。Intel 2010 年退出之后，已经抛弃。
• 5G
• 目前，提供5G解决方案给电信运营商的公司有：诺基亚、爱立信、三星、高通、思科、华为、中兴、大唐电信。
• 美国及其附属国对华为的 5G 产品进行打压，可能华为真的在这方面比较领先。
• 中国 5G 商用时间不算早，但是推进速度快，现在已经是最大规模的 5G 网络。
• 根据网上的科普，可以实现更高的带宽，更低的延迟（重点）。
• 问题：1. 需求不足；2. 高频导致抗干扰能力差；3. 高频导致信号覆盖范围小，需要更大密度架设基站。
• 6G 研发中
• 据说能够实现微妙级的延迟

经常看到的 ITU 和 3GPP 不知道是个什么关系，这些通信技术一会儿说是 ITU 标准，一会儿说是 3GPP 标准。

GSM

GSM，Global System for Mobile Communications，全球移动通讯系统。
第二代（2G）移动电话系统。
GSM 标准当前由 3GPP 组织负责制定和维护。

• 3G（CDMA2000, WCDMA, TD-SCDMA）
• 4G（LTE FDD, TD-LTE）
• 5G

3GPP

http://www.3gpp.org

相关技术文档分成 TR（技术报告）和 TS（技术规范）
技术规范有版本号：Vx.y.z，其中 x 表示 release，y 表示技术版本，z 表示修订版本。
每个 release 都有一个冻结日期，一般 3GPP 协议在冻结以后就不再修改。一般冻结日期为 1 年。
文档由分成 Stage 1 ~ 3，分别从服务使用者角度阐述服务，分析问题，描述技术实现。

参考资料与拓展阅读

• CSDN 博客，【5G核心网】 3GPP TS 系列解读

#6 短信类型

• 短信，Short Message/Messaging Service，SMS
• 1986 年 GSM 协议的一部分，最大允许 160 字节。
• 彩信，多媒体短信，Multimedia Messaging Service，MMS

过去，多媒体短信的大小通常为50KB，这是由运营商和手机终端双方面决定的。现在大部分手机可支持300KB的彩信。彩信中可以加入图片，背景音乐和文字信息。
Although the standard does not specify a maximum size for a message, 300 kB and 600 kB are the recommended sizes used by networks for compatibility with MMS 1.2 and MMS 1.3 devices respectively.
The limit for the first generation of MMS was 50 kB.

MMS 依赖 WAP。
发送彩信的时候，内容编码之后投递给多媒体消息服务中心（MMSC）（如果跨运营商，会中转到收信人运营商 MMSC）。
收信人运营商会确认设备是否支持 MMS，如果支持，就发送一个 WAPPush 通知，内容就是一个 URL，也就是才新内容的地址。
一般来说，默认都是需要收信人手动确认是否接收，如果同意接收就会连上 URL 下载内容在手机端浏览。（网页？）

• 闪信，Flash SMS
• 似乎有地方称之为屏信，展信
• 经常是政府机关或者运营商用来发送通知、提醒（如果用作营销就太恶心了）
• 可能存在的问题：部分机器不支持闪信，闪信相互覆盖
• 和 SMS 不同，据说是跟 USSD 有关
• 又有资料说是只有短信头不同，存疑，如果是的话，为什么没有看到伪基站大量投递闪信
• 根据网上的资料，CMPP 协议支持发闪信
• 影信，同视频短信

• 视频短信，彩信升级版，支持最大 1.8M 的富媒体内容。(不同的地方写的不一样，有的说 1.9M，有的说 2M)

• 阿里云叫做数字短信

  多媒体短信包括数字短信和卡片短信

  其中，卡片短信，可能是下面的 5G消息

• 燃信，中国移动的营销概念，就是视频短信

• 富媒体短信，Rich Communication Services，RCS
• 同样也是 GSMA 推出的协议（GSMA RCS UP 标准），2019 年成为 5G 标准的一部分。
• 文字，图片，音频，视频，地理位置，文件等，几乎微信可以发送的消息，这里都支持。
• 根据维基百科，RCS 可能也被称之为 Advanced Messaging，Chat，joyn，SMSoIP，Message+，SMS+。
• 【澎湃新闻】当地时间12月2日，谷歌发文庆祝短信问世30周年，称现在应转用富媒体通信（RCS），并顺便挖苦不支持RCS的苹果“消息功能还活在30年前”。PS：苹果不支持 RCS。
• 5G阅信？没有看到什么有价值的资料，可能是某个厂商的品牌？
• 5G消息，5G短信，RCS 的国内名称，其实和 5G 没有一毛钱关系
• 几大运营商都在推，试图将短信服务打造成微信（这么牛B的愿景，为什么我一点都没有感受到）
• 不走短信网关，走互联网。如果网络有问题，有回退方案，就是下面的 AIM 这种。
• 2020年4月8日，中国移动、中国电信、中国联通携手11家合作伙伴共同发布《5G消息白皮书》，三大运营商计划在2020年内推出5G消息。
• 2020年5月10日，5G消息APP上架。5月11日，5G消息APP因技术原因暂时下架。
• 2020年12月22日，短信业务升级为5G消息，无需下载客户端，就可实现“消息即服务”。
• 2022年1月25日，中国电信5G消息正式商用。
• 目前存在的问题：收费（他们的脑子是咋想的？）；运营商和手机厂家各怀鬼胎；短信服务早已沦为接受验证码的工具，互联网即时通讯服务的城墙已经非常高了。
• AIM，智能短信，智慧短信，手机上的短信应用将普通文本短信渲染成更丰富的样式，还有交互的功能，可以打开轻应用，应用，H5 页面，拨号，打开地图等。
• 需要手机厂商支持
• 根据网上的资料，可能是深圳梦网推出的。

参考资料与拓展阅读

• https://en.wikipedia.org/wiki/3GPP
• https://en.wikipedia.org/wiki/Short_Message_Service_technical_realisation_(GSM)
• https://en.wikipedia.org/wiki/Unstructured_Supplementary_Service_Data
• https://blog.csdn.net/u010258235/article/details/99967220
• https://monyun.cn/chanpin/AIM.html
• OSCHINA, 谷歌发文批评苹果：不采用 RCS 是在 “拖大家后腿”

#5 CMPP: UDH 头

中国移动 CMPP 协议中的 UDH 头设计源自 SMPP 协议，SMPP 协议又是参考的 GSM 短信服务的相关标准。

1. TP_UDHI 字段，1 bit，对应 GSM 协议中的 UDHI，表示短信中是否包含 UDH。

UDH

UDH，User Data Header，定义在 GSM 03.40 / 3GPP 23.040 中。
UDH 是短信中可能包含的一个二进制头部，对短信服务进行拓展。
可以实现以下功能：

1. 长短信（级联短信）：切割成多条，需要通过 UDH 中的总条数和序号来组装。
2. EMS，增强型消息服务，支持颜色，文件格式，图片，动画，音乐
3. MMS，彩信
4. 本地语言转换表（Nation Language Shift Table）：在 GSM-7 的框架上支持其他国家的语言。

概念:

• TP（Transfer Layer Protocol，传输层协议）
• TP-UD（User Data，用户数据），就是短信的正文部分
• 如果存在 UDH，那就在 TP-UD 的开头
• TP-UDHI（User Data Header Indicator，用户数据头指示器）
• 消息的第六 bit，表示短信中是否存在 UDH

UDHL：UDH Length，UDH 的第一字节，表示 UDH 的长度。
UDH 剩余部分是若干标签 + 长度 + 值的组合。其中标签又叫做 IEI（Information-Element-Identifier，信息元素标识符），占一字节。

例如：05 00 03 5F 03 01

• 第一字节 05，表示后面还有 5 Byte 是 UDH
• 第二字节 00，按照下面的 IEI 表，表示级联短信
• 第三字节 03，表示 IEI Length，也就是说这个 IEI 还有 3 Byte
• 第四字节 5F，按照级联短信的设计，这个 Byte 是一个随机 int8，避免不同批次短信搞混
• 第五字节 03，按照级联短信的设计，这个 Byte 表示总短信长度
• 第六字节 01，按照级联短信的设计，这个 Byte 表示当前短信在这一批次短信中的序号

重点：如果短信采用 GSM-7 编码，则需要对齐到 7 bit，也就是说真正需要的 bit 数是 math.ceil(6 * 8 / 7) * 7
上面这个例子，8 bit _ 6 = 48 bit，需要增加 1 bit，对齐成 7 bit _ 7 = 49 bit。

UDH Information Elements

参考资料与拓展阅读

• https://en.wikipedia.org/wiki/User_Data_Header
• https://en.wikipedia.org/wiki/Concatenated_SMS

#4 SMPP 短信协议

https://en.wikipedia.org/wiki/Short_Message_Peer-to-Peer
https://smpp.org/

Short Message Peer-to-Peer (SMPP) 是一种开放的短信协议。虽然名字中带有 P2P 的字样，但 SMPP 实际上是一种 C/S 协议。
移动 CMPP 协议，联通 SGIP 协议，电信 SMGP 协议，据说他们之间交换信息都是走 SMPP 协议。

常用版本：

• 3.3 https://smpp.org/SMPP_v3_3.pdf
  仅支持 GSM 网络
• 3.4 https://smpp.org/SMPP_v3_4_Issue1_2.pdf
• https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=141
• 5.0 https://smpp.org/SMPP_v5.pdf

根据维基百科的资料，SMPP 之前由 SMS 论坛开发，但是 2007 年，SMS 论坛已经解散了。

数据格式

数据包（PDU (protocol data units, or packets)）格式：

• header (必需)
• command_length 4B
• command_id 4B
• command_status 4B
• sequence_number 4B
• body (可选)

'command_length',             (60) ... 00 00 00 3C
'command_id',                  (4) ... 00 00 00 04
'command_status',              (0) ... 00 00 00 00
'sequence_number',             (5) ... 00 00 00 05

'service_type',                 () ... 00
'source_addr_ton',             (2) ... 02
'source_addr_npi',             (8) ... 08
'source_addr',               (555) ... 35 35 35 00
'dest_addr_ton',               (1) ... 01
'dest_addr_npi',               (1) ... 01
'dest_addr',           (555555555) ... 35 35 35 35 35 35 35 35 35 00
'esm_class',                   (0) ... 00
'protocol_id',                 (0) ... 00
'priority_flag',               (0) ... 00
'schedule_delivery_time',      (0) ... 00
'validity_period',             (0) ... 00
'registered_delivery',         (0) ... 00
'replace_if_present_flag',     (0) ... 00
'data_coding',                 (3) ... 03
'sm_default_msg_id',           (0) ... 00
'sm_length',                  (15) ... 0F
'short_message', (Hello Wikipedia) ... 48 65 6C 6C 6F 20 57 69 6B 69 70 65 64 69 61

名词

• SMSC：short message service center，服务器端
  或者叫 Messaging Center，简写作 MC
• ESME：extended short message entity，客户端

命令

总结：

• 响应：对应请求 + 0x80000000
• outbind，alert_notification 没有对应响应
• 此外，还有 generic_nack 是通用拒绝响应（0x80000000）
• outbind 的场景是服务器端需要推送信息或状态给客户端

#3 CMPP 短信网关协议

术语

• ISMG: Internet Short Message Gateway
• SMPP: Short Message Peer to Peer
  一个国际上比较通用的短信网关协议
  CMPP 可能兼容 SMPP，因为 Wireshark 会将 CMPP 会话识别成 SMPP
• CMPP: China Mobile Peer to Peer
  中国移动开发的的短信网关协议
• SMC: Short Message Center
• GNS: Gateway Name Server
  相当于 CMPP 网络的路由器
• SP: Service Provider
• SMC: Short Message Control
• ISMG_Id: 网关代码
• SP_Id: SP 企业代码
• SP_Code: SP 服务代码
• Service_Id: SP 业务类型
• MO: 手机发送 Originate
• MT: 手机接收 Terminated

网络连接

CMPP 基于 TCP 协议。可以长连接，也可以短连接。
长连接支持一次连接发送多次 CMPP 消息，没有消息的时候需要维持心跳。
短连接则是一次 CMPP 通信之后就断开连接。

关于心跳：
建议每 3 分钟一次心跳，如果 60 秒内没有心跳响应，应该再次心跳，总共 3 次没有响应就断开连接。
关于重试（网关与 SP 之间，网关之间）：
60 秒之后没有响应，立即重试，总共 3 次没有响应就停发。

消息采用并发方式发送，加以滑动窗口流量控制，窗口大小参数 W 可配置，现阶段建议为 16，即接收方在应答前一次收到的消息最多不超过 16 条。

关于短连接：
60 秒超时，重试 2 次。

端口

• 7890 长连接（SP 与网关之间）
• 7900 短连接（SP 与网关之间，网关之间）
• 7930 长连接（网关之间）
• 9168 短连接（网关与 GNS 之间）

数据类型

var Total_Length uint32 // 消息总长度
var Command_Id uint32   // 命令或响应类型
var Sequence_Id uint32  // 消息流水号, 递增, 步长为 1, 循环使用

RESP Command_Id 则是对应的 Command_Id 最高 4 位为 8，即 0x8X。

SP 与 ISMG 之间的通信

对于一般开发来说就这 7 个接口。

1. 建立连接 CMPP_CONNECT
2. 断开连接 CMPP_TERMINATE
3. 提交信息 CMPP_SUBMIT
4. 获取状态 CMPP_DELIVER
5. 撤回信息 CMPP_CANCEL
6. 查询信息 CMPP_QUERY
   只是一些统计信息，我想不到这个接口的应用场景
7. 链路检测 CMPP_ACTIVE_TEST

连接 CMPP_CONNECT

var Source_Addr [6]byte // SP_Id
var AuthenticatorSource [16]byte // SP_Code
// md5(Source_Addr + 9 字节 0 + shared secret + timestamp)
// timestamp: MMDDHHMMSS, 月日时分秒, 补 0
var Version uint8 // 版本号, 高 4 位表示主版本号, 低 4 位表示次版本号, 最大 15.15
var Timestamp uint32 // 时间戳, 默认为 0

CMPP_CONNECT_RESP

var Status uint8 // 状态, 0 正确, 1 结构错误, 2 非法源地址, 3 认证错误, 4 版本错误, 5 其他错误
var AuthenticatorISMG [16]byte // ISMG 认证码
// md5(Status + AuthenticatorSource + shared secret)
// 如果认证错误, 此项为空
var Version uint8 // 服务器支持的最大版本号

断开连接 CMPP_TERMINATE

无请求消息体，无响应消息体

提交信息 CMPP_SUBMIT

var Msg_Id uint64       // 消息标识, 网关负责自主生成，SP 留空
var Pk_total uint8      // 消息总条数, 从 1 开始
var Pk_number uint8     // 消息序号, 从 1 开始
var Registered_Delivery uint8 // 是否要求返回状态确认报告, 0 不需要, 1 需要, 2 产生 SMC 话单 (该类型短信仅供网关计费使用，不发送给目的终端)
var Msg_level uint8     // 信息级别, 0 低, 1 中, 2 高
var Service_Id [10]byte // 业务类型
var Fee_UserType uint8  // 计费用户类型, 0 普通用户, 1 行业用户, 2 用户组
var Fee_terminal_Id [32]byte // 被计费用户的号码
var TP_pid uint8        // GSM协议类型, 0 GSM 03.40, 1 CDMA, 2 WCDMA, 3 CDMA2000, 4 联通移动TD专用协议
var TP_udhi uint8       // GSM协议类型
var Msg_Fmt uint8       // 信息格式, 0 ASCII 串, 3 短信写卡操作, 4 二进制, 8 UCS2 编码, 15 含 GB 汉字
var Msg_src [6]byte     // 消息发送者, SP_Id
var FeeType [2]byte     // 资费类别
var FeeCode [6]byte     // 资费代码, 以分为单位
var ValId_Time [17]byte // 存活有效期，格式遵循 SMPP3.3 协议
var At_Time [17]byte    // 定时发送时间, YYMMDDhhmmsstnnp, t 是 1/10 秒，nn 是与 UTS 时间的差值 00-48，p `+/-`
var Src_Id [21]byte     // 源号码
// SP 的服务代码或前缀为服务代码的长号码,
// 网关将该号码完整的填到 SMPP 协议 Submit_SM 消息相应的 source_addr 字段
// 该号码最终在用户手机上显示为短消息的主叫号码
var DestUsr_tl uint8    // 接收信息的用户数量, 小于 100
var Dest_terminal_Id [][21]byte // 接收短信的用户号码 (MSISDN), 21 * DestUsr_tl
var Msg_Length uint8    // 短消息长度
var Msg_Content []byte  // 短消息内容
var Reserve [8]byte     // 保留

注意：关于短信群发的问题，若 SP 对于群发消息不要求状态报告的回送时，才可以考虑群发，否则必须逐条发送。

关于 TP_udhi 的解释：

如果 = 1，则需要在 Msg_Content 中加入一个 udhi 头，定义如下：

1. 六字节
   05 00 03 开头，分别表示剩余 5 字节，xxx，剩余标识长度为 3
   第四字节，唯一标识
   第五字节，短信条数
   第六字节，序号
2. 七字节
   06 08 04 开头，分别表示剩余 6 字节，xxx，剩余标识长度为 4
   第四五字节，唯一标识
   第六字节，短信条数
   第七字节，序号

CMPP_SUBMIT_RESP

var Msg_Id uint64       // 消息表示, SP 自主生成
var Result uint8        // 结果, 0 正确, 1 消息结构错, 2 命令字错, 3 消息序号重复, 4 消息长度错,
                        //       5 资费代码错, 6 超过最大信息长, 7 业务代码错, 8 流量控制错, 9~ 其他错误

• MMDDHHMMSS，26 位
  月份 4 位, 1-12
  日期 5 位, 1-31
  小时 5 位, 0-23
  分钟 6 位, 0-59
  秒钟 6 位, 0-59
• 网关代码，22 位
• 序列号，16 位，递增, 步长为 1, 循环使用

查询 CMPP_QUERY

var Time [8]byte // YYYYMMDD
var Query_Type uint8 // 查询类型, 0 总数查询, 1 按业务类型查询
var Query_Code [10]byte // 查询码, 查询类型为 0 时无效, 查询类型为 1 时此处为业务类型
var Reserve [8]byte // 保留

CMPP_QUERY_RESP

var Time [8]byte
var Query_Type uint8
var Query_Code [10]byte
var MT_TLMsg uint32 // 接收消息总数
var MT_TLusr uint32 // 接收用户总数
var MT_Scs uint32   // 转发成功总数
var MT_WT uint32    // 待转发总数
var MT_FL uint32    // 转发失败总数
var MO_Scs uint32   // 发送成功总数
var MO_WT uint32    // 待发送总数
var MO_FL uint32    // 发送失败总数

送交短信 CMPP_DELIVER

从网关发送出来的消息

var Msg_Id uint64
var Dest_Id [21]byte            // 目的号码
var Service_Id [10]byte
var TP_pid uint8
var TP_udhi uint8
var Msg_Fmt uint8
var Src_terminal_Id [21]byte    // 源号码
var Registered_Delivery uint8
var Msg_Length uint8
var Msg_Content []byte          // Msg_Length
var Reserved [8]byte

var Msg_Id uint64
var Stat [7]byte
// DELIVRD 送达
// EXPIRED 过期
// DELETED 删除
// UNDELIV 未送达
// ACCEPTD 接收
// UNKNOWN 非法
// REJECTD 拒绝
var Submit_time [10]byte
var Done_time [10]byte
var Dest_terminal_Id [21]byte
var SMSC_sequence uint32

SP 等待状态报告 48 小时。

CMPP_DELIVER_RESP

var Msg_Id uint64
var Result uint8

删除短信 CMPP_CANCEL

var Msg_Id uint64

CMPP_CANCEL_RESP

var Success_Id uint8 // 0 成功, 1 失败

链路检测 CMPP_ACTIVE_TEST

无消息体。

CMPP_ACTIVE_TEST_RESP

var Reserved [8]byte

#2 短信的原理

• Short Message, 短信
• SMS, Short Message Service, 短信服务
• MO, Mobile Originate, 发短信
• MT, Mobile Terminate, 收短信

Terminal 终端
SMC      短信中心
SMS GW   短信网关

重要协议

• GSM 03.40
• SMPP

编码方案

• 7bit ASCII
• 8bit ASCII
• UCS2 (早期的 Unicode 方案，2 Bytes 表示一个字)

长度

受协议限制，短信内容最大 140 字节，所以：

采用 8bit 编码的话，最长 140 字符。
采用 7bit 编码的话，最长 160 字符（正好）。
采用 UCS2 编码的话，最长 70 字符。

如果涉及长短信切割，根据通行的拓展协议，需要采用头三个字节存储相关信息。

采用 8bit 编码的话，每段最长 137 字符。
采用 7bit 编码的话，每段最长 156 字符（最后剩余 4 bits 空着）。
采用 UCS2 编码的话，每段最长 67 字符。

长短信分割

参考 GSM 03.40 9.2.3.24 TP-User Data (TP-UD) 部分，一般有两种方案：

\x05        剩余协议头长度
\x00        短信标识 GSM 03.40
\x03        剩余短信标识长度
随机字节（1 字节）
总包数
包序号（1 开始）

还有一种没有怎么见过的方案，就是采用两个字节做随机标识，然后头三字节改成 \x06\x08\x04。

第二字节叫做 The Information Element Identifier（信息元素标识符），上面的 \x00，\x08 分别标识 1 字节，2 字节随机标识方案。其他值可以参考文档。

#1 短信长度到底是怎么规定的

短信的通信协议从 2G 时代一直到现在基本没有什么变化。

1. 支持 140 个字节（140 Byte = 140 * 8 bit = 1120 bit）
2. 支持 GSM-7 编码，8bit 编码，UCS-2 编码
3. GSM-7 每个字符 7 bit，支持英语和西欧语言，配合 National Language Shift Table 功能，能够支持一些其他字母文字的语言。
4. UCS-2 每个字符 2 Byte（16 bit），传递一些 GSM-7 框架不支持的语言，比如中文（字符太多，7bit 方案反倒不合适）。
5. 8bit 用来传递图片等二进制数据。
6. 根据短信协议，如果长度超出范围，需要在短信前面加上一个二进制头部，叫做 UDH（User Data Header）。
7. UDH 一共 6 个字节
8. 包含一些 SMS 拓展字段
9. 对于短信拆分来讲，里面有这一批短信的总条数，和当前这条短信的序号

所以，

1. 如果是中文短信，用 UCS-2 编码，每个字符 2 Byte，一条短信最长支持 70 个中文字符（140 Byte / 2）。
2. 注意：所有字符，包括 ASCII 中的英文、数字、半角的标点，全部需要转换成 UCS-2 的 2 Byte 编码。
3. 如果长于 70 个字符，就需要切割成多条，UDH 头部需要 6 Byte，每条短信还剩 134 Byte，除以二，还能装 67 个字符。
4. 例如：140 个中文字符的短信，需要切割成 67 + 67 + 6 三条短信。
5. 如果是英文短信，或者部分西欧语言，可以使用 GSM-7 编码，每个字符 7 bit，一条短信最长支持 160 个字符（1120 bit / 7）。
6. 如果长于 160 个字符，也是需要切割，除去 UDH 的 6 Byte = 6 _ 8 bit = 48 bit，还剩 1120 bit - 48 bit = 1072 bit，
   1072 bit = 7 bit _ 153 + 1 bit，也就是说最多发送 153 个字符（多的那 1 bit 置 0，不参与计费）。
7. 例如，320 个英文字符，需要切割成 153 + 153 + 14 三条短信。
8. 注意：GSM-7 编码中，9 个拓展字符 ^ ~ \ | { } [ ] € 需要算两个字符。非常重要
9. 数据通信中都是使用 Byte 为单位，用 GSM-7 编码可能会除不尽，也就是说剩余 1 ~ 7 bit。比如：
   1. 发送 33 个字，33 * 7 bit = 231 bit，需要 29 Byte (232 bit) 来装，就多了 1 bit
   2. 同样的方法计算，发送 34 个字多了 2 bit，... 发送 39 个字剩余 7 bit，发送 40 个字正好 35 Byte，没有多余的 bit...
   3. 根据协议，多余的 bit 需要置零，除非是多出来 7 bit，7 个 0 会和 GSM-7 的 @ 字符冲突，这时候应该置为 0001101，也就是 GSM-7 中的 \r 回车字符。

最后：

1. 关于 GSM-7 的详细信息，可以参考：2022/01/05，GSM-7 编码。
2. 关于 UDH 的详细信息，可以参考：2022/05/13，CMPP: UDHI 头。
3. https://en.wikipedia.org/wiki/Concatenated_SMS

补充：

1. 部分通道采用 7 Byte 的 UDH (短信批次标识由 1 Byte 改成 2 Byte)，所以短信切割长度是 152 个字符（(140 - 7) * 8 / 7）。
2. 如果短信采用 GSM-7 编码，UDH 需要按 7 bit 对齐，也就是说如果是 6B 的 UDH，最后需要占用 49 bit，UDH 后面的 1 bit 填 0。