相关专题：
0 前言
随着电信网络的发展，用户终端种类及新业务数量呈现逐渐增多的趋势，用户数据将会分散在不同的网元设备中。特别是随着LTE及IMS等网络的逐步部署，分散的用户数据库将面临鉴权重同步等一系列问题，同时IMS与2G/3G移动网络用户共号码，以及业务和接入域选择等新增需求，对用户数据提出了融合的基本需求。本文重点分析LTE与2G/3G网络数据融合的需求及策略，研究设备在融合过程中的关键问题，结合中国联通网络现状提出用户数据融合方面的发展策略和建议。
1 LTE与2G/3G数据融合背景及需求
1.1 HLR/HSS融合背景
从整个移动核心网演进的角度来看，移动核心网的电路域和分组域将长期并存，语音、短信业务在一定时期内仍将继续由电路域提供，伴随着LTE网络覆盖的逐步扩展，部分语音业务将基于分组方式承载，随着LTE网络的引入，用户数据将逐步向融合的方向发展。从标准角度来看，3GPP标准组织提出的用户数据融合（UDC）致力于数据库融合技术研究，数据融合已成为业界公认用户数据管理的发展趋势。
从用户数据库的现状来看，现有移动网2G和3G用户基本采用共用HLR的方式。在数据管理方面，IMS和LTE等新网络设备的引入将会使存储用户数据的网元变得复杂，随着IMS、LTE的部署将出现HLR、HSS等多种类型的数据库。为了避免不同业务的用户数据分散存储形成信息孤岛情况，以及独立部署可能面临的鉴权重同步和数据冗余不一致的问题，需要重点对2G/3G HLR、LTE-HSS和IMS-HSS等设备的融合策略进行研究。
1.2 HLR/HSS用户数据库对比分析
在分析HLR/HSS融合需求之前，先来对比一下2G/3G HLR、LTE-HSS和IMS-HSS三类用户数据库的内部数据存储类型以及外部物理接口形态的差别。
首先，从存储内容上来看，虽然标准中没有严格定义如何构造用户数据库，但是具体定义了数据存储的类型，从2G/3G HLR、LTE HSS和IMS HSS用户数据存储的内容上来看，三者存储的用户信息字段参数存在一定差别，具体情况如下：
a） 状态和位置信息。2G/3G HLR主要存储用户在电路域和分组域的状态及位置信息，LTE-HSS中存储用户在EPC的状态和位置信息，IMS-HSS存储IMS用户的状态信息。
b） 业务签约数据。除智能网业务之外，HLR存储用户基本和补充业务等业务签约数据；对LTE-HSS来说，无该类数据；对于IMS-HSS用户来说只有业务触发的基本规则，具体的业务签约在对应的应用服务中存储或以透明数据的形式存储在IMS-HSS中。
c） 接入属性。仅2G/3G HLR与LTE-HSS有用户接入侧的相关属性，IMS-HSS无该信息。
d） 鉴权数据。是数据库共有的数据，主要负责根据用户密钥创建安全信息，三类数据库在生成的鉴权参数（三元组、五元组、四元组）上，不同网络存在一些差别。
其次，从设备形态上来看，三类数据库对外接口类型和运行的协议也存在一些差别。
a） 2G/3G HLR接口。对外主要有C/D/Gr等接口，其中C接口是与GMSC之间的接口，D接口是与MSC之间的接口，Gr接口是与SGSN之间的接口；使用的主要是MAP协议，底层承载可以采用TDM或IP方式，目前以TDM承载为主。
b） LTE-HSS接口。对外主要有S6a/S6d接口，其中S6a接口是与MME之间的接口，S6d接口是与S4-SGSN之间的接口，使用的主要是Diameter协议。
c） IMS-HSS接口。对外主要有Cx/Dx/Sh接口，其中Cx/Dx接口是与CSCF之间的接口，Sh接口是与AS之间的接口，使用的主要是Diameter协议。
从上面的分析可以看出：从数据存储角度来看，HLR与LTE-HSS更接近，这两类数据库中用户数据大约有超过50%的数据字段的重复存储，数据存储上两类数据更易于融合；从设备硬件接口形态上来看，LTE-HSS与IMS-HSS更接近，目前多数厂家两类设备基本采用相同或相似的硬件架构。
1.3 HLR/LTE-HSS融合需求分析
上面从存储和硬件形态上分析了HLR/HSS融合可行性，下面从用户和运营商需求的角度出发，分析若2G/3G HLR 与LTE HSS不融合，采用独立部署的方式下将存在哪些问题。
问题一：开户流程复杂。如果不融合，同一个用户的数据将分布在多个网元中，数据本身存在冗余存储，且业务开通管理流程复杂，对同一用户的业务开通要在多点进行，操作流程非常复杂、低效，且难以保证数据一致性。
问题二：鉴权重同步问题。如果不融合，同一个用户的鉴权数据将分布在多个网元中，鉴权中心（AuC）功能重复，终端检查SQN导致鉴权失败，增加终端不能正常服务的风险。
综上分析，问题一对日常开通和维护产生影响，问题二是一个根本的矛盾，也是SQN鉴权不同步的问题。由于鉴权在用户的正常注册、周期性位置更新以及呼叫和切换过程中都要使用，鉴权失败的潜在问题会增加终端不能服务的风险，特别是在切换和呼叫中，会严重影响用户的体验，因此需要重点解决。
下面针对重同步问题，给出具体的解决方案。
解决方案一（互通方案）。多个数据库共用一个AuC功能。该方法可以临时解决SQN不一致导致的问题，但是需要HLR与HSS之间通过私有接口直连或者通过STP间接互联，来传递相关的鉴权参数。由于数据库之间的接口、协议和参数等未标准化，这种私有化的处理方式对同厂家设备具有可操作性，但是异厂家之间很难操作维护，对运营商来说，不是一个理想的解决方案。
解决方案二（分权分域方案）。采用SQN分权分域的方式，该方案对网络和终端都有特殊的要求，网络侧HLR/HSS需要升级支持分域鉴权功能，同时也需要USIM卡支持分域鉴权功能，该方案对网络和终端都有较高的要求，也不是一个理想的解决方案。
解决方案三（融合方案）。若HLR/LTE-HSS数据库融合，能够从根本上解决鉴权重同步的问题，但是由于现网存在大量的2G/3G HLR设备，如何基于现网HLR设备来实现数据库融合也是后续需要考虑的问题。
对于HLR与LTE-HSS用户数据融合有2种解决方案。
子方案1（全融合）。针对部署LTE业务的本地网，实现所有的2G/3G HLR与LTE HSS的融合。该方案需要对所有的2G/3G HLR与LTE HSS进行融合，采用升级的方式，具体如下：
a） 对于可以升级支持LTE HSS的2G/3G HLR，全部单点升级为融合设备。
b） 对于不支持升级融合的2G/3G HLR，采用新建替换方式，原有设备以一定方式利旧其容量至其他升级后的融合设备。
子方案2（部分融合）。针对部署LTE业务的本地网，采用用户携出或灵活号码寄存器（FNR）的方式，仅针对LTE用户实现融合，不考虑2G/3G用户。该方案仅有部分的2G/3G HLR与LTE HSS设备通过改造或新建进行融合，不同方式下处理方式不同，具体如下：
a） 用户携出方式下，对于新用户采用新号段，原有用户使用LTE业务采用换卡不换号（IMSI变更，MSISDN不变）的方式，当原有用户申请使用LTE业务的时候，原有的2G/3G HLR中该用户数据将予以保留，并同时复制一份新的数据到改造后或新的HLR/HSS融合设备上。该方式对现有网络有一定影响，主要有：由于不换号，开展LTE业务的原有用户，做被叫的时候，路由数据不需要变更，但由于IMSI发生变化，做主叫的时候，需要增加新的IMSI号段数据，将用户直接路由到HLR/HSS融合设备上。
b） FNR方案下，对于新用户采用新号段，原有用户使用LTE业务采用不换号不换卡的方式，其本质上是一种号码携带的方案。由于不换卡，用户位置更新仍然到老的HLR上，通过HLR新增的FNR功能来判断用户是否签约了LTE业务，若未签，则正常处理；若签约则启动FNR功能，将信令转至签约所在的LTE HSS。但该方案对现有网络有一些影响，主要有：需要现有HLR增加FNR逻辑模块功能，或者部署独立的FNR网元，同时需要支撑系统支持该业务逻辑。
1.4 HLR/LTE-HSS/IMS-HSS融合需求分析
上面分析了HLR与LTE-HSS融合需求和解决方案，对IMS用户来说，主要是VoLTE以及RCS-e等业务对融合产生影响，下面具体分析一下存在哪些问题。
问题一：鉴权重同步问题。若IMS业务需要使用AKA鉴权，则也存在鉴权SQN重同步的问题，解决方案同HLR/LTE-HSS的解决方案。从目前来看，RCS-e业务现阶段采用 digest的鉴权方式，暂时不考虑AKA的鉴权，而VoLTE业务基本都采用AKA的鉴权方式，随着AKA鉴权的使用，需解决SQN重同步的问题。
问题二：共号码问题。LTE语音引入后，用户能够使用一张USIM卡基于一个手机号在LTE网络和2G/3G网络签约业务，共号码带来对新功能的要求，需要IMS-AS支持SCC-AS功能，同时支持T-ADS和T-SDS功能；SCC-AS为了获取被叫路由信息，需要查询IMS-HSS，若被叫未在IMS-HSS注册，则需要查询当前用户所在的HLR和LTE-HSS，但是HLR、LTE-HSS与IMS-HSS之间没有标准接口，带来HLR/LTE-HSS和IMS-HSS的融合需求。
综上分析，问题一的解决方式同HLR/LTE-HSS的解决方案，问题二是由于LTE部署后并开展基于IMS的语音业务后引入的问题，需要数据库融合解决该问题。从未来网络演进及网络可扩展性角度，应考虑在HLR/LTE-HSS融合的基础上增加对IMS-HSS功能的支持，实现HLR/LTE-HSS/IMS-HSS三者合一的融合用户数据库设备。
2 HLR/HSS融合的演进策略
HLR/HSS融合是解决LTE网络部署后业务顺利开展的目标解决方案，需要考虑的是HLR/HSS融合的策略。对于HLR/HSS融合的整体演进思路考虑如下：分阶段逐步实现HLR/HSS用户数据融合，实现2G/3G/LTE用户的统一用户数据管理，并以HLR/HSS融合为基础，融合更多数据，构架统一融合数据中心。
具体的策略如图1所示，分4个阶段来部署实现HLR/HSS设备的融合。
阶段一：引入新平台HLR。升级改造或替换现网HLR，引入支持融合的新平台HLR，为后续融合奠定基础。
阶段二：引入LTE-HSS设备（向下兼容HLR功能）。该阶段主要针对新用户新号段开展LTE业务，引入LTE-HSS开展独立新号段，提供2G/3G/LTE数据卡业务，LTE-HSS兼有HLR的功能，并能够演进升级支持IMS-HSS功能。
阶段三：HLR与LTE-HSS融合。该阶段支持原有用户使用LTE业务，可以采用不同的方式来实现HLR/LTE-HSS的融合。原有用户采用原有HLR升级为融合HLR/LTE-HSS方式。
方式一（目标方案）：以本地网为单位，全网HLR改造支持LTE-HSS功能。
方式二（过渡方案）：采用用户携出或者号码携带的方案，即逐步将原有的用户携出来避免初期全网改造。
阶段四： HLR/LTE-HSS/IMS-HSS融合。该阶段考虑在基于IMS开展LTE语音业务后，要求现有HLR/LTE-HSS融合设备升级支持HLR/LTE-HSS/IMS-HSS融合设备。
3 用户数据库长期演进思路
从全网角度出发，结合中国联通现网的演进策略，整体思考SDC、IMS-HSS、HLR、LTE-HSS数据库之间的关系和演进策略。
3.1 当前阶段
从中国联通的现网情况来看，目前主要存在三类基本的用户数据库：固网方面有SDC和IMS-HSS，移动网方面有HLR。
从固定网络角度来看，软交换与IMS在一定时期内仍处于共存的阶段。SDC：主要存储固网软交换用户信息；IMS-HSS：主要存储固网PSTN改造迁移后的用户信息。
从移动网络角度来看，目前2G/3G用户采用共HLR的方式。2G/3G HLR：主要存储移动网2G/3G用户信息。
为了面对未来几年内，RCS-e业务引入、LTE数据业务、VoLTE语音业务，这三大类业务的冲击，需要现有的用户数据库逐步演进。
3.2 阶段一：RCS-e业务引入后情况（2013年）
对于RCS-e业务而言，其要早于LTE部署，因此其RCS-e业务的签约数据，现阶段可以存放在现有固网IMS-HSS中，其他接入的用户信息存放在原有的HLR中。即：SDC主要存储固网软交换用户信息；IMS-HSS主要存储固网PSTN改造迁移后的用户信息，以及RCS业务信息；2G/3G HLR主要存储移动网2G/3G用户信息。
3.3 阶段二：LTE业务引入后情况（2014年左右）
对于LTE用户来说，新号段采用新融合HLR/HSS，老号段分2种情况。
a） 所在HLR为新平台，平台进行升级，支持HLR/LTE-HSS融合。
b） 所在HLR为老平台，不支持升级，则考虑用户迁移，HLR设备退网或替换。
用户数据分布情况：SDC主要存储固网软交换用户信息；IMS-HSS主要存储PSTN改造迁移后的用户信息，以及RCS业务信息；2G/3G HLR主要存储移动网2G/3G用户信息（非LTE用户）；HLR/LTE-HSS主要存储2G/3G和LTE用户（同一用户）信息。
3.4 阶段三：VoLTE业务开展后情况（2015年左右）
基于IMS开展VoLTE语音业务，RCS的语音功能升级支持VoLTE。
a） 现有HLR/LTE-HSS升级支持HLR/LTE-HSS/IMS-HSS融合设备。
b） 开启VoLTE业务的RCS用户信息，将考虑从固网IMS-HSS迁移到HLR/HSS融合设备中。
SDC主要存储固网软交换用户信息；IMS-HSS主要存储PSTN改造迁移后的用户信息，以及RCS业务信息（非VoLTE用户）；2G/3G HLR主要存储移动网2G/3G用户信息（非LTE用户）；HLR/LTE-HSS/IMS-HSS主要存储2G/3G和LTE用户（同一用户）信息、VoLTE用户信息、RCS用户信息（同时是VoLTE用户）。
在此阶段形成固网SDC、固网IMS-HSS、移动2G/3G HLR、融合HLR/LTE-HSS/IMS-HSS设备共存的局面。
3.5 后续演进阶段（2015以后）
随着固网软交换的逐步减少，LTE用户规模的扩大，以及固移融合业务的深入，最终形成单一类型HLR/LTE-HSS/IMS-HSS融合设备的局面。后续阶段考虑将AAA、SPR等用户数据统一融合，构建真正的UDC数据中心。
4 结束语
随着LTE网络的引入，从数据库发展的角度，需要规划并管理好核心网的用户数据，协调HLR与LTE-HSS、IMS-HSS之间的关系。同时为了保证后续的演进能力，也需要考虑用户业务数据等的管理，本文重点进行用户数据融合方面的研究，提出移动网用户数据管理的发展策略，为运营商网络和业务融合及平滑演进提供参考和建议。
参考文献：
［1］ 3GPP TS23.335 User Data Convergence；Technical Realization and Information Flows；Stage 2［S/OL］. ［2012-12-20］. http://www.3gpp.org/ftp/Specs/html-info/23335.htm.
［2］ 3GPP TR 22.985 Service requirement for the User Data Convergence（UDC）［S/OL］. ［2012-12-20］. http://www.etsi.org/deliver/etsi_tr/122900_122999/122985/10.00.00_60/tr_122985v100000p.pdf.
［3］ 3GPP TS 29.335 User Data Convergence（UDC）；User Data Repository Access Protocol over the Ud interface；Stage 3［S/OL］. ［2012-12-20］. http://www.3gpp.org/ftp/Specs/html-info/29335.htm.
［4］ 3GPP TS 32.181 User Data Convergence（UDC）；Framework for Model Handling and Management［S/OL］. ［2012-12-20］. http://www.3gpp.org/ftp/Specs/html-info/32181.htm.
［5］ 3GPP TS 32.182 User Data Convergence（UDC）；Common Baseline Information Model（CBIM）［S/OL］. ［2012-12-20］. http://www.3gpp.org/ftp/Specs/html-info/32182.htm.
作者：朱斌 文涛 符刚 来源：邮电设计技术
