技术领域
[0001] 本
发明涉及通信技术领域，特别是涉及一种支持IP多媒体子系统(IMS)终端享用现有交互式网络电视(IPTV)业务的系统和方法。
[0002] 背景技术
[0003] 会话发起协议(SIP，Session Initiation Protocol)是由IETF(Internet工程任务组)制订的多媒体通信系统
框架协议之一，是用于建立、改变或结束多媒体会话的应用层协议，与实时传输协议/实时流传输控制协议(RTP/RTCP：Realtime Transport Protocol/Realtime Transport ControlProtocol)、会 话 描 述 协 议 (SDP，Session Description Protocol)、实时流传输协议(RTSP，Real-Time Streaming Protocol)、域名系统(DNS，Domain NameSystem)等协议配合，共同完成IP多媒体子系统(IMS)中的会话建立及媒体协商；一旦建立会话，
媒体流将使用RTP协议在承载层中直接传送，在一次会话中可以灵活的交互多种媒体。
[0004] IMS是3GPP R5阶段增加的WCDMA网络中
叠加在已有分组域之上的一个子系统，采用分组域为其上层控制信令和媒体传输的承载通道，引入SIP协议作为业务控制协议，利用SIP简单、易扩展、媒体组合方便的特点，通过将业务控制与承载控制分离，提供丰富的多媒体业务；IMS中主要的功能实体包括控制用户注册、会话控制等功能的呼叫控制功能实体(CSCF)、提供各种业务逻辑控制功能的应用
服务器(AS)、集中管理用户签约数据的归属用户服务器(HSS)以及用于实现与
电路交换网互通的媒体网关控制功能/IP多媒体网关(MGCF/IM-MGW)，用户通过当前所在地代理
节点P-CSCF接入IMS，会话和业务触发控制及与AS的业务控制交互则由其注册地的归属域服务节点S-CSCF完成。
[0005] IPTV也叫交互式网络电视，是集互联网、多媒体、通信等多种技术于一体，提供交互式数字媒体服务的崭新技术。流媒体业务或IPTV业务是近几年迅速发展的一种新业务，流媒体业务利用
流式传输技术，在包交换网络 上传输多媒体文件，包括视频、音频等文件内容。这些内容在
访问时无需完全下载就可以立即播放。流媒体实现的关键技术就是流式传输技术，而流式传输技术是把连续的视频和音频信息经过处理后放上
网站服务器，让用户一边下载一边观看、收听，而不需要等整个文件下载到自己机器后才可以观看的网络传输技术。
[0006] 以D类IP地址发送业务的技术，用于发送者同时向多个接收者(大于等于一个)发送相同业务内容时，因为相同内容只需要向
指定组播地址发送一份即可，因而可以有效降低业务发送方和传输网络的负载。使用组播技术传送业务流，无论接收方有多少，业务发送方只需要发送一个数据流。组播数据在从业务发送点到接收方的传送路径上的传送点之间只产生单一的数据流，显而易见使用组播技术可以减轻发送者(业务提供方)的负荷，并且可以有效利用网络资源。
[0007] 为了获取组播内容，内容接收方(用户)通过加入业务组播组(如使用IGMP协议)来要求邻接的路由器发送业务内容给自己，而路由器之间则通过组播路由协议(如PIM-SM(协议无关组播-稀疏模式)协议等)与其它路由器交互以建立组播转发路径，这样组播业务内容就可以从组播源沿组播转发路径传递给内容接收方。
[0008]
视频点播(VoD)业务通常采用数字
版权管理(DRM，Digital RightManagement)方式对媒体流内容进行保护，DRM基本构架如图1所示：DRM系统主要由内容源、版权发布中心和DRM Agent组成：(1)内容源对内容进行加密，把内容ID和对应的密钥传送给版权发布中心；(2)版权发布中心根据用户的
请求，下发
版权对象；(3)DRM Agent接收媒体流，根据媒体流中的RIURL请求相应内容的版权对象(RO，Right Object)，播放媒体流。 [0009] 传统的电视业务中，通过
条件接收系统(CA，Conditional Access)系统对媒体流进行保护，CA系统使用多层密钥保护机制，其密钥机制如图2所示：
[0010] 媒体流通过控制字(CW，Control Word)进行加扰；控制字CW用业务密钥(SK，Service Key)保护，并通过
授权控制信息(ECM，Entitle ControlMessage)传送给终端；业务密钥SK用个人分发密钥PDK(Personal Distribution Key)保护，并通过授权管理信息(EMM，Entitle Manage Message)传送给终端。
[0011] 业务层保护是指用户在请求多媒体内容时，多媒体服务器对该内容的传输过程加密，传输过程结束后，该保护也随之结束。传输源和目的源需要某种密钥管理机制。 [0012] IMS网络部署初期，IMS网络并不会支持IPTV业务，同时运营商基于市场竞争的需求会基于独立的IPTV解决方案部署IPTV业务，随着IPTV业务的发展，运营商如何利用现网的资源，即应用现在已部署的IPTV网络以及IMS网络，为IMS用户提供IPTV业务，或如何封装后，对外可以宣称支持基于IMS的IPTV方案是个有待解决的问题。 发明内容
[0013] 有鉴于此，本发明的目的是提供一种支持IMS终端享用现有IPTV业务的系统和方法，以及支持IMS终端享用现有IPTV网络VoD和LTV业务的方法，以解决利用现在已部署的IPTV网络以及IMS网络，为IMS用户提供IPTV业务的问题。
[0014] 为达到上述目的，本发明的技术方案包括：
[0015] 一种支持IP多媒体子系统IMS终端享用现有IPTV业务的系统，包括现有IPTV网络Deployed A/V System、IMS核心网IMS core、IP分组核心网IPCore、接入网，IMS的用户终端IMS UE，该系统还包括：业务网关，其中，
[0016] 所述IMS UE，用于通过接入网、IP分组核心网接入IMS核心网，从
电子节目单EPG中获取节目单信息，向业务网关发起包含节目单信息的业务请求；
[0017] 所述业务网关，包含信令面控制实体，用于将接收到的来自IMS UE的业务请求，转换为现有IPTV网络支持的协议格式，以现有IPTV网络终端的方式向现有IPTV网络发起包含节目单信息的业务请求，获取流媒体服务器标识，将来自现有IPTV网络的消息转换为IMS核心网支持的协议格式，建立信令面连接；
[0018] 所述现有IPTV网络，用于在业务网关的控制下与IMS UE建立信令面连接后，通过自身内的流媒体服务器向IMS UE发送媒体流。
[0019] 其中，所述电子节目单EPG位于现有IPTV网络中，或位于IMS核心网 内，或与业务网关为一个实体，或是独立存在的一个服务器。
[0020] 其中，所述现有IPTV网络中的流媒体服务器所发送的媒体流直接到达IMS UE，或通过承载面实体的转换后到达IMS UE。
[0021] 其中，所述承载面实体是业务网关内新设置的逻辑实体，或者，所述承载面实体是IMS Core内的媒体资源功能MRF实体。
[0022] 其中，所述IMS UE与业务网关之间的信令面控制基于会话发起协议SIP，所述业务网关与现有IPTV网络之间的信令面控制基于超文本传输协议HTTP、简单对象访问协议SOAP或实时流传输协议RTSP。
[0023] 一种支持IMS终端享用现有IPTV业务的方法，包括：
[0024] IMS UE从电子节目单EPG中获取节目单信息；
[0025] 业务网关内的信令面控制实体接收到的来自IMS UE的包含节目单信息业务请求后，将其转换为现有IPTV网络支持的协议格式，以现有IPTV网络终端的方式向现有IPTV网络发起业务请求，获取业务信息，将来自现有IPTV网络的消息转换为IMS核心网支持的协议格式，建立信令面连接；
[0026] 在现有IPTV网络与IMS UE建立信令面连接后，现有IPTV网络通过自身内的流媒体服务器向IMS UE发送媒体流。
[0027] 其中，所述IMS UE从电子节目单EPG中获取节目单信息的过程包括： [0028] 如果所述EPG位于现有IPTV网络中，所述IMS UE通过Ut
接口与现有IPTV网络交互，获取节目单信息；或者，
[0029] 如果所述EPG位于IMS核心网内，所述IMS UE与IMS核心网交互，获取节目单信息；或者，
[0030] 如果所述EPG与业务网关为一个实体，所述IMS UE与所述业务网关交互，获取节目单信息；或者，
[0031] 如果所述EPG是独立存在的一个服务器，所述IMS UE与该EPG服务器交互，获取节目单信息。
[0032] 其中，现有IPTV网络通过自身内的流媒体服务器向IMS UE发送媒体流的过程包括：所述现有IPTV网络中的流媒体服务器直接向IMS UE发送媒体流，或者，所述现有IPTV网络中的流媒体服务器向承载面实体发送媒体流，由承载面实体将接收到的媒体流转换为IMS UE能够识别的格式后， 再发送给IMS UE。
[0033] 其中，所述承载面实体是业务网关内的逻辑实体，或者，是IMS Core内的MRF实体；所述业务网关内的信令面控制实体由IPTV AS实现。
[0034] 其中，所述IMS UE接收到的媒体流是经过加密的；
[0035] 所述IMS UE应用已获得的密钥对接收的媒体流解密后，进行显示。 [0036] 一种支持IMS终端享用现有IPTV网络VoD业务的方法，包括：
[0037] IMS UE从电子节目单EPG中获取节目单信息；
[0038] 业务网关内的信令面控制实体接收到的来自IMS UE的包含节目单信息业务请求后，将其转换为现有IPTV网络支持的协议格式，以现有IPTV网络终端的方式向现有IPTV网络发起业务请求，获取VoD流媒体服务器标识，将来自现有IPTV网络的消息转换为IMS核心网支持的协议格式，建立信令面连接；
[0039] VoD流媒体服务器向IMS UE发送媒体流；
[0040] 业务网关内的信令面控制实体获取VCR控制命令，控制VoD流媒体服务器执行VCR控制命令所指示的操作。
[0041] 其中，所述业务网关内的信令面控制实体获取VCR控制命令的过程为： [0042] 业务网关内的信令面控制实体使用订阅Subscribe向IMS UE订阅VCR控制，IMS UE通知Notify其VCR控制命令；或者，
[0043] 在IMS UE得到媒体流后，通过扩展SIP信令通知业务网关内的信令面控制实体其VCR控制命令。
[0044] 其中，所述VoD业务采用RTP流封装；所述建立信令面连接的方式为：业务网关内的信令面控制实体和VoD流媒体服务器之间建立信令面连接；
[0045] 所述VoD流媒体服务器向IMS UE发送媒体流的过程为：所述VoD流媒体服务器直接向IMS UE发送媒体流；或者，所述VoD流媒体服务器向承载面实体发送媒体流，由承载面实体将接收到的媒体流转换为IMS UE能够识别的格式后，再发送给IMS UE； [0046] 所述控制VoD流媒体服务器执行VCR控制命令所指示的操作的过程为：所述业务网关内的信令面控制实体给VoD流媒体服务器发起包含VCR控制命令的RTSP连接请求，控制VoD流媒体服务器执行VCR控制命令所指示 的操作。
[0047] 其中，所述VoD业务采用RTP流封装；所述建立信令面连接的方式为：所述业务网关内的信令面控制实体控制承载面实体与VoD流媒体服务器之间建立信令面连接； [0048] 所述VoD流媒体服务器向IMS UE发送媒体流的过程为：所述VoD流媒体服务器直接向IMS UE发送媒体流；或者，所述VoD流媒体服务器向承载面实体发送媒体流，由承载面实体将接收到的媒体流转换为IMS UE能够识别的格式后，再发送给IMS UE； [0049] 所述控制VoD流媒体服务器执行VCR控制命令所指示的操作的过程为：所述业务网关内的信令面控制实体通过承载面实体给VoD流媒体服务器发起包含VCR控制命令的连接请求，控制VoD流媒体服务器执行VCR控制命令所指示的操作。
[0050] 其中，所述承载面实体是业务网关内的逻辑实体，或者，是IMS Core内的MRF实体；所述业务网关内的信令面控制实体由IPTV AS实现。
[0051] 其中，所述IMS UE接收到媒体流是经过加密的，IMS UE接收到媒体流之后，进一步包括：
[0052] 业务网关内的信令面控制实体获取IMS UE从接收到的媒体流中识别出RIF的标识，代理IMS UE从该RIF标识所指示的RIF中获取版权对象RO，应用该RO得到的用于对媒体流内容进行加密的内容加密密钥，再应用业务网关内的信令面控制实体和IMS UE之间的共享密钥对该已解密的内容加密密钥进行加密，之后，将加密后的内容加密密钥下发给IMS UE；
[0053] IMS UE应用与业务网关之间的共享密钥解密已加密的内容加密密钥，应用该内容加密密钥对已加密媒体流进行解密，显示给用户。
[0054] 其中，业务网关内的信令面控制实体获取RIF的标识的过程包括： [0055] 业务网关内的信令面控制实体使用订阅Subscribe消息向IMS UE订阅RIF标识，IMS UE通知Notify业务网关内的信令面控制实体其从接收到的媒体流中识别出的RIF； [0056] IMS UE从接收到的媒体流中识别出RIF的标识后，通过info消息上报RIF标识给业务网关内的信令面控制实体。
[0057] 其中，所述业务网关内的信令面控制实体向IMS UE下发RIF地址订阅请求，与业务网关内的信令面控制实体向IMS UE下发VCR控制命令订阅请求是相同的订阅请求或不同的订阅请求。
[0058] 其中，所述IMS UE接收到媒体流是经过加密的，
[0059] 所述业务网关内的信令面控制实体以现有IPTV网络终端的方式向现有IPTV网络发起的业务请求中包含请求内容加密密钥的信息；
[0060] 所述业务网关内的信令面控制实体获得内容加密密钥后，进一步包括：业务网关内的信令面控制实体应用与IMS UE之间的共享密钥对该内容加密密钥进行加密，之后，将加密后的内容加密密钥下发给IMS UE；
[0061] IMS UE接收到媒体流之后，进一步包括：应用与业务网关之间的共享密钥解密已加密的内容加密密钥，再应用该内容加密密钥对已加密媒体流进行解密，显示给用户。 [0062] 其中，所述IMS UE接收到媒体流是经过加密的，在VoD业务采用TS流封装时，包括：
[0063] 所述建立信令面连接的方式为：业务网关内的信令面控制实体直接或通过承载面实体与VoD流媒体服务器间建立起RTSP连接；
[0064] 承载面实体通过业务网关内的信令面控制实体与IMS UE之间完成媒体流的传输参数协商；
[0065] 承载面实体接收到来自VoD流媒体服务器的经TS方式封装的组播流后，解析该TS流，从解析后的TS流中获取RTP流、ECM流、EMM流，并从ECM流中取出应用业务网关内的信令面控制实体和VoD流媒体服务器共享密钥加密的SK，从EMM流中取出应用SK加密的CW，将加密的SK和CW通知给业务网关内的信令面控制实体；
[0066] 业务网关内的信令面控制实体应用与VoD流媒体服务器共享密钥解密SK，并用SK解密CW，再应用与IMS UE共享的密钥对已解密的CW进行加密，将加密后的CW给下发给IMS UE，媒体面实体向IMS UE下发RTP流，IMS UE通过共享密钥解密得到CW，并用CW进一步解密媒体流并显示。
[0067] 其中，所述IMS UE接收到媒体流是经过加密的，在VoD业务采用TS 流封装时，包括：
[0068] 所述建立信令面连接的方式为：业务网关内的信令面控制实体直接或通过承载面实体与VoD流媒体服务器间建立起RTSP连接；
[0069] 承载面实体通过业务网关内的信令面控制实体与IMS UE之间完成媒体流的传输参数协商；
[0070] 承载面实体接收到来自VoD流媒体服务器的经TS方式封装的组播流后，解析该TS流，从解析后的TS流中获取RTP流、ECM流、EMM流，并从ECM流中取出应用业务网关内的信令面控制实体和VoD流媒体服务器共享密钥加密的SK，从EMM流中取出应用SK加密的CW，将加密的SK通知给业务网关内的信令面控制实体，将加密的CW下发给IMS UE； [0071] 业务网关内的信令面控制实体应用与VoD流媒体服务器共享密钥解密SK，再将应用与IMS UE共享密钥加密后的SK下发给IMS UE，MRF向UE下发RTP流和应用SK加密的CW流；
[0072] IMS UE通过共享密钥解密得到SK，并用SK解密加密的CW流得到CW，使用CW进一步解密媒体流并显示。
[0073] 一种支持IMS终端享用现有IPTV网络LTV业务的方法，包括：
[0074] IMS UE从电子节目单EPG中获取节目单信息；
[0075] 业务网关内的信令面控制实体接收到的来自IMS UE的包含节目单信息业务请求后，将其转换为现有IPTV网络支持的协议格式，以现有IPTV网络终端的方式向现有IPTV网络发起业务请求，获取LTV频道组播IP地址，将来自现有IPTV网络的消息转换为IMS核心网支持的协议格式，向P-CSCF返回包含频道组播IP地址的响应；并且，业务网关内的信令面控制实体经P-CSCF通过RACS进行接入侧和核心侧承载面组播控制，由P-CSCF给IMSUE返回包含频道组播IP地址或接入侧承载实体地址、以及安全相关参数的业务请求响应信息，建立信令面连接；接入侧承载实体将从内容源接收到的加密组播数据流传送给IMS UE；
[0076] IMS UE应用已获得的密钥对接收到的媒体流进行解密并显示。 [0077] 其中，若所述流传输方式为RTP传输方式，且IMS UE和LTV组播源间的媒体编解码类型匹配；
[0078] 则所述业务网关内的信令面控制实体获取LTV频道组播IP地址的同时，进一步包括：获取SEK及LTV组播源媒体能
力信息；业务网关内的信令面控制实体应用与IMS UE的共享密钥加密SEK，并将所获取的信息包含在返回给P-CSCF的响应中；所述所获取的信息包括加密的SEK、频道组播IP地址、LTV组播源媒体能力；
[0079] 所述接入侧承载实体接收到的加密组播数据流包括来自LTV组播源的媒体流和加密的内容加密密钥TEK流。
[0080] 其中，如果所确定的流传输方式为RTP传输方式，且IMS UE和LTV组播源间的媒体编码类型不匹配；
[0081] 则所述业务网关内的信令面控制实体获取频道组播IP地址的同时，进一步包括：获取节目密钥SEK及LTV组播源媒体能力信息；之后，所述业务网关内的信令面控制实体应用与IMS UE的共享密钥加密SEK，控制媒体面实体进行媒体转换，与LTV组播源间建立组播或单播隧道，并分配新的组播IP地址，控制媒体面实体为新的组播源；将频道组播IP地址、加密的SEK和媒体面实体组播源媒体能力信息包含在返回给P-CSCF的响应中； [0082] 所述接入侧承载实体接收到加密的组播数据流包括来自承载面实体的媒体流和加密的内容加密密钥TEK流。
[0083] 其中，所述IMS UE应用已获得的媒体密钥对接收到的媒体流进行解密的过程包括：
[0084] IMS UE应用与业务网关之间的共享密钥解密SEK；
[0085] 所述IMS UE应用SEK对组播密钥流进行解密，获得内容加密密钥TEK；之后，应用该TEK对接收到的媒体流进行解密。
[0086] 其中，若所述流传输方式为RTP传输方式，且IMS UE和LTV组播源间的媒体编解码类型匹配；
[0087] 则所述业务网关内的信令面控制实体获取LTV频道组播IP地址的同时，进一步包括：获取节目密钥SEK、用SEK加密的内容密钥TEK和LTV组播源媒体能力信息；业务网关内的信令面控制实体利用SEK解出TEK，并用与IMS UE的共享密钥加密TEK；并将组播IP地址、加密的TEK、组播源媒体能力信息包含在返回给P-CSCF的响应中； [0088] 所述接入侧承载实体接收到的加密组播数据流中包括来自LTV组播源的媒体流。 [0089] 其中，如果所确定的流传输方式为RTP传输方式，且IMS UE和LTV组播源间的媒体编码类型不匹配；
[0090] 则所述业务网关内的信令面控制实体获取频道组播IP地址的同时，进一步包括：获取节目密钥SEK、用SEK加密的内容密钥TEK及LTV组播源媒体能力信息；之后，所述业务网关内的信令面控制实体利用SEK解出TEK，并用与IMS UE的共享密钥加密TEK，还控制媒体面实体进行媒体转换，与LTV组播源间建立组播或单播隧道，并分配新的组播IP地址，控制媒体面实体为新的组播源；将频道组播IP地址、加密的TEK和媒体面实体组播源媒体能力信息包含在返回给P-CSCF的响应中；
[0091] 所述接入侧承载实体接收到加密的组播数据流中包括来自承载面实体的媒体流。 [0092] 其中，所述IMS UE应用已获得的媒体密钥对接收到的媒体流进行解密的过程包括：
[0093] IMS UE应用与业务网关之间的共享密钥解密TEK；进一步应用所述TEK对接收到的媒体流进行解密。
[0094] 其中，如果确定的流传输方式为TS传输方式，所述建立信令面控制的过程为： [0095] IPTV AS控制承载面实体与LTV组播源之间建立组播流；
[0096] 承载面实体接收到来自LTV组播源的经TS方式封装的组播流后，解析该TS流，从解析后的TS流中获取RTP流、ECM流、EMM流，并从ECM流中取出应用业务网关内的信令面控制实体和LTV组播源共享密钥加密的SK，从EMM流中取出应用SK加密的CW，将加密的SK和CW通知给业务网关内的信令面控制实体；
[0097] 业务网关内的信令面控制实体应用与LTV组播源共享密钥解密SK，并用SK解密CW，应用与IMS UE共享的密钥对已解密的CW进行加密，之后，业务网关内的信令面控制实体再分配在IMS核心网内有效的组播IP地址，并控制承载面实体将接收到的RTP流作为IMS核心网内的组播流，然 后，业务网关内的信令面控制实体将新分配的所述在IMS核心网内有效的组播IP地址或边界网关功能实体地址，以及应用与IMS UE共享的密钥加密的CW传送给IMS UE；
[0098] 所述IMS UE应用已获得的媒体密钥对接收到的媒体流进行解密的过程包括：IMS UE应用与业务网关内的信令面控制实体共享密钥对接收到的加密的CW进行解密，获取CW，之后，应用该CW对接收到的媒体流进行解密。
[0099] 其中，如果确定的流传输方式为TS传输方式，所述建立信令面控制的过程为： [0100] IPTV AS控制承载面实体与LTV组播源之间建立组播流；
[0101] 承载面实体接收到来自LTV组播源的经TS方式封装的组播流后，解析该TS流，从解析后的TS流中获取RTP流、ECM流、EMM流，并从ECM流中取出应用业务网关内的信令面控制实体和LTV组播源共享密钥加密的SK，从EMM流中取出应用SK加密的CW，将加密的SK通知给业务网关内的信令面控制实体，将加密的CW下发给IMS UE；
[0102] 业务网关内的信令面控制实体应用与LTV组播源共享密钥解密SK，并用与IMS UE的共享密钥对SK再次加密，之后，业务网关内的信令面控制实体再分配在IMS核心网内有效的组播IP地址，并控制承载面实体将接收到的RTP流和媒体密钥流作为IMS核心网内的组播流，然后，业务网关内的信令面控制实体将新分配的所述在IMS核心网内有效的组播IP地址或边界网关功能实体地址，以及应用与IMS UE共享的密钥加密的SK传送给IMSUE； [0103] 所述IMS UE应用已获得的媒体密钥对接收到的媒体流进行解密的过程包括： [0104] IMS UE应用与业务网关内的信令面控制实体共享密钥对接收到的加密的SK进行解密，获取SK，之后，再应用该SK对已接收到的加密的CW进行解密，获取CW，再应用CW对接收到的媒体流进行解密。
[0105] 其中，所述IPTV AS控制承载面实体与LTV组播源之间建立组播流的过程包括： [0106] 承载面实体通过组播路由协议和LTV组播源建立组播转发路径，或者通过应用层组播方式，在承载面实体和LTV组播源间建立单播隧道。
[0107] 其中，当核心侧承载网络支持组播功能时，所述通过RACS进行承载面组播控制的过程为：接入侧承载实体通过组播路由协议建立到现网IPTV系统中的内容源或MRF的组播转发路径；
[0108] 当核心侧承载网络不支持组播功能时，所述通过RACS进行承载面组播控制的过程为：IPTV AS通过RACS进行核心侧组播的控制；所述核心侧组播的控制包括通过应用层组播建立接入侧承载实体设备到内容源的单播或隧道路径；
[0109] 所述内容源为LTV组播源或承载面实体。
[0110] 其中，所述承载面实体是业务网关内的逻辑实体，或者，是IMS Core内的MRF实体；所述业务网关内的信令面控制实体由IPTV AS实现。
[0111] 本发明关键是，增加了一用于IMS网络和现有IPTV网络互通所需的业务网关，其包括信令面的控制功能，其还可以包括承载面功能。针对IMS网络初期IMS UE对IPTV的能力支持有限，不具备一些通用的IPTV终端功能，IMS网络并不会支持IPTV业务的状况，本发明解决了如何利用现网的资源，如已部署的IPTV网络以及IMS网络，为IMS用户提供IPTV业务的问题。不但丰富了IMS网络的业务，而且对IPTV的开展与普及提供了很好的平台。
附图说明
[0112] 图1是现有的DRM基本构架；
[0113] 图2是现有CA系统的多层密钥机制；
[0114] 图3是根据本发明一
实施例的IMS终端享用现有IPTV网络业务的系统架构图； [0115] 图4是基于图3所示系统构架的实现IMS UE享用现有IPTV业务的流程示意图； [0116] 图5是根据本发明一实施例的IMS UE享用现有IPTV网络VoD业务的实现
流程图；
[0117] 图6是根据本发明一实施例的IMS UE享用现有IPTV网络LTV业务的 实现流程图；
[0118] 图7是根据本发明另一实施例的IMS UE享用现有IPTV网络LTV业务的实现流程图。
[0119] 具体实施方式
[0120] 下面结合附图及具体实施例对本发明做进一步详细说明。
[0121] 图3所示为根据本发明一实施例的支持IMS终端享用现有IPTV网络业务的系统架构图。其包括现有IPTV网络(Deployed A/V System)110、IMS核心网(IMScore)130、IP分组核心网(IP Core)140、接入网150，IMS UE160，其中，该系统还包括业务网关120。 [0122] 现有IPTV网络(Deployed A/V System)110为已部署IPTV业务的网络，其内包括电子节目单(EPG)、
中间件(Middleware)、业务管理(ServiceManagement)功能实体、流媒体服务器(Streaming Server)以及其他功能(OtherEnabler)实体等。现有IPTV网络110具备媒体资源管理、EPG生成、内容分发网络(CDN)分发功能、条件接收(CA，Conditional Access)系统、业务层保护或数字
版权管理(DRM，Digital Right Management)等安全保护功能，提供视频点播(VoD，Video On Demand)，实时电视(LTV，Linear TV)等业务。 [0123] 业务网关120为本发明所新增加的网关，用于IMS网络和现有IPTV网络互通所需的业务网关，包括信令面的控制功能，其还可以包括承载面功能。
[0124] IMS core 130提供NGN会话业务，提供注册、鉴权、会话控制、业务触发、路由、计费、资源控制等功能；
[0125] IP分组核心网140可支持单播、组播和广播。
[0126] 接入网络150部分可采用各种IP接入方式，包括各种移动和固定宽带接入如DSL、3G、WiMax、DVB-T/H等各种接入方式。
[0127] IMS的用户终端(IMS UE)160与IMS core 130、IP分组核心网140以及接入网络150之间可直接交互信息。
[0128] 参见图3，上述系统的连接关系如下：
[0129] IMS UE，用于通过接入网、IP分组核心网接入IMS核心网，从EPG中获取节目单信息，向业务网关发起包含节目单信息的业务请求。
[0130] 在图3所示实施例中，上述EPG位于现有IPTV网络中，因此，IMS UE通过Ut接口与现有IPTV网络之间存在直接的连接关系，即图3中IMS UE与现有IPTV网络之间的虚线。在实际应用中，上述EPG还可以位于IMS核心网内，或与业务网关为一个实体，或是独立存在的一个EPG服务器。此时上述虚线将不存在，取而代之的是IMS UE与相应实体之间的连接。
[0131] 上述节目单信息包含节目标识、内容标识等，而且节目单信息内的各种标识以统一资源标识符(SIP URI)方式标识。
[0132] 业务网关，包含信令面控制实体，用于将接收到的来自IMS UE的业务请求，转换为现有IPTV网络支持的协议格式，以现有IPTV网络终端的方式向现有IPTV网络发起包含节目单信息的业务请求，将来自现有IPTV网络的消息转换为IMS核心网支持的协议格式，控制IMS UE与现有IPTV网络中建立信令面连接。上述业务网关内的信令面控制实体可以由IPTV AS来实现。
[0133] IMS UE与业务网关之间的信令面控制基于SIP，业务网关与现有IPTV网络之间的信令面控制基于超文本传输协议(HTTP)、或简单对象访问协议(SOAP，Simple Object Access Protocol)、或RTSP。因而，业务网关主要用于完成SIP协议请求和HTTP、SOAP、RTSP等请求之间协议的转换和会话状态的管理。
[0134] 现有IPTV网络，用于在业务网关的控制下与IMS UE建立信令面连接后，通过自身内的流媒体服务器向IMS UE发送媒体流。此时，媒体服务器所发送的媒体流直接到达IMS UE，也可以通过承载面实体的转换后到达IMS UE。有以下两种情况需要承载面实体的转换：一是IMS UE和媒体流内容的编解码格式不匹配，则此时可以由业务网关内的IPTV AS控制承载面实体完成转码；二是若现有IPTV网络中的媒体流基于TS方式传送，可以由IPTV AS控制承载面实体完成对TS的解复用后将RTP报文传送给IMS UE。
[0135] 上述承载面实体既可以是业务网关内新设置的逻辑实体，参见图3业务网关1 20内的虚线框，也可以是IMS Core内的媒体资源功能(MRF，Media ResourceFunction)实体，即包含媒体资源功能
控制器(MRFC，Media Resource FunctionController)和媒体资源功能处理器(MRFP，Media Resource Function Processor)两个逻辑实体。 [0136] 用户使用IPTV业务的计费由IPTV AS基于IMS网络中的计费机制来完成，现有IPTV网络则将IPTV AS作为一个特殊的用户进行计费，或不计费。
[0137] 对IMS UE的认证授权由IMS网络中现有机制来完成，由IPTV AS基于IMS用户的签约来进行认证和授权，现有IPTV网络对该IPTV AS发起的用户请求不再进行认证和鉴权。
[0138] 图4所示为基于图3所示系统构架的实现IMS UE享用现有IPTV业务的流程示意图。图4中Deployed A/V Service System中除流媒体服务器(StreamingServer)外的实体统称为其他实体(Other Entity)，以下以业务网关内的信令面控制实体由IPTV AS来实现为例进行说明。
[0139] 步骤1，IMS UE通过Ut接口与现有IPTV网络交互，从现有IPTV网络内的EPG中获取节目单信息；该节目单信息包含节目标识、内容标识等，而且以SIPURI方式标识。 [0140] 当然，如果EPG位于IMS核心网内，则IMS UE与IMS核心网交互，从IMS核心网内的EPG中获取节目单信息；如果EPG与业务网关为一个实体，则IMSUE与业务网关交互，获取节目单信息；如果EPG是独立存在的一个服务器，则IMS UE与该EPG服务器交互，获取节目单信息。
[0141] 步骤2，根据用户选择的观看节目，IMS UE向IPTV AS发起包含节目单信息的业务请求。
[0142] 步骤3，IPTV AS将接收到的业务请求转换为现有IPTV网络支持的协议格式，以现有IPTV网络终端的方式向现有IPTV网络发起业务请求，获取业务信息。在应用不同的流媒体服务器时，所获取的业务信息是不同的，比如，如果是VoD流媒体服务器，则上述业务信息为VoD流媒体服务器，如果是LTV组播源，则上述业务信息可能为组播地址等。 [0143] 步骤4，IPTV AS将来自现有IPTV网络的消息转换为IMS核心网支持的协议格式，控制IMS UE与现有IPTV网络建立信令面连接；
[0144] 步骤5，现有IPTV网络通过自身内的流媒体服务器向IMS UE发送媒体流。 [0145] 具体实现过程为：现有IPTV网络中的流媒体服务器直接向IMS UE发送媒体流(即图中实线的步骤5)，或者，现有IPTV网络中的流媒体服务器向承载面实体发送媒体流，由承载面实体将接收到的媒体流转换为IMS UE能够识别 的格式后，再发送给IMS UE(即图中虚线的步骤5)。该承载面实体可以是业务网关内的逻辑实体，也可以是IMS Core内的MRF实体。
[0146] 再有，IMS UE接收到的媒体流很可能是经过加密的；此时，IMS UE应用已获得的密钥对接收的媒体流解密后，进行显示，以供用户观看。
[0147] 图4是基于总体思想的流程图，下面针对两个具体的应用业务，对IMS UE享用现有IPTV业务的实现流程再做说明。同样地，以业务网关内的信令面控制实体由IPTV AS来实现为例进行说明。
[0148] 视频点播(VoD)业务
[0149] VoD业务的实施方式与上述总体思想中介绍的类似，内容的分发、
定位在现网IPTV系统中已解决，主要问题是：(1)如何向IMS UE提供对节目的卡带式影像录放机(VCR，Video Cassette Recorder)控制功能；(2)IPTV AS如何进行业务建立；(3)媒体流安全传输控制；(4)VoD业务采用TS流封装的处理。以下以应用RTSP协议为例进行说明，当然，应用HTTP或SOAP协议也是完全可以的。
[0150] (1)VCR控制的考虑：
[0151] 部分扩展RTSP的功能，如SIP协议头域或参数中指示暂停、播放、快进、快退等命令指示，IMS UE通知IPTV AS其VCR操作命令。
[0152] 具体实现方式可为：IPTV AS在VoD会话建立后，向终端发送Subscribe消息订阅用户的VCR操作命令，IMS UE通过Notify消息将VCR操作命令通知给IPTV AS；或者，IMS UE发送扩展的SIP信令直接传递其VCR控制信息给IPTVAS，而后，IPTV AS就可以向IPTV网络发起RTSP请求，或控制MRF向IPTV网络发起RTSP请求。
[0153] (2)业务建立过程：
[0154] IMS UE从EPG中获取节目单信息，并向IPTV AS发起业务请求； [0155] IPTV AS收到IMS UE的SIP请求后，和现有IPTV系统交互，获取IPTV系统中VoD流媒体服务器的URL，可以采用HTTP、SOAP、RTSP等协议；
[0156] IPTV AS可直接向IPTV网络发起RTSP请求，也可控制MRF向IPTV网络发起RTSP请求。若IMS UE和VoD多媒体服务器编解码格式匹配，携带的SDP描 述为IMS UE的媒体能力和地址，实现VoD流媒体服务器直接将媒体流传送给IMS UE，若不匹配，则IPTV AS控制MRF进行媒体转码，携带的SDP描述为MRF的媒体能力和地址，MRF作为VoD流媒体服务器和IMS UE间的媒体转换节点。也就是说，组合起来共有四种实现方式。 [0157] IMS UE收到加密的媒体流，通过获得的密钥对内容进行解码，显示给用户，以使用户能够观看节目。
[0158] IMS UE进行VCR控制时，通知IPTV AS其VCR控制命令，IPTV AS根据VCR命令直接、或控制MRF向VoD流媒体服务器发起相应的RTSP控制。
[0159] (3)安全控制：
[0160] VoD业务通常采用DRM方式进行保护，基于DRM考虑如下：
[0161] IMS UE接收到媒体流，从中识别出版权发布功能(RIF，Right IssuerFunction)的URI，并通知给IPTV AS；具体实现方式可以为：IPTV AS在与VoD流媒体服务器的会话建立后，向IMS UE发送Subscribe消息订阅用户获取的RIF地址信息，IMS UE通过Notify消息通知IPTV AS；当然，也可以为其它方式，如IMS UE通过扩展的SIP信令通知给IPTV AS等；
[0162] IPTV AS代理用户向RIF发起版权对象的请求，即作为现有IPTV网络内的一个终端向RIF发起版权对象的请求；
[0163] RIF将请求的版权对象(RO，Right Object)返回给IPTV AS；
[0164] IPTV AS从RO中得到对媒体流内容进行加密的内容加密密钥，将该内容加密密钥以IPTV AS和IMS UE之间的共享密钥加密后下发给IMS UE；
[0165] IMS UE解密获取内容加密密钥，解密后显示节目，以便用户观看。 [0166] 如果VoD业务采用非DRM方式进行保护，则考虑如下：
[0167] IPTV AS代理用户向现网IPTV系统发起业务请求，在请求过程中获取VoD业务中的内容加密密钥；
[0168] 该内容加密密钥采用IMS UE和IPTV AS之间的共享密钥加密后下发给IMS UE； [0169] IMS UE获取内容加密密钥，解密后显示节目，以便用户观看。 [0170] (4)传送流(TS，Transport Streams)封装考虑：
[0171] VoD业务采用TS流封装的可能性比较小，如果采用TS流，则IPTV AS直接或控制MRF向VoD流媒体服务器发起RTSP请求，携带的SDP描述为MRF的媒体能力和地址。MRF与VoD流媒体服务器间建立RTSP连接，VoD流媒体服务器向MRF下发TS流： [0172] 如果按下面LTV业务中IPTV AS和MRF共同完成密钥下发的下发方式i)进行密钥下发，则MRF通过IPTV AS完成和IMS UE间的媒体流的传输参数协商，IPTV AS在信令面下发应用与IMS UE共享密钥加密后的CW给IMS UE，MRF向UE下发RTP流。IMS UE通过与IPTV AS共享密钥解密得到CW，并用CW进一步解密媒体流观看节目。IMS UE采用前面的VCR控制方式向IPTV AS通知其VCR控制，IPTV AS直接或控制MRF进行相应的VCR控制，并向VOD流媒体服务器发起相应的RTSP控制请求。
[0173] 如果按下面LTV业务中IPTV AS和MRF共同完成密钥下发的下发方式ii)进行密钥下发，则MRF通过IPTV AS完成和IMS UE间的媒体流和密钥流的传输参数协商，IPTV AS在信令面下发应用与IMS UE共享密钥加密后的SK给IMS UE，MRF向UE下发RTP流和应用SK加密的CW流。IMS UE通过与IPTVAS共享密钥解密得到SK，并用SK解密加密的CW流得到CW，使用CW进一步解密RTP流观看节目。IMS UE采用前面的VCR控制方式向IPTV AS通知其VCR控制，IPTV AS直接或控制MRF进行相应的VCR控制，并向VOD流媒体服务器发起相应的RTSP控制请求。
[0174] 下面结合一具体实现流程对VoD业务的实现过程再做说明。
[0175] 图5所示为根据本发明一实施例的IMS UE享用现有IPTV网络VoD业务的实现流程图。本实施例中，采用RTP流封装，DRM方式进行保护，IMS UE和现网IPTV网络内EPG有Ut接口，Deployed A/V Service System中除StreamingServer外的实体称为Other Entity。承载面实体由MRF实现，且IPTV AS控制MRF向IPTV网络发起RTSP请求。 [0176] 步骤1，IMS UE基于Ut接口向现有IPTV网络的EPG发起请求，获取节目单信息，该节目单信息包含节目标识、内容标识等，而且以SIP URI方式标识。
[0177] 当然，EPG的
位置可灵活放置，与前述同，此处不再赘述。
[0178] 步骤2，根据用户选择的观看节目，IMS UE向IPTV AS发起包含节目单信息的业务请求。该请求基于SIP协议。
[0179] 步骤3，IPTV AS将接收到的业务请求转换为现有IPTV网络支持的协议格式，以现有IPTV网络终端的方式向现有IPTV网络发起业务请求，获取VoD流媒体服务器标识(VoD Streaming Server URI)，该IPTV AS向现有IPTV网络发起请求基于HTTP或SOAP或RTSP等协议。
[0180] 步骤4，IPTV AS控制MRF向VoD服务器发起请求，该请求基于SIP和H.248协议。 [0181] 步骤5，MRF向VoD流媒体服务器发起RTSP请求，若IMS UE和VOD媒体服务器间的编解码格式不匹配，则SDP为MRF的媒体能力和地址，并在响应中获取媒体流的描述信息。若IMS UE和VoD流媒体服务器的编解码格式匹配，则UE得到请求响应中携带的SDP描述为IMS UE的媒体能力和地址。
[0182] 步骤6～7，由于本实施例是步骤5的前一种情况，因此UE得到的请求响应中携带的SDP描述为MRF的媒体能力和地址。
[0183] 步骤8，IPTV AS向UE Subscribe VCR控制及RIF地址信息。
[0184] 步骤9，IMS UE和VoD流媒体服务器间通过RTP方式传送媒体流，中间经过MRF转发RTP流。
[0185] 步骤10～11，IMS UE从媒体流中获取RIF URI，并通过Notify消息通知IPTVAS。 [0186] 步骤12～14，IPTV AS向RIF请求RO，从中得到内容加密密钥，并以和UE间的共享密钥对它加密后，发送给IMS UE。
[0187] 步骤15，IMS UE解密得到内容加密密钥，并解密媒体流，进行显示，以供用户观看节目。
[0188] 步骤16，IMS UE发起VCR控制，并通过Notify的方式通知IPTV AS其VCR控制命令。
[0189] 步骤17～18，IPTV AS控制MRF进行相应的VCR操作，MRF向VoD流媒体服务器发起相应的RTSP请求，指示VoD流媒体服务器执行VCR控制命令所指示的操作。 [0190] 在图4所示实施例中，是以通过信令面获取SEK，媒体面组播数据流获取TEK和媒体流为例，进行说明的，在实际应用中，还可以有一种实现方式：通过信令面获取TEK，通过媒体面组播数据流仅获取媒体流。后一种实现方式与前一种实现方式的区别点主要是： [0191] 流传输方式为RTP传输方式，且IMS UE和LTV组播源间的媒体编解码类型匹配时，IPTV AS获取LTV频道组播IP地址的同时，还获取节目密钥SEK、用SEK加密的内容密钥TEK和LTV组播源媒体能力信息；IPTV AS利用SEK解出TEK，并用与IMS UE的共享密钥加密TEK；并将组播IP地址、加密的TEK、组播源媒体能力信息包含在返回给P-CSCF的响应中；此时，接入侧承载实体如BGF接收到的加密组播数据流中仅包括来自LTV组播源的媒体流。
[0192] 流传输方式为RTP传输方式，且IMS UE和LTV组播源间的媒体编码类型不匹配时，IPTV AS获取LTV频道组播IP地址的同时，还获取节目密钥SEK、用SEK加密的内容密钥TEK及LTV组播源媒体能力信息；之后，IPTV AS利用SEK解出TEK，并用与IMS UE的共享密钥加密TEK，还控制媒体面实体如MRF进行媒体转换，与LTV组播源间建立组播或单播隧道，并分配新的组播IP地址，控制MRF为新的组播源；将频道组播IP地址、加密的TEK和MRF组播源媒体能力信息包含在返回给P-CSCF的响应中；此时，接入侧承载实体如BGF接收到加密的组播数据流中仅包括来自MRF的媒体流。
[0193] 其余与前一种实现方式相同，不再赘述。
[0194] 实时电视(LTV)业务
[0195] LTV业务主要是获取组播IP地址，节目加密密钥，以及用户加入组播组，完成组播路径的建立，但由于IMS UE并不支持组播相关的协议如Internet组管理协议(IGMP)等，同时LTV业务通常采用CA或业务层进行保护、并采用TS方式对媒体流进行封装，因此从以下几方面考虑。以下仍以应用RTSP协议为例进行说明，当然，应用HTTP或SOAP协议也是完全可以的。
[0196] (1)LTV业务请求：
[0197] IMS UE从EPG中获取节目单信息，并向IPTV AS发起业务请求； [0198] IPTV AS向现网IPTV系统发起业务请求，获取该频道、节目的组播IP地址、安全相关的信息；
[0199] 若流传输方式为RTP，且IMS UE与LTV组播源间的媒体编解码类型匹配，则IPTV AS在IMS UE的请求响应中返回组播IP地址、安全相关信息及LTV组播源媒体能力信息，若不匹配，则IPTV AS控制承载面实体如MRF进行媒体转换，与LTV组播源间建立组播或单播隧道，并分配新的组播IP地址，MRF成为新的组播源，IPTV AS在IMS UE的请求响应中返回新的组播IP地址、安全相关信息及MRF组播源媒体能力信息。
[0200] 若采用TS流封装，则IPTV AS控制MRF与LTV组播源间建立组播或单播隧道，MRF解TS流，IPTV AS分配新的组播IP地址，MRF成为新的组播源，IPTVAS在IMS UE的请求响应中返回新的组播IP地址、安全相关信息及MRF组播源媒体能力信息。
[0201] IPTV AS通过资源及
许可控制子系统(RACS，Resource and Admissioncontrol Subsystem)进行接入侧组播的控制，如控制接入边界网关设备，进行组播组的管理，将IMS UE加入所管理的组播组；
[0202] 如果承载网络支持组播路由协议，接入边界网关设备通过组播路由协议建立到现网IPTV系统中的内容源或MRF的组播转发路径；
[0203] 如果承载网络不支持组播功能，IPTV AS通过RACS进行核心侧组播的控制，如通过应用层组播建立接入边界网关设备到内容源的单播或隧道路径；上述内容源为LTV组播源或承载面实体组播源。
[0204] 接入边界网关设备收到组播节目流后向所管理的组播成员用户转发节目流； [0205] IMS UE发起切换时，获取新的组播IP地址、控制接入边界网关设备变更组播成员，转发新的媒体流。
[0206] (2)安全控制：
[0207] 如果采用业务层保护，且基于RTP方式传送，则：
[0208] 业务加密密钥(SEK，Service Encapsulation Key)由IPTV AS从现网IPTV系统获取后，通过IPTV AS和IMS UE之间的共享密钥，如通用鉴权框架(GBA)方式生成的共享密钥，加密后下发给IMS UE，IMS UE解密获取SEK；
[0209] LTV组播源生成的媒体加密密钥(TEK，Traffic Encapsulation Key)由SEK加密，并将加密后的TEK流通过组播通道发给IMS UE，或通过IPTV AS从信令面向IMS UE下发； [0210] IMS UE向IPTV AS请求SEK的更新信息；
[0211] IPTV AS从现网IPTV系统中获取新的SEK后，加密下发给IMS UE。 [0212] 如果采用CA方式保护，且基于TS方式传送，则：
[0213] 承载面实体如MRF从TS流中解封获取RTP流、授权控制信息(ECM，EntitleControl Message)流、授权管理信息(EMM，Entitle Manage Message)流； [0214] 对于RTP流，IPTV AS分配新的组播IP地址，并控制MRF将RTP流作为IMS网络内的组播流下发到给UE；
[0215] IPTV AS和MRF共同完成密钥的下发；具体实现可以为：
[0216] i)MRF从ECM流中获取以业务密钥(SK)加密后的加扰控制字(CW)，从EMM流中获取以用户的个人分配密钥(PDK)或组分发密钥(GDK，GroupDistribution Key)加密后的SK；MRF将上述加密后的CW和加密后的SK通知IPTV AS；IPTV AS通过PDK或GDK(IPTV AS作为现网IPTV系统中的一个特殊用户，会获取和现网IPTV系统中共享的某个PDK或GDK)解密SK；IPTV AS用SK再解密CW；IPTV AS用和终端共享的密钥(如GBA方式生成)加密CW后，通知给IMS UE；IMS UE解密获取CW，用CW解密媒体流，观看频道节目； [0217] ii)MRF从ECM流中获取以SK加密后的CW、从EMM流中获取以用户的PDK或GDK加密后的SK；MRF将上述加密后的SK通知IPTV AS；IPTV AS通过PDK或GDK解密SK；并用和终端共享的密钥(如GBA方式生成)加密SK后，通知给IMS UE；MRF将加密后的CW流通过组播通道下发到给UE，IPTV AS可以给加密后的CW流分配新的组播IP地址，并控制MRF成为新的密钥流组播源；UE解密获取SK，用SK解密密钥流得到CW，并用CW解密媒体流，观看频道、节目；
[0218] (3)TS流封装：
[0219] 如果媒体流采用TS流封装，则采用支持TS流解封装的MRF；
[0220] IPTV AS控制MRF建立和现网IPTV网络中节目内容源之间的连接，接收从内容源发过来的TS流，MRF和内容源之间可以考虑采用单播方式，也可以考虑采用组播方式； [0221] MRF对TS解封，获取RTP流；
[0222] IPTV AS可以分配新的组播IP地址(在IMS域的承载网络内有效，且IMS域承载网络支持组播功能，否则可以考虑采用应用层组播)，通过IMS网络和RACS建立接入边界网关设备和MRF之间的组播网，并控制接入边界网关设备完成组播组的管理，转发从MRF获取的RTP流至IMS UE——新的组播源为MRF。
[0223] 图6所示为根据本发明一实施例的IMS UE享用现有IPTV网络LTV业务的实现流程图。本实施例中，媒体流基于RTP方式传输，TEK密钥流也基于组播方式传输，且LTV组播源直接将组播流下发到IMS UE。
[0224] 步骤1，IMS UE基于Ut接口向现有IPTV网络的EPG发起请求，获取节目单信息，该节目单信息包含节目标识、内容标识等，而且以SIP URI方式标识。
[0225] 当然，EPG的位置可灵活放置，与前述同，此处不再赘述。
[0226] 步骤2，根据用户选择的观看节目，IMS UE向IPTV AS发起包含节目单信息的业务请求。该请求基于SIP协议。
[0227] 步骤3，IPTV AS将接收到的业务请求转换为现有IPTV网络支持的协议格式，以现有IPTV网络终端的方式向现有IPTV网络发起业务请求，该请求基于HTTP、SOAP或RTSP等协议，获取频道组播IP地址，节目密钥(SEK)。
[0228] 步骤4，假设UE和LTV组播源间媒体格式匹配，IPTV AS使用和终端共享的密钥(如GBA方式生成)加密SEK后，将媒体流和密钥流的组播IP地址/端口号、LTV组播源媒体能力和加密的SEK作为请求响应发给IMS网络内的P-CSCF；
[0229] 步骤5，P-CSCF通过RACS控制边界网关功能实体，如BGF，进行组播管理，用户加入组播组；
[0230] 步骤6.P-CSCF将请求响应转发给IMS UE，该响应中携带媒体流和密钥流的组播地址/端口号或BGF地址、LTV组播源媒体能力以及加密后的SEK。
[0231] 以上步骤5和步骤6之间没有严格的先后顺序，也可同时执行。 [0232] 步骤7，IMS UE应用与IPTV AS的共享密钥解密SEK。
[0233] 步骤8，BGF通过组播路由协议建立到LTV组播源的组播转发路径。 [0234] 步骤9，LTV组播源传输RTP媒体流和密钥流给UE；上述密钥流即用SEK加密的TEK流，而且，上述媒体流和密钥流可以是同一个组播流，不同的端口号，也可以是两个的组播流，且上述媒体流和密钥流可被统称为数据流。
[0235] 步骤10，IMS UE利用SEK解密密钥流得到TEK，利用TEK解密媒体流，并进行显示，以供用户观看。
[0236] 图7是根据本发明另一实施例的IMS UE享用现有IPTV网络LTV业务的实现流程图。本实施例中，LTV业务基于TS流传输，且使用CA保护方式，承载面实体为MRF，由MRF解TS流，并成为UE新的组播源。
[0237] 步骤1，IMS UE基于Ut接口向现有IPTV网络的EPG发起请求，获取节目单信息，该节目单信息包含节目标识、内容标识等，而且以SIP URI方式标识。
[0238] 当然，EPG的位置可灵活放置，与前述同，此处不再赘述。
[0239] 步骤2，根据用户选择的观看节目，IMS UE向IPTV AS发起包含节目单信息的业务请求。该请求基于SIP协议。
[0240] 步骤3，IPTV AS将接收到的业务请求转换为现有IPTV网络支持的协议格式，以现有IPTV网络终端的方式向现有IPTV网络发起业务请求，该请求基于HTTP、SOAP或RTSP等协议，获取频道组播IP地址。
[0241] 步骤4，IPTV AS控制MRF与LTV组播源之间建立组播流；
[0242] 步骤5，MRF通过组播路由协议建立和LTV组播源建立组播转发路径，或者通过应用层组播方式，在MRF和LTV组播源间建立单播隧道；
[0243] 步骤6，IPTV AS向MRF订阅密钥包。
[0244] 步骤7，LTV组播源下发TS流。
[0245] 步骤8.MRF解TS流，获取RTP流、ECM流和EMM流，从ECM流中取出加密的SK，EMM流中取出加密的CW。
[0246] 步骤9，MRF向IPTV AS上报加密的SK和CW。
[0247] 步骤10，IPTV AS利用和LTV共享的PDK或GDK解密SK，并用SK解密CW，且用和IMS UE共享的密钥(如GBA方式生成的共享密钥)加密CW。
[0248] 步骤11，IPTV AS分配新的组播IP地址，该组播地址旨在IMS域的承载网络内有效；
[0249] 步骤12，IPTV AS控制MRF将RTP流作为IMS网络内的组播流；
[0250] 步骤13，IPTV AS向IMS网络内的P-CSCF返回请求响应，携带新的组播IP地址和加密的CW；
[0251] 步骤14～15，P-CSCF控制BGF进行组播组管理、用户加入组播组；并将请求响应转发给IMS UE；IMS UE接收到的响应中包含组播IP地址或BGF的地址，以及加密后的CW。 [0252] 步骤16，UE应用与IPTV共享的密钥解密得到CW。
[0253] 步骤17，BGF通过组播路由协议建立和MRF间的组播转发路径。 [0254] 步骤18，MRF通过组播转发路径下发RTP流，BGF进一步完成RTP流的复制转发给UE；
[0255] 步骤19，UE利用CW解密媒体流并显示，以供用户观看节目。
[0256] 对于图7所示实施例，仅是以IPTV AS和MRF共同完成密钥的下发的方式1)为例进行说明的，如果采用方式ii)的下方方式也完全可以，此处不再重复说明。 [0257] 以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何
修改、等同替换、改进等，均包含在本发明的保护范围内。
