APN(Access Point Name) in LTE
APN 意指接入点名称。此乃一种网关（抑或锚定点），您的 UE（移动电话）与之相连，便能接入核心网络，从而获取多数数据服务。于本页之内，探讨 APN 的实际事宜。
How APN is assinged ?
APN如何分配给UE？基本上它是由网络根据 UE 的请求进行分配的。所以它是UE设置（用于请求）和网络配置的组合。由于双方都参与 APN 分配，因此该 APN 分配常常会导致各种问题，特别是对于测试 UE 而言。 （对于在实际网络中使用的商用手机，您不会发现太多问题，由于它们在您购买时已预先配置为完全匹配网络要求，但在许多测试情况下，您常常会看到确切的 APN 要求的情况UE 和网络未知。有些 UE 对测试设备的 APN 分配不匹配超级灵活/容忍，但有些 UE 对测试设备的 APN 分配超级挑剔，当网络分配与网络分配不完全匹配时，会表现出各种奇怪的行为。它正在期待。
因此，当您测试 UE (DUT) 进行大多数数据服务相关测试（例如，IP 吞吐量、浏览、IMS 等）时，您必须思考 APN 分配的协议方面和 UE 侧 APN 设置。
Protocol aspect of APN assignment.
APN 分配协议的典型过程超级简单。它分为以下两个步骤。
- i) UE -> NW : PDN Connectivity Request // UE一般请求具有特定APN（或没有指定APN）的PDN
- ii) UE <- NW : Activate Default EPS Bearer Context Request // 网络始终指定特定的 APN
实际上，这两条 NAS 信息被嵌入到不同的 RRC 信息中。一般，您可能会看到以下两种携带这些 NAS 信息的 RRC 信息。
Case 1 : Assignment of default APN
在分配默认 APN 的情况下，一般涉及以下两个步骤。
i) RRC : RRC Connection Setup Complete + NAS : Attach Request + ESM : PDN Connectivity Request
ii) RRC : RRC Connection Reconfiguration + NAS : Attach Accept + NAS : Activate Default EPS Bearer Context Req
Case 2 : Assignment of additional APN
如果在默认 APN 后分配附加 APN，一般涉及以下两个步骤。
- i) RRC : ulinformationTransfer + ESM : PDN Connectivity Request
- ii) RRC : RRC Connection Reconfiguration + NAS : Activate Default EPS Bearer Context Req
APN in S1AP
以下是一些通过 S1AP 携带 APN 信息的消息示例。
UE Setting Aspect of APN Assignement
UE 上有特殊设置，您可以在其中添加或删除（定义）您自己的 APN。如何在 UE 端定义这些 APN 将极大地改变 UE 的行为。因此，在测试时，配置UE侧APN设置以匹配设备APN设置超级重大。但问题是..取决于UE，有些UE让您完全控制APN设置，但有些UE根本不给您任何控制或给您有限的控制能力。现代的商用手机一般都会根据插入的卡来自动匹配APN信息。
Why sometimes UE does not specify APN name in PDN Connectivity Request ?
Case 1 : UE不想在建立安全性之前发送这些信息
我认为这是最常见的情况，并且在默认承载设置中最常发生。 PDN 请求承载在“安全模式命令”过程之前发生的附加请求中。也就是说，UE不希望在没有任何安全保护的情况下发送这种信息。在这种情况下，预计 UE 发送 ESM 信息传输 transfer flat = 1的 PDN 连接请求。然后网络将在安全过程完成后发送 ESM 信息请求，然后 UE 将在 ESM 信息响应消息中通知它想要使用的 APN 名称。
NOTE : ESM信息传输标志的含义在3GPP 24.301-9.9.4.5中规定如下 :
- ESM信息传输标志信息元素的目的是指示ESM信息（即，协议配置选项或APN或两者）是否要被安全保护地传输。
值 0：不需要安全保护的 ESM 信息传输
值 1：需要安全保护的 ESM 信息传输
Case 2 : 意味着 UE 不关心网络分配哪个 APN
我不确定 3GPP 是否明确允许这样做，但我看到许多情况下，当 UE 未在 PDN 请求中指定 APN 名称时，UE 接受网络分配的任何 APN。
Case 3 : UE的BUG
我看到一些 UE 在 PDN 请求中省略 APN 名称而不设置 ESM 信息传输标志的情况。在这种情况下，某些网络可能会拒绝 PDN 请求。
Common Issues and Challenges for APN related issues
APN的最大问题之一是3GPP中没有明确规定严格的规则、要求。许多详细行为取决于 UE 协议栈的实现和运营商的要求。最重大的因素是“UE侧期望和NW侧期望之间的匹配”。最大的问题是很难找到掌握这方面明确信息的合适人选。就我而言，我遇到的大多数问题都是由负责应用层测试（例如 IP 吞吐量、IMS 等）的 UE 制造商/工程师解决的，以下是最终的常见情况。
步骤 i) 我认为我们需要清楚了解 UE 端 APN 处理实现，您需要就此问题与您的无线协议工程师进行沟通。
步骤 ii)（经过很长时间（至少几天）才能从无线协议工程师那里获得任何反馈）。此协议实现由芯片组制造商实现。我们无法控制它。我们需要与芯片组制造商沟通以获取清晰的信息。
步骤 iii)（经过更长的时间才能从芯片组供应商那里获得任何回复）。芯片组制造商表明 APN 配置因每个运营商（网络运营商）而异。如果您从运营商那里获得清晰的问题描述，我们可能会修改我们的堆栈以解决问题。
步骤 iv)（UE 制造商与运营商沟通，也需要很长时间才能获得任何反馈）。运营商说“我们在我们的协议中指定我们需要这种和这种类型的 APN，您必须让它以任何方式工作。如果您在详细的协议层中遇到任何问题，那是您的问题。我们在协议序列方面没有任何明确的定义”。
在步骤 iv) 之后，返回到步骤 i)，经过几次迭代但没有取得任何生产性进展后，验证工程师一般会放弃任何进一步的技术沟通，并尝试依赖如下临时方法。
方法1）不断改变UE侧APN设置参数，直至与特定测试设备配合使用
方法 2) 不断更改测试设备参数，直到其适用于特定的 UE 设置
有时，此种临时之法诚然奏效，不过其决然无法成为尽善尽美的解决之策。有人采用方法 1，有人采用方法 2。故而，即便运用一样的设备对同一个 UE 进行测试，倘若由两个不同之人执行测试，最终于 UE 和设备之上的配置亦会全然相异。另外，在某些 UE 当中，鉴于设备之限制，您仅能运用方法 1，而在其他一些情形之下，由于 UE 侧的限制，您仅可使用方法 2。因而，它们皆难以成为通用的解决之方。实言相告，我觉得此问题不会存有通用的解决之策，除非 3GPP 就此提出明晰的要求。当下，最为合理的举措乃是创建一个自身的明晰要求与检查清单，并协调每一个人（芯片组制造商、UE 制造商以及运营商）遵循检查清单中所定义的规则。就我个人而言，我认为运营商（网络运营商）最具执行此种举措的能力。
Check List
许多 APN 相关问题（例如 APN 名称）没有对错之分。这只是一个特定的规则（由开发人员或网络运营商设置）并严格遵守该规则的问题。因此，本节中的检查清单会询问您“您自己有这样或那样的规则吗？”
1. UE在什么情况下在PDN连接请求消息中设置APN名称？正如我在 APN 分配的协议方面提到的，在某些情况下，UE 指定 APN 名称，而在某些情况下，UE 不指定它。问题是“在您的 UE 中，何时在 PDN 连接请求中指定 APN 名称？”。
2. 当 UE 未在其 PDN 连接请求中指定 APN 名称时，UE 在激活默认 EPS 承载上下文请求中期望从网络获得什么 APN 名称？任何 APN 名称都可以吗？或者它是否需要任何特定的 APN 名称？
3. 如果 UE 在激活默认 EPS 承载上下文请求中期望来自网络的任何特定 APN 名称，则特定 APN 名称从何而来？是网络运营商的要求吗？或者是您在 UE APN 设置中指定的内容？
4. 如果 UE 发送 IP 类型 = IPv4v6 的 PDN 请求，并且网络在激活默认 EPS 承载上下文请求中分配 IPv4v6，但 RS（路由器请求）/RA（路由器广告）过程失败，UE 应如何反应？
希望 UE 放弃 IPv6 设置过程并仅坚持使用 IPv4，但我看到一些 UE 重试 PDN 请求过程，直到 RS/RA 成功。
注意：与APN名称问题不同，3GPP中有相对明确的要求。有关此问题的更多信息，请参阅 ESM 缘由部分。
暂无评论内容