如何理解 三大運營商發佈的“5G消息白皮書”？

如何理解 三大運營商發佈的“5G消息白皮書”？

2020年4月8日，中國移動、中國聯通、中國電信三大運營商聯合發佈“5G消息白皮書”，那這個5G消息白皮書到底說的是什麼呢？

• 5G消息到底是什麼？
• 運營商爲什麼要發佈“5G消息白皮書”？
• 運營商的優勢？
• MaaP (Messaging as a Platform) 簡介
• 實現中會用到哪些協議？

一、5G消息到底是什麼？

實現方面：
將基於基站的短彩信消息，升級到基於移動網絡與WLAN網絡的融合通信消息（Rich Communication Suite）。

• 短信SMS (Short Messaging Service)的接收和發送依賴基站實現；
• 彩信MMS (Multimedia Messaging Service) 的接收與發送同樣基於基站來實現，不同點在於通過基站接收到媒體類型的URL地址後，再通過GPRS下載多媒體內容，最後呈現出來；
• 融合通信消息的接收與發送完全依賴移動網絡或WLAN網絡實現；

呈現效果上：

• 一對一消息方面：
  支持文本消息、圖片消息、音視頻消息、文件傳輸消息；
• A2P (Application to Person) ：
  企業應用方面引入MaaP（Message as a Platform）概念；
  企業接入5G消息提供的MaaP平臺後，企業以Chatbot（聊天機器人 AI+人工客服）的形式與個人用戶通過運營商網絡進行溝通，幫助終端用戶實現訂餐、訂票、購物等操作；
  行業客戶下行消息方面，在一對一消息（文本、圖片、音視頻、文件）基礎上增加富媒體卡片消息類型，同時每條下行消息中還可攜帶建議操作和建議回覆。
  建議操作：點擊後可以觸發 打開一個Web頁、向某人撥打電話等、打開某個軟件等操作；
  建議回覆：點擊後會將該條建議文字作爲一條新的消息發送出去；

下圖爲 鐵路部門聊天機器人（Chatbot）與用戶溝通，幫助用戶實現購票操作時，會話窗口實現效果圖：

我對於5G消息的理解是：
5G消息客戶端就是一個IM軟件客戶端：可看做是類似 微信一對一消息 + 微信公衆號消息；

二、運營商爲什麼要發佈“5G消息白皮書”

• 短信承載能力有限：每條短信最多能發送140個字節的數據（70個漢字）；
• 對於用戶而言：隨着智能手機普及，用戶更喜歡圖文並茂交互能力強的消息形態；
  短信消息只能編輯文字，交互方式略感單調乏味；發送彩信成本相對較高；
  圖文消息更加直觀、承載信息量更大、交互能力強，升級圖文消息可以很大程度上提升終端用戶的使用體驗；
• 行業應用方面：GSMA RCS Universal Profile 2.0引入了MaaP的概念
  行業用戶可以 以Chatbot（聊天機器人）與終端用戶聊天交互，幫助行業用戶實現訂餐、訂票、訂酒店等操作；從而拓展行業用戶的業務能力，提升了行業客戶的服務體驗。

三、運營商的優勢？

• 無需用戶安裝
  5G消息APP是對系統Message 應用的更新升級，作爲系統出廠內置應用無需用戶手動安裝，隨着終端手機廠商的集成，可迅速達到一個很高的安裝覆蓋率；
• 到達率
  5G消息APP爲系統應用，其後臺Service不會被系統殺死，保證消息的及時到達；
  在弱網環境中，消息可回落到短彩信消息進行接收與發送，保證消息及時準確到達；

四、MaaP (Messaging as a Platform)

5G消息白皮書中寫道：
通信運營商建立的消息能力，使行業客戶可以爲其用戶提供富媒體信息服務。

讀起來還是迷糊，其實就是企業端接入5G消息提供的MaaP平臺，MaaP平臺會爲接入的企業提供Chatbot（聊天機器人），企業的聊天機器人與終端用戶會話溝通幫助用戶實現訂餐、訂票、訂酒店等操作。

企業以（Chatbot）聊天機器人（AI 或人工）方式與用戶進行交互，完成用戶訂餐、訂票、訂酒店等企業相關業務服務。

手機端展示效果：

五、通信過程中會涉及到哪些協議？

接下來一一對以上協議進行簡單舉例說明

5.1、SIP（Session Initiation Protocol）

多媒體通信協議，支持語音、視頻、數據等多媒體業務，用於創建、修改和釋放一個或多個參與者的會話。

詳細瞭解SIP協議，可查看我的這篇文章
https://xiaxl.blog.csdn.net/article/details/104661248

SIP類似於HTTP協議：
分爲請求行（狀態行）、消息Header、消息Body；

消息體舉例：

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

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

Large Model

對於消息體內容大於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，會話終止。

5.2、SDP（Session Description Protocol）

SDP 在會話初始化過程中，用來傳送會話參與者的能力列表，以協調會話雙方的各項參數。
例如：建立會話前，呼叫方通過SDP協議向代理服務器發送其具備的能力列表，比如支持視頻消息、音頻消息、文本消息等；

詳細瞭解SDP消息格式，可查看我的這篇文章
https://xiaxl.blog.csdn.net/article/details/104723834

消息舉例：

// 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: <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 

5.3、CPIM（Common Presence and Instant Messaging）

一種消息格式，ContentType爲Message/CPIM，當SIP Session會話建立後，通過MSRP消息格式傳遞消息；

舉例見SDP消息舉例

詳細瞭解CPIM消息格式，可查看我的這篇文章
https://xiaxl.blog.csdn.net/article/details/104718006

5.4、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

5.5、HTTP

超文本傳輸協議，此處不做介紹