EPC网络相关原理和案例-20121228-B-V10.docx

EPC网络相关原理和案例 内部公开 内部公开资料编码产品名称PS使用对象产品版本编写部门PS核心网团队资料版本V1.0华为2012年移动宽带PS维护宝典EPC网络相关原理和案例拟 制：黄瀚日 期：2012-12-17审 核：PS核心网团队日 期：批 准：日 期： 华为技术有限公司 版权所有 侵权必究修订记录日期修订版本修订描述作者2012-12-17V1.0初稿黄瀚目录EPC网络相关原理和案例1第一章 用户访问安全原理和案例61.EPC网络用户访问安全原理61.1 EPC网络用户访问安全整体框架61.2 EPC网络AKA（Authentication and Key Agreement）流程71.3 EPC网络完整性保护和加密82.EPC网络用户访问安全相关案例92.1 开户配置错误案例92.1.1用户接入4G网络，附着成功后MME马上对用户发起分离，分离原因是no-EPS-bearer-context-activated。92.1.2OP/OPc开户错误导致终端鉴权上报MAC-failure102.1.3FAQ 附着拒绝中带有原因值llegal UE 常规解决方法112.2 安全算法配置错误相关案例132.2.1鉴权关闭导致Initial_Context_Setup流程失败132.2.2因在使能SMC功能下MME未配置完整性保护算法导致用户附着4G网络失败152.3 终端问题相关案例172.3.1由于终端不支持EEA2&EIA2算法导致加密鉴权失败172.3.2FAQ如何解决手机鉴权返回同步失败的问题18第二章 DNS解析和网元选择及案例221.DNS解析和网元选择原理221.1 EPC网络中的DNS域名解析服务221.2MME选择功能221.3S-GW选择功能231.4P-GW选择功能241.5网元优选策略242.DNS解析服务和网元选择相关案例252.1HSS APNOI与USN FQDN不匹配导致DNS解析失败252.2USN的Hostfile解析S-GW IP配置错误导致初始化EPS失败，手机无法正常附着 网络272.3USN的S-GW本地DNS数据中，TAI配置错误导致附着失败292.4PGW Blacklist timeout interval导致DNS解析失败312.5RAU或P-TMSI附着所带old rai中LAC大于0x8000导致用户RAU失败或身份识别 失败32第三章 专有承载建立原理及案例351.EPC网络专有承载建立流程352.EPC网络专有承载建立流程相关案例362.1大小写问题造成的专有承载创建失败362.2播放器设置错误导致UGW无法创建专用承载37第四章 EPC QoS架构原理及案例401.EPC QoS架构原理401.1 EPC QoS架构模型401.2 EPS网络相关概念401.3EPS网络中系统实现412.EPC QoS架构原理相关案例422.1 签约APN对应的QCI值错误导致用户接入4G网络失败422.2 FAQ-更改各QCI数据流对应 PHB和DSCP 值的设置方法44第1章 用户访问安全原理和案例1 EPC网络用户访问安全原理1.1 EPC网络用户访问安全整体框架EPC安全架构包含5方面内容：1、网络访问安全1) 用户标识保密：MSIN、IMEI和IMEISV需要保密，NAS安全机制建立之前，UE不能发送IMEI和IMEISV，除了在UE设有IMSI/GUTI/PTMSI的紧急呼叫场景。2) 鉴权3) 加密：协议推荐RRC信令、NAS信令和UP用户面数据加密，其中RRC信令和UP用户 面数据加密在UE和eNB之间PDCP层执行，NAS信令加密在UE和MME之间NAS层执行。目前支持的加密算法有EEA0（0000，不加密）、128-EEA1（0001，Snow3G）和128-EEA2（0010，AES）。使用128比特密钥作为输入，将来可能扩展到256比特密钥。4) 数据完整性：NAS信令和RRC信令需要做完整性保护（除了TS24.301和TS36.331中明确要求不保护的信令消息），UE和eNB之间的UP用户面数据不需要完整性保护。UE和eNB之间执行RRC信令保护，UE和MME之间执行NAS信令保护，一旦NAS安全交互建立后，所有的NAS消息都必须通过完整性保护，否则即使进行了加密也将被丢弃。目前支持的加密算法有EIA0（0000，不保护）、128-EIA1（0001，Snow3G）和128-EIA2（0010，AES）。使用128比特密钥作为输入，将来可能扩展到256比特密钥。EIA0仅用于紧急呼叫的特殊场景。2、 网络域安全3、 用户域安全4、 应用域安全5、 安全的可视化和可配置1.2 EPC网络AKA（Authentication and Key Agreement）流程EPS AKA主体流程图如下：EPS AKA关键流程1 - MME从HE获取鉴权向量1) MME发送鉴权请求给HSS，携带IMSI、服务网络标识SNI、接入网类型（E-UTRAN等）；注：建议每次AKA 过程中MME 仅索取一组鉴权向量，因为EPS采用了更精细的密钥分层架构，AKA执行的次数相应减少。可以用存储的KASME 对后续服务请求进行认证，而不需要AKA 过程。另外，通过TS33.102描述的UMTS序列号管理机制来避免重同步问题，是一种可选方案，重同步问题来源于多组鉴权向量的交叉使用。除了序列号管理机制之外可以通过立即从HSS 获取一组鉴权向量用于UE 和MME之间的鉴权，来避免重同步问题。2) HE/HSS返回鉴权向量4元组：RAND、AUTN、KASME、XRES，其中计算AUTN所用的AMF比特位0是Separation比特，如果接入网类型为E-UTRAN，则需要置为1，表示该鉴权向量只能用于EPS；如果接入网类型为GERAN/UTRAN，则置为0。MME与ME进行双向鉴权流程图如下：EPS AKA关键流程2 - MME与ME/USIM进行双向鉴权1) MME向UE发起鉴权请求，携带RAND、AUTN、KSIASME，其中KSIASME用于标识此次鉴权所使用的KASME；2) ME需要检查AUTN的AMF中Separation比特位（比特0）的值是否为1，如果不是1，ME认为该网络不是EPS网络，将拒绝接入；3) 类似于UMTS，USIM计算并比对MAC/SQN，如果比对失败，则返回鉴权失败；如果比对成功，说明USIM对网络侧鉴权成功，USIM计算RES，返回给MME；4) MME将ME返回的RES与本地保存的XRES进行比对，如果相同，则鉴权通过。1.3 EPC网络完整性保护和加密加密及完整性保护流程中涉及到的所有密钥产生流程图如下所示：加密和完整性包括分为3个层面：NAS层的加密和完整性保护（用户UE和MME之间）、RRC层的加密和完整性保护（用于UE和eNodeB之间）以及用户层面的加密（用于UE和eNodeB之间）。鉴权四元组中的KASME，即用于上述完整性保护。4G中采用密钥分离，每种加密密钥、完整性保护密钥均由KASME衍生出来，但是各自的产生算法不同。鉴权流程完成之后，MME和UE侧均保留有相同的KASME。1. NAS层的加密及完整性保护。MME和UE均会以KASME为输入，通过双方协商的加密及完整性保护算法，分别计算出KNASenc和KNASint。前者用于NAS层加密，后者用于NAS层完整性保护。2. RRC层与用户层的加密及完整性保护。RRC层以及用户层的加密和完整性保护，用于UE和eNodeB之间，但是eNodeB没有相应的密钥，如何获取呢？MME会根据KASME计算出一个提供给eNodeB用于加密及完整性保护的密钥，也就是KeNB，MME将其发送给eNodeB。UE侧存有与MME侧相同的KASME，可以计算出相同的KeNB。eNodeB收到KeNB之后，会根据与UE协商的加密及完整性保护算法，计算出KRRCenc、KRRCint及KUPenc。同样，UE也会计算出上述3个密钥。KRRCenc用于RRC层加密，KRRCint用于RRC层完整性保护，而KUPenc用于用户层加密，用户层没有完整性保护。至此，加密与完整性保护流程所需要的密钥生成完毕。2 EPC网络用户访问安全相关案例2.1 开户配置错误案例作者黄寅工号140846产品名称USN9810编写日期2010-10-112.1.1 因MME在上下文中保留的用户签约数据与HSS不一致导致用户附着后立即被分离现象描述：户接入4G网络，附着成功后MME马上对用户发起分离，分离原因是no-EPS-bearer-context-activated。原因分析：查看用户跟踪，发现MME在下发Attachaccept后给HSS发了NotifyRequest消息，此为正常流程，但HSS回复的NotifyResponse消息携带的原因值却是diameter-unable-to-comply，导致MME发起了用户分离（先向SGW发起删除承载请求，再向UE发起了分离请求），分离原因是no-EPS-bearer-context-activated。经HSS侧分析，HSS回复该原因值是因为MME在NotifyRequest消息中带上来的用户签约数据与当前HSS中储存的数据不一致，而造成这个不一致的最终原因是HSS侧未配置订阅通知信息（BE侧：ADDNOTIFYCFG），导致在HSS修改用户签约数据后HSS并未立即将相关的更新发给MME（用户在该MME非初次附着，因此MME在上下文中保留有用户签约数据）。告警信息：无处理过程：解决问题可在MME侧用RMVUSER删除用户，再次接入后MME便会重新去HSS取签约数据，用户即可顺利接入。从根本上解决问题需要在HSSBE侧增加ADDNOTIFYCFG的订阅通知配置，保证每次在HSS修改签约数据后都会立即向MME发起更新。解决问题可在MME侧用RMVUSER删除用户，再次接入后MME便会重新去HSS取签约数据，用户即可顺利接入。从根本上解决问题需要在HSSBE侧增加ADDNOTIFYCFG的订阅通知配置，保证每次在HSS修改签约数据后都会立即向MME发起更新。案例点评：关于HSSBE侧ADDNOTIFYCFG命令：1、如果不配置，不影响用户基本接入功能，但在HSS签约数据修改后，只存储在HSS中，MME无法得到最新数据，也不知道数据已经修改。除非用户再次通过MME上ULR消息，才能在ULA中下发最新的签约数据。2、如果配置，当在HSS修改签约数据后，BE/PGW会立即通知FE，FE也会立即通知MME，在通知的同时也已经把修改的的数据下发给MME了，MME利用HSS发过来的IDR/DSR消息更新本地数据即可。作者肖阳工号00159170产品名称SAE-HSS9820编写日期2011-02-182.1.2 OP/OPc开户错误导致终端鉴权上报MAC-failure现象描述：某国LTE-EPC局点，第一次附着的时候发现终端上报MAC-FAILURE拒绝附着，跟踪消息如下：告警信息：无原因分析：协议24301上 节 Authentication not accepted by the UE中，关于此原因值的描述：MAC code failure:If the UE finds the MAC code (supplied by the core network in the AUTN parameter) to be invalid, the UE shall send an AUTHENTICATION FAILURE message to the network, with the EMM cause #20 MAC failure. The UE shall then follow the procedure described in subclause, itemc.通过协议可以看到，应该是核心网在下发AUTN参数不正确。处理过程：1) 关于鉴权参数，在终端上只配置K值和OP值。2) 对比HSS开户信息与终端上的信息IMSI、K、OP是否一致。在HSS中发现在添加用户鉴权信息的时候直接输入了OPC值，而没有填写OP索引。3) 问题就很明白了OP值不对导致终端认为鉴权失败。注：OP与OPC的区别：协议35206里面详细讲解了OPC与OP K的算法关系A 128-bit value OPC is derived from OP and K as follows: OPC = OP EOPK.可见，OPC是由OP和K运算而来的，所以直接把OPC值填为OP值生成的AUTN值在终端认为肯定是不对的。4) 重新添加OP索引，在鉴权数据中进行索引，再次进行附着请求，附着成功。案例点评：OP和OPC不能概念混淆，OPC值是OP和K值运算的来，因此在配置过程中，不能混淆。作者陈利伟工号00176545产品名称USN9810编写日期2012-11-302.1.3 FAQ 附着拒绝中带有原因值llegal UE 常规解决方法现象描述：用户发起附着，在鉴权阶段，UE回复鉴权消息为Authentication failure ，并携带原因值为“MAC failure”，则Attach流程失败，Attach Reject中带有原因值“Illegal UE”。告警信息：无原因分析：在USN9810的LMT上开启对应用户的用户跟踪，用户发起附着但被拒绝，抓取信令如下：打开S1AP_SPU_UPLINK_NAS_TRANSPORT信息，观察到鉴权失败原因致是mAC-failure，并且发现拒绝原因致是illegal-UE，如下所示：处理过程：1）合法UE出现这种情况，可以确定HSS上安全开户信息错误，请首先核对UE和HSS开户的K和OP/OPC值是否相同。HSS上开户的K和OP/OPC值不能为全1，否则会被认为是无效的K和OP/OPC值。3）如果都相同，则可能UE的USIM卡上烧的为OPC而不是OP。请使用ADD KSI命令修改为OPC值，再重新附着。4）HSS上开户安全信息、安全相关原理见附录配置相关知识中的“HSS配置”章节。2.2 安全算法配置错误相关案例作者颜小杰工号产品名称USN9810编写日期2011-04-062.2.1 鉴权关闭导致Initial_Context_Setup流程失败现象描述：某4G局点，USN版本为MMEV900R001C03SPC100，EnodeB版本为V100R002C00SPC210。在附着流程中，USN收到SGW创建默认承载的响应后，USN将发送Initial_Context_Setup_Req消息给EnodeB，里面包含了attach accept信息和SGW上用户面的承载信息及用于UE的 AS安全上下文信息。用户跟踪显示，eNodeB给USN返回了Initial_Context_Setup_Fail消息。用户跟踪消息见下图：告警信息：无原因分析：USN上只收到了Initial_Context_Setup_Fail消息，但是看不到具体的失败原因。但是从eNodeB的空口跟踪上发现UE回了安全模式失败的消息，从而导致eNodeB给USN回了Initial_Context_Setup_Fail。空口跟踪消息见下图：USN向eNodeB发送的Initial_Context_Setup_Request消息里面包含了用于指示UE和eNodeB创建安全上下文的相关信息，查看协议3GPP TS36.413V8.7.0发现，包括UE Security Capabilities和KeNB。eNodeB收到这个Initial_Context_Setup_Request消息后，将综合考虑自身的安全算法配置和UE Security Capabilities选取出安全算法，将选定的算法下发给UE，同时根据KeNB派生出RRC/UP安全密钥。通过查看用户跟踪消息Initial_Context_Setup_Request发现USN给eNodeB下发的KeNB值为0，跟踪消息见下图：由于USN在Initial_Context_Setup_Request消息里面下发的KeNB值为0，意味着MME没有选择安全算法，从而UE返回了安全模式失败，导致了eNodeB给USN回Initial_Context_Setup_Fail消息。安全算法和KeNB是USN完成UE鉴权后产生的，而当时USN的鉴权开关是关闭的，所以导致了上述问题的发生。对于三星UE， 是需要鉴权加密的，所以USN上必须打开鉴权，否则USN将下发一个值为0的KeNB给eNodeB，导致eNodeB选择AS安全算法。这一点和华为UE不同，华为UE上面有个参数可以灵活控制是否鉴权加密，只要USN和UE的设置保持一致即可。处理过程： 通过以上的原因分析，问题是由于USN没有对UE进行鉴权产生的。在USN上执行命令：MOD S1USRSECPARA: IMSIPRE=DEFAULT, SECPLC=AUTHANDPROTECTED把鉴权开关打开后，跟踪消息显示USN就触发了鉴权流程。鉴权完成后，Initial_Context_Setup流程就能顺利完成了，跟踪消息见下图：案例点评：ADD S1USRSECPARA这个命令作用是针对某一个IMSI集是否在进行鉴权的参数，参数有三种情况，第一个是鉴权参数打开，MME则强行鉴权，第二种情况则是NEVER，就是不进行鉴权，第三个是将该IMSI级通过RMV S1USRSECPARA删除，此时将使用系统默认鉴权配置进行处理，正常情况下，系统默认为鉴权开启。作者黄寅工号140846产品名称USN9810编写日期2010-09-192.2.2 因在使能SMC功能下MME未配置完整性保护算法导致用户附着4G网络失败现象描述：用户尝试附着4G网络，进行到鉴权流程时，MME与HSS之间AIR和AIA流程结束，MME向UE下发Authenticationrequest，UE返回Authenticationresponse消息，接下来MME就回复了attachreject消息，原因值是protocol-error-unspecified（图1）。告警信息：无原因分析：该问题从现象看容易让人认为是开户数据不匹配（USIM卡的K/OP值与开户数据中的不匹配），但是如果是用户鉴权失败的话MME发送attachreject会携带原因值illegal-UE，而不是protocol-error-unspecified，因此排除这种可能。 使用LSTS1SECPARA命令查看MME的安全设置，发现AKA（鉴权）以及SMC（SecurityModeControl）功能都是打开的，即用户接入需要执行鉴权、加密以及完整性保护；但同时发现设置的完整性保护算法种类是却NULL（Integrityalgorithm=NULL），即没有定义使用哪种完整性算法，正是由于这个问题导致MME拒绝了用户的附着。处理过程：SETS1SECPARA:SUPTINTAGTH=EIA2-1;定义MME使用的完整性算法为EIA2（目前MME只支持该算法），重新接入后问题解决。案例点评：无2.3 终端问题相关案例作者肖阳工号00159170产品名称USN9810编写日期2011-06-232.3.1 由于终端不支持EEA2&EIA2算法导致加密鉴权失败现象描述：某LTE局点进行ATP测试时发现，如果不进行加密鉴权业务正常进行，在MME/eNodeB设置加密鉴权之后，业务失败。USN版本：MME V900R001C05。 告警信息：无原因分析：根据LTE-EPC系统构架，从上到下有以下几种原因：1) USN配置错误，导致鉴权失败。2) eNodeB侧配置错误，导致鉴权失败。3) 终端原因导致加密鉴权失败。 处理过程：1) 首先检查USN的配置，确认对测试用户460018888888801的配置如下：ADD S1USRSECPARA: IMSIPRE=460018888888801, SECPLC=AUTHANDPROTECTED, SUPTINTAGTH=EIA2-1, SUPTCIPHAGTH=EEA2-1;C03版本就此命令关于加密鉴权，所以USN配置是没问题的。2) 继续查询eNodeB上配置，是采用优先级设置，且都选择了AES为第一优先级。MOD ENODEBCIPHERCAP: PrimaryCiperAlg=AES, SecondCiperAlg=Snow3G, ThirdCiperAlg=NULL;MOD ENODEBINTEGRITYCAP: PrimaryIntegrityAlg=AES, SecondIntegrityAlg=Snow3G, ThirdIntegrityAlg=NULL;3) 既然都没有问题，就来分析一下跟踪消息。在ATTACH REQ消息中，发现UE带上来的UE网络能力显示：80 80 00 00：在TS24.301协议4中有关于UE Network Capability描述，如下图：所以可知此UE并不支持EIA2&EEA2算法，被终端拒绝。最终UE升级到2.0版本，问题解决。案例点评：此案例主要强调的是问题分析过程，指导我们怎么去排查鉴权失败的场景，我们要明确鉴权过程，首先是UE要对网络侧进行鉴权，鉴权通过后，网络侧再对UE进行鉴权。此案例发生在UE对网络侧鉴权中，不支持EIA2&EEA2算法，导致计算出来的值不能和网络层下发预期值进行匹配，导致鉴权失败。作者余蕾工号69995产品名称SGSN9810编写日期2.3.2 FAQ如何解决手机鉴权返回同步失败的问题现象描述：某些用户在附着，或者切换过程中进行鉴权失败，手机返回鉴权同步失败。随后SGSN重新向HLR获取用户的鉴权信息。并重新向手机下发鉴权请求，然而手机仍然返回鉴权同步失败。随后SGSN拒绝了手机的业务请求。原因分析：1， UE位置更新消息跟踪如下：1630: 终端发送 PMM_RA_UPDATE_REQ 消息到SGSN。1644: SGSN 发送 PMM_AUTH_CIPH_REQ 鉴权请求到终端。1661: 终端发送 PMM_AUTH_CIPH_FAILURE 消息到SGSN原因是synch_failure.1670: SGSN 向HLR重新获取鉴权信息，再次下发鉴权请求给终端. 1694: 终端再次发送 PMM_AUTH_CIPH_FAILURE to SGSN 原因仍然是同步失败。1696: SGSN返回RAU失败.2， 根据失败原因值分析，查询协议，终端侧根据SGSN下发的鉴权数据计算出的SQN超出了合理的范围导致了同步失败的情况。由于SGSN只是从HLR上获取鉴权信息，并透传到手机，所以SGSN本身并不参与实际的鉴权过程，所以鉴权失败一般都是由于SIM卡制作问题，或者是由于HLR的签约问题。SGSN无法解决。但是某些情况下，由于问题SIM卡已经大量上市导致问题无法挽回的情况下，SGSN提供了办法来规避此类问题。解决方案就是一旦手机返回鉴权同步失败，SGSN就可以多次向HLR获取鉴权参数，并多次发起鉴权请求，实践证明一般最多3到4次鉴权，手机就可以鉴权成功。处理过程：解决手机附着和系统内切换时返回同步失败的问题SGSN提供了两个软参：BYTE49BIT3 ：控制用户鉴权同步失败后，SGSN重鉴权尝试的次数。0：尝试一次。1：重尝试次数为软参50配置的值，但是不能大于20。默认值为0：不打开该功能，重试一次BYTE50：本软参与49号软参BIT3联用。取值范围为020当大于20时，按20处理。该软参R3、R7、R9版本都已支持。解决手机2G切3G或3G切2G等系统间切换时返回同步失败的问题DWORD6 BIT8 ：控制在Intra RAU 系统间路由区更新的时候（2G到3G，3G到2G），鉴权收到Auth Sync Failure的情况下，SGSN重鉴权尝试的次数0：按以前的方式处理，尝试一次。1：重尝试次数为BYTE50配置的值，但是不能大于20。BYTE50：本软参与49号软参BIT3联用。取值范围为020当大于20时，按20处理。该软参R9C01SPH113版本新增。案例点评：无第2章 DNS解析和网元选择及案例1 DNS解析和网元选择原理1.1 EPC网络中的DNS域名解析服务DNS在EPC网络中用于解析S10/S11/S5/S8等接口地址。在EPC信令流程Attach、建立PDN连接、TAU、Handover中，需要使用DNS解析S-GW、P-GW、MME等网元地址信息，供MME进行最优目标网元节点选择，这是基于拓扑、权重、优先级、协议类型等进行多重选择，是EPC的基本能力，因此EPC网络中DNS服务器须支持NAPTR和SRV功能，实现域名和网元节点多对多的关系。EPC网络中MME进行域名解析可以有三种手段，查询先后顺序是：使用本地主机信息表（hostfile），DNS cache，外置DNS服务器。MME与DNS服务器通过IP连接，协议中接口协议栈如图1所示。图1 DNS接口协议栈 1.2 MME选择功能在Attach、inter-RAU和handover流程里，涉及到MME的选择。Attach流程中，MME收到UE发出的附着请求，MME根据Old GUTI中包含的MME Group ID(MMEGI)和MME Code(MMEC)构建旧侧MME的FQDN，发送DNS解析请求给DNS Server。此场景下旧侧MME是唯一确定的。备注：FQDN：fully qualitied domain naming，全称权威域名解析，DNS解析查询的输入参数。TAU流程中，新侧MME找旧侧MME，同Attach。 Handover流程中，切换旧侧MME收到接入侧发来的切换请求，MME根据消息中的切换目标eNodeB的TAI信息，构建FQDN发给DNS server进行域名解析，查找新侧MME地址信息。 备注：如果是pool的场景，目标MME不唯一，根据优先级和权重选择一个合适的MME。配置MME的DNS数据，用于INTRA LTE的Handover流程中，根据TAI选择MME。HOSTNAME格式定义：.FQDN格式定义：TAC-LB.TAC-HB.TAC.EPC.MNC.MCC.3GPPNETWORK.ORG配置MME的DNS数据，用于INTRA LTE的Attach/TAU流程中，根据GUTI选择MME。HOSTNAME格式定义：.备注：这个需要LICENSE支持FQDN格式定义：MMEC.MMEGI.MME.EPC.MNC.MCC.3GPPNETWORK.ORG1.3 S-GW选择功能在Attach/TAU/Handover流程中均涉及到S-GW的选择。Attach流程中，在建立连接之前，MME要获取S-GW和P-GW的地址。MME首先根据APN构建FQDN，向DNS发起P-GW地址解析，同时根据TAI信息构建FQDN向DNS发起解析请求。DNS返回S-GW和P-GW地址列表，MME根据选择策略选择一个P-GW和S-GW。TAU流程中，新侧MME从旧侧MME获取了源S-GW域名等信息，新侧MME用新TAI构建FQDN向DNS发起请求，获取S-GW地址信息，MME进行比较判断S-GW是否需要切换，如需切换，则向新S-GW发起会话请求。此场景下P-GW不变，只涉及S-GW选择。Handover流程中，由于目标eNodeB的TAI发生改变，其相应的S-GW可能发生改变。MME根据TAI构建FQDN向DNS发起解析请求，DNS返回S-GW地址列表。MME根据源上下文信息中旧S-GW信息进行比较，判断是否需进行切换，如需切换，则向新侧S-GW发起会话建立请求。此场景下P-GW不变，只涉及S-GW选择。HOSTNAME格式定义：. TOPON：代表优选拓扑最近的节点。TOPOFF：代表不优选拓扑最近的节点。 SINGLE-LABEL-INTERFACE-NAME：用于命名一个节点的特定接口。 CANONICAL-NODE-NAME：一个节点的规范命名。FQDN格式定义：TAC-LB.TAC-HB.TAC.EPC.MNC.MCC.3GPPNETWORK.ORG1.4 P-GW选择功能Attach流程中，根据APN解析P-GW地址，分析同S-GW选择。PDN连接请求流程，在向S-GW发起承载上下文建立之前，需获取P-GW的地址，MME根据APN构建FQDN向DNS发起解析请求，获取P-GW地址信息。此场景下S-GW不变，只涉及P-GW选择。配置P-GW的DNS数据，用于Attach/PDN连接建立流程中，根据APN选择P-GW。HOSTNAME格式定义：.FQDN格式定义：.APN.EPC.MNC.MCC.3GPPNETWORK.ORG配置P-GW的Hostfile数据。HOSTNAME格式定义：.1.5 网元优选策略网元优选功能通过MME来完成，DNS是实现优选所需信息的提供者，MME、S-GW、P-GW的各自优选策略如下：l MME：pool场景下，在增加MME网元时会配置权重参数，在建立SCTP偶联的时候下发给eNodeB，用户第一次附着时eNodeB根据这个参数选择合适的MME；在Attach和TAU流程中，MME是唯一确定不变的；只有在Handover流程中会涉及优选，优选参数也仅根据优先级和权重进行选择。 l S-GW：S-GW选择需根据S5/S8接口协议类型、网络拓扑（与P-GW的位置关系）以及运营商的策略算法（负荷、权重）进行。 l P-GW：P-GW选择需优先考虑HSS下发的P-GW IP地址，若HSS没有配置，则通过APN解析，根据S5/S8接口协议类型，本地或归属接入配置策略，网络拓扑（与S-GW的位置关系）以及运营商的策略算法（负荷、权重）进行优选。优选策略着重体现的是网关选取，MME上开启智能网关选择功能，S-GW和P-GW联合选取。总体流程如下：1. 根据APN、TAI构建FQDN发起查询，获取S-GW和P-GW列表。 备注：某些场景下，S-GW或者P-GW固定，请参考“域名解析场景分析”小节。另外，若HSS签约信息包含P-GW信息，这种情况下也不涉及P-GW选择。2. 选择满足S5/S8接口协议要求的S-GW和P-GW。 3. 根据优先级参数进行排序。 4. 拓扑关系相近比较，获取合一和拓扑相近的S-GW和P-GW节点对，同时根据P-GW黑名单进行过滤，得到节点对顺序。 备注：拓扑关系描述请参考“资源记录规划”章节的主机名规划小节。5. 按节点对顺序对节点对进行相应地址信息查询，获取优选S-GW和P-GW的IP地址。附EPC网元选择总结表格：2 DNS解析服务和网元选择相关案例作者丁磊工号00131708产品名称USN9810编写日期2011-09-292.1 HSS APNOI与USN FQDN不匹配导致DNS解析失败现象描述： V国M局业务测试，USN在进行DNS查询流程中失败，会话无法建立。用户跟踪中DNS 回复消息为：DNS-SMSM-MM告警信息： 无。原因分析：通过消息流程，我们定位到MME与DNS之间消息交互失败，该问题属于DNS解析失败的问题。通常情况下，DNS解析失败有如下排查思路：1, 检查对接协商参数配置，并且记录下来，有可能在后面的数据配置中要保持一致，该步骤主要保证MME和DNS之间协议和协商参数正确，能够正确的完成对接，具体命令详见GPI配置DNS服务器部分。2、检查DNS配置运行参数，命令为：SET DNS。具体含义详见GPI配置DNS服务器数据章节。本案例中，将配置文件逐一打印出来，经过反复测试和比对，根据消息内容和配置比对，发现USN中 ADD DNSN：FQDN的配置与请求解析的域名不一致。USN DNSN 配置为：ADD DNSN: FQDN=INTERNET.MOVISTAR.VE.APN.EPC.MNC734.MCC004.3GPPNETWORK.ORG, HSINDEX=2, ENTITY=PGW, INTYPE=S5;消息跟踪中SM-DNS 请求解析的名字为： FQDN 为标准格式配置，DNS 消息请求中格式不一样。处理过程： 1. 检查HSS 开户信息时发现，APNOI 的格式与DNS 请求消息中名字格式一样，后半部分都为：MNC734.MCC004.3GPPNET2. 尝试更改HSS APNOI 的配置为 APN.EPC.MNC004.MCC734.3GPPNETWORK.ORG 或保持APNOI 默认为空ADDSSUB:IMSI=734047300245908,MSISDN=4148888888,ACCESSTYPE=3GPP,APNOI=APN.EPC.MNC734.MCC004.3GPPNETWORK.ORG,3. 改HSS 的APNOI配置后，可以看到这时DNS请求的名字（aucNodeName） 为：INTERNET.MOVISTAR.VE.APN.EPC.MNC734.MCC004.3GPPNETWORK.ORG4. 这时DNS 可以正常解析，在SM-GTPC 消息中 可以看到创建会话请求。另一种方法，更改USN ADD DNSN：FQDN 为：INTERNET.MOVISTAR.VE.MNC734.MCC004.3GPPNET 也可以解决此问题，总之必须保持HSS APNOI 和 FQDN 的一致才可正常进行DNS解析。案例点评：首先，介绍下HSS APNOI 和 FQDN的含义和功能。FQDN是全球保准域名规范，另外，在USN网元下的ADD DNSN配置命令里面，还有实体名索引，网元类型和接口类型。这四个参数共同确定所选择的网元。FQDN格式定义：APNNI.APN.EPC.MNC.MCC.3GPPNETWORK.ORG。在HSS中，ADD APNOI为可选配置功能，配置APN运营商标识，当此处APNOI为空，则USN将会根据MNC.MCC和FQDN确定对端网元。如果配置了APNOI后，USN会将自身配置的FQDN与APNOI进行对比，只有在两者一致的情况下，才能匹配到正确网元，否则会失败。通过本案例，可以总结DNS解析失败的处理办法，在链路可达的情况下，如果发现解析失败，我们首先要锁定消息跟踪的解析失败的信元。其次将信元记录下来，将本段和对端网元涉及到该信元的配置罗列处理，进行逐一比对，检查是否规范填写。最后确定错误点进行排查。作者马洪禹工号00133971产品名称USN9810编写日期2010-08-312.2 USN的Hostfile解析S-GW IP配置错误导致初始化EPS失败，手机无法正常附着网络现象描述： 某LTE演示局，用户Attach流程失败，通过消息跟踪发现用户初始化PDP上下文失败，原因为：unknownormissingAPN。告警信息： 无原因分析：通过消息跟踪发现失败原因为unknownormissingAPN，按照这个原因可以断定是APN配置问题导致的附着失败，通过对比USN和UGW配置发现在现场USN中Hostfile配置S5-lifIp为解析S-GW的IP，S5-rifIP为解析P-GW的IP，后经过和家里确认明确了S-GWIP应该为S11if的IP，所以该问题是由于这个IP配置错误导致。处理过程： 通过消息跟踪发现失败原因为unknownormissingAPN，按照这个原因可以断定是APN配置问题导致的附着失败，可以按照以下几个方面进行逐一排查：1、测试终端APN配置错误。2、检查用户在HSS上签约的APN是否正确。3、USN上配置的DNS解析失败。4、UGW上配置的APN与HSS上配置的不一致。 首先通过检查SamSung的测试4GUE发现该测试终端不需要手动配置APN（这一点与3G测试终端不同）该APN是由核心网下发给UE，UE将采用这个APN进行激活，然后检查HSS和UGW的APN配置APNNI都为,HSSAPN配置如下：SETSAPNTPL:APNTPLID=100,APNTPL_NAME=apn100,OPERTYPE=ADD,SERSELECTION=,PDNGWALLOCTYPE=DYNAMIC通过排查1，2，4项配置都正确，问题还是在DNS解析上。检查USN的Hostfile配置如下：ADDIPV4DNSH:NM=SGW.TAC-LB21.TAC-HB00.TAC.EPC.MNC002.MCC250.3GPPNETWORK.ORG,ADDRT=AF_INET,ADDRNUM=SIXTEEN,ADDR1=6,ADDIPV4DNSH:NM=HUAWEI.GTP.APN.EPC.MNC002.MCC250.3GPPNETWORK.ORG,ADDRT=AF_INET,ADDRNUM=SIXTEEN,ADDR1=7,DNS解析消息如下：检查GGSN业务IP配置如下：interfaceS5-lif3/0/0ipaddress655#interfaceS5-rif3/0/0ipaddress755#interfaceS11if3/0/0ipaddress555 通过对比USN和UGW配置发现在现场USN中Hostfile配置S5-lifIp为解析S-GW的IP，S5-rifIP为解析P-GW的IP，后经过和家里确认明确了S-GWIP应该为S11if的IP，所以该问题是由于这个IP配置错误导致,在USN中更改Hostfile解析S-GWIP为S11ifIP后用户附着成功。案例点评：在SAE核心网中UGW包含了S-GW和P-GW两个网元，这一点与GGSN有很大区别，UGW需要配置S-GW，P-GW和S1-U三个业务IP，所以在USN配置DNS解析的时候一定要明确S5-lif,S5-rifandS11if这3个IP的含义，以免配置混乱导致DNS解析失败。作者杨泽工号00192956产品名称USN9810编写日期2012-03-242.3 USN的S-GW本地DNS数据中，TAI配置错误导致附着失败现象描述：PS9.1版本实验室搭建环境，测试时用户附着失败。用户跟踪如下：告警信息： 无原因分析：一、首先考虑到是DNS的问题，检查DNS交互消息，发现DNS_SM_RSP消息中并没有返回地址信息，确定