应用功能实体会话的修改方法及设备 【技术领域】
本发明涉及多媒体领域, 特别涉及一种应用功能实体会话的修改方法及设备。背景技术 在 LTE(Long Term Evolution, 长期演进 ) 的 PCC(Policy Control andCharging, 策略控制与计费 ) 架构中, PCRF(Policy Control and Charging RuleFunction, 策略控制 与计费规则功能实体 ) 设备和 AF(Application Function, 应用功能实体 ) 设备通过 Rx 接 口的消息交互, 达到对 AF session( 会话 ) 进行管理的功能。
AF session 的管理包含 AF session 的建立、 修改、 删除等流程, 其中, 针对 AF session 的修改存在多种触发条件, 例如, 现有技术中当 AF 收到订阅事件时, 将触发 AF 发起 AF session 的修改。
在实现本发明的过程中, 发明人发现现有技术至少存在以下缺点 :
当业务流的媒体成分修改时, 现有技术无法触发 AF session 的修改, 导致无法触 发 IP-CAN(Internet Protocol-Connectivity Access Network, 网际协议 - 连接访问网络 ) 会话的修改流程, 进而使业务流的传输得不到保证。发明内容
为了在业务流的媒体成分修改时, 能够触发 AF 会话的修改, 进而触发 IP-CAN 会话 的修改流程, 为业务流的传输提供有效的保证, 本发明实施例提供了一种应用功能实体会 话的修改方法及设备, 所述技术方案如下 :
一方面, 提供了一种应用功能实体会话的修改方法, 所述方法包括 :
接收应用功能实体发送的会话修改请求 ;
判断所述会话修改请求中是否携带媒体成分描述信息 ;
如果是, 则根据所述会话修改请求中携带的媒体成分描述信息更新本地媒体成分 描述信息, 并更新对应的 PCC(Policy Control and Charging, 策略控制与计费 ) 规则。
另一方面, 提供了一种应用功能实体会话的修改设备, 所述设备包括 :
接收模块, 用于接收应用功能实体发送的会话修改请求 ;
判断模块, 用于判断所述接收模块接收到的会话修改请求中是否携带媒体成分描 述信息 ;
第一处理模块, 用于在所述判断模块判断出所述接收模块接收到的会话修改请求 中携带媒体成分描述信息时, 根据所述会话修改请求中携带的媒体成分描述信息更新本地 媒体成分描述信息, 并更新对应的策略控制与计费 PCC 规则。
本发明实施例提供的技术方案的有益效果是 :
通过根据会话修改请求中携带的媒体成分描述信息更新本地媒体成分描述信息, 并生成对应的 PCC 规则, 不仅给出了 AF 会话中媒体成分的具体修改步骤, 还给出了影响 IP-CAN 会话的具体 PCC 规则, 从而对 IP-CAN 会话修改的后续流程起到指导作用, 为用户业务流的传输提供有效的保证。 附图说明 为了更清楚地说明本发明实施例中的技术方案, 下面将对实施例描述中所需要使 用的附图作简单地介绍, 显而易见地, 下面描述中的附图仅仅是本发明的一些实施例, 对于 本领域普通技术人员来讲, 在不付出创造性劳动的前提下, 还可以根据这些附图获得其他 的附图。
图 1 是本发明实施例一提供的应用功能实体会话的修改方法流程图 ;
图 2 是本发明实施例二提供的应用功能实体会话的修改方法流程图 ;
图 3 是本发明实施例二提供的应用功能实体会话的修改消息流程示意图 ;
图 4 是本发明实施例三提供的应用功能实体会话的修改设备结构示意图 ;
图 5 是本发明实施例三提供的第一处理模块结构示意图 ;
图 6 是本发明实施例三提供的另一种第一处理模块结构示意图 ;
图 7 是本发明实施例三提供的另一种应用功能实体会话的修改设备结构示意图 ;
图 8 是本发明实施例三提供的又一种应用功能实体会话的修改设备结构示意图。
具体实施方式
为使本发明的目的、 技术方案和优点更加清楚, 下面将结合附图对本发明实施方 式作进一步地详细描述。
实施例一
参见图 1, 本实施例提供了一种应用功能实体会话的修改方法, 该方法流程具体如 下:
101 : 接收应用功能实体发送的会话修改请求 ;
102 : 判断会话修改请求中是否携带媒体成分描述信息, 如果是, 执行步骤 103, 否 则, 执行步骤 104 ;
103 : 根据会话修改请求中携带的媒体成分描述信息更新本地媒体成分描述信息, 并更新对应的策略控制与计费 PCC 规则 ;
104 : 保持本地媒体成分描述信息及对应的 PCC 规则。
本实施例提供的方法, 通过根据会话修改请求中携带的媒体成分描述信息更新本 地媒体成分描述信息, 并生成对应的 PCC 规则, 不仅给出了 AF 会话中媒体成分的具体修改 步骤, 还给出了影响 IP-CAN 会话的具体 PCC 规则, 从而对 IP-CAN 会话修改的后续流程起到 指导作用, 为用户业务流的传输提供有效的保证。
实施例二
本实施例提供了一种应用功能实体会话的修改方法, 该方法针对业务流的媒体成 分修改, 导致应用功能实体会话的修改时, 通过将接收到的 AF session 修改请求中携带的 媒体成分描述信息和已经存在的媒体成分描述信息进行比较, 给出影响 IP-CAN session 的 具体 PCC 规则列表, 达到能够指导 IP-CANsession 修改的后续流程的目的。以应用功能实 体会话的修改设备为 PCRF 为例, 参见图 2, 本实施例提供的方法流程具体如下 :
201 : PCRF 接收 AF 发送的会话修改请求 ;其中, 会话修改请求可以 AAR(Auth-Application-Request, 应用认证请求 ) 消息 的形式由 AF 发送给 PCRF, 且通过内部或外部的事件触发, 本实施例不对具体触发方式进行 限定。
202 : 判断该会话修改请求中是否携带媒体成分描述信息, 如果是, 执行 203, 否 则, 执行 205 ;
针 对 该 步 骤, 媒 体 成 分 描 述 信 息 包 括 但 不 限 于 IP 流 的 IP 地 址, 端口 号、 媒 体 类 型 等, 本 实 施 例 对 此 不 作 具 体 限 定。 由 于 一 个 媒 体 成 分 描 述 信 息 Media-Component-Description 对应一个 SDF(Service Data Function, 业务数据流 ), 为了 便于说明, 本实施例将以 SDF 替代媒体成分描述信息 Media-Component-Description。 PCRF 收到 AF 发送的 AF session 的 AAR 消息后, 通过消息解码, 即可判断出 AAR 消息中是否携带 SDF。之所以会判断会话修改请求中是否携带 SDF, 不仅需要 PCRF 保存携带的 SDF, 还要识 别该 SDF 对 IP-CAN 会话的影响, 并对其进行分析, 从而根据携带的 SDF 更新对应的 PCC 规 则。
对于 AAR 消息中携带 SDF 的不同情况, 本实施例提供的方法对此进行了区别处理, 处理过程详见下面步骤。 203 : 根据携带的媒体成分描述信息更新本地媒体成分描述信息, 并更新对应的 PCC 规则 ;
具体地, 无论是 PCRF 的本地 SDF, 还是 AF 发送的会话请求中携带的 SDF, 为了能够 区分不同媒体业务的 SDF, 每个 SDF 均具有一个媒体成分号, 用于标识对应的 SDF。在根据 携带的媒体成分描述信息更新本地媒体成分描述信息时, 需要将 AAR 消息中携带的一个或 多个 SDF 与 PCRF 本地存在的所有媒体成分逐一进行比较, 以确定更新的具体操作, 而比较 的方式即可通过比较媒体成分号是否相同来实现。 在根据比较之后的具体情况进行更新操 作时, 包括但不限于以下两种情况 :
第一种情况 : 携带的 SDF 的 Media-Component-Number( 媒体成分号 ) 和本地存在 的 SDF 信息中 Media-Component-Number 相同, 此时, 说明携带的 SDF 是为了修改本地已经 存在的该 Media-Component-Number 对应的媒体成分描述信息, 则需要将携带的 SDF 替换本 地已经存在的该 Media-Component-Number 对应的媒体成分描述信息 ;
第二种情况 : 携带的 SDF 中的 Media-Component-Number 和本地存在的所有 SDF 信 息中 Media-Component-Number 都不相同, 此时, 说明携带的 SDF 是为了在本地原有的 SDF 基础上增加新的 SDF, 因此, 需要将携带的 SDF 增加到本地的 SDF 中。
进一步地, 由于不同的 SDF 对应不同的 PCC 规则, 在根据携带的 SDF 更新本地 SDF 后, 需要更新对应的 PCC 规则, 具体更新过程, 也将根据上面两种不同情况区分处理, 具体 更新过程如下 :
针对更新本地 SDF 的第一种情况, 更新对应的 PCC 规则时, 由于携带的 SDF 替换了 本地已经存在的 Media-Component-Number 对应的媒体成分描述信息, 则需要将该媒体成 分号标识的本地 SDF 对应的 PCC 规则删除, 并根据会话请求中携带的 SDF 生成新的 PCC 规 则。此处之所以采用先删除再建立的方式而不是采用新 PCC 规则覆盖原 PCC 规则的方式, 主要是为了很清晰地分辨出更新前的 SDF 对应的 PCC 规则和更新后的 SDF 对应的 PCC 规 则, 目的是为了在后续步骤对更新的 PCC 规则进行认证时, 如果认证失败, 能够快速释放本
次的更新内容, 使内存回到修改前的状态, 有利于某些业务 ( 例如上网浏览 ) 的用户体验。
针对更新本地 SDF 的第二种情况, 更新对应的 PCC 规则时, 仅需根据会话请求中携 带的 SDF 生成对应的 PCC 规则即可。
需要说明的是, 无论是上述哪种更新媒体成分描述信息的情况, 以及更新 PCC 规 则的情况, PCRF 在更新本地媒体成分描述信息及对应的 PCC 规则之后, PCRF 都需要向 AF 返 回 AAA(Auth-Application-Answer, 应用认证响应 ) 消息, 至此, AF 会话中媒体成分的修改 流程结束。然而, 由于 PCRF 更新了对应的 PCC 规则, 因此, 将导致触发 IP-CAN 会话修改流 程, 具体过程详见后续步骤。
204 : 将 更 新 后 的 PCC 规 则 发 送 给 PCEF(Policy and Charging EnforcementFunction, 策略与计费执行实体 ), 触发 IP-CAN 会话修改, 流程结束 ;
针对该步骤, PCRF 将本次 AF session 修改请求消息中携带的所有 SDF 信息全部 分析并生成相应的 PCC 规则后, 不仅需要将生成的新的 PCC 规则发送给 PCEF 进行认证, 还 需要将删除的 PCC 规则一同发送给 PCEF, 以触发 PCEF 进行 IP-CAN 会话修改。具体实现时, 由于生成的新的 PCC 规则可能不止一个, 删除的 PCC 规则也可能不止一个, 则可以列表的形 式将生成的新的 PCC 规则及删除的 PCC 规则发送给 PCEF。因此, 在上述步骤 203 中, 通过 将删除的 PCC 规则加入到待删除 PCC 规则列表 Charging-Rule-Remove 中, 并将生成的新 的 PCC 规则增加到 Charging-Rule-Install 列表中, 使该步骤在将更新的 PCC 规则发送给 PCEF 时, 仅需将生成的 PCC 规则所在的 Charging-Rule-Install 列表及删除的 PCC 规则所 在的 Charging-Rule-Remove 列表封装到 RAR(Re-Auth-Request, 重新认证请求 ) 消息中, 发送给 PCEF 即可。无论是删除的 PCC 规则, 还是生成的新的 PCC 规则, 都将影响 IP-CAN 会 话修改, 因此, 当 PCRF 将删除的 PCC 规则所在列表及生成的新的 PCC 规则所在列表发送给 PCEF 后, 都将触发 PCEF 执行 IP-CAN 会话修改的相关操作。
如 果 PCRF 收 到 PCEF 返 回 的 RAA(Re-Auth-Answer, 重新认证响应 ) 消息标识 IP-CAN 会话修改成功, 则 PCRF 将从内存中删除 Charging-Rule-Remove 列表中的 PCC 规则, 同时将 Charging-Rule-Install 列表中 PCC 规则写入内存 ;
如果 PCRF 收到 PCEF 返回的 RAA 消息标识 IP-CAN 会话修改失败, 则 PCRF 将删除 Charging-Rule-Install 列表中的信息, 同时保持原来的内存信息。
优选地, 对于 IP-CAN 会话修改失败的情况, 由于 AF 会话中媒体成分的修改结果不 能满足 AF 侧触发的修改请求, 则需要通知 AF 功能实体本次会话中媒体成分的修改失败, 使其能够清楚本次会话修改的执行结果, 并采取相应措施, 例如, 重新发送会话修改请求等 等, 本实施例对此不作具体限定。
205 : 保持本地媒体成分描述信息及对应的 PCC 规则, 流程结束。
针对该步骤, 由于 AAR 消息中没有携带 SDF, 则该 AF session 修改并不需要 PCC 规 则的重新修改, 只需保持本地媒体成分描述信息及对应的 PCC 规则即可。
需要说明的是, 上述步骤 204 和步骤 205 中的流程结束仅代表会话中媒体成分的 修改流程结束, 但并不意味着整个会话修改流程结束, 因为即使会话修改请求中不携带媒 体成分描述信息, 也有可能会携带其他信息, 从而需要进行会话修改, 例如, 订阅信息等, 因 此, PCRF 还需要将会话请求中携带的其他信息发送给 PCEF, 本实施例对此不再赘述。从消 息流的角度, 本实施例提供的应用功能实体会话中媒体成分的修改以及触发的后续 IP-CAN会话的修改原理可如图 3 所示。
本实施例提供的方法, 通过根据会话修改请求中携带的媒体成分描述信息更新本 地媒体成分描述信息, 并更新对应的 PCC 规则, 不仅给出了 AF 会话中媒体成分的具体修改 步骤, 还给出了影响 IP-CAN 会话的具体 PCC 规则, 从而对 IP-CAN 会话修改的后续流程起到 指导作用, 完善了协议中对于 AF session 中 SDF 的修改流程, 为用户业务流的传输提供有 效的保证 ; 另外, 根据 PCER 返回的响应结果来处理内存的修改, 不仅在成功响应时, 能够将 内存更新为希望更新的内容, 在失败响应时, 还能够快速回到修改前的内存状态, 并不会因 为修改失败, 使内存处于一种不可控的状态。
实施例三
参见图 4, 本实施例提供了一种应用功能实体会话的修改设备, 该设备包括 :
接收模块 401, 用于接收应用功能实体发送的会话修改请求 ;
判断模块 402, 用于判断接收模块 401 接收到的会话修改请求中是否携带媒体成 分描述信息 ;
第一处理模块 403, 用于在判断模块 402 判断出接收模块 401 接收到的会话修改请 求中携带媒体成分描述信息时, 根据会话修改请求中携带的媒体成分描述信息更新本地媒 体成分描述信息, 并更新对应的策略控制与计费 PCC 规则。 实际应用中, 该应用功能实体会话中媒体成分的修改设备可以为 PCRF 设备, 本实 施例对此不作具体限定。
参见图 5, 第一处理模块 403, 具体包括 :
第一更新单元 403a, 用于在会话修改请求中携带的媒体成分描述信息的媒体成分 号与本地媒体成分描述信息中的媒体成分号相同时, 将该媒体成分号标识的本地媒体成分 描述信息替换为会话修改请求中携带的媒体成分描述信息 ;
第二更新单元 403b, 用于将该媒体成分号标识的本地媒体成分描述信息对应的 PCC 规则删除, 并根据会话修改请求中携带的媒体成分描述信息生成新的 PCC 规则。
可选地, 参见图 6, 第一处理模块 403, 具体包括 :
第三更新单元 403c, 用于在会话修改请求中携带的媒体成分描述信息的媒体成分 号与本地媒体成分描述信息中的媒体成分号不同时, 将会话修改请求中携带的媒体成分描 述信息增加到本地媒体成分描述信息中 ;
第四更新单元 403d, 用于根据会话修改请求中携带的媒体成分描述信息生成新的 PCC 规则。
参见图 7, 该应用功能实体会话修改的设备, 还包括 :
第二处理模块 404, 用于将删除的 PCC 规则及生成的新的 PCC 规则发送给 PCEF, 触 发 PCEF 进行 IP-CAN 会话修改 ; 在接收到 PCEF 返回的失败响应时, 将删除的 PCC 规则还原, 将生成的新的 PCC 规则删除, 并通知应用功能实体本次会话中媒体成分的修改失败。
可选地, 参见图 8, 该应用功能实体会话修改的设备, 还包括 :
第 三 处 理 模 块 405, 用 于 将 生 成 的 新 的 PCC 规 则 发 送 给 PCEF, 触 发 PCEF 进 行 IP-CAN 会话修改 ; 在接收到 PCEF 返回的失败响应时, 将生成的新的 PCC 规则删除, 并通知 应用功能实体本次会话中媒体成分的修改失败。
综上所述, 本实施例提供的设备, 通过根据会话修改请求中携带的媒体成分描述
信息更新本地媒体成分描述信息, 并生成对应的 PCC 规则, 不仅给出了 AF 会话中媒体成分 的具体修改步骤, 还给出了影响 IP-CAN 会话的具体 PCC 规则, 从而对 IP-CAN 会话修改的后 续流程起到指导作用, 为用户业务流的传输提供有效的保证。
需要说明的是 : 上述实施例提供的应用功能实体会话的修改设备, 在进行媒体成 分修改时, 仅以上述各功能模块的划分进行举例说明, 实际应用中, 可以根据需要而将上述 功能分配由不同的功能模块完成, 即将设备的内部结构划分成不同的功能模块, 以完成以 上描述的全部或者部分功能。另外, 上述实施例提供的应用功能实体会话的修改设备与应 用功能实体会话的修改方法实施例属于同一构思, 其具体实现过程详见方法实施例, 这里 不再赘述。
上述本发明实施例序号仅仅为了描述, 不代表实施例的优劣。
本发明实施例中的全部或部分步骤, 可以利用软件实现, 相应的软件程序可以存 储在可读取的存储介质中, 如光盘或硬盘等。
以上所述仅为本发明的较佳实施例, 并不用以限制本发明, 凡在本发明的精神和 原则之内, 所作的任何修改、 等同替换、 改进等, 均应包含在本发明的保护范围之内。