几天和一个朋友聊到这个话题。问题就是CC信令里Emergency Setup里为什么没有表示紧急呼叫中心的紧急号码？
众所周知，每个国家的紧急号码都大相径庭。同一个号码可能在某国是匪警，换做其他国家就是火警。所以需要一个标识来告诉MSC/MME这通紧急呼叫需要转给哪个紧急呼叫中心，会有如下前5种的公安紧急呼叫中心，医疗救护中心，公安消防中心，海岸救援中心，山地救护中心。
而这个标识就叫做emergency category/service category，有的协议规范里也会称作emergency call type。通常来说，一个紧急号码会对应一到多个emergency category，例如112在意大利既是火警也是匪警，而在瑞典则对应所有的5类紧急服务。这种对应关系（emergency number <-> emergency category）会存放在SIM/USIM卡中。如下，
摘自3GPP TS22.101 Technical Specification Group Services and System Aspects;Service aspects;Service principles
SIM/USIM中的EFecc就扮演了这个角色，可以看到Emergency Number占据每个ECC record前三个字节，这里叫做Emergency Call Code。Emergency Category占据每个ECC record的最后一个字节。
摘自3GPP TS31.102 Characteristics of the Universal Subscriber Identity Module (USIM) application
那这一个字节具体哪位表示Policy，哪位表示Ambulance呢？参看下面最右一位算Bit 1。举例如果Emergency Service Category = 0x02就代表是Ambulance类型；如果Emergency Service Category = 0x03就代表是Policy and Ambulance类型。
摘自3GPP TS24.008 Mobile radio interface Layer 3 specification;Core network protocols; Stage 3
因此在UE呼出紧急电话的Emergency Setup CC信令里不会注明具体的紧急号码，而是注明Emergency category，如下：
上面可以看到Emergency Category为可选IE，意味着在某些场景下不会包含emergency category，那针对这种类型的紧急呼叫，MSC该如何处理呢？ 即
2017 Dec 13 18:57:13.425 [7A] 0x713A UMTS UE OTA -- EMERGENCY_SETUP
Message Direction = From UE
chan_type = 0 (0x0)
prot_disc_check = 3 (0x3)
trans_id_or_skip_ind = 0 (0x0)
prot_disc = 3 (0x3) (GSM_CALL_CONTROL)
msg_type = 14 (0xe)
prot
call_ctrl_prot
EMERGENCY_SETUP
emerg_cat_incl = 0 (0x0)
摘自3GPP TS24.008 Mobile radio interface Layer 3 specification;Core network protocols; Stage 3
答案如上标黄和红线所示，如果没有Emergency Category IE或者存在此IE但是8个位全是0，MSC应该会把这通紧急电话转到运营商定义的默认紧急中心，猜测就是人工台来咨询转接到具体的紧急中心。
话说回来现在VoLTE这么发达，如果用户是在VoLTE上拨打紧急电话，上哪里去找这个Emergency Category去呢？( 有关IMS上的紧急呼叫业务流程请参考春天工作室的《IMS中的紧急呼叫业务研究(IMS Emergency Call)》) 答案就是通过下表从Emergency Category映射出的Emergency Service URN。
摘自3GPP TS24.229 IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3
在这里唯一需要注意的地方是，不同于GSM/UMTS的紧急号码可以一个紧急号码对多个Emergency Category，在VoLTE紧急电话中一个号码只能对应有且只有一个Emergency Service URN！那么问题就来了，如果EFecc里的对应关系就是一对多，在发起VoLTE紧急呼叫时，到底映射哪个URN呢？协议里写的很泛泛，只是说了UE需要按照上表映射任一类型即可，具体实现各家芯片厂商定夺。当然如果不存在Emergency Category，则会映射为urn:service:sos.
Q公司的实现原则就是映射最低位，即
For example, Bit 2 and Bit 3 in Emergency Category are set to “1”, then the UE only selects Bit 2, i.e., the emergency service category is “Ambulance” not "Fire Brigade"，So URN should be urn:service:sos.ambulance。
根据上面的NOTE3，这种一个紧急号码会对应多个Emergency Category的事情，还会存在由于紧急号码来源不同导致。那紧急号码的来源有几处呢？答案如下SIM/USIM的EFecc，服务网络下发和ME内部存储。还强调了无卡情况下8个号码000,08,110,999,118,119,112,911要存到ME中。
摘自3GPP TS22.101 Technical Specification Group Services and System Aspects;Service aspects;Service principles
关于SIM/USIM的EFecc，上面我已经阐述了。下面就先看看服务网络下发的d) 。实际上就是在注册网络后，由网络下发的Attach Accept/TAU Accept里包含的IE --- Emergency Number List来告诉UE所在地区/国家的紧急号码有哪些，分别对应的Emergency Category是什么。当然这个IE不是必选的，根据当地运营商策略决定。
摘自3GPP TS24.008 Mobile radio interface Layer 3 specification;Core network protocols; Stage 3
举例：Attach Accept下发紧急号码911，对应Emergency Category为0x3F，Bit1 - Bit5全为1，5种类型的紧急服务。
关于ME内部存储的紧急号码，完全依赖于终端厂商、芯片商、平台商的实现了。那真是八仙过海，各显神通了，这里深度解析下Q平台的实现策略。这期为了简化，抛开为支持全球化紧急号码的AP侧方案qcril.db，看看BP侧的存放紧急号码的地点就有这些东东，当然并不是都会配置，依赖厂商自行定夺。
NV#67221 /nv/item_files/pbm/pbm_ecc_nums
NV#69736 /nv/item_files/pbm/pbm_hardcoded_ecc_config
NV#69737 /nv/item_files/pbm/pbm_hardcoded_ecc_list
NV#73755 /nv/item_files/pbm/pbm_nv_ecc_list_per_sub
Haykey哥这就带大家滤清它们的关系，让你以后不再对它们蒙圈。细心的读者会发现这些NV/EFs文件的共性都是存放在一个叫做PBM的路径下。PBM = Phonebook Manager的简称，以本硕专业都是学计算机的我看来，PBM就是Q实现的一种DBMS数据库。传统数据库都是由一堆表构成，每张表里行叫做Record，列叫做Field，代表Record的每项属性，如下：
而Q平台的PBM数据库则维护了 PBM_ECC, PBM_FDN, PBM_ADN等各种表格。顾名思义，PBM_ECC就是存放紧急号码相关的地方，见上表，可以得知每个紧急电话就是一行Record，而这个紧急电话Record里主要有四列（Fields)，号码，Source（来源），Emergency Category和网络模式。号码显而易见，没什么可多解释的。需要注意的是后三个属性，Source（来源）表示这个号码是从哪里获取的，SIM/USIM中的EFecc? 由网络下发的Attach Accept/TAU Accept里包含的IE --- Emergency Number List? 还是ME内部维护的NV or 硬编码的？对应的枚举值为
PBM_FIELD_NETWORK_ECC,
PBM_FIELD_SIM_ECC,
PBM_FIELD_HARDCODED_ECC,
PBM_FIELD_NV_ECC
对于NV_ECC和HARDCODED_ECC的区别，我相信如果你不去深入研究，你会不知所然的。先谈HARDCODED_ECC，Hardcoded硬编码的意思就是直接写在代码里，如下分为有卡hardcoded_with_uim，有卡无EFecc文件hardcoded_with_uim_but_no_ecc和无卡hardcoded_with_no_uim三种情况下的硬编码紧急号码数组：
以无卡情况为例，harcoded_with_no_uim里包含了911，112，000，08，110，999，118，119号码，正好满足了协议以下要求。
唯一一点需要注意的是所有Hardcoded的紧急号码，Emergency Category为PBM_EMERGENCY_SERVICE_CAT_DEFAULT = 0，不存在Emergency Category IE，MSC会把对应紧急电话转到运营商定义的默认紧急中心。 随着时间的推移，Q公司发现这种纯正的Hardcoded ECC不灵活，不能满足各个国家，如中国近乎变态的紧急号码需求，又引入两个新的NVs，NV#69736和NV#69737用于取代代码级Hardcoded ECC（势必注意它们虽然以NV形式表示，但仍隶属Hardcoded ECC而非NV ECC）。
NV#69736 /nv/item_files/pbm/pbm_hardcoded_ecc_config
NV#69737 /nv/item_files/pbm/pbm_hardcoded_ecc_list
NV#69736为新旧Hardcoded ECC方案开关，如果为1，采用新方案NV#69737里的hardcoded ECC；如果为0，兼容以前平台仍使用代码里的hardcoded ECC，即有卡hardcoded_with_uim，有卡无EFecc文件hardcoded_with_uim_but_no_ecc和无卡hardcoded_with_no_uim的硬编码紧急号码数组。
NV#69737里各项定义如下：
0）number_digits：digits号码位数
1）digits：具体配置的紧急号码
2）value：不用配置，取值为0即可
3）category_length：emergency_category的长度
4）emergency_category：紧急号码类型，在中国配置为0，国外紧急号码具体情况具体分析
5）emergency_mode：0：在GWTL上发起紧急呼叫；1:在1x上发起紧急呼叫；2：任何制式均可发起
6）hardcoded_type：0：无论是否插卡call type都是emergency type（Emergency Setup)；1：不插卡时call type是emergency type，插卡时call type是normal call(CC Setup)，例如中国紧急呼叫；2：插卡时call type是emergency type
先把结论抛出来，NV#67221 /nv/item_files/pbm/pbm_ecc_nums属于PBM_FIELD_NV_ECC，NV#73755 /nv/item_files/pbm/pbm_nv_ecc_list_per_sub属于PBM_FIELD_SIM_ECC。原因就是在PBM ECC初始化时，
pbm_ecc_set_hardcoded_eccs函数读取/nv/item_files/pbm/pbm_hardcoded_ecc_list，并且构建Category为PBM_FIELD_HARDCODED_ECC类型的record, 如下：
随后pbm_init_ecc_nv还会读取/nv/item_files/pbm/pbm_ecc_nums，并且构建Category为PBM_FIELD_NV_ECC类型的record
当插卡后回调pbm_card_status_cb
case MMGSDI_CARD_INSERTED_EVT:
pbm_build_slot_specific_ecc_cache
读取EFecc文件比对由pbm_nv_ecc_list_per_sub构建的pbm_slot_specific_ecc_list_ptr，如果pbm_slot_specific_ecc_list_ptr里有的而卡里没有的紧急号码，和卡里的紧急号码共同构建Category为PBM_FIELD_SIM_ECC类型的record, 如下：
这样一个相同的紧急号码会有多处来源，可能存在于EFecc，也有可能同时放在NV#69737中，如果Emergency Category相同的话则万事大吉，如果不同，该以谁为主呢？即规范里的这段文字描述
Q平台的实现是以Rel11为界， Rel11前优先级PBM_FIELD_SIM_ECC > PBM_NETWORK_SIM_ECC > PBM_FIELD_HARDCODED_ECC > PBM_FIELD_NV_ECC；Rel11后优先级PBM_FIELD_NETWORK_ECC > PBM_FIELD_SIM_ECC > PBM_FIELD_HARDCODED_ECC > PBM_FIELD_NV_ECC，如下：
间接地，其实PBM那三个存放紧急号码的NV优先级就是 pbm_nv_ecc_list_per_sub > pbm_hardcoded_ecc_list > pbm_ecc_nums。
至此，Emergency Category在BP侧的来龙去脉已经全部讲解完毕，但是事情远远没有结束。随着以粗粮为代表的国内厂商集体出海，高端旗舰机型必将支持越来越多的全球频段，以小米MIX2为代表，竟然支持43个频段！这就意味着到哪个国家都可以毫无压力地打电话。所以Haykey哥猜测粗粮这款MIX2的紧急号码列表肯定不是放在BP侧的，而是放在之前所说的qcril.db数据库中，毕竟要支持全球各地区国家的紧急号码，其量之大远远超过了NV的承载能力。
当紧急号码放在了AP侧，中间件QCRIL可以直接查询出数据库里的emergency category，并且通过QMI Voice Dial Request直接发给Modem，省去了再查询PBM模块Emergency Category的过程，如下日志：
0x138E QMI Link 1 RX PDU MsgType = QMI_VOICE_DIAL_CALL_MSG
call_type = EMERGENCY
emer_cat = AMBULANCE_BIT
19:34:11.687 cm.c 02964 =CM= Emerg serv categ given = 1
对应Codes：
如果紧急号码列表没有放到AP侧，Modem内部会咨询PBM模块查询之前讲述的PBM_ECC表，得出对应号码的Emergency Category，如下日志打印
紧急号码112对应Emergency Category为0x07(Police Bit&Ambulance Bit&Fire Brigade Bit = 1)，而且通过field type可知这个112的信息来自于SIM/USIM的EFecc。
MSG 07:52:20.439 Phonebook Manager/High [ pbm_ecc_lib.c 121] Checking num as emergency. Len:0x3. Num:0x31 0x31 0x32 0xffffffff 0xffffffff pbm_3gpp_rel_ver 0x91 p_session_type 0x2
MSG 07:52:20.439 Phonebook Manager/High [ pbm_ecc.c 2748] Found ECC cat 0x7 with field type 0xff40（SIM_ECC ) emergency_mode 0x0 srv_status_flag 0x0
MSG 07:52:20.439 Phonebook Manager/High [ pbm_ecc_lib.c 234] Picking GW emergency category 0x7 based on field 0xff40
针对这种情况，112的Emergency Category为0x07，如果是Emergency over VoLTE发出，Emergency Service URN是什么呢？Q平台映射最低位，最后在SIP Invite里就是Bit1 -- Police Bit的urn:service:sos.police，如下：
MSG 07:52:21.366 IMS/Medium [ qpdpl.c 13949] qpDplGetEmergencyContextCategory sData[7]
MSG 07:52:21.366 IMS/High [qipcallh_emergency.c 230] qipcallh_process_emergency_registration_callback: Emergency sub category available = 1, Mask = 7 --》 Emergency Category
MSG 07:52:21.366 IMS QIPCALL/High [ qipcallh_emergency 231] qipcallh_process_emergency_registration_callback: Emergency sub category urn:service:sos.police
MSG 07:52:21.375 IMS QIPCALL/High [ qimfif.cpp 4533] qimfif_send_invite: to_hdr:urn:service:sos.police@ims.t-mobile.pl
（本文完）
来源：CSDN
作者：知不足而奋进
链接：https://blog.csdn.net/ZhongGuoRenMei/article/details/103674997