OTA简单介绍

转载baidu文库

参考文档：IS_95B协议，683协议, 80-V0223-1_X3_ota

OTA是Over The Air的简称，也就是我们通常所说的空中接口。由发起方来分类，可以分成OTASP与OTAPA。其中：OTASP是Over
the air service provisioning的简称，由用户端发起，通过拨打Activation code：*228,*22800(800M A
系统),*22801（800M B系统）来执行。OTAPA是Over the air parameter administration的简称，由网络端发起，用户并不知晓。

OTA的主要功能是下载NAM Parameter（号码分配模块）与PRL List（优先漫游列表），而且更多的应用是用于下载PRL。

这里简要的介绍一下NAM参数：
NAM:
号码分配模块，每一个NAM是一些独立的网络参数的集合，MS正是依赖这些参数来接入网络。卡中只有一个NAM，NV中最大可以支持4个NAM，一般是2个NAM。
NAM参数有：
IMSI：国际移动站标识，15位10进制数表示，由MCC,MNC,MIN组成。
MCC:
移动国家码码，3位10进制数表示，IMSI的最高3位，占10bit内存，存储在NV_IMSI_MCC_I中
MNC:
移动网络码，2位10进制数表示，IMSI的第11，12位，占7bit内存，存储在
NV_IMSI_11_12_I中
MIN:
移动标识号码：是IMSI的最低10位，分成MIN2(高3位)，MIN1（低7位）。MIN2存储在NV_MIN2_I中，占10bit，MIN1存储在NV_MIN1_I中，占34bit
SPC: Service Programming Code。安全密码，用于控制NAM参数的修改。如果要修改NAM参数，则必须先通过SPC验证。6位10进制数，范围从000000到999999，存储在NV_SEC_CODE_I中
SPASM：Subscriber Parameter Administration Security Mechanism。是用来防止NAM值被未经认证的网络修改的安全机制。
A_KEY:用于鉴权的输入，存储在NV_A_KEY_I中
A_KEY Checksum：在写A_KEY的时候需要输入26位的十进制数，前20位是A_KEY，后6位是CHECK
SUM，MS 先用A_KEY通过CAVE算法算出一个CHECK SUM跟输入的比较，如果相同则写允许写NV
ESN:
电子序列号，手机出厂时的序列号，也用于鉴权，存放在NV_ESN_I中
UIM_ID：卡的ID。有卡版本把UIM_ID做为ESN号码。
NAME：可以用来存放运营商的名字
SSD（Shared Secret Data）：当需要鉴权的时候，网络端发送随机数跟SSD过来，MS通过A_KEY,ESN,MIN，随机数产生SSD跟网络端发过来的SSD比较，如果相同则鉴权通过
MDN:用来存放电话号码，存储在NV_DIR_NUMBER_I
SID:系统标识，当前系统的系统标识，是一个动态变化的值，通过跟手机里面存储的Home SID,NID对进行比较，用来判断是不是漫游
NID:网络标识，也是一个动态变化的值，从当前捕获的系统中得到
HOME SID REG：是否允许网内SID漫游
FOR SID REG：是否允许网外SID漫游
FOR NID REG：是否允许网外NID漫游
HOME SID NID PAIR：20对，存放在NV_SID_NID_LIST_I中

PRL:漫游优先列表，在搜索系统中用到，可以通过QPST工具或者OTA更新。
PRL Enable：用来标识搜网时是用PRL还是用系统默认的表，存放在NV_PRL_ENABLED_I

下面时关于OTA流程的一些简要介绍：
•
OTASP (user-initiated OTA activation)
– NAM parameter download (IMSI, MDN)
– Preferred Roaming List (PRL) download
– Service Programming Lock download
–
A-Key exchange

•
OTAPA (network-initiated OTA activation)
– New with IS-683A
– Supported in DMSS 3100 Release 2.0 and later
– Existing standard OTASP capability
– Service Programming without user intervention
– NAM lock

OTASP的工作流程如下：

用户拨打Activation code：（*FC + XX + SEND）发起呼叫。
其中*FC是Feature Code（*228或*act），标识发起的是一个OTA
call
xx是System Selection Code，00指800 MHz,
A-Band，01指800 MHz, B-Band
（关于Activation code详细的说明见IS683 3.2.1）

建立call连接以后，MS与基站通过Data Burst来通讯：

基站给MS发送Request消息要求MS执行某种操作
然后MS回给基站Response消息告诉基站操作的结果：
Request消息的类型有下面几种：
–
OTASP_CONFIG_REQ_MSG：读取NAM参数配置
–
OTASP_DOWNLOAD_REQ_MSG：下载NAM参数到一个临时的存储器中
–
OTASP_MS_KEY_REQ_MSG：更新A_KEY

–
OTASP_KEY_GEN_REQ_MSG：产生SSD
–
OTASP_REAUTH_REQ_MSG：重新鉴权
–
OTASP_COMMIT_REQ_MSG：把临时存储器中的NAM参数写到NV里面去
–
OTASP_PROT_CAP_REQ_MSG：MS支持哪些OTA业务
–
OTASP_SSPR_CONFIG_REQ_MSG：读取PRL配置
–
OTASP_SSPR_DOWNLOAD_REQ_MSG：下载PRL到一个临时的存储器中
–
OTASP_VALIDATION_REQ_MSG：验证（包括SPC,SPASM）
–
OTASP_OTAPA_REQ_MSG：OTAPA业务

对应的Response消息类型有：
–
OTASP_CONFIG_RSP_MSG
–
OTASP_DOWNLOAD_RSP_MSG
–
OTASP_MS_KEY_RSP_MSG
–
OTASP_KEY_GEN_RSP_MSG
–
OTASP_REAUTH_RSP_MSG
–
OTASP_COMMIT_RSP_MSG
–
OTASP_PROT_CAP_RSP_MSG
–
OTASP_SSPR_CONFIG_RSP_MSG
–
OTASP_SSPR_DOWNLOAD_RSP_MSG
–
OTASP_VALIDATION_RSP_MSG
–
OTASP_OTAPA_RSP_MSG

下面通过一个PRL下载的例子来说明一下流程：
我们假定用户拨了*22800，OTASP CALL已经建立好了，这时候CDMA状态处于Convation状态：
首先，基站想知道MS支持哪些OTA function，它发了一个Protocol Capability Request:

然后MS处理这条Data burst短信，返回一个Protocol Capability Response告诉基站它支持下面这些OTA
业务

因为Feature包含了Service Programming Lock，所以需要验证SPC，于是基站发送Validation
Request给MS,并给出SPC=0看看是否跟手机当中的SPC匹配

MS验证SPC以后，回复Validation Response给基站,告诉基站验证成功

基站想知道MS支持的最大PRL长度是多少，于是发送SSPR Configuration Request读取MS中PRL
长度的配置：

MS返回SSPR Configuration Resonse消息告诉基站它支持的PRL最大长度为3k，当前的PRL长度为3067，PRL
Version为0

然后开始下载PRL到临时的存储器中，由于PRL表比较大，所以需要分段下载，segment_offset告诉MS偏移首地址多少开始存储，由于刚开始，所以值为0,Segment_size告诉MS这一段PRL的大小。Last_segment标识是不是最后一个PRL段。

MS返回存储的结果，告诉基站存储成功

其他的段重复上面的过程。

我们看一下最后两段的SSPR Download Request:

last_segment =1标识最后一段已经收到，整个PRL download结束

然后基站给MS发送Commit Request，要求把临时存储器里面的PRL表写到NV/RUIM中去：

MS处理Commit Request消息，存储完毕，告诉基站PRL写入成功

这时候整个PRL下载过程就结束了。

支持OTA需要打开的宏：

我们自己定义的宏：

LT_DIAMOND_UI_OTASP

部分代码如下：

在CALL建立好以后，cdma的MAIN STATE处于CDMA_TC(mccdma.c里面的mcc_subtask)的CDMA_CONV子状态，这时候收到一条Data
burst消息，调用tc_conv_msg（mcctc.c）函数进行处理。

switch (msg_ptr->msg.gen.msg_type)

{

case
CAI_TC_REV_BURST_MSG:/*Data burst type*/

next_state =
process_tc_data_burst( &msg_ptr->msg, next_state );

break;

}

在process_tc_data_burst（mcctcsup.c）函数中因为收到的是OTA消息

if (msg_ptr->tc_burst.burst_type ==
CAI_OTA_ACTIVATION)

调用otaspx_ext_to_int把消息转化成otasp的消息类型

typedef union

{

otaspi_gen_msg_type gen;

otaspi_config_req_msg_type config_req; /* Configuration Request */

otaspi_download_req_msg_type dload_req; /* Download Request */

otaspi_commit_req_msg_type commit_req; /* Commit Request */

otaspi_reauth_req_msg_type reauth_req; /* Re-Authenticate Request */

otaspi_ms_key_req_msg_type ms_key_req; /* MS Key Request */

otaspi_key_gen_req_msg_type key_gen_req; /* Key Generation Request */

otaspi_prot_cap_req_msg_type prot_cap_req; /* Protocol Capability Request */

otaspi_sspr_cfg_req_msg_type sspr_cfg_req; /* SSPR Config Request */

otaspi_sspr_dload_req_msg_type sspr_dload_req; /* SSPR Download Request */

otaspi_validation_req_msg_type validn_req; /* Validation Request */

otaspi_otapa_req_msg_type otapa_req; /* OTAPA Request */

} otaspi_ftc_msg_type;

gen表示Request消息的类型，消息实体放入对应类型的块

转化成功以后再调用otasp_process_msg(otasp.c)处理具体的消息

switch (otasp_msg_ptr->gen.msg_type)

{

case
OTASP_CONFIG_REQ_MSG:

process_config_req (&otasp_msg_ptr->config_req);

break;

case
OTASP_DOWNLOAD_REQ_MSG:

next_state = process_dload_req (&otasp_msg_ptr->dload_req);

break;

…

}

otasp与otapa最终执行的操作都在这个函数里。有兴趣的同事可以直接在这里（otasp.c）开始看OTA对不同类型消息的处理过程。这些代码由于我也是刚开始学习，不是很熟悉，准备下次再介绍。

另外，关于OTASP的一些UI的提示。

1：提示”Programming need initial”。在当前使用nam的MIN值没有被写过的情况下，需要在开机的时候提示用户。

在uisstrt.c中处理。

Uistate_startup()

case INIT_S:中有很大一段代码是对NAM一些参数合法性的验证，如果超出范围，就整个NAM初始化掉。在读出MIN1或者MIN2的时候，如果ui_get_nv返回的状态是NV_NOTACTIVE_S,我们就在这里置一个标志，然后在进入idling的时候弹出pop框提示

2：在用户拨打*228,*22800,*22801的时候，需要在通话界面显示

Searching。。。

Activation

OTASP

在ui_call_show_outgoing_call（）中处理，画界面

3:：在通话中，显示Programming in Progress

在ui_call_show_conversation（）中处理，画界面

3：OTASP完成以后，显示根据结果显示Programming Successful或者

Programming Unsuccessful

在ui_call_show_release_call（）处理，画界面

4：OTASP/OTAPA结束以后，需要beep 3
声。

在end_conversation()中处理，设了一个400ms的定时器

#ifdef LT_DIAMOND_UI_OTASP

/* OTASP ending tone */

if ( ISOTASP(curr_call.cm_info.call_type) )

{

ota_beep_time = 1;

ui_menutimer_set((int4)400);

}

#endif /* LT_DIAMOND_UI_OTASP */

然后在call_end_disp_mode_event（）中对timer事件进行处理

#ifdef LT_DIAMOND_UI_OTASP

case UI_MENUTIMER_F:

if(ota_beep_time < 3)

{

ota_beep_time ++;

uisnd_tone( UI_EARBEEP_SND, SND_TIME, 200 );

ui_menutimer_set((int4)400);

}

#endif /* LT_DIAMOND_UI_OTASP */

OTAPA的流程跟OTASP类似，只是不需要UI的提示，因为OTAPA是网络端发起的，用户并不知道，所以在执行OTAPA操作的时候，不需要做UI处理。

OTA相关可能使用到的工具有：

QPST，QXDM

QXDM用来查看一些NAM项的内容

QPST--àRoam--àSave to file
得到 *****.qcn打开可以查看PRL的信息

这里介绍的只是OTA处理的一个大体框架，细节方面我会慢慢完善进去，因为刚接触OTA，难免有一些理解上面的错误，欢迎指正，谢谢