简介
本文档介绍使用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”属性。
假设
- 每个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的复制和同步的属性管理,它可以确保高可用性、操作灵活性和改进的紧急呼叫可靠性。