目录

简介

体系结构概述

LWR集群组件

PCRF -LWR区域和主题配置

插件配置

插件配置：LWR客户端插件配置

LWR服务选项

服务选项：LWR

CRD更改 — Lwr-Apn — 映射

搜索表组> CRD:Lwr-Apn-Mapping

自定义引用数据表：Lwr-Apn-Mapping

主题查找

自定义引用数据表：主题查找

关键概念和数据流

属性复制

域和服务更新

假设

呼叫流程

优势和影响

结论

简介

本文档介绍使用LWR和UDC VM对紧急呼叫（例如E911呼叫）进行有效的承载处理，从而确保优先设置、可靠性和优化的网络资源使用。

体系结构概述

E911紧急呼叫要求优先处理承载管理，以确保呼叫质量和网络可用性。此解决方案利用轻量级复制(LWR)和用户数据缓存(UDC)虚拟机。LWR在内部使用Kafka DB进行复制。Kafka跨多个PCRF集群提供高速复制，从而在紧急呼叫期间实现协调承载控制。

此功能可帮助PCRF共享用户信息，如附加APN的数量、通知状态和中间状态（如更新和承载释放）。

LWR集群组件

- Zookeeper:用于选择控制器，确保只有一个控制器，并在发生故障时选择新的控制器。它管理集群成员(哪些代理处于活动状态，是集群的一部分)并监管主题配置(存在哪些主题、每个分区有多少个分区、副本位于何处、谁是首选引导者，以及为每个主题设置了哪些配置覆盖)。

- 经纪人：LWR使用在主机上运行的消息队列的代理服务。Kafka代理接收来自生成器的消息，并将它们存储在由唯一偏移量标记的磁盘上。它允许消费者按主题、分区、偏移量获取消息，并且可以通过使用Zookeeper彼此直接或间接共享信息来创建Kafka群集。

- MirrorMaker:Kafka MirrorMaker用于镜像Kafka群集之间的数据。这有助于创建数据从一个数据中心到另一个数据中心的副本。可以同时运行多个镜像进程，以提高吞吐量和容错能力。

PCRF - LWR区域和主题配置

在生产中，您可以将PCRF分组到多个区域，如西部、东南部和东北部。每个区域可以有大约5到6个通过LWR互连的PCRF节点。每当用户发生某些事件时，PCRF都会在LWR上写入或更新数据。这些事件的一些示例包括：

- 连接到网络

- 服务/承载创建

- 从网络分离

插件配置

在“cluster-udc”下，添加了“lwr client plugin”配置，其中包括：

- 区域名:此PCRF所属区域的名称。

- 前端Id:PCRF的前端ID。此值必须与UDC配置中使用的现有前端ID值相同。

- 地区中的前端Id:该区域中所有PCRF的前端ID。

- 主题表:映射到缩放器和代理的主题名称列表，它指示哪个主题是本地主题，哪个主题不是。此表必须配置全部三个区域主题。本地主题必须设置为true;对于本地主题，其余两个主题设置为false。

插件配置：LWR客户端插件配置

LWR服务选项

添加新的服务选项以支持LWR写入；此服务配置必须在UDC服务中使用。

LWR服务选项使用主题名称来选择必须在LWR上写入的主题数据和属性列表。必须根据前端ID从CRD表中选择主题名称。

服务选项：LWR

CRD更改 — Lwr-Apn — 映射

此表提供了在LWR上写入属性(lwrpcrferab)的控制，以及是否释放承载以进行E911承载管理。

搜索表组> CRD:Lwr-Apn-Mapping

只有当“enable_lwr_write”为true时，UDC才会将“lwrpcrferab”属性写入LWR。因此，这会向操作团队提供控制，以启用APN的LWR写入。例如，最初，LWR写入仅针对某些测试APN启用，而针对所有其他APN禁用。这允许操作团队验证LWR功能和复制是否正常工作。

同样，如果“bearer_release”为true，则只有PCRF可以在接收SOS呼叫时释放APN承载；如果APN的“bearer_release”为false，则E911承载管理无法启动该APN。

自定义引用数据表：Lwr-Apn-Mapping

主题查找

此CRD表用于根据前端ID派生主题名称。LWR服务选项使用此信息来连接到PCRF配置的特定主题。

自定义引用数据表：主题查找

关键概念和数据流

属性复制

- 主要复制属性是“lwrpcrferab”，编码与E911相关的承载状态。

- PCRF将此属性写入UDC，然后通过LWR传播该属性。

- LWR跨站点复制属性，更新本地UDC和PCRF以维护同步的承载状态。

域和服务更新

- 新域支持通过UDC和LDAP进行SOS APN属性管理。

- 现有SOS域现在使用“lwrpcrferab”属性。

- 延迟SOS呼叫接受以允许承载释放。

- 在SOS呼叫期间拒绝新的承载/会话请求。

- 在SOS呼叫发起时释放IMS和MCPT承载。

- 在SOS呼叫期间暂停并稍后恢复承载。

假设

- 每个APN控制LWR写入启用以允许分阶段部署和测试。

- PCRF仅在新的会话请求上写入“lwrpcrferab”属性，或者如果该属性已经存在，则防止写入过多。

- SOS呼叫接受中的默认延迟（例如，600毫秒）允许PCRF在建立紧急呼叫之前释放优先级较低的承载。

- 过时的属性保护计时器可确保及时清除过时的SOS会话或属性。

呼叫流程

- 将数据APN的“attach”发送到PGW，然后PGW将CCR-I发送到PCRF A并获得成功响应。

- 将热点APN的“attach”发送到PGW，然后PGW将CCR-I发送到PCRF A并获得成功响应。

- 向PGW发送“紧急呼叫”，然后PGW向PCRF B发送CCR-I并获得成功响应。

- PCRF更新名为“lwrpcrferab”的属性，将其阶段设置为“Start”，优先级设置为“1”。 这可能表示紧急呼叫处理的开始，并为其分配最高优先级。

- PCRF将此更新的“lwrpcrferab”属性写入UDC。

- 然后，UDC将“lwrpcrferab”属性写入LWR。“lwrpcrferab”属性在LWR集群中的所有节点和区域之间复制，以确保一致性和可用性。

- PCRF多集群中的每个节点使用复制的属性信息更新其本地UDC和PCRF实例。

- 然后，PCRF释放优先级较低的承载。这些低优先级服务的示例包括热点、IMS视频和IPME。此操作可释放用于高优先级紧急呼叫的网络资源。

- SOS CCA-I消息存在配置的延迟（默认为600毫秒）。这是为了确保资源分配或同步，然后再继续。

- 最后，系统拒绝对特定APN（例如热点）的任何新承载或会话请求，通过防止新的低优先级连接来进一步优先处理紧急呼叫。

- 当GW发送CCR-T以删除SOS呼叫时，PCRF接受数据APN的新承载创建请求。

优势和影响

- 高可用性和可扩展性：基于Kafka的LWR可确保跨多个数据中心的实时复制和容错能力。

- 优先级处理：在紧急呼叫期间启用动态释放或暂停低优先级承载。

- 运营控制：支持基于APN的分阶段功能启用和细粒度承载管理。

- 提高紧急呼叫质量：有效的承载资源管理支持可靠的E911呼叫建立和维护。

结论

使用LWR的承载管理解决方案提供强大、可扩展且高效的机制，以便在E911呼叫期间对LTE承载进行优先级划分和管理。通过利用基于Kafka的复制和同步的属性管理，它可以确保高可用性、操作灵活性和改进的紧急呼叫可靠性。