一种无线承载选择方法 本申请是申请日为 2008 年 10 月 16 日、 申请号为 200810170258.0 的发明专利申 请 “一种多媒体广播组播业务实现方法、 系统和承载选择方法” 的分案申请。
技术领域 本发明涉及通信领域， 具体而言， 涉及 WCDMA( 宽带码分多址 ) 移动通信系统中， 一 种多媒体广播组播业务 (MBMS， Multimedia Broadcast/Multicast Service) 的无线承载选 择方法。
背景技术 多媒体广播组播业务 (Multimedia Broadcast/Multicast Service， 缩写为 MBMS) rd 由第三代合作伙伴计划 3GPP(3 Generation Partnership Project) 定义， 从一个数据源 向多个目标传送数据的点到多点的技术， 可以实现网络资源共享， 提高网络资源的利用率， 尤其是空口资源。MBMS 不仅可以实现纯文本低速率的消息类组播和广播， 而且还能实现高 速多媒体业务的组播和广播， 提供多种丰富的视频、 音频和多媒体业务， 这无疑顺应了未来 移动数据发展的趋势， 为 3G 的发展提供更好的业务前景。
为了实现 MBMS， 需要对 WCDMA 网络中现有的 SGSN(Serving GPRS Support Node， 服 务 GPRS 支持节点 )、 GGSN(Gateway GPRS Support Node， 网关 GPRS 支持节点 )、 RNC(Radio Network Controller， 无线网络控制器 ) 和 UE(User Equipment， 用户设备 ) 等分组域的节 点增加 MBMS 功能， 同时需要增加广播组播服务中心 BM-SC(Broadcast Multicast Service Center)。
MBMS 业务系统的体系结构如图 1 所示 ：
在图 1 中 Gmb、 Gi 参考点为 BM-SC 与 GGSN 之间的接口， 其中， Gmb 接口提供控制面 功能， Gi 口提供用户面功能。BM-SC 是新增的节点， 它是 MBMS 业务提供者的入口， 用于授权 和发起 MBMS 业务， 保存一些 MBMS 业务参数信息， 并按照预定时间发送 MBMS 业务。
MBMS 有广播和多播两种工作模式。 广播模式是指多媒体数据从一个业务源被单向 发送给广播服务区域内的所有 UE， 该模式下 UE 无需注册即可接收广播数据， 可有效节约无 线资源， 但无法保证 UE 接收数据的完整性 ； 多播模式与广播模式十分类似， 但可接收多播 数据的 UE 只限于已注册的 UE， 当小区中接收多播数据的 UE 过少时， 可选择 PTP(Point to Point， 点到点 ) 的无线承载方式发送多播数据， 以减少对其他无线链路的干扰。
现有的组播模式实现需要 UE 发起业务激活和 GGSN 向 BM-SC 注册流程， 流程如图 2 所示 ：
步骤 201、 UE 向 GGSN 发送 IGMP(Internet Group Management Protocol， 互联网 组管理协议 ) 或者 MLD(Multicast Listener Discovery， 组播监听发现 ) 加入请求， 消息建 立在 PDP(Packet Data Protocol， 分组数据协议 ) 上下文上， 用来表示具体对接收某一个多 媒体组播业务感兴趣 ；
步骤 202、 GGSN 向 BM-SC 发送 AAR 认证请求以便使得发送激活请求的 UE 能够接收
所感兴趣的业务的数据 ；
步骤 203、 BM-SC 将认证响应决定包含在 AAA 消息中发送给 GGSN， AAA 消息和 APN(Access Point Name， 接入点名称 ) 一起被用来创建 MBMS UE CONTEXT( 多媒体广播组 播用户设备上下文 )， 如果 AAA 消息指示用户没有通过认证则流程终止 ；
步骤 204、 GGSN 向 SGSN 发送 MBMS Notification Request， 其中包含 IP 组播地址， APN， NSAPI(Network Service Access Point Identifier， 网络服务接入点标识 ) ；
步骤 205、 SGSN 向 GGSN 发送 MBMS Notification Response(cause) 响应， cause 用来指示 MBMS 业务激活是否成功 ；
步骤 206、 SGSN 创建 MBMS UE Context 并且向 GGSN 发送 Create MBMS Context Request( 创建多媒体广播组播上下文请求 ) ；
步骤 207、 GGSN 向 BM-SC 发送 AAR 消息为 UE 鉴权 ；
步骤 208、 BM-SC 向 GGSN 返回将鉴权结果， 鉴权结果包含在 AAA 消息中 ；
步骤 209、 如果 GGSN 没有承载上下文来为这个业务提供承载， 比如 GGSN 没有注册， 那么 GGSN 需要再向 BM-SC 发送注册请求， 如果没有为承载的业务分配 TMGI， 那么 BM-SC 将 为其分配新的 TMGI， 并由 AAA 消息传送给 GGSN ； 步骤 210、 BM-SC 返回 AAA 消息给 GGSN， 其中包含为 MBMS 业务的提供承载的承载 上下文信息并且将 GGSN 存入到 BM-SC 承载上下文中的下游节点中 ；
步骤 211、 GGSN 创建 MBMS UE Context 并且向 SGSN 返回 Create MBMS Context Response( 创建多媒体广播组播上下文响应 )。
图 3 所示是 MBMS 信道映射图。点到点的无线承载是双向承载， 包括逻辑信道 DTCH( 专用业务信道 )、 传输信道 DPCH( 专用信道 ) 和物理信道 DPCH( 专用物理信道 ) 或 SCCPCH( 辅公共控制物理信道 )。点到多点的无线承载是单向承载， 包括逻辑信道 MTCH(MBMS 业务信道 )、 传输信道 FACH( 前向接入信道 ) 和物理信道 SCCPCH( 辅公共控制物 理信道 )。逻辑信道 MTCH 是为由一个小区提供的每个 MBMS 服务而配置的并且用于将 MBMS 服务的用户平面数据发送给多个 UE。 逻辑信道 MCCH(MBMS 控制信道 ) 是点到多点下行链路 信道并且被用于发送与 MBMS 相关联的控制信息。
现有的 MBMS 业务发送方式是 UTRAN(UMTS 无线接入网 ) 根据小区中订阅某一 MBMS 业务的 UE 数目来决定是采用 PTP 或是 PTM( 点到多点 ) 来承载该 MBMS 业务。然而基于 UE 的个数来决定采用何种无线承载方式并不是很合理。例如分别给 5 个靠近小区中心的 UE 建立 PTP 的无线承载方式所带来的干扰可能要小于在整个网络中使用 PTM 的无线承载方式 多播该业务所带来的干扰。不过如果这 5 个 UE 在小区的边缘， 则可能使用 PTM 的无线承载 方式会带来较小的干扰。
另一个要考虑的因素是 MBMS 业务的服务质量， 对于使用较高带宽的 MBMS 业务， 无 线承载方式切换的门限， 即订阅该业务的 UE 数目要小于使用较少无线资源的 MBMS 业务所 对应的切换门限。当业务的无线承载方式发生变化时， 接收该业务的 UE 在 RLC( 无线链路 控制 ) 子层和 MAC( 媒体接入控制 ) 子层对应的实体将进行重建。
如果 UE 接收的是后台业务， 则当该业务的无线承载方式从 PTP 切换到 PTM 时， UE 在 RLC 子层对应的实体将从 AM 模式切换到 UM 模式， 在 MAC 子层对应的实体从 MAC-d 切换到 MAC-m， 逻辑信道从 DTCH 切换到 MTCH， 传输信道从 DPCH 切换到 FACH ； 反之亦然。如果 UE 接
收的是流媒体业务， 则当该业务的无线承载方式从 PTP 切换到 PTM 时， UE 在 MAC 子层对应的 实体从 MAC-d 切换到 MAC-m， 逻辑信道从 DTCH 切换到 MTCH， 传输信道从 DPCH 切换到 FACH ； 反之亦然。
通过对图 2 的分析， 可知现有的多媒体广播组播业务的实现方式涉及多个网元并 且流程比较复杂， 且无线承载方式的切换方法不够合理、 过于繁琐。 发明内容
本发明要解决的技术问题是提供一种无线承载选择方法， 业务实现过程简单， 无 线承载切换合理。
本发明提出一种无线承载选择方法， 包含 ：
无线网络控制器收到会话开始请求时， 向终端发送业务相关信息 ；
终端向无线网络控制器反馈响应消息， 当终端为该业务的订购用户时， 无线网络 控制器根据终端返回的响应消息中的承载方式标识的指示为终端分配相应的承载方式。
进一步的， 上述方法还可具有以下特点， 终端向广播组播服务中心发送订购请求， 请求中携带承载方式标识 ； 广播组播服务中心返回订购响应给终端， 订购响应中携带业务 标识、 可能性因子和承载方式标识， 终端保存该业务标识、 可能性因子和承载方式标识， 广 播组播服务中心将该可能性因子发送给无线网络控制器。
进一步的， 上述方法还可具有以下特点， 通过如下方式判断终端是否为该业务的 订购用户 ： 所述业务相关信息中包含可能性因子， 所述终端检查该可能性因子和终端本地 保存的可能性因子是否一致， 如果一致， 则终端为该业务的订购用户， 在响应消息中携带承 载方式标识， 如果不一致， 则终端不是该业务的订购用户。
进一步的， 上述方法还可具有以下特点， 通过如下方式判断终端是否为该业务的 订购用户， 所述终端返回的响应消息中携带可能性因子和承载方式标识， 所述无线网络控 制器检查该响应消息中的可能性因子是否和无线网络控制器的可能性因子一致， 如果一 致， 则终端为该业务的订购用户， 如果不一致， 则终端不是该业务的订购用户。 。
进一步的， 上述方法还可具有以下特点， 所述承载方式标识指示需要为终端分配 点到点无线承载时， 无线网络控制器为此用户终端分配点到点无线承载， 如果承载方式标 识未指示需要为终端分配点到点无线承载， 则为此用户终端分配点到多点无线承载。
综上所述， 本发明提供了一种无线承载方式， 根据终端的无线承载标识选择承载 方式， 实现简单方便。 附图说明
图 1 现有 MBMS 业务系统结构模型 ； 图 2 现有 MBMS 组播业务激活流程 ； 图 3 现有 MBMS 信道映射图 ； 图 4 本发明实施例中实现 MBMS 业务的 BM-SC 模块划分图 ； 图 5 本发明实施例组播广播业务实现方法流程图 ； 图 6 本发明实施例 UE 主动请求 PTP 承载流程图 ； 图 7 本发明实施例 BM-SC 向 GGSN 节点发送可能性因子流程图 ；图 8 本发明实施例无线承载选择方法流程图。具体实施方式
本发明提供一种 MBMS 业务的实现方法， 对 MBMS 业务进行区分， 包括 ： 对业务添加 业务类型标识， 将业务区分为需要订购的业务和不需要订购的业务， 根据业务类型标识来 判断业务是否需要用户订购后才能接收。对需要用户订购的业务， 在发送业务数据前对已 订购此业务的用户终端发送用 MUK(MBMS User Key， 多媒体广播组播业务用户密钥 ) 加密的 业务密钥 MSK(MBMS Service Key， 多媒体广播组播业务密钥 )， 还下发使用业务密钥加密的 传输密钥， 并对业务流加密， 终端利用用户密钥解密加密的业务密钥， 得到业务密钥， 利用 业务密钥解密加密的传输密钥， 利用传输密钥解密加密的节目流， 得到节目流 ； 对不需要用 户订购的业务， 不下发 MTK(MBMS Traffic Key， 多媒体广播组播业务传输密钥 )， 不对下发 的业务流加密。后续说明中， 对 MUK 简称为用户密钥， MSK 简称为业务密钥， MTK 简称为传输 密钥。
请参阅图 4， 是本发明实施例 BM-SC 网元节点功能模块划分图 ：
业务通告模块 401， 用于向用户终端提供业务指南信息， 业务指南信息中包含媒体 和会话描述， 比如视频和音频的编码类型， 多媒体业务标识， 地址和传送时间等等。 业务密钥模块 402， 用于生成和管理业务密钥， 在业务控制模块的触发下， 使用用 户密钥加密业务密钥， 向用户发送加密业务密钥， 并且能够向其他模块同步业务密钥， 例如 和流密钥管理模块同步业务密钥。
业务控制模块 403， 提供 GMB 接口功能， 能够向下个网元节点 GGSN 发送会话开始和 会话结束信令， 并且可以触发业务密钥模块下发加密的业务密钥， 触发业务通告模块下发 业务指南信息， 和触发流密钥管理模块下发加密的传输密钥和加密业务流 ；
订购管理模块 404， 用来处理用户的订购请求和管理用户的订购关系。
流密钥管理模块 405， 用来生成和管理传输密钥， 在业务控制模块的触发下， 用业 务密钥 MSK 加密传输密钥 MTK 得到加密传输密钥 EncryptedMTK， 使用传输密钥加密业务流， 下发 Encrypted MTK、 加密业务流给用户终端。
用户终端使用和 BM-SC 交互生成的用户密钥解密 Encrypted MSK 生成 MSK， 再用 MSK 解密 Encrypt MTK 得到 MTK， 用 MTK 解密加密业务流得到业务流。
内容提供商 406， 用于提供多媒体广播组播业务， 提供广电下发的节目或者是自己 制作的流媒体广告电视等等。 其中， 内容提供商也可以独立于多媒体广播组播中心， 为一个 独立模块。
请参阅图 5， 是本发明实施例多媒体组播广播业务实现方法流程图 ：
管理员配置业务时对业务进行分类， 分为需要用户订购的业务和不需要订购就可 以直接播放的 ( 比如流媒体广告 ) 业务， 通过对业务添加业务类型标识进行区分， 设定业务 类型标识为 SubscribeFlag。或者建立一数据库， 保存业务及其业务类型， 在使用该业务时 查询数据库， 获知业务类型。
步骤 501、 业务控制模块在传输节目前， 查询即将发送的业务的业务类型标识 SubscribeFlag， 根据业务类型标识作出判断， 确定业务是需要用户订购的业务还是不需要 订购的业务， SubscribeFlag 为 1 则表明为需要订购的业务， SubscribeFlag 为 0 则为不需
要订购的业务， 也可以使用其他数字或符号表示业务类型， 比如为 0 表示是需要订购的业 务， 为 1 表示为不需要订购的业务， 本发明对此不作限定。如果是需要用户订购的业务， 转 步骤 502， 否则， 转步骤 503 ；
步骤 502、 如果业务类型标识为需要用户订购的业务， 比如 SubscribeFlag 为 1 时， 业务控制模块通过 Gmb 接口向 GGSN 发送会话开始请求， 通知网络为数据传输建立承载 ； 业 务控制模块通知业务密钥模块将业务对应的业务密钥使用用户密钥加密后下发给用户终 端， 还通知流密钥管理模块生成传输密钥 MTK， 使用 MSK 加密 MTK， 使用 MTK 加密业务流， 下 发加密后的 MTK、 加密的业务流给已经订购此业务的用户终端， 从而确保只有订购者才能够 接收加密的业务流， 播放即将下发的节目， 转步骤 504 ；
步骤 503、 如果业务类型标识为不需要订购就可以播放的业务， 如 SubscribeFlag 为 0 时， 流密钥控制模块不对业务流加密， 同时不对用户终端下发 MTK， 减少了网络资源消 耗， 转步骤 505 ；
步骤 504， 终端接收加密的 MSK， 加密的 MTK 和加密业务流， 使用用户密钥解密接收 到的加密的 MSK， 得到 MSK， 使用 MSK 解密加密的 MTK， 得到 MTK， 使用 MTK 解密加密业务流， 播放业务流， 结束。 步骤 505， 终端接收并播放业务流， 结束。
其中， 在步骤 501 之前， 还包含步骤， 业务通告模块向终端发送业务指南信息， 终 端根据该业务指南信息选择业务， 向订购管理模块发出订购请求， 订购业务， 订购管理模块 响应该订购请求。
本发明还提供了一种 MBMS 业务实现方式过程中能简单有效的选择无线承载方式 的方法， 包括 ： 不针对小区中订购业务的 UE 的数目来选择无线承载方式， 用户终端可以在 订购请求中主动带上承载方式标识， RNC 向 UE 发送 MBMS 业务相关信息时， UE 向 RNC 的返回 消息中携带承载方式标识， RNC 根据承载方式标识决定为 UE 选择 PTP 承载还是 PTM 承载。
请参照图 6， 是本发明实施例 UE 主动请求 PTP 承载流程图 ：
步骤 601、 UE 根据 BM-SC 的业务通告模块 401 下发的业务指南选择想订购的业务， 向 BM-SC 发出订购请求， 请求中携带了承载方式标识 PTPFLAG， 标明 UE 选择何种承载方式， 比如是否选择 PTP 承载， 是否需要网络为其分配专用控制信道 DCCH ；
步骤 602、 BM-SC 向 UE 返回订购成功响应消息， 消息中包含业务标识、 PTPFLAG 和 可能性因子 ；
可能性因子是业务相关的参数， 用来确定此业务是否为终端订购的业务。比如业 务 1 包含可能性因子 1234， 当然可以用更复杂的参数表示可能性因子。用户终端订购业务 后， 网络侧返回该业务的可能性因子给该用户终端， 在业务控制模块发送会话开始请求时 携带业务 1 的可能性因子， 终端与 RNC 交互时对可能性因子作检查， 如果通过则为已订购业 务， 未通过则为未订购业务。
步骤 603、 UE 收到响应消息后， 保存响应消息中的业务标识、 PTPFLAG 和可能性因 子。
上述流程的作用是确认终端是否能够针对某个具体的业务具有选择 PTPFLAG 的 能力， 只有在订购请求成功后， 网络侧返回响应， 终端才会保存 PTPFLAG， 从而在后续的 UE 向 RNC 返回消息中才能带上 PTPFALG。
UE 保存可能性因子用来对在 RNC 发出 MBMS 接入相关信息中的可能性因子做判断， 而 RNC 的可能性因子是由 BM-SC 通过核心网发送过来的， 具体请参照图 7 ：
步骤 701、 BM-SC 发送 Session Start Request( 会话开始请求 ) 消息给 GGSN， 该 请求消息包含在 RAR 消息中， 在该消息中添加新的 AVP 数据包， 新的 AVP 数据包中包含可能 性因子 ；
步骤 702、 GGSN 收到 BM-SC 发送的会话开始请求消息后， 向 BM-SC 返回 RAA 响应消 息。
步骤 703、 GGSN 向下游节点 SGSN 发送 Session Start Request( 会话开始请求 ) 消息， 消息中包含了可能性因子 ；
步骤 704、 SGSN 继续向下游节点 RNC 发送 Session Start Request 消息， 确保在网 络承载资源分配的同时将可能性因子发送给 RNC。
请参照图 8， 是本发明实施例一种 MBMS 业务实现过程中无线承载选择方法的流程 图。
步骤 801、 当 RNC 收到 SGSN 发送的会话开始请求消息 (Session Start Request) 后， 在 MCCH 上发送业务相关信息给 UE， 业务相关信息包含接入信息、 业务标识和可能性因 子； 步骤 802、 UE 接收业务相关信息并根据业务标识确定具体为哪个业务， 再对可能 性因子做可能性检查， 如果通过可能性检查， 则执行步骤 803， 否则， 执行步骤 804 ；
所述检查是指将本地保存的可能性因子和接收到的可能性因子进行比较， 如果二 者一致， 则通过可能性检查， 如果二者不一致， 则未通过可能性检查。
步骤 803、 通过可能性检查则表示用户终端为已订购用户， UE 向 RNC 返回响应消息 并且带上业务标识和承载方式标识， 承载方式标识指示是否需要为此用户终端分配点到点 无线承载， 如果需要， 转步骤 806， 否则， 转步骤 805 ；
步骤 804、 未通过可能性检查则表示用户终端为未订购用户， UE 向 RNC 返回响应并 带标识表明未订购此业务， RNC 不为用户终端分配无线承载， 结束。
步骤 805、 如果 UE 向 RNC 返回的响应消息中未标识需要为此用户终端分配点到 点无线承载或者标识需要为此用户分配点到多点无线承载， 则选择点到多点无线承载， 用 MCCH 向用户终端发送承载设置信息， 用 SCCPCH 来传输广播数据， 结束。
步骤 806、 如果 UE 向 RNC 返回的响应消息中标识了需要为用户分配点到点无线承 载， 则为此用户终端分配点到点无线承载， 用 DCCH 向用户终端发送承载设置信息， 用 DPCH 来传输广播数据， 结束。
在本发明另一实施例中， 步骤 801 中， RNC 发送的业务相关信息中可以不携带可能 性因子， 终端返回响应消息给 RNC 时携带业务标识、 承载方式标识和可能性因子。RNC 对该 响应消息中的可能性因子进行检查， 如果通过可能性因子检查， 再进一步对该响应消息中 的承载方式标识进行判断， 如果承载方式标识指示需要为用户终端分配点到点无线承载， 则为此用户终端分配点到点无线承载， 如果承载方式标识未指示需要为用户终端分配点到 点无线承载， 则为此用户终端分配点到多点无线承载。
上述无线承载方式的选择方法可以应用在本发明多媒体广播组播业务实现方法 中， 在步骤 502 中， 业务控制模块通过 Gmb 接口向 GGSN 发送会话开始请求， 通知网络为数据
传输建立承载时， 使用该无线承载选择方法为终端建立承载。
本发明提出的选择无线承载方式的方法， UE 在订购业务时主动选择承载方式标 识， 标明 UE 需要 RNC 为其分配何种无线承载方式。UE 对 RNC 发出的 MBMS 业务信息作可能 性检查， 如果检查通过则证明 UE 为已订购用户， 进一步地向 RNC 回复承载方式标识， 如果表 明需要 PTP 承载则为 UE 分配点到点承载， 用 DCCH 向移动终端发送承载设置信息， 用 DPCH 传输业务数据 ； 若表明不需要 PTP 承载则为 UE 分配点到多点承载， 用 MCCH 向移动终端发送 承载设置信息， 用 SCCPCH 传输业务数据。
综上所述， 本发明实施例的技术方案明显简化了多媒体广播多播业务的实现方 式， 本技术方案中直接通过对业务进行区分， 对需要订购才能播放的业务在业务即将开始 时或开始前由 BM-SC 向订购此业务的 UE 下发业务密钥， 对不需要订购的业务流不加密， 从 而减少了网络广播 MTK 带来的资源消耗。
以上所述实现方式在业务处理领域可以有多种变化， 凡在本发明的精神和原则之 内， 所做的任何修改、 等同替换、 改进等， 均应包含在本发明的保护范围之内。