各种消息的一些实现原理

本文试图说明消息领域各种类型消息的主要技术实现

1. 一些通信背景知识

上图是目前整个移动通信主要结构：

• 基站负责处理无线信号，运营商在无委会分配频段（例如：900MHZ/1800MHZ）上进行数据传输，具体通信技术包括FDM、TDMA、CDMA等，核心是解决有限频率资源限制下数据带宽问题
• 基站到运营商机房，目前绝大多数都采用光缆，传输物理介质也经历了双绞线->同轴电缆->光缆的演进。传输技术上也经历了类似（FDM、TDM、CDM）的调制解调技术与算法的演进；
• 运营商通信中心中，包含很多传输/交换转换的设备，通常称为网元，例如：HLR、MSC、SMSC、ISMG、SGSN、LSTP、NFV、SDN…… 核心是处理数据转接存储，发展方向有点类似现在服务端开发中的弹性伸缩，在5G阶段已经将原有特定功能网元设备改为软件定义；

2. 短信

依次经历 SP（创蓝） -> ISMG(短信网关) -> SMSC(短信中心) -> 基站 -> 手机(Modem RIL -> framework -> APK)，在空口到RIL以PDU方式封装消息传输 短信收发在手机与基站间，占用的是TMDA调制信道也就是GSM的无线物理信道 例如：900MHZ有125个频点(将900MHZ左右分频点的过程就是FDM)，每个频点8个时隙；一个信道就是：频点+时隙；也就是说在900MHZ非干扰覆盖区域内最大支持通话与短信的量就是125*8个 这种信道上：

• 在GPRS时代，数据的带宽为21kbit/s
• 在3G时代，数据的带宽是2～7Mbit/s
• 在4G时代，数据带宽是50～100Mbit/s
• 在5G时代，数据带宽是1Gbit/s 我们可以换算下 1条短信140bytes = 140*8 bits = 1120bits，这些信息占用了一个信道
• GPRS可以传递数据量为21kbits，是短信的20倍
• 3G时代可以传递数据量为7Mbits，是短信的7000多倍
• 4G时代可以传递数据量为100Mbits，是短信的10万倍
• 5G时代可以传递数据量为1Gbits，是短信的100万倍 上面是粗略估算，仅是理论值，实际情况虽没那么夸张，但几个数量级的差距还是有的。不知道运营商涨价倒逼SP切5G是不是也有这层通道利用率的考虑。

3. 彩信

大体上跟短信类似，也会经历一系列运营商网元（如MMSC等）到达手机终端，流程上稍有不同的是

• 先通过WAP协议发送通知到终端，通知中包含一个URL
• 终端中通过应用层设置“是否自动下载彩信”，决定是否下载对应URL中的内容 因为这种通过两次交互的原因，彩信的到达率也曾经一直被诟病，运营商也专项优化从不到90%提升到号称95%的成功率

4. RCS

在通道与协议层面改革，通道直接摒弃了通讯通道，采用数据通道，协议更换为SIP协议。经历了几个版本的迭代，从最开始解决C2C，发展到现在还可以解决B2C问题的 UP2.4版本。 功能实现层面可以完全类比微信等IM，依次有注册->登录->长连接->收发消息 通常所称的RCS仅强调C2C部分，即作为短信延伸解决人与人之间互发免费短信而且还支持了更大的图片、视频、语音、地理位置等 在终端侧通常有三种方式即成RCS

• 一 封装协议栈sdk，增加一个系统应用向通/短/联提供RCS能力支持，通/短/联通过远程调用方式使用改协议栈
• 二 仅将协议栈sdk放到短信中，在短信中直接调用RCS sdk完成业务；
• 三 平台方在modem RIL层封装协议栈，随芯片售卖 最后一种方式基本没人用

5. 5G消息

5.1 通道与主要技术实现

本质上是RCS UP2.4定义下的富媒体卡片消息，除消息本身外，还包括Maap与Chatbot。在网上找了张描述整体架构的图，如下：

运营商网络中增加了5GMC消息系统和Maap平台管理模块，富媒体卡片在SIP中通过application/vnd.gsma.botmessage.v1.0+json下发；消息体例子没找到，简单理解就是描述了消息类型是图文，还是红包等，图文的话，标题是什么，图片地址是什么、摘要是什么……

5.2 Maap

Maap 即 Message as a platform，核心目标是在消息会话内完成任务闭环。如：客服场景的自动对话应答解决客户问题；购物场景的询价、换商品、下单、支付、退货…… 实现方式上，因为有基于长连接的IM能力，所以，

• 可以支持在线实时对话的通道；
• 后端对话再加一个聊天机器人，就可以实现对应的业务场景了；
• 该聊天机器人又是个比较大的领域，具体做法上可以

1. 采用难度较高的类似siri的方式实现通用型聊天对话，
2. 也可以在特定领域以问题穷举方式训练领域对话机器人
3. 或者更简单的方式直接通过suggested actions（快捷建议操作）直接定义机器人能处理的指令，如：客服电话、下单等快捷建议操作按钮；

6. AIM

本质上是一种场景触发的拉取消息 发送短信过程与上面短信无任何差别，完全一致 区别在于接收短短信之后会在终端手机中做一次解析，这个解析逻辑主要是看短信中url是否命中url白名单，如果命中则就去服务端再拉取一次富媒体卡片消息内容

卡片渲染这里采用了快应用卡片，可以在服务端定义动态化展现形式，客户端根据定义动态化渲染

7. 阅信

技术方案与AIM完全相同，差别仅在于上图中“厂商接口”换成全部运营商的，部署在中国移动互联网公司。

8. IP消息

厂商自建一条长连接通道，在上面承载C2C、B2C消息；简单理解就是建了个微信，只不过终端应用交互落在短信应用里面而已；苹果的iMessage也是一种支持IP消息的短信应用 主要是用技术：Push（包括FCM）、IM 主要解决问题：

• 设备 <-> 手机号 <-> IM ID <-> Push client ID对应关系；
• 短/彩信与IP通道消息合并/去重；
• B2C消息（包括富媒体卡片消息）运营/审核平台；

延展讨论：

目前现有消息或者通讯都仍采用中心化的方式做的，不论是传统消息还是微信、飞书，或是号称端到端加密的WhatsApp，都必须有个中心服务器做消息路由转发。那未来可不可以有去中心化的解决方案呢？答案是肯定的，例如：自组网络，这也不是新概念，早在上世纪70年代就提出过，有兴趣的同学可以自行百度。