于改变的网络接入点或网络干扰而改变时，则决定管理器136通过 将所识别的通信模式适配于当前输运能力来重复决定过程。这可以包括CAL上的适配机制 的涉及，该适配机制然后对于应用自身来说是透明的。丢失的网络连接性上的响应时间相 比于网络干扰而言更加关键。另一触发可以是与网络接入竞争且要求平衡和/或业务优先 化的经启动或经停止的应用。为了防止系统的振荡，必须附加地定义最小非评价时间或容 许时间。
[0045] 现在将基于图6至9描述输入文档和通信模式可能看上去如何的示例。该示例不 要求保护完整性；然而，其有助于理解所有所涉及的文档的含义和策略值以及决定过程的 结果。
[0046] 在基本场景（同样参见图1)中，用户在其移动设备上实施基于NTL的视频串流应 用117。应用支持视频和音频二者或仅具有音频的静止图像。这取决于可用网络及其当前 可用的能力，诸如带宽。在决定过程被触发时，两个网络可用以供决定管理器选择。
[0047] 图6示出具有设备文档的集合的数据结构600。第一设备文档610描述诸如屏幕 大小、CPU效率、总存储器等之类的设备能力，并且第二设备文档描述诸如电池状态、可用存 储器和是否电话呼叫在进行中之类的设备状态。电话呼叫将具有超过其它应用的优先级， 因为其使用大量设备资源并且是设备的主导应用。设备文档620、650是图4中的设备文档 430的示例。
[0048] 应用提供了描述其要求和需求的应用文档。在该示例中，应用支持三个可替换的 应用集合：最小、良好和满意。对于要操作的应用，必须观察要求集合"最小"的要求，即，要 求集合"最小"是强制的。在该情况中，应用仅使用具有静止图像的一个音频流。两个其它 要求集合"良好"和"满意"是可选的。
[0049] 图7示出特别地具有有利的要求集合"良好" 710的数据结构700。在该情况中， 应用利用应用要求文档720中的若干编解码器支持内容类型"音频"和"视频"。当应用请 求视频分发数据流时,该流使用"请求getStream"，其具有所指派的多个客户端-端点。应 用选择例如具有名称"视频会议"的预定义简档，其描述针对支持网络要求文档770中的应 用的视频会议配置的要求的某个集合。要求集合"满意"是以相同方式定义的。应用要求 720和网络要求770是图4中的应用文档410的示例。
[0050] 此时，两个网络可用："WLAN"和"GSM-GPRS-CS4-8时隙"。这些网络的能力被描述 在预定义的文档中。为了满足应用的要求，描述了预定义的协议栈，决定管理器可以从该协 议栈作出选择。
[0051] 图8示出具有网络配置810的集合的数据结构800。网络配置810的集合具有在 当前时间处可能的三个网络配置或协议栈820、860、890。
[0052] - 820标示网络配置"WLAN之上的VPN之上的SVC"。
[0053] - 860标示网络配置"GSM-GPRS-CS4-8时隙之上的VPN之上的SVC"。
[0054] - 890描述网络配置"WLAN之上的SVC"。
[0055] 描述特征和能力的文档将针对协议和网络的组合820、860、890中的每一个而存 在。此外，NTL 150将提供描述这些网络的当前状态的文档；例如，刚已测量的WLAN连接的 平均比特率为233 Mbits/s (参见图8,分支：SVC/VPN/WLAN/网络状态/平均比特率)。所 有这些文档是针对图4中的网络文档440的示例。
[0056] 决定管理器136将必须确定这些组件820、860、890中的哪个最适于满足要求。例 如，最后的组合890 "WLAN之上的SVC"违反如应用所需求的要求"安全VPN"并且决定管理 器将因此不选择该组合。
[0057] 此外，能力是正在针对或者将针对每一个协议或网络而指定的，但是决定管理器 136将必须还评价经组合的值。例如，给出WLAN的理论带宽，但是与VPN组合，实际带宽将 较低。
[0058] 最后，决定管理器将推荐可用选项的适合子集或部分集合。图9示出具有所选子 集910的可能描述的数据结构900。决定管理器已经选择简档"视频会议"920。当应用施 行"请求getStream" 930时，其将从具有"端点1"的服务器接收视频流。参与的网络和协 议为：WLAN 940、VPN 950,并且压缩标准为SVC 970 (来自H.264/MPEG-4 AVC的扩展附录 G，参见 960)。
[0059] 图9中的描述示出了决定过程的结果可能看上去如何的示例。然后将该结果转换 成描述所要求的适配组件、网络、协议、其配置、呼叫的时间顺序等的文档。
[0060] 以下将基于图IOA至IOC中的若干相继部分中所示的序列图详细描述功能单元 (决定管理器136、TAL 180、可能地CAL 160)中的视频数据流的拆分以及接收器(终端110) 中的组合和同步。
[0061] 图IOA至IOC示出根据本发明的过程1000,其根据基于三个相继段中的序列图的 实施例。换言之，图IOA中所示的过程1000的段之后跟随图IOB中所示的段，并且图IOB 中所示的段之后跟随图IOC中所示的段。处理序列总是从上到下。
[0062] NTL架构的之前提到的组件及其部分层被演示为实体或实例。假定三个网络接入 点n、m、k可用。如图1中所示，连接经由122、124在交点112、114处终止。
[0063] 过程1000以选择阶段"S"开始。最初，设备110与连接性层（网络接入196)连 接(步骤1001，1002, 1003)。连接性层对应于图2中演示的Sillberg架构的多个网络接 入。"网络接入"代表多个网络接入(参见图2,附图标记284)。其向决定管理器136继续传 递该信息(步骤1006, 1007, 1008)连同关于可用网络接入点n、m、k的信息。终端110自身 直接向决定管理器136传输其自身能力、要求和参数的描述(步骤1009)。在应用开始（步 骤1010)并且传送其要求(步骤1011)之后，将这些要求从CAL 160继续传递到决定管理器 136 (步骤1012)。后者比较应用的要求与网络接入点的那些要求(步骤1015)并从它们之 中选择几个可使用的通信模式且将其传输至协作的NTL子层CAL 160和TAL 180二者（步 骤1017, 1018)。在功能上，图IOA至IOC中的TAL 180特别地是指根据图2的作为TAL 180 的一部分的自适应网络功能性282。作为示例，TAL 180现在选择网络接入点η和m (步骤 1020)并配置它们（步骤1021)。在确认选择(步骤1022, 1023)之后，应用138接收所使用 或所选择的通信模式(步骤1025)。
[0064] 通信阶段"C"此后开始，并且应用138以传输使用信息(步骤1030)而开始。连接 性层196适当地在网络接入点η和m之上分发该信息(步骤1035, 1036)。由于这两个网络 接入点η和m都可用，因此应用数据可以被传输，例如在视频串流应用的本示例中在基本层 和一个或多个增强层之上分布，且因此可以被以改进的视频质量传输。使用网络接入η和m 的通信阶段C因此可以是具有增加的视频质量的通信阶段，参见现在在图IOB处开始。可 以在其它应用中向两个网络接入点指派不同的使用划分。
[0065] 在通信阶段C期间，连接性层196重复更新网络状态，并将其传输至决定管理 器136 (未详细示出）。终端110经由接口监视来检测网络接口 η的干扰或质量缺陷(步 骤1040)。这触发重评价阶段"R"，其以终端110关断网络接口 η (步骤1041)而开始。连 接性层196在其上向决定管理器136传输网络状态的更新(步骤1042)。后者评价当前情 形(步骤1045)且现在向协作的NTL子层CAL 160和TAL 180传输可能的通信模式(步骤 1047,1048)。TAL 180现在选择网络接入点k和m (步骤1050)并配置它们（步骤1051)。 在确认选择(步骤1052, 1053)之后，应用138接收所使用的通信模式(步骤1055)，并且通信 阶段"C"再次开始。尽管在图中未详细示出，但是其最初包括向连接性层196传输使用信 息，于是该信息被适当地经由网络接入点k和m分发。由于仅网络接入点k和m仍旧可用， 因此应用数据可以继续经由两个网络接入点分发到终端110并可以在那里被重组。由于先 前为了有利于网络接入η而已经拒绝网络接入k (选择步骤1020)，因此现在可以是：经由 网络接入点k和m仅传输低视频质量；或者可