背景

本技术分析文章通过对高通的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

0x17

ecall 0x1701 ecall_app ,0x1702 ecall_ivs

0x18

policyman

0x1a

rflm

模块ID

下图是MDM9607 LTE的部分子模块ID的对应关系

tech_id+mod_id

name

0x401

ML1 MGR

0x407

LL1_SRCH

0x408

LL1_DL

0x409

LL1_UL

0x40a

LL1_SYS

0x40b

LL1_Async

0x40d

RRC

0x40f

MAC

0x411

RLC DL

0x412

RLC UL

0x413

PDCP DL

0x414

PDCP UL

0x41b

ML1_GM

0x41e

SW.app

0x420

ML1_GM_SCHDLR

0x427

TLB(Test Loop )

0x42b

ML1_GM_Sleep

0x434

ML1_AFC

0x43b

PDCP offload

0x43e

ML1 offload

0x43f

ML1 Co-existence

0x441

ML1 GM MSMGR

0x442

PDCPCOMP

0x445

ML1 SM FSCAN

关键消息发送API:

msgr_send(umsg *buf,uint32 buf_size);

struct umsg{

struct msgr_hdr_struct_type{

uint32 dest_umid; //offset 0 ，要发送的UMID号

uint16 src_tech_mod_id; //offset 4，发送源tech_mod_id的标识

uint8 num_attach;// offset 7

uint8 tail_flag ;// offset 8 ，头部结尾标志0x7f

uint8 inst_id;// offset 9，

}

uint8 send_dsm_flag;//offset 0x10 ,置1表示发送数据通过dsm结构承载的标志

dsm *dsm_obj;//offset 0x14 , 发送数据dsm结构指针

}

msgrq_wait(void *msgr_client_ptr,void *msg_recv_buf,uint32 msg_recv_buf_size,uint32 *msg_recvd_size_ptr);//接受消息的函数

msgr_register(uint16 mod_id,void *msgr_client_ptr,void *mailbox_obj,uint32 umid);//msgr_client注册umid的消息路由

消息路由

我们已经了解到UMID所对应原语操作的含义，如果需要执行相应的原语操作，只需要向注册过UMID的模块发送umid消息即可，接下来我们需要了解umid消息是如何路由到相应模块(tech_mod_id)的消息接收器(msgr_client)的，下面会详细介绍相应的算法和数据结构，我整理了几张表来描述。

map_name

map_size

key

value

value_size

Memory Attribution

techs_map

techs * 8

tech_id

module_counts, modules_map

8 bytes

Read Only

modules_map

module_counts * 0x11 * 2

(mod_id * 0x11+type_id) * 2

types_map_id

2 bytes

Read Only

types_map

types_map_ids * 0x20

types_map_id * 0x20 +(op_type_id&0x1e)

tech_mod_type_seq

2 bytes

Read/Write

umids_map

umid_seq_id * 0x8

8 * (tech_mod_type_seq+op_id)

umid, next_umid_seq_id,msgr_client_id

8 bytes

Read/Write

msgr_clients_map

0x34*total_msgr_client_counts

msgr_client_seq_id

msgr_client_desc

0x34

Read/Write

struct msgr_client_desc{ //全局msgr_client结构描述

uint32 umids_registered;

uint16 msgr_client_reg_type;//1 ->msgrq_sig type,2-> rexq_sig

uint16 tech_mod_id;//

union *msg_sig_p{ //offset 0x10

struct msgrq_sig *msgq_p;//msgr reg type 1,4G及以后使用的mailbox消息传递系统

struct rexq_sig *rexq_p;//msgr reg type 2,兼容2G/3G时代使用的Rex IPC消息传递系统

}

struct msgrq *msgrq_p;//offset 0x14 ,if reg type 1

struct msgr_client_obj *msgr_client_obj_ptr;//offset 0x30

}

struct msgr_client_obj{//msgr_client结构体

unsigned int msgr_client_reg_type;//1-> msgrq aka mailbox,2->rex_q,接受消息的方式

unsigned int register_umid_counts;//offset 8 ,消息接受器注册的umid的总数

unsigned int total_reged_recv_signal_counts;//offset 0x0c,注册的接受消息的signal的个数

union sig_recv_obj{

msgrq_sig *msgrq_signal_obj;// offset 0x10 msgrq_sig type,4/5G未来的主流类型

rexq_sig *rex_signal_obj;//offset 0x10 rexq_sig type ,这个主要是为了兼容之前2/3G的系统的数据结构

}

unsigned int task_recv_signal_set_mask;//offset 0x14 ,注册的接受消息的signal号的掩码

uint32 err_counts;//offset 0x18

unsigned int recvd_signal_id;//offset 0x1c,当前接受到的signal id,msgr_client_reg_type为1

struct msgrq *recvd_msgrq_ptr;//offset 0x20,当前接受消息承载的msgrq对象,msgr_client_reg_type为1

struct msgrq *msgrq_first_entry;// offset 0x24,接受msgrq消息链表结构指针,msgr_client_reg_type为1

unsigned int total_msgrq_counts;//offset 0x28, 可以接受msgrq消息的总数,通过可以task_recv_signal_set_mask来确定,msgr_client_reg_type为1

}

struct msgrq_sig{

uint32 sig_ready_flag;//must be 1

struct sig_def{

uint32 signal_id_for_recv;//offset 8

uint32 signal_reged_wait_mask;//offset 0xc

void * kernel_msg_queue;

unsigned int attribute;

};

}

struct rexq_sig{ //size 0x1c, 兼容2/3G系统的数据结构

utcb *msgr_client_utcb_ptr;//offset 0 任务接受消息使用的utcb标识

uint32 msgr_client_signal_id;//offset 4 接受消息使用的signal id

msg_queue *msgr_out_msg_q;//offset 0x8

msg_queue *rex_msg_in_q;//offset 0xc

uint16 msg_data_q_used_size;//offset 0x10

uint16 rexq_id;//offset 0x12

uint16 msg_data_q_size;//offset 0x14

}

struct msg_data_q{

struct msg_data_q *prev_q;

struct msg_data_q *next_q;

char data[msg_data_q_size-8];

}

struct msg_queue{

struct msg_data_q *headp;

struct msg_data_q *tailp;

uint32 total_q_counts;

}

struct msgrq{

void *msg_recv_buf_header;//offset 0

void *msg_recv_end_buf;//offset 4

char msgrq_name[16];//offset 0x10

int msgrq_recvd_seq;//ofset 0x18

unsigned int reged_recv_signal_id_mask;//offset 0x1c,可供接受消息signal的掩码

void *msgr_buf_remain_ptr;//offset 0x20,可供接受消息的剩余空间起始地址

void *msgr_recv_buf;//offset 0x24,当前接受到消息的buf地址

uint32 msgr_buf_remain_size;//offset 0x28

unsigned int total_msg_recv_buf_size;//offset 0x30

int8 is_buf_in_use;//offset 0x70 ,0-> in use, 1-> not in use

uint32 recvd_msg_blocks;//offset 0x58 ,收到的消息次数总和

struct msgrq *next_msgrq;//offset 0x74

}

为了更方便的理解上述的数据结构的关系与操作算法，画了一张简单的图来加深该消息系统的理解。

通过以上算法和数据结构，可以很方便的完成UMID与tech_mod_id的消息路由的注册，消息发送等操作。

需要说明的一点就是一个tech_mod_id可能会关联多个msgr_client，所以msgr_client_id就成了消息传递的唯一标识，通过msgr_client_id得到全局的msgr_client_desc的结构定义，该结构体里面包含接受消息的任务utcb和接受消息的signal id，这里通过tech_mod_id 0xf19对应的MM(Mobility Management)任务进行举例。

我在一个实时运行的MDM9607系统上面，描绘出所有UMID和tech_mod_id之间的消息路由情况，由于实在太大，

可以在https://github.com/vessial/baseband/blob/master/umid_pro.svg 进行查看。

消息状态机(State Machine)

高通基带系统里面的消息状态机，是实现3GPP定义功能最重要的组成部分，消息状态机在移动通信系统里面扮演着非常重要的角色，也是多模移动通信系统的核心，3GPP在定义的多个移动通信技术的分层协议栈时，不同的通信技术模式之间切换，会通过状态机来维护相应的分层逻辑的状态和可操作功能，接下来将重要介绍高通基带系统使用的状态机数据结构以及相关算法，本文将研究主要流4G LTE和5G NR系统上使用的第二代状态机消息系统，老的第一代状态机系统不在这里介绍了。

struct sm_state_instance{ //eg ,size 0x1c

struct sm_obj *sm;//状态机对象定义

unsigned int current_state_id;//状态机当前所处的状态id

unsigned int recvd_umid_in_sm_entity_seq;//offset 8, 状态机当前收到的umid所在状态机umid列表中的序列号

unsigned int instance_id;// 状态机实例编号

uint8 sm_state_lock;//offset 0x11 0->state unlock,1-> state lock 状态机锁的状态

void *stm_idle_buf;//offset 0x14 状态机操作可能需要的buf空间

unsigned int debug_code;//offset 0x18 状态机调试码

}

struct sm_obj{ //状态机的定义结构

struct msgr_stm_obj *stm;

unsigned char *stm_obj_name; //状态机的名称，例如LTE_RRC_SIB_SM

unsigned int stm_obj_name_hash; //状态机名称的hash值

unsigned int stm_inst_id;//stm instance id ，状态机的实例编号，状态机可能存在多个实例，通过这个编号来区别不同的状态机实体

}

struct msgr_stm_obj {

int instance_counts; //该状态机支持的实例个数

int state_cnts; //该状态机的状态数量

struct state_status_def *state_def;//状态机每个不同状态的定义的数据结构,size state_cnts*0x10

int umid_cnts;//状态机注册的可接受umid总数

struct umid_msg_list *umid_msg_def;//存储umid和umid描述信息的指针,size umid_cnts*8

struct umid_msg_states_func_cb_list *umid_in_state_cb;//存储着所有umid对应每个状态的回调操作函数

void *cb_func1;// stm enter //offset 0x18 ,进入该状态机的回调函数

void *cb_func2;// stm exit //offset 0x1c ,退出该状态机的回调函数

void *cb_func3;// stm error //offset 0x20 ,状态机出错的回调函数

void *cb_func4; //stm debug //offset 0x24 ,状态机调试的回调函数

unsigned int init_state_id; // default 0 ,状态机初始默认状态id

}

struct umid_msg_states_func_cb_list {//状态机在接受到相应的umid后的原语操作回调函数

void *umid_msg_in_states_1_cb_list[umid_cnts];

void *umid_msg_in_states_2_cb_list[umid_cnts];

void *umid_msg_in_states_3_cb_list[umid_cnts];

...

void *umid_msg_in_states_state_cnts_cb_list[umid_cnts];

}

struct state_status_def{//每个状态的定义

unsigned char *state_name; //状态名称，eg,active/inactive etc

void *cb_func1; //state enter //状态机进入该状态的回调函数

void *cb_func2; //state exit //状态机退出该状态的回调函数

void *cb_func3; //state debug ?//可能是调试函数

}

struct umid_msg_list{//状态机可接受的umid消息定义

unsigned char *umid_msg_name; //umid对应的描述名称

unsigned int umid; //umid

}

关键API描述

stm_instance_activate(struct sm_state_instance *sm_st_inst,uint32 inst_id,uint32 initial_state_id);//初始化状态机实例

stm_instance_process_input(uint32 state_id,struct sm_state_instance *sm_st_inst,uint32 sm_inst_id,uint32 umid_input,void *stm_payload_ptr);//对状态机接受到的umid和数据进行原语操作

我从MDM9607固件里面提取的详细的状态机信息可以在https://github.com/vessial/baseband/blob/master/lte_sm.log 进行查看。

3GPP定义的L3层的RRC(Radio Resource Control)的状态机是最为复杂的，高通在实现4G LTE的RRC时使用了大量的状态机进行功能管理。

MDM9607 4G LTE RRC状态机类型如下:

state name: LTE_RRC_CSG_ASF_SM

state name: LTE_RRC_DT_SM //

state name: LTE_RRC_IRAT_TO_G_MGR_SM

state name: LTE_RRC_LLC_SM

state name: LTE_RRC_CAPABILITIES_SM

state name: LTE_RRC_IRAT_FROM_1X_MGR_SM

state name: LTE_RRC_SEC_SM //sim认证和密钥协商管理相关的状态机

state name: LTE_RRC_CRP_SM

state name: LTE_RRC_IRAT_FROM_DO_MGR_SM //负责从CDMA-EVDO切换到LTE的管理状态机

state name: LTE_RRC_IRAT_FROM_TDS_MGR_SM //负责从TDSCDMA切换到LTE的状态机

state name: LTE_RRC_PAGING_SM //寻呼管理的状态机

state name: LTE_RRC_CONFIG_SM

state name: LTE_RRC_MISC_SM

state name: LTE_RRC_MEAS_SM

state name: LTE_RRC_CEP_SM

state name: LTE_RRC_IRAT_TO_1X_MGR_SM

state name: LTE_RRC_IRAT_FROM_W_MGR_SM

state name: LTE_RRC_MDT_SM

state name: LTE_RRC_IRAT_TO_DO_MGR_SM

state name: LTE_RRC_CONTROLLER_SM //关键的LTE的控制状态机，控制服务的停止和开启

state name: LTE_RRC_IRAT_TO_TDS_MGR_SM

state name: LTE_RRC_IRAT_TO_W_MGR_SM //从LTE切换到WCDMA的管理状态机

state name: LTE_RRC_EMP_SM

state name: LTE_RRC_MH_SM

state name: LTE_RRC_UEINFO_SM //UE信息管理的状态机

state name: LTE_RRC_SIB_SM //系统信息块的管理状态机

state name: LTE_RRC_PLMN_SEARCH_SM //搜索网络使用的状态机

state name: LTE_RRC_IRAT_FROM_G_MGR_SM //从GSM切换到LTE的状态机

state name: LTE_RRC_CSP_SM //cell search plmn状态机

state name: LTE_RRC_ESMGR_SM // EMBMS管理状态机

state name: LTE_RRC_CRE_SM

我们拿LTE_RRC_PAGING_SM状态机定义作例子与之对应的数据结构作解析

LTE_RRC_PAGING_SM addr 0xd10b35e0

state machine name: LTE_RRC_PAGING_SM inst_cnts 1 total states 3 total umid 10

state name: INITIAL state enter 0xd0b923a8 state exit 0xd0b923c8 state debug 0x0

state name: IDLE_CAMPED state enter 0xd0b923e0 state exit 0xd0b92400 state debug 0x0

state name: CONNECTED state enter 0xd0b92418 state exit 0xd0b92450 state debug 0x0

0x040d140c LTE_RRC_CAMPED_INDI

0x040d0207 LTE_RRC_DRX_INFO_REQ

0x040d0206 LTE_RRC_SIM_UPDATE_REQ

0x040d0401 LTE_RRC_SERVICE_IND

0x040d0710 LTE_RRC_PAGING_DLM

0x040d1405 LTE_RRC_CONNECTED_INDI

0x040d022a LTE_RRC_MTC_CFG_REQ

0x040d1400 LTE_RRC_STOPPED_INDI

0x040d140b LTE_RRC_NOT_CAMPED_INDI

0x040d1402 LTE_RRC_SIB_UPDATED_INDI

下图为MDM9607 4G LTE_RRC的状态机图谱

状态机操作实例

为了更直观的理解消息状态机的操作过程，我这里提供了一个例子来展示消息传递过程以及状态机的处理过程，这个过程是在基带处于IDLE状态下，没有接入任何移动通信网络，到基带一次接入4G LTE网络到SIM认证的过程，这里只提供RRC的状态机的处理过程。

发送端

接受端

接受UMID号

处理状态机

描述信息

0xF19 emm

LTE_RRC

0x40d0204

LTE_RRC_CSP_SM

LTE_RRC_SERVICE_REQ

0xF19 emm

LTE_RRC

0x40d0204

LTE_RRC_IRAT_FROM_W_MGR_SM

LTE_RRC_SERVICE_REQ

0xF19 emm

LTE_RRC

0x40d0204

LTE_RRC_IRAT_FROM_G_MGR_SM

LTE_RRC_SERVICE_REQ

0xF19 emm

LTE_RRC

0x40d0204

LTE_RRC_IRAT_FROM_TDS_MGR_SM

LTE_RRC_SERVICE_REQ

0x40d LTE_RRC

LTE_RRC

0x40d1442

LTE_RRC_MEAS_SM

LTE_RRC_CLEAR_DEPRI_FREQ_INDI

0x40d LTE_RRC

LTE_RRC

0x40d120d

LTE_RRC_CONTROLLER_SM

LTE_RRC_MODE_CHANGE_REQI

0x40f LTE_MAC

LTE_RRC

0x40f0803

LTE_RRC_CONTROLLER_SM

LTE_MAC_START_CNF

0x412 LTE_RLCUL

LTE_RRC

0x4120801

LTE_RRC_CONTROLLER_SM

LTE_RLCUL_START_CNF

0x411 LTE_RLCDL

LTE_RRC

0x4110801

LTE_RRC_CONTROLLER_SM

LTE_RLCDL_START_CNF

0x413 LTE_PDCPDL

LTE_RRC

0x4130806

LTE_RRC_CONTROLLER_SM

LTE_PDCPDL_START_CNF

0x414 LTE_PDCPUL

LTE_RRC

0x4140807

LTE_RRC_CONTROLLER_SM

LTE_PDCPUL_START_CNF

0x40c LTE_ML1_MGR

LTE_RRC

0x40c0801

LTE_RRC_CONTROLLER_SM

LTE_CPHY_START_CNF

0x40d LTE_RRC

LTE_RRC

0x40d1513

LTE_RRC_CSP_SM

LTE_RRC_MODE_CHANGE_CNFI

0x40d LTE_RRC

LTE_RRC

0x40d1206

LTE_RRC_LLC_SM

LTE_RRC_CFG_REQI

0x40c LTE_ML1_MGR

LTE_RRC

0x40c0809

LTE_RRC_CSP_SM

LTE_CPHY_SYSTEM_SCAN_CNF

0x40d LTE_RRC

LTE_RRC

0x40d1206

LTE_RRC_LLC_SM

LTE_RRC_CFG_REQI

0x40c LTE_ML1_MGR

LTE_RRC

0x40c0800

LTE_RRC_CSP_SM

LTE_CPHY_ACQ_CNF

0x40d LTE_RRC

LTE_RRC

0x40d1202

LTE_RRC_SIB_SM

LTE_RRC_GET_SIBS_REQI

0x403 LTE_ML1_DLM

LTE_RRC

0x40c0402

LTE_RRC_SIB_SM

LTE_CPHY_MIB_IND

0x40F LTE_MAC

LTE_RRC

0x40f0406

LTE_RRC_SIB_SM

LTE_MAC_RRC_BCCH_DL_DATA_IND

BCCH DL SCH SIB1

0x40c LTE_ML1_MGR

LTE_RRC

0x40c0823

LTE_RRC_SIB_SM

LTE_CPHY_TDD_CFG_CNF

0x40F LTE_MAC

LTE_RRC

0x40f0406

LTE_RRC_SIB_SM

LTE_MAC_RRC_BCCH_DL_DATA_IND

BCCH DL SCH SI

0x40d LTE_RRC

LTE_RRC

0x40d1514

LTE_RRC_CSP_SM

LTE_RRC_GET_SIBS_CNFI

0x40F LTE_MAC

LTE_RRC

0x40f0406

LTE_RRC_SIB_SM

LTE_MAC_RRC_BCCH_DL_DATA_IND

BCCH DL SCH SIB1

0x40c LTE_ML1_MGR

LTE_RRC

0x40c080a

LTE_RRC_CSP_SM

LTE_CPHY_CELL_SELECT_CNF

0x40d LTE_RRC

LTE_RRC

0x40d1206

LTE_RRC_LLC_SM

LTE_RRC_CFG_REQI

0x40c LTE_ML1_MGR

LTE_RRC

0x40c0804

LTE_RRC_LLC_SM

LTE_CPHY_COMMON_CFG_CNF

0x40c LTE_ML1_MGR

LTE_RRC

0x40c0805

LTE_RRC_LLC_SM

LTE_CPHY_DEDICATED_CFG_CNF

0x40f LTE_MAC

LTE_RRC

0x40f0801

LTE_RRC_LLC_SM

LTE_MAC_CFG_CNF

0x40d LTE_RRC

LTE_RRC

0x40d1516

LTE_RRC_CSP_SM

LTE_RRC_CFG_CNFI

0x40d LTE_RRC

LTE_RRC

0x40d140c

LTE_RRC_SIB_SM

LTE_RRC_CAMPED_INDI

inactive

0x40d LTE_RRC

LTE_RRC

0x40d140c

LTE_RRC_SIB_SM

LTE_RRC_CAMPED_INDI

active

0x40d LTE_RRC

LTE_RRC

0x40d140c

LTE_RRC_MEAS_SM

LTE_RRC_CAMPED_INDI

0x40d LTE_RRC

LTE_RRC

0x40d140c

LTE_RRC_CAPABILITIES_SM

LTE_RRC_CAMPED_INDI

0x40d LTE_RRC

LTE_RRC

0x40d140c

LTE_RRC_CEP_SM

LTE_RRC_CAMPED_INDI

0x40d LTE_RRC

LTE_RRC

0x40d140c

LTE_RRC_MISC_SM

LTE_RRC_CAMPED_INDI

0x40d LTE_RRC

LTE_RRC

0x40d1516

LTE_RRC_CONTROLLER_SM

LTE_RRC_CFG_CNFI

0x40d LTE_RRC

LTE_RRC

0x40d1402

LTE_RRC_CSP_SM

LTE_RRC_SIB_UPDATED_INDI

0x40d LTE_RRC

LTE_RRC

0x40d1402

LTE_RRC_CEP_SM

LTE_RRC_SIB_UPDATED_INDI

0x40d LTE_RRC

LTE_RRC

0x40d1402

LTE_RRC_PAGING_SM

LTE_RRC_SIB_UPDATED_INDI

0x40d LTE_RRC

LTE_RRC

0x40d1402

LTE_RRC_MEAS_SM

LTE_RRC_SIB_UPDATED_INDI

0x40d LTE_RRC

LTE_RRC

0x40d1402

LTE_RRC_CSG_ASF_SM

LTE_RRC_SIB_UPDATED_INDI

0x40d LTE_RRC

LTE_RRC

0x40d1402

LTE_RRC_IRAT_TO_G_MGR_SM

LTE_RRC_SIB_UPDATED_INDI

0x40d LTE_RRC

LTE_RRC

0x40d1402

LTE_RRC_IRAT_TO_TDS_MGR_SM

LTE_RRC_SIB_UPDATED_INDI

0x40d LTE_RRC

LTE_RRC

0x40D0401

LTE_RRC_CSG_ASF_SM

LTE_RRC_SERVICE_IND

0x40d LTE_RRC

LTE_RRC

0x40D0401

LTE_RRC_PAGING_SM

LTE_RRC_SERVICE_IND

0x40c LTE_ML1_MGR

LTE_RRC

0x40c0815

LTE_RRC_MEAS_SM

LTE_CPHY_IDLE_MEAS_CFG_CNF

0x40d LTE_RRC

LTE_RRC

0x40d0225

LTE_RRC_CSP_SM

LTE_RRC_AVOIDANCE_REQ

0x40F LTE_MAC

LTE_RRC

0x40f0406

LTE_RRC_SIB_SM

LTE_MAC_RRC_BCCH_DL_DATA_IND

SI

0x40d LTE_RRC

LTE_RRC

0x40d1437

LTE_RRC_CSP_SM

LTE_RRC_INTERFREQ_LIST_UPDATE_INDI

0xf19 EMM

LTE_RRC

0x40d0200

LTE_RRC_CEP_SM

LTE_RRC_CONN_EST_REQ

Attach Request NAS msg

0x40d LTE_RRC

LTE_RRC

0x40D1404

LTE_RRC_CONTROLLER_SM

LTE_RRC_CONN_ESTABLISHMENT_STARTED_INDI

RRC Connection Request

0x40d LTE_RRC

LTE_RRC

0x40D143d

LTE_RRC_CONTROLLER_SM

LTE_RRC_TRM_PRIORITY_CHANGE_INDI

0xF19 EMM

LTE_RRC

0x40d0206

LTE_RRC_CONTROLLER_SM

LTE_RRC_SIM_UPDATE_REQ

0xF19 EMM

LTE_RRC

0x40d0206

LTE_RRC_PAGING_SM

LTE_RRC_SIM_UPDATE_REQ

0xF19 EMM

LTE_RRC

0x40d0206

LTE_RRC_SEC_SM

LTE_RRC_SIM_UPDATE_REQ

SIM Update Req received from NAS

0xF19 EMM

LTE_RRC

0x40d0206

LTE_RRC_CAPABILITIES_SM

LTE_RRC_SIM_UPDATE_REQ

0x404 LTE_ML1_ULM

LTE_RRC

0x40c0421

LTE_RRC_CEP_SM

LTE_CPHY_RACH_MSG1_SCHED_IND

LTE MAC RACH Attempt

0x40f LTE_MAC

LTE_RRC

0x40f0800

LTE_RRC_CEP_SM

LTE_MAC_ACCESS_CNF

0x40f LTE_MAC

LTE_RRC

0x40f0405

LTE_RRC_MH_SM

LTE_MAC_RRC_CCCH_DL_DATA_IND

CCCH RRC Connection Setup

0x40d LTE_RRC

LTE_RRC

0x40d0703

LTE_RRC_CEP_SM

LTE_RRC_RRC_CONNECTION_SETUP_DLM

CCCH RRC Connection Setup

0x40d LTE_RRC

LTE_RRC

0x40d1206

LTE_RRC_LLC_SM

LTE_RRC_CFG_REQI

0x40d LTE_RRC

LTE_RRC

0x40D1408

LTE_RRC_CSP_SM

LTE_RRC_PROCEED_WITH_RESEL_INDI

0x411 LTE_RLCDL

LTE_RRC

0x4110800

LTE_RRC_LLC_SM

LTE_RLCDL_CFG_CNF

0x412 LTE_RLCUL

LTE_RRC

0x4120800

LTE_RRC_LLC_SM

LTE_RLCUL_CFG_CNF

0x413 LTE_PDCPDL

LTE_RRC

0x4130800

LTE_RRC_LLC_SM

LTE_PDCPDL_CFG_CNF

0x414 LTE_PDCPUL

LTE_RRC

0x4140800

LTE_RRC_LLC_SM

LTE_PDCPUL_CFG_CNF

0x40d LTE_RRC

LTE_RRC

0x40d1516

LTE_RRC_CEP_SM

LTE_RRC_CFG_CNFI

0x40d LTE_RRC

LTE_RRC

0x40d1200

LTE_RRC_MH_SM

LTE_RRC_SEND_UL_MSG_REQI

0x40d LTE_RRC

LTE_RRC

0x40d1405

LTE_RRC_SIB_SM

LTE_RRC_CONNECTED_INDI

0x414 LTE_PDCPUL

LTE_RRC

0x4140802

LTE_RRC_MH_SM

LTE_PDCPUL_SDU_CNF

0x40d LTE_RRC

LTE_RRC

0x40d1504

LTE_RRC_CEP_SM

LTE_RRC_RRC_CONNECTION_SETUP_COMPLETE_CNFI

UL_DCCH RRC connection Setup Complete

0x413 LTE_PDCPDL

LTE_RRC

0x4130400

LTE_RRC_MH_SM

LTE_PDCPDL_SDU_IND

DL_DCCH info Transfer

0x40d LTE_RRC

LTE_RRC

0x40d0705

LTE_RRC_DT_SM

LTE_RRC_DL_INFORMATION_TRANSFER_DLM

DL_DCCH Auth Request Msg recvd

0x40d LTE_RRC

LTE_RRC

0x40d141f

LTE_RRC_MH_SM

LTE_RRC_DLM_PROCESSED_INDI

0xF19 EMM

LTE_RRC

0x40d0201

LTE_RRC_DT_SM

LTE_RRC_UL_DATA_REQ

send Auth Resp data

0x40d LTE_RRC

LTE_RRC

0x40d1200

LTE_RRC_MH_SM

LTE_RRC_SEND_UL_MSG_REQI

UL_DCCH ULinfo Transfer send NAS Auth resp

0x414 LTE_PDCPUL

LTE_RRC

0x4140802

LTE_RRC_MH_SM

LTE_PDCPUL_SDU_CNF

0x40d LTE_RRC

LTE_RRC

0x40d1509

LTE_RRC_DT_SM

LTE_RRC_UL_INFORMATION_TRANSFER_CNFI

DL_DCCH的Information Transfer字段里面包含了来自MME发送过来的认证请求数据(LTE NAS EMM信令消息id 0x52)，包含有nas key set id,

16个字节的认证随机数据auth_param rand，以及16个字节的auth param AUTN数据，SIM卡通过收到的这两个关键信息进行认证，

并计算生成Auth_resp发送给MME进行比较完成本地端和服务器端的认证，本地端计算如下。

本地端收到的rand(16bytes)+AUTN(16bytes)

K为sim卡和MME都持有的sim卡的唯一隐私数据，sim卡端只有sim卡芯片可以读取。

SIM卡端密钥派生认证过程，f1/2/3/4/5为sim卡的计算功能函数

AK=f5(K,rand)

IK=f4(K,rand)

CK=f3(K,rand)

RES=f2(K,rand) //计算给MME进行认证SIM卡的数据

SQN=AUTN^AK (6bytes)

AMF=AUTN[6:8]

MAC=f1(K,SQN,rand,AMF)

SIM卡端认证MME端过程

sim_autn=SQN^AK(6bytes)+AMF(2bytes)+MAC(8bytes)

比较MME发过来的AUTN和sim_autn ，相等则认为MME合法。

基带把sim卡计算得到的RES通过LTE NAS EMM 信令消息号0x53包裹到UL_DCCH的InformationTransfer字段里面发给基站进而到MME进行认证。

MME认证SIM卡的过程就比较简单了，

MME端计算XRES=f2(K,rand)，然后比较收到的RES，相等表示MME认证SIM卡成功，至此认证完成。

由于上述操作涉及EMM和RRC之间的交互过程比较复杂，这里只是简单提一下，EMM的状态机会在下一篇文章里面单独详细介绍。

结语

由于从全球公开的信息渠道中并不能获取高通基带系统的深入信息，所以花费1年多的时间通过对底层操作系统和上层3GPP实现的业务系统进行深度逆向工程，这篇文章只是系统性的介绍了高通4/5G基带系统的消息机制和消息状态机，我认为这是一个关键的架构设计，梳理清楚其消息架构对于理解3GPP实现的消息原语操作以及对移动通信技术的多模分层设计有非常大的帮助，该消息系统架构设计具有非常好的扩展性，可以很灵活的增加新的功能到该消息框架中去，可以很好的减少系统测试成本，有很多设计理念值得学习和借鉴，由于现今高通5G基带所支持的UMID操作数高达2万多个，所以这里的展示的例子只是揭示了状态机功能操作的冰山一角，后续会持续研究对于状态机安全漏洞的挖掘研究，实现高效的5G安全测试体系，通过对基带系统的深刻认知，可以更好的对基站系统和核心网系统进行安全评估。

最后行文仓促，如有错误，欢迎反馈指正，预告下一章节将会介绍高通基带系统的A2/IPA硬件IP加速功能模块。

本文由 Seebug Paper 发布，如需转载请注明来源。本文地址：https://paper.seebug.org/1555/