CN106332300A - 专用承载建立方法、装置及用户设备 - Google Patents

Abstract

本发明提供了一种专用承载建立方法、装置及用户设备，其中，该方法包括：确定需要经由用户设备传输外部设备与远端设备之间的媒体流，其中，用户设备通过承载网与远端设备进行通信；建立用户设备与承载网之间的专用承载，其中，外部设备与远端设备之间的媒体流在专用承载上传输。通过本发明，解决了外部设备上的媒体流的QoS要求无法保证的问题，通过专用承载为外部设备的媒体流传输提供了QoS保障。

Description

专用承载建立方法、装置及用户设备

技术领域

本发明涉及通信领域，具体而言，涉及一种专用承载建立方法、装置及用户设备。

背景技术

随着无线技术的发展，特别是第三代通信技术(3G)/第四代通信技术(4G)的推广普及，用户设备UE，包括但不限于智能手持设备或者专用的3G/4G无线路由器设备等，越来越多将自身的3G/4G接入能力，通过作为无线局域网(Wi-Fi)热点的方式向用户身边的其它外部设备开放。使得其它设备可以在移动的环境下，便捷的高速上网。

目前UE虽然有将3G/4G接入能力，并通过Wi-Fi热点的方式向外部设备开放，但UE与承载网使用的是默认承载，而不是专用承载，因此，无法为这些传输提供服务质量(QoS)保障。

如果外部设备上的媒体流(即外挂媒体流，例如音视频通话，或者交互式应用业务等)需要有QoS要求，则会因为上述限制，而无法开展业务。

此外，UE将3G/4G接入能力通过Wi-Fi热点的方式向外部设备开放时，还可以为外部设备提供网络地址转换(Net Address Translation，简称为NAT)功能。即把私网内的IP地址和端口转换成公网的IP地址和端口，也即进行IP地址映射。

例如：公司内的私网(假设其网段为10.1.1.1)；公司通过公网服务器(网关A)接入互联网(Internet)，该公网服务器的私网IP地址为10.1.1.1，公网IP地址为220.220.1.6。私网内的机器B(假设IP地址为10.1.1.102)打开其88端口想要连接公网中的网页(WEB)服务器(服务器C，假设IP地址为204.56.43.8，端口为80)，则通过NAT功能实现的过程如下：

步骤1，机器B将数据包(10.1.1.102:88->204.56.43.8:80)发送给网关A(10.1.1.1)；

步骤2，网关A将数据包的源地址(10.1.1.102:88)更换为公网服务器的公网IP地址，并分配一个端口(假设为200)；网关A将数据包(220.220.1.6:200->204.56.43.8:80)发送出去；

步骤3，服务器C将响应数据包(204.56.43.8:80->220.220.1.6:200)发送给网关A；

步骤4，网关A将服务器C返回的响应数据包的目的地址和端口进行修改，然后把响应数据包(204.56.43.8:80->10.1.1.102:88)发送出去；

步骤5，机器B接收服务器C的响应数据包。

在机器B的角度来看，机器B感受不到自己是在私网，它有在公网一样的权利，这也就是NAT的优点所在：用同一个公网IP地址可以实现多个用户的Internet接入。

针对相关技术中外部设备上的媒体流的QoS要求无法保证的问题，目前尚未提出有效的解决方案。

发明内容

为了解决上述技术问题，本发明提供了一种专用承载建立方法、装置及用户设备。

根据本发明的一个方面，提供了一种专用承载建立方法，包括：确定需要经由用户设备传输外部设备与远端设备之间的媒体流，其中，所述用户设备通过承载网与所述远端设备进行通信；建立所述用户设备与所述承载网之间的专用承载，其中，所述外部设备与所述远端设备之间的媒体流在所述专用承载上传输。

优选地，确定需要经由所述用户设备传输所述外部设备与所述远端设备之间的媒体流包括：所述用户设备接收所述外部设备的媒体描述或者承载资源修改请求；所述用户设备根据所述媒体描述或者所述承载资源修改请求，确定需要经由所述用户设备传输所述外部设备与所述远端设备之间的媒体流。

优选地，在所述用户设备接收所述外部设备的媒体描述之前，所述方法还包括：所述用户设备发送媒体描述查询请求或者所述远端设备的呼叫请求至所述外部设备。

优选地，所述用户设备确定需要经由所述用户设备传输所述外部设备与所述远端设备之间的媒体流包括：所述用户设备接收所述外部设备的预设消息，其中，所述预设消息包括以下之一：呼叫请求、注册请求、呼叫响应、媒体描述查询响应，所述预设消息中携带有所述媒体描述/所述承载资源修改请求；所述用户设备根据所述预设消息，确定需要经由所述用户设备传输所述外部设备与所述远端设备之间的媒体流。

优选地，建立所述用户设备与所述承载网之间的所述专用承载包括：所述用户设备发送承载资源修改请求至所述承载网，其中，所述承载资源修改请求用于请求建立所述专用承载。

优选地，建立所述用户设备与所述承载网之间的所述专用承载包括：所述用户设备发送所述承载资源修改请求至所述承载网的P-GW；所述P-GW与PCRF交互；所述PCRF触发所述承载网创建所述专用承载的过程；所述承载网完成所述专用承载的建立。

优选地，建立所述用户设备与所述承载网之间的所述专用承载包括：所述用户设备发送所述承载资源修改请求至所述承载网的PCRF；所述PCRF触发所述承载网创建所述专用承载的过程；所述承载网完成所述专用承载的建立。

优选地，确定需要经由所述用户设备传输所述外部设备与所述远端设备之间的媒体流包括：所述承载网接收所述外部设备的媒体描述；所述承载网根据所述媒体描述，确定需要经由所述用户设备传输所述外部设备与所述远端设备之间的媒体流。

优选地，建立所述用户设备与所述承载网之间的所述专用承载包括：所述承载网的AF接收所述用户设备发送的呼叫请求；所述AF与PCRF交互；所述PCRF触发所述承载网创建所述专用承载的过程；所述承载网完成所述专用承载的建立。

根据本发明的另一个方面，还提供了一种专用承载建立装置，应用于用户设备，包括：确定模块，用于确定需要经由所述用户设备传输外部设备与远端设备之间的媒体流，其中，所述用户设备通过承载网与所述远端设备进行通信；建立模块，用于建立所述用户设备与所述承载网之间的专用承载，其中，所述外部设备与所述远端设备之间的媒体流在所述专用承载上传输。

优选地，所述确定模块包括：接收单元，用于接收所述外部设备的媒体描述或者承载资源修改请求；确定单元，用于根据所述媒体描述或者所述承载资源修改请求，确定需要经由所述用户设备传输所述外部设备与所述远端设备之间的媒体流。

优选地，所述装置还包括：发送模块，用于发送媒体描述查询请求或者所述远端设备的呼叫请求至所述外部设备。

优选地，所述接收单元，用于接收所述外部设备的预设消息，其中，所述预设消息包括以下之一：呼叫请求、注册请求、呼叫响应、媒体描述查询响应，所述预设消息中携带有所述媒体描述/所述承载资源修改请求；所述确定单元，用于根据所述预设消息，确定需要经由所述用户设备传输所述外部设备与所述远端设备之间的媒体流。

优选地，所述建立模块，用于发送承载资源修改请求至所述承载网，其中，所述承载资源修改请求用于请求建立所述专用承载。

根据本发明的另一个方面，还提供了一种专用承载建立装置，应用于承载网，包括：确定模块，用于确定需要经由所述用户设备传输外部设备与远端设备之间的媒体流，其中，所述用户设备通过承载网与所述远端设备进行通信；建立模块，用于建立所述用户设备与所述承载网之间的专用承载，其中，所述外部设备与所述远端设备之间的媒体流在所述专用承载上传输。

优选地，所述确定模块包括：接收单元，用于接收所述外部设备的媒体描述；确定单元，用于根据所述媒体描述，确定需要经由所述用户设备传输所述外部设备与所述远端设备之间的媒体流。

根据本发明的另一个方面，还提供了一种用户设备，包括：上述的专用承载建立装置。

通过本发明，采用确定需要经由用户设备传输外部设备与远端设备之间的媒体流，其中，用户设备通过承载网与远端设备进行通信；建立用户设备与承载网之间的专用承载，其中，外部设备与远端设备之间的媒体流在专用承载上传输的方式，解决了外部设备上的媒体流的QoS要求无法保证的问题，通过专用承载为外部设备的媒体流传输提供了QoS保障。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的专用承载建立方法的流程图；

图2是根据本发明实施例的专用承载建立系统的结构示意图一；

图3是根据本发明实施例的专用承载建立系统的结构示意图二；

图4是根据本发明实施例的专用承载建立系统的结构示意图三；

图5是根据本发明实施例的专用承载建立系统的结构示意图四；

图6是根据本发明实施例的专用承载的示意图一；

图7是根据本发明实施例的专用承载的示意图二；

图8是根据本发明实施例的专用承载的示意图三；

图9是根据本发明优选实施例的专用承载建立方法的流程示意图；

图10是根据本发明优选实施例的承载网创建专用承载过程的流程图；

图11是根据本发明优选实施例的UE1发起专用承载建立时的专用承载建立过程的流程图一；

图12是根据本发明优选实施例的UE1发起专用承载建立时的专用承载建立过程的流程图二；

图13是根据本发明优选实施例的透明呼叫的注册流程的流程图一；

图14是根据本发明优选实施例的透明呼叫的注册流程的流程图二；

图15是根据本发明优选实施例的结合NAT穿越服务器的透明呼叫过程的流程图；

图16是根据本发明优选实施例的基于ALG的透明呼叫过程的流程图；

图17是根据本发明优选实施例的采用透明呼叫的主叫过程的流程图；

图18是根据本发明优选实施例的采用透明呼叫的被叫过程的流程图；

图19是根据本发明优选实施例的融合设备呼叫的主叫过程的流程图；

图20是根据本发明优选实施例的融合设备呼叫的被叫过程的流程图；

图21是根据本发明优选实施例的用户设备及其在专用承载建立系统中的位置关系的示意图；

图22是根据本发明实施例的外部应用支持QoS的流程示意图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

本发明实施例提供了一种专用承载建立方法，图1是根据本发明实施例的专用承载建立方法的流程图，如图1所示，该流程包括如下步骤：

步骤S102，确定需要经由用户设备传输外部设备与远端设备之间的媒体流，其中，用户设备通过承载网与远端设备进行通信；

步骤S104，建立用户设备与承载网之间的专用承载，其中，外部设备与远端设备之间的媒体流在专用承载上传输。

通过上述步骤，在确定需要经由用户设备传输外部设备与远端设备之间的媒体流的情况下，建立用户设备与承载网之间的专用承载。相对于相关技术中使用默认承载无法进行QoS控制导致外部设备的业务无法提供QoS保证的问题，采用本发明实施例提供的上述步骤，使得外部设备与远端设备之间的媒体流可以进行QoS控制，解决了外部设备上的媒体流的QoS要求无法保证的问题，通过专用承载为外部设备的媒体流传输提供了QoS保障。

优选地，确定需要经由用户设备传输外部设备与远端设备之间的媒体流包括：用户设备接收外部设备的媒体描述或者承载资源修改请求；用户设备根据媒体描述或者承载资源修改请求，确定需要经由用户设备传输外部设备与远端设备之间的媒体流。

优选地，在用户设备接收外部设备的媒体描述之前，用户设备发送媒体描述查询请求或者远端设备的呼叫请求至外部设备。

优选地，用户设备确定需要经由用户设备传输外部设备与远端设备之间的媒体流包括：用户设备接收外部设备的预设消息，其中，预设消息包括以下之一：呼叫请求、注册请求、呼叫响应、媒体描述查询响应，预设消息中携带有媒体描述/承载资源修改请求；用户设备根据预设消息，确定需要经由用户设备传输外部设备与远端设备之间的媒体流。

优选地，建立用户设备与承载网之间的专用承载包括：用户设备发送承载资源修改请求至承载网，其中，承载资源修改请求用于请求建立专用承载。

优选地，建立用户设备与承载网之间的专用承载包括：用户设备发送承载资源修改请求至承载网的P-GW；P-GW与PCRF交互；PCRF触发承载网创建专用承载的过程；承载网完成专用承载的建立。

优选地，建立用户设备与承载网之间的专用承载包括：用户设备发送承载资源修改请求至承载网的PCRF；PCRF触发承载网创建专用承载的过程；承载网完成专用承载的建立。

优选地，确定需要经由用户设备传输外部设备与远端设备之间的媒体流包括：承载网接收外部设备的媒体描述；承载网根据媒体描述，确定需要经由用户设备传输外部设备与远端设备之间的媒体流。

优选地，建立用户设备与承载网之间的专用承载包括：承载网的AF接收用户设备发送的呼叫请求；AF与PCRF交互；PCRF触发承载网创建专用承载的过程；承载网完成专用承载的建立。

在本实施例中还提供了一种专用承载建立装置，用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述，下面对该装置中涉及到的模块进行说明。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

该专用承载建立装置，应用于用户设备，包括：确定模块，用于确定需要经由用户设备传输外部设备与远端设备之间的媒体流，其中，用户设备通过承载网与远端设备进行通信；建立模块，用于建立用户设备与承载网之间的专用承载，其中，外部设备与远端设备之间的媒体流在专用承载上传输。

优选地，确定模块包括：接收单元，用于接收外部设备的媒体描述或者承载资源修改请求；确定单元，用于根据媒体描述或者承载资源修改请求，确定需要经由用户设备传输外部设备与远端设备之间的媒体流。

优选地，装置还包括：发送模块，用于发送媒体描述查询请求或者远端设备的呼叫请求至外部设备。

优选地，接收单元，用于接收外部设备的预设消息，其中，预设消息包括以下之一：呼叫请求、注册请求、呼叫响应、媒体描述查询响应，预设消息中携带有媒体描述/承载资源修改请求；确定单元，用于根据预设消息，确定需要经由用户设备传输外部设备与远端设备之间的媒体流。

优选地，建立模块，用于发送承载资源修改请求至承载网，其中，承载资源修改请求用于请求建立专用承载。

本发明实施例还提供了一种专用承载建立装置，应用于承载网，包括：确定模块，用于确定需要经由用户设备传输外部设备与远端设备之间的媒体流，其中，用户设备通过承载网与远端设备进行通信；建立模块，用于建立用户设备与承载网之间的专用承载，其中，外部设备与远端设备之间的媒体流在专用承载上传输。

优选地，确定模块包括：接收单元，用于接收外部设备的媒体描述；确定单元，用于根据媒体描述，确定需要经由用户设备传输外部设备与远端设备之间的媒体流。

本发明实施例还提供了一种用户设备，包括：上述的专用承载建立装置。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

图2是根据本发明实施例的专用承载建立系统的结构示意图一，如图2所示，在本发明实施例中，涉及的实体包括：

用户设备(User Equipment，简称为UE)：具有通信能力的终端设备，例如：智能手机、Pad类平板电脑、笔记本电脑或其它用户智能设备。

外部设备：在本发明实施例中又被称为融合通信设备，该设备具有多媒体能力，同时具备通信能力的设备。

承载网：UE接入外部网络的承载网，包括但不限于3G/4G网络，以及后续演进的其他网络(例如5G)。对于4G网络而言，承载网包括：基站(eNode B)、移动性管理实体(MME)、服务网关(Serving-Gateway，简称为S-GW)、分组数据网关(Packet DataNetwork Gateway，简称为P-GW)。

远端设备：与UE(或者外部设备)建立通话的对端，可以是另一个UE，也可以是媒体服务器。

本发明实施例中的“经由用户设备传输的、外部设备与远端设备之间的媒体流”即外挂的媒体流，是指媒体流建立在外部设备与远端设备之间，但从网络传输上来看是经过UE的。例如：UE作为3G/4G/5G的无线路由器，UE提供Wi-Fi热点(或者其他无线接入点，例如蓝牙、近场通讯等)并为外部设备分配无线局域网(WLAN)的地址；外部设备通过UE的Wi-Fi热点与外部网络交互，而UE将外部设备的网络传输，承载在其3G/4G/5G上。

参照图2，为了实现本发明实施例的上述步骤，可以新增或者利用的网络接口包括：

控制接口1：UE与融合通信设备之间的控制接口。用于UE与外部设备之间传递媒体描述；可选地，该控制接口1还可以用来承载通道的建立指示、承载通道的状态等。对于控制接口1中的控制信令，可以承载在UE与外部设备之间的多种网络连接上，例如蓝牙、WLAN、近场通信(NFC)等。

其中，媒体描述可以在现有的呼叫请求(例如INVITE请求)中携带，不需要额外扩展信令。这种方式，定义为透明呼叫方式；媒体描述也可以使用呼叫请求以外的信令通道传递，例如融合设备的方式，该方式将在本发明实施例的后续内容中进行介绍。

控制接口2：UE与承载网之间的控制接口。用于承载资源修改请求。

媒体接口1：外部设备与UE之间用于传输媒体流的媒体接口。

媒体接口2：UE与承载网之间用于传输媒体流的媒体接口。其中，媒体流在媒体接口2的传输将使用具有QoS保障的传输，即，使用专用承载(Dedicated Bearer)传输媒体流。

现有媒体接口：承载网与远端设备之间的媒体接口，该媒体接口为相关技术中的已有接口，可以不进行改动。

图3是根据本发明实施例的专用承载建立系统的结构示意图二，图3为图2的另一种演进形态，UE如果不能使用图2的方式与承载网交互，则也可以使用图3的方式。

如图3所示，在该系统中通过策略和计费规则功能(Policy and Charging RulesFunction，简称为PCRF)与承载网交互，实现QoS控制；

其中，PCRF包括拜访PCRF(Visited-PCRF，简称为V-PCRF)和归属PCRF(Home-PCRF，简称为H-PCRF)。一般UE先与V-PCRF交互，当V-PCRF不能确认时，例如需要结合用户签约数据才能确认时，则V-PCRF与H-PCRF交互确认。

在图3所示的系统架构中，还要建立媒体接口1与媒体接口2的映射关系，并在媒体接口2建立专用承载。

在图3中还包括：

控制接口2：UE与PCRF之间的控制接口，用于UE直接向PCRF请求承载修改，以实现专用承载建立；该控制接口2与图2中的控制接口2功能类似，但是使用的信令、传递的路径有所不同。

Gx接口：PCRF与承载网之间的接口，为相关技术中已有的接口。

图4是根据本发明实施例的专用承载建立系统的结构示意图三，图4是图3的另一种演进形态，利用图4所示的系统结构，网络侧(即承载网)可以直接触发专用承载的建立。

如图4所示，其中，应用功能(Application Function，简称为AF)，用于接受UE的应用层信令，并与PCRF交互，以实现承载修改。

在图4所示的系统架构中，还要建立媒体接口1与媒体接口2的映射关系，并在媒体接口2建立专用承载。

在图4中还包括：

控制接口2：UE与AF之间的接口，AF在与UE交互的信令中，获取媒体描述；

Rx接口：AF与PCRF之间的接口，为相关技术中已有的接口。

其中，UE作为3G/4G/5G的无线路由器和Wi-Fi热点，为外部设备分配WLAN的地址。在IPv4构架中，UE还需要进行NAT的功能(在IPv6中则可以不需要进行NAT的功能)。如果UE为媒体流提供了应用层网关(Application Layer Gateways，简称为ALG)功能，则外部设备可以不需要考虑NAT穿越；否则，外部设备还需要考虑NAT穿越。

图5是根据本发明实施例的专用承载建立系统的结构示意图四，图5是图2的另一种演进形态，为了实现外部设备的NAT穿越，在图5所示的系统中采用了NAT穿越服务器。

NAT穿越服务器：为NAT穿越提供服务的服务器，如NAT的用户数据报协议(UDP)简单穿越(Simple Traversal of UDP over NATs，简称为STUN)服务器、使用中继的NAT穿越(Traversal Using Relays around NAT，简称为TURN)服务器。对于交互式连接建立(Interactive Connectivity Establishment，简称为ICE)穿越NAT的方式，同时需要STUN和TURN协议，则NAT穿越服务器可能是两个或两个以上。

在图5所示的系统架构中，还要建立媒体接口1与媒体接口2的映射关系，并在媒体接口2建立专用承载。

在图5中还包括：

控制接口3：在UE与NAT穿越服务器之间，外部设备穿越NAT所使用的接口，其报文经过NAT(UE)和承载网。

下面对本发明实施例中建立的专用承载进行介绍。

图6是根据本发明实施例的专用承载的示意图一，如图6所示，媒体流的上下行使用一个专用承载。对于媒体描述协议(Session Description Protocol，简称为SDP)内的一个m行(对应于一个媒体流)，例如音频(Audio)，可以具有上行(外部设备到远端的媒体流)和下行(远端到外部设备的媒体流)，这两个流在一个专用承载内。

图7是根据本发明实施例的专用承载的示意图二，如图7所示，多个媒体流可以使用同一个专用承载。对于SDP内的多个m行，例如音频(Audio)和视频(Video)，音频、视频媒体流在一个专用承载内。

其中，对于SDP的表述，可以使用显示的指示，也可以采用隐示的方式而默认表示使用一个流。

图8是根据本发明实施例的专用承载的示意图三，如图8所示，多个媒体流分别使用多个专用承载。对于SDP内的多个m行，例如Audio和Video，音频、视频媒体流分别在不同的专用承载内。

其中，对于SDP的表述，需要使用显示的指示。例如，如果是由UE请求专用承载的建立，UE需要为不同的组(group，一个媒体流，或多个媒体流可以在一个组内传输)请求建立专用承载，并由承载网分别建立专用承载；如果是承载网主动发起专用承载建立，承载网需要为不同的group分别建立专用承载。

下面结合优选实施例对图1所示的方法进行描述和说明。

图9是根据本发明优选实施例的专用承载建立方法的流程示意图，图9是图1的一种变形形式，如图9所示，该优选流程包括：

步骤S902，外部设备向UE1发送媒体描述；

其中，外部设备可以主动发送呼叫请求，该呼叫请求中携带媒体描述；或者在步骤S902之前UE1可以预先向外部设备发送媒体描述查询请求。外部设备主动发送的呼叫请求，可以是INVITE请求，也可以是类似融合设备一类的扩展消息；

步骤S904，UE1向注册服务器发送呼叫请求；

其中，如果是图4所示的系统架构，则呼叫请求可以发送给AF，例如代理呼叫会话控制功能((Proxy-Call Session Control Function，简称为P-CSCF)；

步骤S906，注册服务器转发呼叫请求到远端设备(即UE2)；

步骤S908，UE2返回临时响应，可以携带UE2的媒体描述；

步骤S910，注册服务器转发临时响应到UE1；

步骤S912，如果临时响应中携带有媒体描述，则UE1将临时响应中的媒体描述发送到外部设备；发送媒体描述的消息可以是临时响应消息，也可以是类似融合设备一类的扩展消息；

步骤S914，如果采用UE1发起专用承载建立，则执行本步骤。UE1发起承载资源修改请求。如果UE1支持图2的系统的控制接口2，则消息发送给承载网的P-GW；如果UE1支持图3的系统，则消息发送给PCRF。如果由网络侧(承载网)发起专用承载建立(即采用图4所示的系统)的方式，则跳过步骤S914；

步骤S916，如果采用承载网发起专用承载建立，承载网发送创建专用承载请求消息到UE1；如果由网络侧(承载网)发起专用承载建立(即采用图4所示的系统)的方式，则AF与PCRF进行交互，PCRF与承载网的其他实体进行交互，以完成专用承载的建立。

步骤S918，UE1返回创建专用承载响应到承载网；至此专用承载已经建立并已经通知UE1专用承载建立完毕。

步骤S920，UE2发送呼叫响应到注册服务器；

步骤S922，注册服务器转发呼叫响应到UE1；

步骤S924，可选地，UE1发送呼叫响应(或呼叫响应通知)到外部设备；

至此，媒体面建立在外部设备与UE2之间；并且UE1与承载网之间的传输为专用承载，支持QoS。需要说明的是，在图9中以远端设备(UE2)到UE1的媒体流向为例(即下行)以说明专用承载部分及UE1对媒体的转发，而实际上媒体流可以是上下行两个方向。

此外，上述流程步骤的顺序并非是固定的，在某些情况下也可以以不同的顺序执行，并且，为了适应不同顺序的执行，还可以对上述流程步骤进行适当的改造或者补充。例如，UE1发送承载资源修改请求，以及相应的创建专用承载的过程，也可以在UE1接收到呼叫响应之后再发送；在这种情况下，在被叫用户振铃前，专用承载可能没有建立完成。

以4G为例，承载网包括：eNode B、MME、S-GW、P-GW；图10是根据本发明优选实施例的承载网创建专用承载过程的流程图，如图10所示，承载网创建专用承载包括如下步骤：

步骤S1002，P-GW向S-GW发送创建承载请求；一般是由PCRF触发P-GW发送创建承载请求。

步骤S1004，S-GW向MME发送创建承载请求；

步骤S1006，MME分配承载ID；

步骤S1008，MME向eNode B发送演进的通用陆基无线接入网(Evolved UniversalTerrestrial Radio Access Network，简称为E-UTRAN)无线接入承载(E-UTRAN RadioAccess Bearer，简称为E-RAB)建立请求/承载管理请求；

步骤S1010，eNode B与UE1交互，进行无线资源控制(Radio Resource Control，简称为RRC)重配置；

步骤S1012，eNode B向MME发送E-RAB建立响应；

步骤S1014，UE1向MME发送承载管理响应；

步骤S1016，MME向S-GW发送创建承载响应；

步骤S1018，S-GW向P-GW发送创建承载响应。

下面对采用UE1发起专用承载建立时的专用承载建立进行描述。

图11是根据本发明优选实施例的UE1发起专用承载建立时的专用承载建立过程的流程图一，该流程应用于图2所示的系统架构中。如图11所示，包括如下步骤：

步骤S1102，UE1向MME发送承载资源修改请求；

步骤S1104，MME向S-GW发送承载资源修改请求；

步骤S1106，S-GW向P-GW发送承载资源修改请求；

步骤S1108，P-GW与PCRF交互；

步骤S1110，PCRF触发创建专用承载过程，参照图10所示的过程；

步骤S1112，创建完成后，P-GW与PCRF交互，将创建的情况通知PCRF。

图12是根据本发明优选实施例的UE1发起专用承载建立时的专用承载建立过程的流程图二，该流程应用于图3所示的系统架构中。如图12所示，包括如下步骤：

步骤S1202，UE1向PCRF发送承载资源修改请求；

其中，在相关技术中UE1可能没有能将图11方式的承载资源修改请求能力开放给应用层，尤其是非IP多媒体子系统(IMS)的应用。所以在图12所示的系统架构中，PCRF可开放一个接口，直接接收UE1的承载资源修改请求。这个接口可以应用于UE1内置应用的媒体流，也可以应用于外挂的媒体流。

步骤S1204，PCRF与P-GW交互；

步骤S1206，PCRF触发创建专用承载过程，参照图10所示的过程；

步骤S1208，创建完成后，P-GW与PCRF交互，将创建的情况通知PCRF。

应用图1所示的专用承载建立方法，本发明实施例提供了在注册过程中实现专用承载建立的方法。其中，在注册过程中，可以采用透明呼叫的注册流程，也可以采用融合设备通信的注册流程。

其中，透明呼叫是指信令和媒体流都终结在外部设备上，例如，UE1仅作为提供Wi-Fi的无线路由器，对于外部设备而言，UE1可以看成是透明的。

本发明实施例提供了一种透明呼叫的注册流程，在该注册流程中，外部设备向UE1发送创建信令承载请求。图13是根据本发明优选实施例的透明呼叫的注册流程的流程图一，如图13所示，包括如下步骤：

步骤S1302，外部设备向UE1发送创建信令承载请求(用于触发UE1向承载网发送承载资源修改请求)；

步骤S1304，UE1向承载网发送承载资源修改请求；可选的，也可以由外部设备向UE1发送承载资源修改请求，UE1将承载资源修改请求转发至承载网；

步骤S1306，承载网向UE1发送创建专用承载请求；

步骤S1308，UE1向承载网发送创建专用承载响应；

步骤S1310，UE1向外部设备发送创建信令承载响应(相当于专用承载建立响应)，至此，专用承载建立完毕；

步骤S1312，外部设备发送注册请求，第一跳经过UE1；

步骤S1314，UE1转发注册请求到注册服务器，注册请求在专用承载中传输；

步骤S1316，注册服务器发送注册响应至UE1，注册响应在专用承载中传输。

步骤S1318，UE1转发注册响应到外部设备。

本发明实施例还提供了另一种透明呼叫的注册流程，在该注册流程中，外部设备向UE1发送注册请求。图14是根据本发明优选实施例的透明呼叫的注册流程的流程图二，如图14所示，包括如下步骤：

步骤S1402，外部设备发送注册请求，第一跳经过UE1；

步骤S1404，UE1向承载网发送承载资源修改请求；

步骤S1406，承载网向UE1发送创建专用承载请求；

步骤S1408，UE1向承载网发送创建专用承载响应，至此，专用承载建立完毕；

步骤S1410，UE1转发注册请求到注册服务器，注册请求在承载网专用承载中传输；

步骤S1412，注册服务器发送注册响应至UE1，注册响应在承载网专用承载中传输；

步骤S1414，UE1转发注册响应到外部设备。

比较图13和图14的注册流程可知，外部设备向承载网发送注册请求的步骤可以在建立专用承载之前，也可以在建立专用承载之后。

在上述过程中已经提及，可以采用图5所示的系统架构，实现报文NAT穿越。需要说明的是，图5中突出描述的是存在NAT穿越服务器时的系统架构，该系统架构可以是基于图2～图4中任一个的改进。

下面以图2与图5相结合的系统架构为例，对结合NAT穿越服务器的透明呼叫过程进行描述。图15是根据本发明优选实施例的结合NAT穿越服务器的透明呼叫过程的流程图，如图15所示，包括如下步骤：

步骤S1502，外部设备与NAT穿越服务器交互，获取将创建的媒体流由UE1(NAT)转发所使用的外部地址(即公网地址)，UE1(NAT)创建NAT映射表；

步骤S1504，外部设备发送INVITE请求(呼叫请求)，其中，媒体描述使用步骤S1502中获取的外部地址；消息第一跳发送到UE1；

步骤S1506，UE1转发INVITE请求到注册服务器；

步骤S1508，注册服务器转发INVITE请求到UE2(即远端设备)；

步骤S1510，UE2发送临时响应183，其中携带有UE2的媒体描述；

步骤S1512，注册服务器转发临时响应183到UE1；

步骤S1514，UE1转发临时响应183到外部设备；

步骤S1516，在创建承载由UE1触发的情况下，外部设备发送订阅承载建立状态消息；在创建承载由外部设备触发的情况下，外部设备发送创建承载请求；

步骤S1518，UE1向承载网发送承载资源修改请求；

步骤S1520，承载网向UE1发送创建专用承载请求；

步骤S1522，UE1向承载网发送创建专用承载响应；

步骤S1524，UE1向外部设备发送承载建立完成通知，此时，专用承载建立完毕；

步骤S1526，外部设备发送UPDATE，经过中间网元转发到UE2；

步骤S1528，UE2回200OK，经过中间网元转发到外部设备；

步骤S1530，UE2回呼叫响应，经过中间网元转发到外部设备；

步骤S1532，建立媒体流，该媒体流在UE1与承载网之间，并在专用承载中传输；

需要说明的是，图15中为了表示转发关系，仅画了下行方向，实际是可以有上下行两个方向；此外，因为NAT的结合比较独立，后续的实施例将不再结合NAT描述。

在UE1具有ALG功能时，可以不需要借助NAT穿越服务器实现NAT功能。图16是根据本发明优选实施例的基于ALG的透明呼叫过程的流程图，如图16所示，包括如下步骤：

步骤S1602，外部设备发送INVITE请求，媒体描述为内网地址，即UE为外部设备分配的地址，消息第一跳发送到UE。

步骤S1604，UE1根据收到INVITE请求，创建媒体转发映射表；

步骤S1606，UE1转发INVITE请求到注册服务器；

步骤S1608，注册服务器转发INVITE请求到UE2；

步骤S1610，UE2发送临时响应183，携带UE2的媒体描述；

步骤S1612，注册服务器转发临时响应183到UE1；

步骤S1614，UE1更新媒体转发映射表；

步骤S1616，UE1转发临时响应183到外部设备；

步骤S1618，在创建承载由UE1触发的情况下，外部设备发送订阅承载建立状态消息；在创建承载由外部设备触发的情况下，外部设备发送创建承载请求；

步骤S1620，UE1向承载网发送承载资源修改请求；

步骤S1622，承载网向UE1发送创建专用承载请求；

步骤S1624，UE1向承载网发送创建专用承载响应；

步骤S1626，UE1向外部设备发送承载建立完成通知，此时，专用承载建立完毕；

步骤S1628，外部设备发送UPDATE，经过中间网元转发到UE2；

步骤S1630，UE2回200OK，经过中间网元转发到外部设备；

步骤S1632，UE2回呼叫响应，经过中间网元转发到外部设备；

步骤S1634，建立媒体流，该媒体流在UE1与承载网之间，并在专用承载中传输；UE1执行ALG的行为，根据媒体转发映射表，在内外网之间转发媒体。

需要说明的是，图16中为了表示转发关系，仅画了下行方向，实际是可以有上下行两个方向；此外，因为ALG的结合比较独立，后续的实施例将不再结合ALG描述。

下面将从透明呼叫过程、融合设备呼叫过程两个方面，分别对外部设备的主叫、被叫过程进行描述和说明。

本发明实施例结合图3的系统架构提出了透明呼叫的主叫过程。图17是根据本发明优选实施例的采用透明呼叫的主叫过程的流程图，如图17所示，包括如下步骤：

步骤S1702，外部设备发送INVITE请求，消息第一跳发送到UE1；

步骤S1704，UE1转发INVITE请求到注册服务器；

步骤S1706，注册服务器转发INVITE请求到UE2；

步骤S1708，UE2发送临时响应183，携带UE2的媒体描述；

步骤S1710，注册服务器转发临时响应183到UE1；

步骤S1712，UE1转发临时响应183到外部设备；

步骤S1714，在创建承载由UE1触发的情况下，外部设备发送订阅承载建立状态消息；在创建承载由外部设备触发的情况下，外部设备发送创建承载请求；

步骤S1716，UE1向PCRF发送承载资源修改请求；

步骤S1718，PCRF与承载网交互；

步骤S1720，承载网向UE1发送创建专用承载请求；

步骤S1722，UE1向承载网发送创建专用承载响应；

步骤S1724，承载网与PCRF交互；

步骤S1726，PCRF向UE1发送承载资源修改通知；

步骤S1728，UE1向外部设备发送承载建立完成通知，此时，专用承载建立完毕；

步骤S1730，外部设备发送UPDATE，经过中间网元转发到UE2；

步骤S1732，UE2回200OK，经过中间网元转发到外部设备；

步骤S1734，UE2回呼叫响应，经过中间网元转发到外部设备；

步骤S1736，建立媒体流，媒体流在UE与承载网之间，并在专用承载中传输。

需要说明的是，图17中为了表示转发关系，仅画了下行方向，实际是可以有上下行两个方向。

本发明实施例结合图3的系统架构提出了透明呼叫的被叫过程。图18是根据本发明优选实施例的采用透明呼叫的被叫过程的流程图，如图18所示，包括如下步骤：

步骤S1802，UE2向注册服务器发送INVITE请求；

步骤S1804，注册服务器转发INVITE请求到UE1；

步骤S1806，UE1转发INVITE请求到外部设备；

步骤S1808，外部设备发送临时响应183，携带外部设备的媒体描述；

步骤S1810，UE1转发临时响应183到注册服务器；

步骤S1812，注册服务器转发临时响应183到UE2；

步骤S1814，在创建承载由UE1触发的情况下，外部设备发送订阅承载建立状态消息；在创建承载由外部设备触发的情况下，外部设备发送创建承载请求；

步骤S1816，UE1向PCRF发送承载资源修改请求；

步骤S1818，PCRF与承载网交互；

步骤S1820，承载网向UE1发送创建专用承载请求；

步骤S1822，UE1向承载网发送创建专用承载响应；

步骤S1824，承载网与PCRF交互；

步骤S1826，PCRF向UE1发送承载资源修改通知；

步骤S1828，UE1向外部设备发送承载建立完成通知；

步骤S1830，UE2发送UPDATE，经过中间网元转发到外部设备；

步骤S1832，外部设备回200OK，经过中间网元转发到UE2；

步骤S1834，外部设备回用户振铃180，经过中间网元转发到UE2；

步骤S1836，外部设备回呼叫响应，经过中间网元转发到UE2；

步骤S1838，建立媒体流，媒体流在UE与承载网之间，并在专用承载中传输。

需要说明的是，图18中为了表示转发关系，仅画了下行方向，实际是可以有上下行两个方向。

本发明实施例提出了融合设备呼叫的主叫过程。融合设备呼叫的信令面保留在UE1，一般可以由网络侧发起专用承载的建立。在本发明实施例中将以网络侧建立专用承载为例进行说明。图19是根据本发明优选实施例的融合设备呼叫的主叫过程的流程图，如图19所示，包括如下步骤：

步骤S1902，UE1向外部设备发送媒体描述查询；

步骤S1904，外部设备返回媒体描述；

步骤S1906，UE1使用外部设备的媒体描述，构造SDP，发送INVITE请求；如果是IMS系统，INVITE请求发送到P-CSCF；

步骤S1908，P-CSCF转发INVITE请求注册服务器；

步骤S1910，注册服务器转发INVITE请求到UE2；

步骤S1912，UE2发送临时响应183，携带UE2的媒体描述；

步骤S1914，注册服务器转发临时响应183到P-CSCF；

步骤S1916，注册服务器转发临时响应183到UE1；

步骤S1918，AF(P-CSCF)与PCRF交互，触发专用承载建立；

步骤S1920，PCRF与承载网交互，触发专用承载建立；

步骤S1922，承载网向UE发送创建专用承载请求；

步骤S1924，UE向承载网发送创建专用承载响应；

步骤S1926，承载网与PCRF交互；

步骤S1928，PCRF与AF交互；

步骤S1930，UE1发送UPDATE，经过中间网元转发到UE2；

步骤S1932，UE2回200OK，经过中间网元转发到UE1；

步骤S1934，UE2回呼叫响应，经过中间网元转发到UE1；

步骤S1936，建立媒体流，媒体流在UE与承载网之间，并在专用承载中传输。

需要说明的是，图19中为了表示转发关系，仅画了下行方向，实际是可以有上下行两个方向。

本发明实施例提出了融合设备呼叫的被叫过程。图20是根据本发明优选实施例的融合设备呼叫的被叫过程的流程图，如图20所示，包括如下步骤：

步骤S2002，UE2向注册服务器发送INVITE请求；

步骤S2004，注册服务器转发INVITE请求到P-CSCF；

步骤S2006，注册服务器转发INVITE请求到UE1；

步骤S2008，UE1向外部设备发送媒体描述查询；

步骤S2010，外部设备返回媒体描述；

步骤S2012，UE1使用外部设备的媒体描述，构造SDP，发送临时响应183；

步骤S2014，P-CSCF转发临时响应183到注册服务器；

步骤S2016，注册服务器转发临时响应183到UE2；

步骤S2018，AF(P-CSCF)与PCRF交互，触发专用承载建立；

步骤S2020，PCRF与承载网交互，触发专用承载建立；

步骤S2022，承载网向UE发送创建专用承载请求；

步骤S2024，UE向承载网发送创建专用承载响应；

步骤S2026，承载网与PCRF交互；

步骤S2028，PCRF与AF交互；

步骤S2030，UE2发送UPDATE，经过中间网元转发到UE1；

步骤S2032，UE1回200OK，经过中间网元转发到UE2；

步骤S2034，UE1回用户振铃180，经过中间网元转发到UE2；

步骤S2036，UE1回呼叫响应，经过中间网元转发到UE2；

步骤S2038，建立媒体流，媒体流在UE与承载网之间，并在专用承载中传输。

需要说明的是，图20中为了表示转发关系，仅画了下行方向，实际是可以有上下行两个方向。

为了实现本发明实施例的上述方案，提出了一种UE。图21是根据本发明优选实施例的用户设备及其在专用承载建立系统中的位置关系的示意图，如图21所示，UE支持向外部应用开放专用承载建立的内部结构。外部应用可以是UE内置的应用(App)，也可以是提供外部媒体流的无线路由器控制模块。

其中，UE内部的操作系统(Operating System，简称为OS)或软件开发工具包(Software Development Kit，简称为SDK)提供支持专用承载的网络编程接口，创建响应的连接，在承载网中使用专用承载传输，与远端建立媒体流。

图22是根据本发明实施例的外部应用支持QoS的流程示意图，如图22所示，包括如下步骤：

步骤S2202，外部应用调用OS/SDK的Socket接口，创建专用承载通道；

步骤S2204，OS/SDK向承载网发送承载资源修改请求；

步骤S2206，承载网向OS/SDK发送创建专用承载请求；

步骤S2208，OS/SDK向承载网发送创建专用承载响应；

步骤S2210，外部应用的数据收发将在承载网的专用承载中传输。

综上所述，通过本发明的上述实施例和优选实施例，提出一种外挂媒体流支持QoS的架构，支持在外部设备上的媒体流可以通过UE1的3G/4G/5G进行有QoS保障的传输。

在另外一个实施例中，还提供了一种软件，该软件用于执行上述实施例及优选实施方式中描述的技术方案。

在另外一个实施例中，还提供了一种存储介质，该存储介质中存储有上述软件，该存储介质包括但不限于：光盘、软盘、硬盘、可擦写存储器等。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的对象在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (17)

1.一种专用承载建立方法，其特征在于包括：

确定需要经由用户设备传输外部设备与远端设备之间的媒体流，其中，所述用户设备通过承载网与所述远端设备进行通信；

建立所述用户设备与所述承载网之间的专用承载，其中，所述外部设备与所述远端设备之间的媒体流在所述专用承载上传输。

2.根据权利要求1所述的方法，其特征在于，确定需要经由所述用户设备传输所述外部设备与所述远端设备之间的媒体流包括：

所述用户设备接收所述外部设备的媒体描述或者承载资源修改请求；

所述用户设备根据所述媒体描述或者所述承载资源修改请求，确定需要经由所述用户设备传输所述外部设备与所述远端设备之间的媒体流。

3.根据权利要求2所述的方法，其特征在于，在所述用户设备接收所述外部设备的媒体描述之前，所述方法还包括：

所述用户设备发送媒体描述查询请求或者所述远端设备的呼叫请求至所述外部设备。

4.根据权利要求2所述的方法，其特征在于，所述用户设备确定需要经由所述用户设备传输所述外部设备与所述远端设备之间的媒体流包括：

所述用户设备接收所述外部设备的预设消息，其中，所述预设消息包括以下之一：呼叫请求、注册请求、呼叫响应、媒体描述查询响应，所述预设消息中携带有所述媒体描述/所述承载资源修改请求；

所述用户设备根据所述预设消息，确定需要经由所述用户设备传输所述外部设备与所述远端设备之间的媒体流。

5.根据权利要求2所述的方法，其特征在于，建立所述用户设备与所述承载网之间的所述专用承载包括：

所述用户设备发送承载资源修改请求至所述承载网，其中，所述承载资源修改请求用于请求建立所述专用承载。

6.根据权利要求5所述的方法，其特征在于，建立所述用户设备与所述承载网之间的所述专用承载包括：

所述用户设备发送所述承载资源修改请求至所述承载网的P-GW；

所述P-GW与PCRF交互；

所述PCRF触发所述承载网创建所述专用承载的过程；

所述承载网完成所述专用承载的建立。

7.根据权利要求5所述的方法，其特征在于，建立所述用户设备与所述承载网之间的所述专用承载包括：

所述用户设备发送所述承载资源修改请求至所述承载网的PCRF；

所述PCRF触发所述承载网创建所述专用承载的过程；

所述承载网完成所述专用承载的建立。

8.根据权利要求1所述的方法，其特征在于，确定需要经由所述用户设备传输所述外部设备与所述远端设备之间的媒体流包括：

所述承载网接收所述外部设备的媒体描述；

所述承载网根据所述媒体描述，确定需要经由所述用户设备传输所述外部设备与所述远端设备之间的媒体流。

9.根据权利要求8所述的方法，其特征在于，建立所述用户设备与所述承载网之间的所述专用承载包括：

所述承载网的AF接收所述用户设备发送的呼叫请求；

所述AF与PCRF交互；

所述PCRF触发所述承载网创建所述专用承载的过程；

所述承载网完成所述专用承载的建立。

10.一种专用承载建立装置，应用于用户设备，其特征在于包括：

确定模块，用于确定需要经由所述用户设备传输外部设备与远端设备之间的媒体流，其中，所述用户设备通过承载网与所述远端设备进行通信；

建立模块，用于建立所述用户设备与所述承载网之间的专用承载，其中，所述外部设备与所述远端设备之间的媒体流在所述专用承载上传输。

11.根据权利要求10所述的装置，其特征在于，所述确定模块包括：

接收单元，用于接收所述外部设备的媒体描述或者承载资源修改请求；

确定单元，用于根据所述媒体描述或者所述承载资源修改请求，确定需要经由所述用户设备传输所述外部设备与所述远端设备之间的媒体流。

12.根据权利要求11所述的装置，其特征在于，所述装置还包括：

发送模块，用于发送媒体描述查询请求或者所述远端设备的呼叫请求至所述外部设备。

13.根据权利要求11所述的装置，其特征在于，

所述接收单元，用于接收所述外部设备的预设消息，其中，所述预设消息包括以下之一：呼叫请求、注册请求、呼叫响应、媒体描述查询响应，所述预设消息中携带有所述媒体描述/所述承载资源修改请求；

所述确定单元，用于根据所述预设消息，确定需要经由所述用户设备传输所述外部设备与所述远端设备之间的媒体流。

14.根据权利要求11所述的装置，其特征在于，

所述建立模块，用于发送承载资源修改请求至所述承载网，其中，所述承载资源修改请求用于请求建立所述专用承载。

15.一种专用承载建立装置，应用于承载网，其特征在于包括：

确定模块，用于确定需要经由所述用户设备传输外部设备与远端设备之间的媒体流，其中，所述用户设备通过承载网与所述远端设备进行通信；

建立模块，用于建立所述用户设备与所述承载网之间的专用承载，其中，所述外部设备与所述远端设备之间的媒体流在所述专用承载上传输。

16.根据权利要求10所述的装置，其特征在于，所述确定模块包括：

接收单元，用于接收所述外部设备的媒体描述；

确定单元，用于根据所述媒体描述，确定需要经由所述用户设备传输所述外部设备与所述远端设备之间的媒体流。

17.一种用户设备，其特征在于包括：如权利要求10至14中任一项所述的专用承载建立装置。