如何理解三大運營商發布的《5G消息白皮書》？

如何理解三大運營商發布的《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:[e-mail] SIP/2.0

// 消息header
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse
Max-Forwards: 70
From: sip:[e-mail];tag=49583
To: sip:[e-mail]
Call-ID: asd88asd77a@1.2.3.4
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:[e-mail];;tag=49394
To: sip:[e-mail];tag=ab8asdasd9
Call-ID: asd88asd77a@1.2.3.4
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: 13930589117@182.1.1.203
From: <user1pc.domain.com>;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 [phone] 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: <user1pc.domain.com>
To: <user2pc.domain.com>
NS: imdn<urn:ietf:params: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