关于IMS-BaseIPTV架构，已经明确将采用NGN中提出的公共部件NASS（网络附着子系统）和RACS（资源接纳控制子系统），目前主要研究的关键点如下：
（1）重用哪些IMS核心控制提供的相关功能
包括IPTV业务应用控制平台是否能够直接和IPTV中媒体分发网络进行交互，还是必须要经过IMS核心控制部件。从目前的研究情况来看，FGIPTV采用直接交互的方式，而TISPAN经过会议讨论采用了经由IMS核心控制间接交互的方式。
为了支持IPTV业务，需要对IMS核心中的实体MRFC和MRFP进行扩展，以便能够实现对IPTV相关媒体的控制，并能够接收来自用户的控制命令，如播放、暂停等。FGIPTV对IPTV中提供媒体资源以及媒体控制功能还缺少明确的规定，在TISPAN基本已经明确为IPTV提供相关资源和控制功能的实体和MRFC以及MRFP之间存在关系，并已经给3GPP发送联络函提请分析。
（2）关于用户业务清单
用户业务清单UPSF是NGN中提出的一个公共部件，主要存储和用户相关数据。为了支持IPTV业务，需要对该功能实体进行一定程度的扩展。FGIPTV针对IPTV提出了三种清单的概念，包括内容清单、用户清单和业务清单，但具体的数据组织形式以及和NGN中UPSF的关系还缺乏详细的论述。在TISPAN采用了直接在UPSF已经定义的数据结构上进行扩展的方式，如图5所示。
图5 IPTV用户数据模型
（3）关于内容定位
用户所请求的IPTV资源可能同时分布在多个服务器上，如果确定为某次用户请求提供服务的服务器也是IPTV体系架构中需要深入研究的一个关键问题。在FGIPTV关于这一点在体系架构中还没有明确的反映和说明。在TISPAN，曾经讨论过增加媒体资源Broker功能实体来实现内容定位功能。媒体资源Broker可以采用两种工作模式——重定向模式和代理模式，当Broker工作在代理模式时，只参与选择MCF的初始过程。但是会议没有达成一致的意见。
（4）内容发现
主要关于如何向用户呈现IPTV内容相关的信息。FGIPTV和TISPAN都在IPTV体系架构中提出了相关的控制功能实体，在FGIPTV为IP应用（IPTVApplication），在TISPAN为业务发现和选择功能实体（SD&S）。在向用户呈现内容相关的信息时，可能需要和其他功能实体进行交互获得相关的信息，如用户的Profile信息，以便提供个性化的内容信息。该功能实体的功能还需要深入的讨论。
4、组播控制方面
为了支持广播类IPTV业务，IPTV架构还需要考虑提供组播相关的功能，包括组播的实现和组播相关的控制。
在FGIPTV有专门的工作文档研究IPTV组播架构（IPTVMulticastFrameworks），组播控制可以采用CDN，P2P和Overlay控制方式，或者采用不同控制方式相结合，FG IPTV在组播控制文档中对Overlay这种组播控制架构进行了详细描述。在Overlay这种控制方式下，承载网络中每个节点动态建立组播分发路径（工作方式类似于IP组播路由器），路径中的每个网络节点负责向下行节点前传送上行节点收到的媒体信息，承载网络之上的组播控制节点之间可以进行能力交互，这些组播控制节点中的某些节点将针对IPTV相关的业务部件执行策略管理、配置和监视功能，组播控制节点结合动态信息处理用户的业务请求。
在TISPAN，关于IPTV组播的研究在RACS体系架构中体现。为了支持组播，目前关于RACS的输出草案中提出了新的功能实体MPF（组播处理功能，MulticastProcessingFunction），对应到承载网中的DSLAM或第一个三层IP节点主要处理组播树的接入、离开请求。并且针对组播给出了三种控制方式，一种是RACS不参与组播控制，用于组播和单播等资源分别通过运营维护子系统（OSS）进行分配，也称为Exclusivescenario模式；第二种方式是RACS控制MPF中组播资源的门限，RACS负责设置MPF可服务的频道数据，如果在提供业务时需要更多的资源，RACS可以调整相应的门限，MPF也可以向RACS发送资源监测报告，也称为Provisioning Scenario模式；第三种方式是RACS参与组播和单播的控制和管理，MPF向RACS请求相关的资源。当然，为了提高效率，MPF可以一次向RACS请求块资源（对应多个频道），这种方式也称为Dynamic scenario。
