高通ims架构android,深度揭密高通4/5G移动基带消息系统和状态机
背景
本技术分析文章通过对高通的4/5G移动基带系统进行深入逆向工程提示其内部消息通信机制以及核心架构设计逻辑，本文的研究基于高通的4G基带MDM9707以及5G基带模块sdx55的固件之上分析完成，高通基带系统现在都是基于高通主流的hexagon DSP指令架构来实现，该架构非常适合应用于音视频编解码，计算机视觉等，软件无线电等应用中的浮点和向量计算，在高通骁龙处理器的子系统中大量使用，大多应用于手机，汽车，可穿戴设备以及移动通信设备中，Hexagon DSP相关信息可以从这里获取，运行在Hexagon DSP芯片上的操作系统QuRT是由高通设计的实时操作系统，高通基带系统所有的上层业务将会运行在该操作系统之上，阅读该技术分析文章之前，假定你已经对操作系统的原理有所了解，例如CPU调度，IPC(进程间通信)，以及基本的数据队列enqueue/dequeue的操作。
消息机制简介
一个系统里面运行着不同的任务，不同任务在不同的运行状态在处理相应的业务逻辑时可能需要与其它任务交换数据或者同步信息，这里面就需要操作系统的底层IPC机制来完成了，3GPP组织定义了不同移动通信技术从物理层/链路层/逻辑处理层等各种标准，例如(5GNR/4GLTE/3G WCDMA/TD-SCDMA/CDMA2000/2G /GSM等通信技术)，这些技术标准在基带系统里面实现会被划分成不同的任务来维护不同的状态，处理不同的消息信令，以及维护不同通信技术的切换等操作，比如现在的大部分智能手机基带系统基本上都支持2/3/4G通信相关的技术，这些基带系统根据移动运营商支持的移动通信技术和国家区域支持的标准的不同会使用相应的移动通信技术，比如中国在3G时代中国移动使用的TD-SCDMA，而中国联通使用的是WCDMA技术，为了保证移动设备的一些基本功能的可用性(语音通信和sms短信息)，比如某些地方部署了4G基站，你可以在那里使用4G LTE的(Voice-over-IP/SMS-over-IP)通信技术，在一些偏远的地区可能只部署了2G基站，这时基带系统根据环境切换到GSM的协议栈，这些功能的维护与切换从基带系统层面来讲都需要系统消息机制来配合完成。
高通基带系统的消息机制建立在运行的实时操作系统QuRT之上，之前我有一篇文章有简单介绍过底层IPC机制，今天我将详细介绍上层业务逻辑相关的消息传递机制与数据结构。我们把运行在基带系统上的业务逻辑实体的最小单位定义为线程(thread)，根据线程生命周期的不同分为以下两大类：
短生命周期线程
驱动/任务初始化线程(Driver initiator/Services Launcher)
中断服务例程(IST)
长生命周期线程
阻塞型消息接受线程
消息通信底层API封装简介：
//信号发送
int rex_send_sigs(utcb *dst_task_obj,unsigned int signal_id);
//第一个参数为向目标任务发送消息的结构定义，第二个参数为要发送的信号id
int rex_wait_sigs(unsigned int recv_sigs_masks);
//第一个参数为可以允许接受信号id的掩码，每个任务最多可以设置可接受信号id个数为32个，每个任务可以接受多个信号id时，通过信号id的或操作来得到该任务可以接受信号的掩码，返回值为接受到的信号id
//如果是带数据的信号发送，封装底层API，类似如下
int send_sigs_with_dat(utcb *dst_task_obj,unsigned int signal_id,data_queue *send_data_queue);
int recv_sigs_with_dat(unsigned int recv_sigs_masks,data_queue *recv_data_queue);
而根据任务线程的业务功能的不同划分成以下几大类：
系统功能任务
通信技术协议栈分层任务
GSM/WCDMA/TDSCDMA/LTE L1/L2/L3相关的协议栈的任务等
上层应用任务
IMS volte/ecall/数据服务/包服务等
外设相关的任务
UIM/SIO/A2等
我在这里记录了高通MDM9607基带系统一次实时运行的任务快照列表。
高通基带系统消息机制
消息通信核心架构设计逻辑
兼容性
在新的基带芯片上面开发新的移动通信技术单元的同时，保证老的功能模块能够正常使用，例如在开发5G功能的同时，以往的4G/3G/2G功能都能够正常使用和切换。
可扩展性
在已有的功能模块上增加新的功能，具备灵活的扩展性，而不需要作太大的软件和硬件改动。
低耦合性
新增的功能模块与已有系统上功能模块的耦合度低，接口少，减少引入问题的接口点和测试成本。
基于以上的设计理念，高通设计一套灵活的消息通信系统，一直到现在5GNR的基带系统也在用，接下来我将详细介绍该消息系统的架构，相关的算法和数据结构。
消息通信架构
为了区分不同任务所接受到的消息以及任务所能处理相应消息的原语操作权限，通过接受到的消息来区分消息来源以及接受到相应消息后的相应的处理动作，高通的消息系统引入了任务消息接受体(msgr_client)和UMID(Unique Message ID)的机制，任务消息接受体由相应的任务创建生成，并通过初始注册可接受消息UMID来设置任务相应原语操作的权限，每个任务可以创建一个或者多个msgr_client，每一个UMID消息也可以注册给多个msgr_client，每一个UMID消息标示着一次相应的原语操作，在MDM9607里面定义的UMID数量多达1万多个，而在最新高通的5G基带里面可使用的UMID高达2万多，每个UMID背后都对应着相应的原语操作，UMID的值与相应的命名规则如下。
UMID由32位组成，结构如下表
Name
offset and length
Comment
tech_id
24~31 8bits
eg, LTE->0x04, IMS->0x15, MDM9607 0x1b, SDX55 0x20
mod_id
16~23 8bits
eg, 0xd -> RRC 0xf -> MAC 0x11-> RLC DL
type_id
8~15 8bits
type <= 0x09) || (type >= 0x11 && type <= 0x17,totally 0x11 type_ids
op_type_id
4~8 4bits
Op entity ,eg IRAT_FROM_LTE_TO_G
op_id
0~3 4bits
Opcode seq, eg abort/search/startup/deinit/init/cfg etc
注：if type_id>9 ,type_id=type_id-6
offset bit 8~15 8bits type_id list
Type_name
value
Comment
CMD
1
Command primitive
REQ
2
request
RSP
3
response
IND
4
indication
DLM
7
downlink message
CNF
8
confirm
TMR
9
timer
REQI
0x12
request Internal
RSPI
0x13
Response internal
INDI
0x14
indication internal
CNFI
0x15
confirm internal
TMRI
0x16
timer internal
举个例子UMID 0x40D120E 对应的描述原语是LTE_RRC_IRAT_FROM_LTE_TO_G_RESEL_REQI，拆分结果如下:
name
value
LTE
0x04
RRC
0x0d
REQI
0x12
RESEL
0x0
IRAT_FROM_LTE_TO_G
0x0e
注：这种UMID值的解析方法在某些定义里面并不适用，比如LTE_ML1_DLM_TST_SKIP_RACH_REQ的值为6，就没法用上面的方法解析，有些值并不严格遵循这种解析算法，可能是由于历史原因，定义UMID值的规则不一样。
基带系统把任务标示为多个不同的技术大类，来标示和模块化相应的子功能，以MDM9607为例：
tech_id
Tech_name
0
MCS(Modem Common Service)
2
MM_CM(0x201) UI(0x20a) (Unnumbered Information) MM_DOM(0x202),MM_MMOC(0x251)
4
LTE
5
FTM
6
rfa_tech (0x600 rf_fwrsp,0x603 rfgsm, 0x604 rf_1x ,0x601 0x605 rf_hdr ,0x606 rfgsm_ftm,0x607 rf_lte,0x608 rf_lte_ftm,0x60b rf_qmi, 0x60c rf_meas,0x40f/0x1a04 rf_lte ,0x120f rf_tdscdma)
7
cdma
8
hdr
9
gsm
0x0a
location(gps/gnss)
0x0b
wcdma
0x0c
ds(data service)
0x0d
1x(csfb)
0x0f
nas(0xf19 mm, 0xf1c esm)
0x10
gstk(Generic SIM Application Toolkit)
0x12
tdscdma
0x13
wms
0x15
ims
0x16
qmi