如何理解三大运营商发布的《5G消息白皮书》？
2020年4月8日中国移动、中国电信、中国联通携手华为、小米、vivo、OPPO、中兴等11家终端厂商联合发布了《5G消息白皮书》，用来推动传统短消息服务升级。
三大运营商联合发布的《5G消息白皮书》创造了一种怎样的商业模式，我们该如何理解《5G消息白皮书》？本文我们从以下几个方面进行说明：
- 如何理解5G消息？
- 运营商为什么要发布《5G消息白皮书》？
- 如何理解MaaP (Messaging as a Platform) 消息即平台？
- 5G消息软件研发方面，运营商有哪些优势？
- 5G消息通信过程中涉及到的协议及使用举例
一、如何理解5G消息？
5G消息是对传统短信服务的升级，将基于基站的短彩信消息，升级到基于移动网络与WLAN网络的融合通信消息（Rich Communication Suite）。
在具体实现方面：
传统短彩信消息的收发主要是依赖基站实现，5G消息的收发完全依赖网络实现。
传统短信SMS（Short Messaging Service）消息的接收与发送依赖基站实现；
彩信MMS (Multimedia Messaging Service)消息的接收与发送同样基于基站来实现，与短信相比不同点在于彩信消息通过基站接收到媒体类型的URL地址后，再通过GPRS下载多媒体内容，最后呈现出来；融合通信消息（Rich Communication Suite）的接收与发送完全依赖移动网络或WLAN网络实现；
在显示效果方面：
5G消息在点对点消息方面对消息类型和显示效果进行了升级，在企业对用户消息方面新增了富媒体卡片消息类型。
- 点对点消息：
5G消息支持文本、图片、音视频、文件等消息类型（点对点消息方面可以说显示效果与微信消息类似）； - 企业对用户消息：
5G消息在点对点消息（文本、图片、音视频、文件等消息）基础上增加富媒体卡片消息，并且每条企业下行到用户的消息中还可携带建议操作和建议回复；
建议回复用户点击后会将该条建议文字作为一条新的消息发送出去；
建议操作用户点击后可触发打开一个Web页、向某人拨打电话、打开日历添加一条日程提醒等操作；
二、运营商为什么要发布《5G消息白皮书》？
将传统短彩信服务升级到5G消息服务后，对于终端用户而言可显著提升其用户体验，对于行业客户而言可帮助行业客户拓展服务能力，对于运营商而言为运营商的服务转型提供了一个突破口。
- 对于终端用户：
随着智能手机的普及，终端用户更喜欢图文并茂交互能力强的消息形态；相比较而言短信消息只能编辑文字，交互方式略感单调乏味，而且短信承载能力有限（每条短信最多能发送140个字节的数据，70个汉字）；彩信消息虽然可编辑图文消息，但对于用户而言其发送成本相对较高； - 对于行业客户：
GSMA RCS Universal Profile 2.0引入了MaaP的概念，按照这个标准行业客户可以以Chatbot（聊天机器人）的方式与终端用户聊天交互，帮助终端用户实现订餐、订票、订酒店等操作，拓展行业客户的业务能力，提升了行业客户的服务体验； - 对于运营商：
5G消息构建一个MaaP平台（Messaging as a Platform消息即平台），企业客户接入MaaP平台后，企业以Chatbot聊天机器人（AI+人工）的方式向终端用户提供服务，随着越来越多的企业接入MaaP平台，一方面运营商可有效控制垃圾短信的发送；
另一方面可助力运营商转型，从卖通话时间、卖短信、卖网络流量转型到卖服务；可以说MaaP平台的搭建为运营商的转型提供了一个突破口。
MaaP平台搭建后，用户在Message短信聊天窗口中可以向银行查询自己的账单详情、咨询业务；向航空公司预定机票、购买机票等；向餐厅酒店预定位置、预定房间等。
三、如何理解MaaP (Messaging as a Platform) 消息即平台？
MaaP (Messaging as a Platform) 消息即平台是2017年GSMA在RCS Universal Profile 2.0中引入的最新RCS A2P（Application to Person）信息全球标准，其旨在将传统短彩信升级为富媒体消息，并引入Chatbot（聊天机器人）的概念使用户在消息窗口内就可进行搜索、交互、支付等一站式业务体验。
这里可以把MaaP消息平台 看做一个Chatbot Store，行业客户接入MaaP消息平台后，平台为其分配与终端用户交互的Chatbot账户，行业客户通过MaaP平台分配的Chatbot(聊天机器人)向终端用户提供服务。
5G消息利用MaaP平台聚合行业客户，通过5G消息中心为行业客户与终端用户的沟通交流提供消息服务。
四、5G消息研发方面运营商有哪些优势？
目前三大运营商正在积极推进5G消息技术研究及相关产业推进，那运营商在5G消息的研发方面有哪些优势呢？
- 软件安装覆盖率
5G消息APP是对系统Message 应用的更新升级，作为系统出厂内置应用无需用户手动安装，随着终端手机厂商的集成，可迅速达到一个很高的安装覆盖率； - 消息到达率
5G消息APP为系统应用，其后台Service不会被系统杀死，保证消息的及时到达；
在弱网环境中，消息可回落到短彩信消息进行接收与发送，保证消息及时准确到达；
五、MaaP实现与通信中涉及到的协议
5G消息白皮书中写道：
通信运营商建立的消息能力，使行业客户可以为其用户提供富媒体信息服务。
读起来还是迷糊，其实就是企业端接入5G消息提供的MaaP平台，MaaP平台会为接入的企业提供Chatbot（聊天机器人），企业的聊天机器人与终端用户会话沟通帮助用户实现订餐、订票、订酒店等操作。
企业CPIhatbot）聊天机器人（A、 或人工）方式与用户进行交互，完成用户订餐S订票D订酒店
企业相关业务服务
HTTP（HyperText Transfer Protocol）：
超文本传输协议，5G消息通信过程中，通过HTTP协议将终端用户将要发送的图片、音频、视频上传到5G消息中心，然后通过SIP协议将上传后的URI地址发送给消息接收方。
SIP（Session Initiation Protocol）：
SIP协议为5G消息通信过程中用到的多媒体通信协议，支持文本、音频、视频等多媒体消息传输。
详细了解SIP协议，可查看我的这篇文章
https://xiaxl.blog.csdn.net/article/details/104661248
5G消息基于SIP协议通信过程中，采用Standalone Messsage方式，涉及到两种通信方式Pager Mode 与 Large Mode。
SIP有两种会话模式：
在Sip消 通信应用过程中，一般存在着两种会话模式：
- Pager Model
- Large Model
Pager Model
在Sip消息中，对于消息体不大于1300字节时，一般采用Pager Model。
Sip息通信中，采用 MESSAGE 方法不建立Session会话在多数应用中，每条IM消息都是独立的，颇似分页消息。
- 步骤1：
User1发送MESSAGE请求到代理服务器； - 步骤2：
代理服务器转发User1的MESSAGE请求给USER2； - 步骤3：
User2收到User1的消息后，回复200 OK给代理服务器； - 步骤7~9：
代理服务器转发200 OK回复给User1
// ---------user1给user2发送一条消息：“user2, come here.”---------
// 请求行（REGISTER、INVITE、ACK、CANCEL、BYE、MESSAGE等）
MESSAGE sip:[email protected] SIP/2.0
// 消息header
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse
Max-Forwards: 70
From: sip:[email protected];tag=49583
To: sip:[email protected]
Call-ID: [email protected]
CSeq: 1 MESSAGE
Content-Type: text/plain //消息body的类型
Content-Length: 18
// 消息body
user2, come here.
// ---------user2收到消息后，回应200 ok---------
// 状态行
SIP/2.0 200 OK
// 消息header
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;
From: sip:[email protected];;tag=49394
To: sip:[email protected];tag=ab8asdasd9
Call-ID: [email protected]
CSeq: 1 MESSAGE
Content-Length: 0
Large Model
在Sip消息通信中，对于消息体内容大于1300字节时，需要建立Session会话。
主叫方A呼叫被叫方B：
- 步骤1：
主叫方A发送INVITE请求到代理服务器； - 步骤2：
代理服务器发送100 Trying 响应主叫方A； - 步骤3~6：
代理服务器搜索被叫方B的地址，获取地址后转发INVITE请求； - 步骤7~9：
被叫方B生成的180 振铃响应，返回给主叫方A； - 步骤10~12：
被叫方B生成的200 OK响应，返回给主叫方A； - 步骤13~17：
主叫方A收到被叫方B200 OK响应后，向被叫方B发送一个ACK，会话建立； - 步骤18~20：会话结束后，任何参与者（A或B）都可以发送一个BYE请求来终止会话；
- 步骤21~23：
主叫方A发送200 OK响应来确认BYE，会话终止。
SDP（Session Description Protocol）：
SDP 在会话初始化过程中，用来传送会话参与者的能力列表，以协调会话双方的各项参数。例如：建立会话前，呼叫方通过SDP协议向代理服务器发送其具备的能力列表，比如支持视频消息、音频消息、文本消息等。
详细了解SDP消息格式，可查看我的这篇文章
https://xiaxl.blog.csdn.net/article/details/104723834
CPIM（Common Presence and Instant Messaging）：
SIP通信过程中用到的一种会话描述格式，SIP消息中其ContentType为Message/CPIM。
详细了解CPIM消息格式，可查看我的这篇文章
https://xiaxl.blog.csdn.net/article/details/104718006
SIP通信中SDP与CPIM使用举例：
// sip 请求行
INVITE user2pc.domain.comSIP/2.0
// sip 请求Header
Via: SIP/2.0/UDP 182.1.1.203:41200;branch=z9hG4bK1393058911736
Call-ID: [email protected]
From: ;tag=2684043253
To: user2pc.domain.com
CSeq: 1 INVITE
Max-Forwards: 70
Accept-Contact: *;+g.3gpp.icsi-ref=“urn%3Aurn-7%3A3gpp-service.ims.icsi.oma.cpm.session
Session-Expires: 1800
User-Agent: CPM-client/OMA2.2 RCS-client/UP_2.4 term-Vendor1/Model1-XXXX client-CLN1/Software1234 OS-Android/8.1
Conversation-ID:u13900010001010203
Contribution-ID:u201403011700010003
Content-Length: 741
Content-Type: multipart/mixed;boundary=spiderboundary
// sdp
Content-Type: application/sdp
v=0 // version sdp版本号
o=Spider-Phone 28994 29098 IN IP4 182.1.1.203 // origion 会话发起者的描述
s=- // Session Name
c=IN IP4 182.1.1.203 // Connection Data
t=0 0 // {开始时间} {结束时间}
m=message 10110 TCP/MSRP * // media name and transport address
a=path:msrp://182.1.1.203:10110/10110;tcp
a=setup:active
a=accept-types:text/* message/* // 本终端支持的媒体类型
a=sendrecv
// cpim
Content-Type: message/CPIM
Content-Length：168
From:
To:
NS: imdn
imdn.Message-ID: W8ecb6pd
DateTime: 2012-09-20T10:42:31.35+08:00
imdn.Disposition-Notification: positive-delivery,display
Content-Type:text/plain;charset=UTF-8
Content-Length：102
Content-Transfer-Encoding: base64
// cpim body
c3Nzc3Nz
**MSRP（Message Session Relay Protocol）
一种消息格式，当SIP Session会话建立后，通过MSRP消息格式传递消息；
// 起始行:MSRP 事务ID 方法名(SEND or REPORT)
MSRP msrprequest100001 SEND
// 头域
To-Path: msrp://10.71.174.102:7654/10001;tcp //
From-Path: msrp://10.66.139.77:22100/10002;tcp
Message-ID: msrprequest100001
Byte-Range: 1-176/176
Success-Report: no
Failure-Report: yes
Content-type:text/plain;charset=UTF-8
// 消息体
adfadfadfadfadfadf