技术领域

本发明涉及无线通信领域， 尤其涉及一种实现服务质量 （Quality of Service , QoS )控制的方法和系统。 背景技术

第三代合作伙伴计划 （3rd Generation Partnership Project, 3GPP ) 的演进 的分组系统（Evolved Packet System, EPS ) 由演进的通用地面无线接入网 ( Evolved Universal Terrestrial Radio Access Network , E-UTRAN )、移动管理 单元 ( Mobility Management Entity, MME ) 、 服务网关 ( Serving Gateway, S-GW ) 、 分组数据网络网关（Packet Data Network Gateway, P-GW )、 归属 用户服务器（ Home Subscriber Server, HSS )组成。

图 1 是根据相关技术的非漫游场景下的演进家庭基 站 （Home evolved NodeB, HeNB )接入 EPS的架构示意图， 如图 1所示， MME与 EUTRAN、 S-GW和家庭基站网关（HeNB GW )相连接， 负责移动性管理、 非接入层信 令的处理和用户移动管理上下文的管理等控制 面的相关工作； S-GW是与 E-UTRAN相连的接入网关设备 , 在 E-UTRAN和 P-GW之间转发数据 , 并且 负责对寻呼等待数据进行緩存； P-GW则是 EPS与分组数据网络（ Packet Data Network, PDN )网络的边界网关， 负责 PDN的接入及在 EPS与 PDN间转发 数据等功能。

如果 EPS系统支持策略计费控制 （Policy and Charging Control, PCC ) , 则策略和计费规则功能（ Policy and Charging Rules Function, PCRF )进行策 略和计费规则的制定， 它通过接口 Rx和运营商网络协议（ Internet Protocol , IP )业务网络中的应用功能（ Application Function , AF )相连， 获取业务信息， 用于生成 PCC策略的业务信息。当 S-GW与 P-GW之间的 S5接口釆用 GPRS 隧道协议（ GPRS tunnel Protocol , GTP )协议时， P-GW中驻留了策略和计费 执行功能（ Policy and Charging Enforcement Function, PCEF ) , PCRF与 P-GW 间通过 Gx接口交换信息， 负责发起承载的建立、修改和释放， 保证业务数据 的服务质量（Quality of Service, QoS ) , 并进行计费控制。 当 S-GW与 P-GW 的 S5接口釆用代理移动 IP ( Proxy Mobile IP, PMIP )时， S-GW中驻留承载 绑定和事件报告功能（Bearer Binding and Event Report Function, BBERF ) , 并且 S-GW与 PCRF之间通过 Gxc接口交换信息，由 BBERF负责发起承载的 建立、 修改和释放， 保证业务数据的服务质量， 由 PCEF进行计费控制。

现有的 EPS系统中， P-GW (或者其他网元， 如 S-GW )具有承载绑定功 能， 在进行承载绑定时， 是用数据包的五元组（源地址、 目的地址、 源端口 号、 目的端口号、 协议号 ) 向 TFT ( Traffic Flow Template, 业务流模板） 匹 配， 组成 TFT的 PF ( acket Filter, 数据包过滤器）与不同的承载建立了对应 关系。 当数据包的五元组和某个 PF匹配时， 则该数据包被放到对应的承载上 传输。

EPS支持 HeNB的接入， HeNB是一种小型、 低功率的基站， 部署在家 庭、 办公室及企业大楼等室内场所。 闭合用户组（ Closed Subscriber Group, CSG )是引入家庭基站后提出的概念。 通常一个家庭或者一个企业内部的用 户组成一个闭合用户组， 这个闭合用户组用 CSG ID进行标识。 为这个闭合 用户组内用户服务的家庭基站具有相同的 CSG ID。当一个闭合用户组只由一 个家庭基站服务时，该闭合用户组也可以直接 釆用家庭基站标识（例如 BS ID ) 来进行标识。 根据家庭基站管理者的意愿， CSG用户和 /或非 CSG用户可以 区分不同的等级， 优先级不同则其享受的业务优先级， 享受服务质量和业务 类别都可以不同。 用户通过与运营商签约可以接入到多个闭合用 户组所对应 的家庭基站， 例如， 用户的办公场所、 家庭等。 因此引入了允许闭合用户组 列表的概念。 这个列表保存在用户的终端和网络侧的用户数 据服务器中。

家庭基站的使用模式分为三种： 闭合模式、 混合模式和开放模式。 当家 庭基站是闭合模式的时候，只有该家庭基站所 属 CSG签约用户可以接入该基 站并享受基站提供的业务； 当家庭基站是开放模式的时候， 任何运营商签约 用户都可以接入该基站， 此时的家庭基站等同于宏基站使用； 当家庭基站是 混合模式的时候， 同样允许任何运营商签约用户或者漫游用户接 入使用， 但 是要根据用户是否签约 CSG的信息区分不同的级别， 也就是说签约该 CSG 的用户在使用混合型家庭基站的时候具有更高 的业务优先级， 享受更好的服 务质量和业务类别。

HeNB通常通过租用的固网线路接入 EPS的核心网 （如图 1所示 ) , 为 了保障接入的安全， 核心网中引入安全网关（Security Gateway, SeGW )进 行屏蔽， HeNB与 SeGW之间的数据将釆用因特网协议安全性（IP Security, IPSec )机制进行封装。 HeNB连接到核心网的 MME和 S-GW, 或者通过 HeNB GW(HeNB GW是一个可选网元， 是否釆用基于运营商的网络部署）连 接到 MME和 S-GW, 控制信令或者用户数据中间通过 HeNB与 SeGW之间 的 IPSec隧道。

此夕卜 , 通用移动通信系统 ( Universal Mobile Telecommunications System , UMTS )支持家庭基站 HNB ( Home NodeB )的接入。 图 2是根据相关技术的 非漫游场景下的 HNB接入 UMTS的架构示意图， 图 2中的架构与图 1的架 构类似， 不同的是， 使用服务通用分组无线业务支撑节点 （Serving General Packet Radio Service Support Node , SGSN )代替了 MME和 S-GW, 使用网关 通用分组无线业务支持节点 ( Gateway General Packet Radio Service Supporting Node , GGSN )代替了 P-GW。 同样， HNB 又可以通过增强的 SGSN (即 S4-SGSN )接入到 EPC核心网， S4-SGSN与 S-GW之间通过 S4接口连接， 与 HSS通过 S6d/Gr接口连接， S4-SGSN的同能同 HeNB场景下 MME的功 能， 如图 2a。

当前的 HeNB/HNB系统中， 引入了 HeNB/HNB PF ( Policy Function , 策 略功能） 网元， 其功能是在 3GPP的 HeNB/HNB系统和固网系统中传递策略 协商的控制信令及对应策略， 以及制定某些策略决策。 当前对 HeNB/HNB PF 自身的功能、 与其他网元的信息交互机制等， 有两种并行的架构方案， 这两 种方案具体描述如下：

架构一（图 1图 2中， 当只有 Tl、 T2接口时） ： T1-T2方案

该方案中， 在 SeGW和 HeNB/HNB PF间设置了接口 T1 , 在 HeNB/HNB 和 HeNB/HNB PF之间设置了接口 T2。

T1接口用于当 HeNB/HNB上电时，向 HeNB/HNB PF及固网传递相关的 HeNB/HNB系统消息， 例如 HeNB/HNB的地址， HeNB/HNB标识等信息， 用 于关联策略会话和定位 HeNB/HNB 在固网中的位置等。 T2 接口用于 HeNB/HNB向 HeNB/HNB PF及固网传递相关的策略协商控制信令及对应� �� 略， 对 HeNB/HNB上的用户数据实现 QoS控制等。

架构二（图 1图 2中， 当只有 Tl、 T3接口时） ： T1-T3方案

该方案中， 在 SeGW和 HeNB/HNB PF间设置了接口 T1 , 在 HeNB/HNB GW/MME和 HeNB/HNB PF之间设置了接口 T3。

T1接口用于当 HeNB/HNB上电时，向 HeNB/HNB PF及固网传递相关的 HeNB/HNB系统消息， 例如 HeNB/HNB的地址， HeNB/HNB标识等信息， 用 于关联策略会话和定位 HeNB/HNB 在固网中的位置等。 T3 接口用于 HeNB/HNB GW/MME向 HeNB/HNB PF及固网传递相关的策略协商控制信令 及对应策略， 对 HeNB/HNB上的用户数据实现 QoS控制等。

当前网络 HeNB/HNB接入的时候，在 QoS控制方面存在如下问题。在用 户通过 HeNB/HNB接入核心网的场景下， 由于 HeNB/HNB接入的固网线路 的 QoS通常是受到 HeNB/HNB的拥有者与固网运营商的签约限制的，� ��户业 务数据在经过 IPsec隧道封装后再由固网链路传输时，固网能� ��保证业务数据 的 QoS是完全取决于固网资源状况。当前接入同一 个 HeNB/HNB的所有终端 的、 所有 PDN连接的、 所有数据业务（例如语音、 视频等各种不同的数据业 务）都是通过同一个的 IPSec隧道传输的， 这样对不同的业务就无法针对其 特性为其保证其需要的 QoS。 特别是在固网资源不充足的情况下， 如果针对 不同类的业务没有 QoS区分，导致了对 QoS要求高的业务的无法进行甚至失 败。 举例来说： 数据下载等一类 BE ( Best Effort, 尽力而为）业务， 对 QoS 要求不是很高， 而语音等一类业务对 QoS要求非常高， 但是因为没有 QoS区 分机制，资源不足的时候，以上两类业务却获 得了同样的带宽（统计上来说）， 这样的带宽对数据下载这一类 BE业务来说足够了， 但是这样的带宽可能无 法满足语音等业务的要求，导致语音一类业务 的传输质量极差甚至业务失败。 发明内容

本发明要解决的技术问题提出一种实现 Q 0 S控制的方法和系统， 以实现 针对不同的业务保证相应的 QoS。

为了解决上述问题， 本发明提供一种实现服务质量控制的方法， 包括： 安全网关（ SeGW )通过第二网元将下行方向的因特网协议安全� �（ IPsec ) 隧道信息和 IP数据流信息之间的对应关系信息上报给固网� ��元， SeGW或第 一网元通过第二网元将上行方向的 IPsec隧道信息和 IP数据流信息之间的对 应关系信息上报给固网网元， 由固网网元执行服务质量（ QoS )控制；

其中， 所述第一网元为演进家庭基站（HeNB ) , 第二网元为演进家庭基 站策略功能（HeNB PF ) ； 或者， 所述第一网元为家庭基站（ HNB ) , 第二 网元为家庭基站策略功能（HNB PF ) 。

优选地， 上述方法具有以下特点：

在 SeGW通过第二网元将下行方向的 IPsec隧道信息和 IP数据流信息之 间的对应关系信息上报给固网网元， SeGW或第一网元通过第二网元将上行 方向的 IPsec隧道信息和 IP数据流信息之间的对应关系信息上报给固网� ��元 之前， 所述方法还包括：

第一网元与 SeGW之间建立一条以上的 IPsec隧道。

优选地， 上述方法具有以下特点：

第一网元与 SeGW之间釆用静态或者动态的方式， 建立 IPsec隧道。 优选地， 上述方法具有以下特点：

在将下行方向和上行方向的对应关系信息上报 给固网网元之前， 所述方 法还包括：

所述第一网元和 /或 SeGW接收到从核心网下发的 IP数据流信息， 建立 IPsec隧道信息和 IP数据流信息之间的对应关系。

优选地， 上述方法具有以下特点：

所述 IPsec隧道信息为安全参数索引（ SPI )或者差分服务代码点（ DSCP ) 信息；

所述 IP数据流信息为如下信息中的一种或多种： 五元组信息、 隧道端点 标识 （ TEID ) 、 无线承载标识 （ RB-ID ) 、 QoS规则、 业务流模板 ( TFT ) 或数据包过滤器（PF ) , 其中， 五元组信息包括源地址、 目的地址， 源端口 号、 目的端口号和协议号的信息。

优选地， 上述方法具有以下特点：

固网网元接收到的所述对应关系信息为 SPI和 QoS规则之间的对应关系 信息。

优选地， 上述方法具有以下特点：

所述固网网元执行 QoS控制是指： 固网网元依据不同的 SPI及其对应的 QoS规则， 为传输数据包提供区分等级的 QoS保证。

优选地， 所述方法还包括：

所述第一网元根据 RB-ID或者五元组信息和 QoS信息， 以及 QoS信息 和 SPI之间的对应关系创建上行方向的映射表或过 滤器， 映射或过滤上行数 据；

所述 SeGW根据 TEID或者五元组信息和 QoS信息， 以及 QoS信息和 SPI之间的对应关系创建下行方向的映射表或过 滤器， 映射或过滤下行数据。

优选地， 上述方法具有以下特点：

接收所述 IPsec隧道信息和 IP数据流信息之间的对应关系信息的固网网 元为宽带论坛策略控制功能（BPCF ) , 由所述 BPCF为传输数据提供区分等 级的 QoS保证， 或者所述 BPCF与固网网元宽带网络网关（BNG )或宽带远 程接入服务器（BRAS )为传输数据提供区分等级的 QoS保证。

优选地， 上述方法具有以下特点：

在 SeGW通过第二网元将下行方向的 IPsec隧道信息和 IP数据流信息之 间的对应关系信息上报给固网网元的步骤中， 所述 SeGW通过通知请求消息 将所述对应关系信息发送给第二网元； 所述第二网元通过 S9*接口会话消息 将所述对应关系信息发送给固网网元；

在 SeGW或第一网元通过第二网元将上行方向的 IPsec隧道信息和 IP数 据流信息之间的对应关系信息上报给固网网元 的步骤中， 所述 SeGW通过通 知请求消息将所述对应关系信息发送给第二网 元， 或者， 所述第一网元通过 资源请求消息或资源修改请求消息将所述对应 关系信息发送给第二网元； 所 述第二网元通过 S9*接口会话消息将所述对应关系信息发送给固 网网元。

本发明要解决的技术问题提出一种实现服务质 量控制的系统， 包括： 第 一网元、 第二网元、 SeGW和固网网元， 其中，

所述 SeGW设置为： 通过第二网元将下行方向的 IPsec隧道信息和 IP数 据流信息之间的对应关系信息上报给固网网元 ；

所述 SeGW或第一网元设置为： 通过第二网元将上行方向的 IPsec隧道 信息和 IP数据流信息之间的对应关系信息上报给固网� ��元；

所述固网网元设置为： 根据下行方向和上行方向的所述对应关系信息 ， 保证相 IPsec隧道中传输数据的 QoS;

其中， 所述第一网元为 HeNB， 第二网元为 HeNB PF; 或者， 所述第一 网元为 HNB, 第二网元为 HNB PF。

优选地， 上述系统具有以下特点：

所述第一网元还设置为： 与 SeGW之间建立一条以上的 IPsec隧道。 优选地， 上述系统具有以下特点：

所述 IPsec隧道信息为安全参数索引（ SPI )或者差分良务代码点（ DSCP ) 信息；

所述 IP数据流信息为如下信息中的一种或多种： 五元组信息、 隧道端点 标识 （ TEID ) 、 无线承载标识 （ RB-ID ) 、 QoS规则、 业务流模板 ( TFT ) 或数据包过滤器（PF ) ， 其中， 五元组信息包括源地址、 目的地址， 源端口 号、 目的端口号和协议号的信息。

优选地， 上述系统具有以下特点：

所述第一网元还设置为： 根据 RB-ID或者五元组信息和 QoS信息， 以及 QoS信息和 SPI之间的对应关系创建上行方向的映射表或过 滤器， 映射或过 滤上行数据；

所述 SeGW还设置为：根据 TEID或者五元组信息和 QoS信息，以及 QoS 信息和 SPI之间的对应关系创建下行方向的映射表或过 滤器， 映射或过滤下 行数据。 本发明实施例能够保证终端在从 HeNB/HNB接入时，对不同的业务实现 QoS区分， 对 QoS要求高的业务， 优先满足其 QoS需求， 提高用户体验。 附图概述

图 1为根据相关技术的 HeNB接入 EPS的架构示意图；

图 2为根据相关技术的 HNB接入 UMTS的架构示意图；

图 2a为根据相关技术的 HNB接入 EPS的架构示意图；

图 3为本发明的静态建立多个 SA并实现 QoS控制的流程示意图； 图 4为本发明的动态建立多个 SA并实现 QoS控制的流程示意图； 图 5为本发明的上行映射关系结构示意图；

图 6为本发明的下行映射关系结构示意图；

图 7为本发明上下行过滤器结构示意图；

图 8为本发明实施例一流程图 （ SeGW解析 Sl/Iuh消息， 基于 T1-T2架 构） ；

图 9为本发明是实例二流程图 （ SeGW解析 Sl/Iuh消息， 基于 T1-T3架 构） ；

图 10为本发明实施例三流程图 （ SeGW不解析 Sl/Iuh消息， 基于 T1-T2 架构） ；

图 11为本发明实施例四流程图 （ SeGW不解析 Sl/Iuh消息， 基于 T1-T2 架构） 。 本发明的较佳实施方式

针对现有技术中， 不同的业务无法针对其特性为其保证其需要的 QoS的 问题， 最直接的解决方案就是在 HeNB/HNB和 SeGW之间建立多条 IPsec隧 道， 不同的 IPsec隧道传输不同的业务， 以达到区分的对待的目的。

现有技术中， IPSec隧道 /SA ( Security Association, 安全联盟 )的建立过 程为： 在两网元之间进行 IKEv2 ( Internet Key exchange , 因特网密钥交换） 初始化协商， 建立一个 IKE— SA, 之后可以建立多个子 SA ( Child— SA ) 。 每 个 SA (包括子 SA )都是单向的， 每一个 SA都有一个特定的 SPI ( Security Parameter Index, 安全参数索引）标识。 因为 SA是单向的， 故其标识 SPI也 分为上行和下行的 SPI。 当前 HeNB/HNB系统中，只支持单个 IPSec隧道（一 对 SA ) , 还不支持多 IPsec隧道（多对 SA ) 。

本发明的基本思想是： HeNB/HNB与 SeGW建立多个 IPSec隧道 /SA对， 不同的 IPsec隧道 /SA对由不同的 SPI (对）标识， 由固网根据 SPI (对）提 供不同的 QoS保证。

具体地， 包括： 第一网元与 SeGW之间建立一条以上的 IPsec隧道；

SeGW通过第二网元将下行方向的 IPsec隧道信息和 IP数据流信息之间 的对应关系信息上报给固网网元， SeGW或第一网元通过第二网元将上行方 向的 IPsec隧道信息和 IP数据流信息之间的对应关系信息上报给固网� ��元； 由固网网元执行 QoS控制。

其中， 所述第一网元为 HeNB, 第二网元为 HeNB PF; 或者， 所述第一 网元为 HNB， 第二网元为 HNB PF。

第一网元与 SeGW之间可釆用静态或者动态的方式， 建立 IPsec隧道。 通过核心网下发， 第一网元和 /或 SeGW获得 IP数据流信息， 进而建立 IPsec隧道信息和 IP数据流信息之间的对应关系。

IPsec隧道信息可以是 SPI或者 DSCP信息；

所述 IP数据流信息为如下信息中的一种或多种： 五元组信息、 TEID ( Tunnel End Point Identifier, 隧道端点标识） 、 RB-ID (无线 载的标识） 、 QoS规则、 TFT或 PF, 其中， 五元组信息包括源地址、 目的地址， 源端口号、 目的端口号和协议号的信息。

在一具体的实施例中， 发送给固网网元的对应关系信息为 SPI和 QoS规 则之间的对应关系信息。 IPsec 隧道 /SA建立生成后， HeNB/HNB 子系统将 SPI和 QoS的对应关系上 4艮给固网网元， 固网网元依据不同的 SPI及其对应 的 QoS规则， 为传输数据包提供区分等级的 QoS保证。 所述第一网元根据 RB-ID或者五元组信息和 QoS信息， 以及 QoS信息 和 SPI之间的对应关系创建上行方向的映射表或过 滤器， 映射或过滤上行数 据；

所述 SeGW根据 TEID或者五元组信息和 QoS信息， 以及 QoS信息和 SP1之间的对应关系创建下行方向的映射表或过 滤器， 映射或过滤下行数据。

上述接收所述 Psec隧道信息和 IP数据流信息之间的对应关系信息的固 控制功能） ， 由所述 BPCF为传输数据提供区分等级的 QoS保证， 或者所述 BPCF与其他固网网元， 比如 BNG/BRAS ( Broadband Network Gateway宽带 网络网关/ Broadband Remote Access Server宽带远程接入服务器）为传输数据 提供区分等级的 QoS保证。

另外， 在 SeGW通过第二网元将下行方向的 IPsec隧道信息和 IP数据流 信息之间的对应关系信息上报给固网网元的步 骤中， 所述 SeGW通过通知请 求消息将所述对应关系信息发送给第二网元； 所述第二网元通过 S9*接口会 话消息将所述对应关系信息发送给固网网元；

在 SeGW或第一网元通过第二网元将上行方向的 IPsec隧道信息和 IP数 据流信息之间的对应关系信息上报给固网网元 的步骤中， 所述 SeGW通过通 知请求消息将所述对应关系信息发送给第二网 元， 或者， 所述第一网元通过 资源请求消息或资源修改请求消息将所述对应 关系信息发送给第二网元； 所 述第二网元通过 S9*接口会话消息将所述对应关系信息发送给固 网网元。

其中， S9*接口指修改或增强的 S9接口。

相应地， 本发明实施例的实现服务质量控制的系统， 包括： 第一网元、 第二网元、 SeGW和固网网元， 其实现如上所述。

下面对本发明的关键技术进行论述

(一 ) IPSec隧道 /SA的创建（静态 )

该场景中， He B/HNB上电后，就与 SeGW—次性建立多个（比如 m个） IPsec隧道，每个隧道对应不同的 QoS规则范围，每个隧道对应上下行的 SA, 每个 SA对应其各自的 SPI, 对应图 3。

m个不同的 IPsec通道，按照一定的优先次序排列， 当用户数据到来的时 候， 按照优先级的次序把数据包往 IPsec隧道 /SA上映射 /匹配， 映射 /匹配到 哪个隧道上， 就用哪个隧道传输。

作为一种具体实现， 可以设置一个优先级最低的 IPsec隧道， 服务于 BE

( Best Effort, 尽力而为）的业务或者不能映射 /匹配的业务。 也就是说： M-1 个隧道都对应特定 QoS或者 QoS范围， 这 M-1个隧道称为 "专有隧道" ， 一个 IPsec隧道没有特定的 QoS要求， 称为 "默认 /缺省隧道" 。 用户数据到 达后， 逐一往这 M个隧道上映射 /匹配， 映射 /匹配到哪个隧道上， 就用哪个 隧道传输， 如果前 M-1个 IPsec隧道都不适合传输某个业务或者对该业务� �� 本没有特定的 QoS要求务， 该业务可以默认的被映射 /匹配到 "默认 /缺省隧 道" 上。

作为一种特定的实现方式， 从 M个隧道中选定一个特定的隧道（一般情 况下， 该隧道的优先级和 QoS要求最高）作为 "信令隧道" ， 所有通过 IPsec 通道传输的 3GPP控制面信令， 都通过该特定的 "信令隧道" 传输。

如果存在 "信令隧道" 的时候， 信令隧道优先于其他隧道建立， 即： 在 HeNB/HNB接入认证之后就建立信令隧道， 为传输后续的 HeNB发往其他网 络的注册信令或者其他控制面信令服务。

隧道的建立可以由 HeNB/HNB或者 SeGW发起。 不同的 IPsec隧道可以 是独立的 IPsec隧道，也可以是属于同一族的多 IPSec隧道 /子 SA( CMd-SA )。

(二 ) IPSec隧道 /SA的创建（动态）

该场景中， 当某个用户有 Sl/Iuh接口消息（例如： 附着/ PDN连接建立 / 承载建立 /承载修改请求）到达后，要求特定的 QoS规则时， HeNB/HNB/SeGW 根据相关规则， 决定该 QoS需要建立 /修改 /删除专有的 SA/IPsec隧道为其保 证 QoS。 即， 该方案不同与 （一）之处在于， 不是 HeNB—上电的时候就建 立多条 QoS不同的 IPsec隧道， 而是当有业务的特定 QoS需求的时候， 再决 定新建 IPSec隧道。 参见图 4。

类似（一） ， 每个 IPsec隧道对应不同的 QoS范围， 每个 IPsec隧道的 SA对应其各自的 SPI。

作为一种具体实现， 可以在 HeNB/HNB—上电的时候就建立一个 "默认 /缺省隧道"，该隧道服务于 BE业务或者当所有专有的 IPsec隧道都无法映射 /匹配的业务。

作为一种具体实现，可以在 HeNB/HNB—上电的时候就建立一个特定的 隧道（一般情况下， 该隧道的优先级和 QoS要求最高）作为 "信令隧道" ， 所有通过 IPsec通道传输的 3GPP控制面信令， 都通过该特定的 "信令隧道" 传输。

如果存在 "信令隧道" 的时候， 信令隧道优先于其他隧道建立， 即： 在 HeNB/HNB接入认证之后就建立信令隧道，为传输� ��续的 HeNB/HNB发往其 他网络的注册信令或者其他控制面信令服务。

隧道的建立可以由 HeNB/HNB或 SeGW发起。 不同的 IPsec隧道可以是 独立的 IPsec隧道， 也可以是属于同一族的多 IPSec隧道 /子 SA ( Child-SA ) 。

(三） 映射表 /过滤器的结构

HeNB/HNB作为 IPsec隧道的一个端点， 存有上行数据映射表 /过滤器， 该映射表 /过滤器的作用是将数据包（上行） 映射 /匹配到合适的 IPsec隧道上 去。 该过滤器的结构如图 5所示。 图中， 无线承载和 QoS范围存在一对一或 者多对一的关系，而 QoS范围和 IPsec隧道的上行 SA(SPI)存在一对一的关系。 这样， 就建立了无线承载的标识（在此用 RB-ID, Radio Bearer Identity来标 识）和 SPI的对应关系。

无线承载和 QoS范围， 以及无线承载和上行的 SA/SPI未必是——对应 的关系， 可能多个 RB-ID对应同一个 SPI (如图 5所示） ， 或者反之。 这取 决于无线承载的 QoS和 IPsec隧道的 QoS区分的粒度的粗细。但 QoS范围和 SPI是——对应的关系。 下面 SeGW类同。

SeGW作为 IPsec隧道的另外一个端点， 存有下行数据映射表 /过滤器， 该映射表 /过滤器的作用是将数据包（下行） 映射 /匹配到合适的 IPsec隧道上 去。该映射表 /过滤器的结构如图 6所示。 图中， Sl/Iuh承载（属于 GTP承载） 和 QoS范围存在一对一或者多对一的关系， 而 QoS范围和 IPsec隧道 /SPI存 在一对一的关系。 这样， 就建立了 Sl/Iuh承载的标识 TEID和 SPI的一对一 或者多对一的关系。

映射表 /过滤器还可以有另外一种结构（在此称为结� �二） ， 不同于上述 的 RB-ID或者 TEID与 SPI建立多对一或者一对一的对应关系 （上述结构称 作结构一） ， 而是数据包的五元组 (数据包的源地址、 目的地址、 源端口号、 目的端口号、 协议号)建立与 SPI的一对一或者多对一的对应关系。 如图 7所 示。 结构二的映射表 /过滤器既可以用于 SeGW上也可以用于 HeNB/HNB上， 只是对应的 QoS范围、 SPI、 五元组分别是下行、 上行的即可。

(四 ) 映射表 /过滤器的生成

在 EPS/UMTS系统中， 终端接入 EPS/UMTS、 或者建立 PDN连接、 或 者发起专有承载建立、 或者网络侧发起专有承载建立， 最后的操作都会归结 到 EPS/UMTS网络的网元 MME/SGSN给 HeNB/HNB发送 S 1/Iuh接口上的消 息 (比如： 初始上下文建立请求 /附着接受 /承载建立请求 /PDN连接接受 ) , 该消息中携带了承载的 QoS(默认承载除外）规则（还可能包括五元组� �息）。 根据现有技术， HeNB/HNB在收到该消息后， 根据该携带的 QoS决定修改 / 创建 /删除无线承载（ RB ) , 也就是该 QoS和无线承载之间存在了对应关系。 在此发明中， HeNB/HNB会根据该 QoS找到对应的 IPSec隧道对应的 "QoS 范围" ， 这样就建立了该 QoS和 IPSec隧道的 SA标识 SPI的对应关系。 这 样一来， 无线承载的标识、 承载的 QoS以及 SPI就建立了对应关系。 这个对 应关系就是该承载的映射表 /过滤器。 当然， 不同的承载有不同的承载映射表 /过滤器， 不同的终端上的映射表 /过滤器也不同。

如果 SeGW截获 Sl/Iuh消息时， SeGW在截获 Sl/Iuh接口上的消息（例 如： 初始上下文建立请求 /附着接受 /承载建立请求 /PDN连接接受）后， 获取 了承载的 QoS (默认承载除外）规则和承载标识 TEID (或者五元组信息） 。 SeGW会根据该 QoS找到对应的 IPSec隧道对应的 "QoS范围" ， 这样就建 立了该 QoS和 IPSec隧道的下行 SA标识 SPI的对应关系。从而建立了 TEID、 承载的 QoS和 SPI的对应关系， 这个对应关系就是该承载的映射表 /过滤器。 当然， 不同的承载有不同的承载映射表 /过滤器， 不同的终端上的映射 /过滤 器也不同。 如果 SeGW不截获 Sl/Iuh消息时，下行的映射表 /过滤器可以委托其他网 元生成， 比如 HeNB/HNB PF或者 HeNB/HNB。

同样， HeNB/HNB 上的映射表 /过滤器也可以委托其他网元生成， 比如 SeGW, HeNB/HNB PF等。 具体的操作取决于具体的实现方案， 在后面的流 程实施例中会介绍到。

对于映射表 /过滤器的另外一种形式， Sl/Iuh消息（例如： 初始上下文建 立请求 /附着接受 /承载建立请求 /PDN连接接受） 消息中携带了该业务数据包 的五元组信息和 QoS信息。 因此 SeGW和 HeNB都可以建立五元组、 QoS和 SPI的对应关系， 该对应就可以作为该承载的过滤器。

(五） 映射表 /过滤器的应用

根据（四）所述， HeNB/HNB/SeGW上的映射表 /过滤器即为： 无线承载 的标识 /TEID、 承载的 QoS以及 SPI的对应关系。 所以当 HeNB/HNB从无线 承载上获得上行数据后， 根据该数据包所在无线承载的 RB-ID就能对应找到 IPsec隧道， 将数据包映射 /匹配到了合适的 IPSec隧道中。 SeGW从 Sl/Iuh承 载上获得下行数据后， 根据该数据包所在 Sl/Iuh承载的 TEID就能对应找到 IPsec隧道， 将数据包映射 /匹配到了合适的 IPSec隧道中。

对应过滤器的另外一种形式，当 HeNB/HNB/SeGW接收到上 /下行数据包 后， 根据数据包的五元组找到对应的 SPI, 将数据包匹配到了合适的 IPSec隧 道中。

(六）对应关系的上报

HeNB/HNB/SeGW在生成了映射关系 /过滤器后，用于本地映射 /过滤数据 包， 并且需要将 QoS和 SPI的对应关系通过 HeNB/HNB PF上报给固网， 这 样固网获知了 SPI和 QoS的对应关系， 才能保证不同的 IPSec隧道中传输的 数据包的 QoS。

其中 HeNB/HNB在通过 HeNB/HNB PF向固网上报 "SPI和 QoS的对应 关系" 时， HeNB HNB首先通过 T2接口的 "资源请求 /修改请求 /释放请求" 消息将 "对应关系 " 上报给 HeNB/HNB PF , HeNB/HNB PF通过 S9*接口会 话消息上报给固网的 BPCF ,由 BPCF及固网的其他网元执根据该对应关系执 行区分不同等级的 QoS控制。

作为具体的实施方式， PF除了是向固网上报 QoS和 SPI对应关系的中介 网元外， 在某些场景下还是 HeNB/HNB和 SeGW互通映射关系 /过滤器、 IP 数据流信息的中间网元， 具体体现在后续的流程中。

在本发明中， IPsec隧道信息是指标识该 IPsec隧道 /SA的标识信息， 比 如： SPI。也可以是其他唯一标识 IPSec隧道的信息，比如 DSCP( Differentiated Services Code Point, 差分服务代码点）等。 在本发明的实施例及关键技术论 述中， 一般只提到了 SPI作为 IPsec隧道信息， 但不排除可以釆用 DSCP等其 他隧道信息的可能。 也就是说， 可以等价替换成 DSCP等其他隧道信息， 该 方案也可以运行， 也是本发明的内容。

IP数据流信息是能够描述某个 IP数据流的标识信息， 策略信息等， 包括 但不限于以下信息中的一种或者几种： 五元组（源地址， 目的地址， 源端口 号， 目的端口号， 协议号） 、 TEID、 QoS规则、 TFT/PF等。

IPsec隧道信息和 IP数据流信息的对应关系为任意一种 IPsec隧道信息

( SPI或者 DSCP或者其他 )和任意一种或者几种 IP数据流信息 （五元组、 TEID、 QoS规则、 TFT/PF )的对应关系。 在本发明的实施例及关键技术论述 中， SPI和 QoS的对应关系是一种典型的实现。 但不排除可以釆用 DSCP等 其他隧道信息和 QoS规则以及其他 IP数据流信息建立对应关系的可能。也就 是说， SPI可以等价替换成 DSCP等其他 IPsec隧道信息， QoS规则可以等价 的替换成其他 IP数据流信息， 从而建立对应关系， 该方案也可以运行， 也是 本发明的内容。

流程实施例

实施例一： SeGW解析 Sl/Iuh接口消息， 基于 T1T2架构 （图 8 ) 步骤 801 : UE发起附着/ PDN连接建立操作， 无线侧及核心网的相关处 理， 此是现有技术。

步骤 802: 终端通过 HeNB/HNB接入到 EPS/UMTS之后， 无论是附着， PDN连接建立、 终端发起的或者是网络侧发起的专有承载建立 ， 最终都会由 网络侧发送对应的消息给 HeNB/HNB , 该消息为 Sl/Iuh接口的 GTP ( GPRS tunnel Protocol, GPRS隧道协议）控制信令， 如图中所示的消息： 初始上下 文建立请求 /附着接受 /承载建立请求 /PDN连接接受。 该消息中携带了所要创 建 /修改 /释放的承载所对应的 QoS规则和上下行 TEID、 五元组等信息， 也即 IP数据流信息。

Sl/Iuh接口的信令在经过 SeGW时， 由 SeGW截获， 并获取信令中的 IP 数据流信息后再将 Sl/Iuh消息发送给 HeNB/HNB。

步骤 803: SeGW根据从 GTP消息中获取 IP数据流信息， 并根据相关策 略决定创建新 SA (动态方案）或者选择 SA (动态或者静态方案）

如果是创建新的 SA, SeGW发送 IKEv2消息的 "创建子 SA请求" 给 HeNB/HNB, 并在消息中携带了由 SeGW选定的下行 SA的 SPI。

SeGW从 Sl/Iuh接口的 GTP消息中获取了 QoS规则、 TEID和 /或五元组 信息， SeGW根据自身配置的信息，判断接收到的 QoS规则是否需要新建 SA 或者是现有的 SA就能满足该 QoS规则的需求。 这样新建或者选择的 SA的 SPI就能与 QoS规则建立对应关系； 而在 GTP消息中， QoS规则和 TEID又 存在对应关系， 于是 TEID 和 SPI 就建立了对应关系， 或者说是映射 ( MAPPING ) 关系， 参见图 6。

如果不是建立 SPI和 TEID的对应关系， 而是根据 QoS规则建立了 SPI 和五元组的对应关系， 则该对应关系称作 "过滤器" ， 参见图 7。

在 SeGW上生成的映射表 /过滤器用于过滤 /映射下行数据包， 称作下行 ( downlink, DL ) 映射 /过滤器。

步骤 804: SeGW发送 "创建子 SA请求" 给 HeNB/HNB, 并在消息中 携带了由 SeGW选定的下行 SA的 SPI; HeNB/HNB收到请求后， 选择上行 SA的 SPI, 并通过 "创建子 SA回应" 消息发送给 SeGW。

步骤 805: HeNB/HNB收到了 Sl/Iuh消息， 并获取了其中的 QoS规则、 TEID和 /或五元组信息。

HeNB/HNB根据 QoS规则能判断将该 GTP承载对应到哪个无线承载上， 即和无线承载标识 RB-ID建立了对应关系 （现有技术）； HeNB/HNB自身配 置的信息， 判断接收到的 QoS规则是否需要新建 SA或者是现有的 SA就能 满足该 QoS规则的需求。 这样新建或者选择的 SA的 SPI就能与 QoS规则建 立对应关系； 如此一来 RB-ID和 SPI就通过 QoS规则建立了对应关系 （映射 关系 /映射表） ， 如图 5所示。

如果不是建立 SPI和 RB-ID的对应关系， 而是根据 QoS规则建立了 SPI 和五元组的对应关系， 则该对应关系称作 "过滤器" ， 参见图 7。

在 HeNB/HNB上生成的映射表 /过滤器用于过滤 /映射上行数据包， 称作 上行（uplink, UL ) 映射 /过滤器。

以上步骤 803-805 中， 没有特定的先后关系。 子 SA的建立发起可能是

SeGW也可能是 HeNB/HNB, 而且一对 IKEv2消息建立的上下行 SA可能但 未必一定服务于同一个承载上的上下行数据流 。 当 SeGW或者 HeNB/HNB发 现新接收到的 QoS规则后， 先去查看已经存在的 SA中有没有 "与 QoS无关 联" 的 SA, 如果有， 就与该 SA建立关联关系； 如果没有， 则发起新建， 并 与之建立关联关系；

上述提到可能存在 "与 QoS无关联" 的 SA， 在几种场景下可以出现这 种情况： 1 ) 因为 IKEv2消息是成对发送的 （请求 +回应） ， 因此， 请求方选 择了 SPI (对应一个 SA )可以建立 SPI和 QoS的对应关系； 但是回应方不知 道其选择的 SPI对应的 SA应该关联什么样的 QoS,因此就存在了一个与 QoS 无关联关系的 SA。 当接收方收到 QoS后， 就可以建立该 QoS与该 "没有做 关联的 SA" 的关联关系。 2 ) EPS/UMTS核心网除了发送新建承载请求外， 还可能发送释放承载的请求， 因此某个承载释放后， 该 SA就可能是空闲的 (与 QoS无绑定关系） 了。

步骤 806: HeNB/HNB 通过 T2接口的 "资源请求 /修改请求" 消息向 HeNB/HNB PF 上才艮下行 "SPI 和 QoS 对应关系" 。 HeNB/HNB PF 向 HeNB/HNB回复应答消息；

步骤 807, SeGW通过 T1接口的 "通知请求" 消息向 HeNB/HNB PF上 报上行 " SPI和 QoS对应关系 " 。 HeNB/HNB PF向 SeGW回复应答消息； HeNB/HNB PF收到 806步和 807步的消息后，对两会话上报的对应关系 作关联（现有技术中 T1会话和 T2会话已经可以关联， 因此根据会话的关联 关系， 可以将上报的上下行 "SPI和 QoS对应关系" 关联）， 并通过 S9*接口 报告给固网 BPCF,由 BPCF或者 BPCF委托其他固网网元为传输在不同 IPsec 隧道中的数据包保证 QoS。

注： 如果是静态建立 SA的场景， 可以釆用在步骤 S806上 ^艮该 "SPI和 QoS对应关系" ， 也可以釆用一种优化方式， 即该 SPI和 QoS规则的对应关 系可以在初始建立完所有 SA的时候就上报给 HeNB/HNB PF。

步骤 808: HeNB/HNB向 EPS核心网回应 Sl/Iuh接口的 GTP消息。

实施例二： SeGW解析 Sl/Iuh消息， 基于 T1T3架构 （图 9 )

步骤 901 : UE发起附着/ PDN连接建立操作， 无线侧及核心网的相关处 理， 此是现有技术。

步骤 902: 终端通过 HeNB/HNB接入到 EPC/UMTS之后， 无论是附着， PDN连接建立、 终端发起的或者是网络侧发起的专有承载建立 ， 最终都会由 网络侧发送对应的消息给 HeNB/HNB ,该消息为 Sl/Iuh接口的 GTP控制信令。 即图中所示的消息： 初始上下文建立请求 /附着接受 /承载建立请求 /PDN连接 接受， 如消息中携带了所要创建 /修改 /释放的承载所对应的 QoS规则和上下 行 TEID、 五元组等信息， 也即 IP数据流信息。

Sl/Iuh接口的 GTP信令在经过 SeGW时， 由 SeGW截获， 并获取信令中 的 IP数据流信息后再将 Sl/Iuh消息发送给 HeNB/HNB。

步骤 903: SeGW根据从 GTP消息中获取 IP数据流信息， 并根据相关策 略决定创建新 SA (动态方案）或者选择 SA (动态或者静态方案）

如果是创建新的 SA, SeGW发送 IKEv2消息的 "创建子 SA请求" 给 HeNB/HNB, 并在消息中携带了由 SeGW选定的下行 SA的 SPI。

SeGW从 Sl/Iuh接口的 GTP消息中获取了 QoS规则、 TEID和 /或五元组 信息， SeGW根据自身配置的信息，判断接收到的 QoS规则是否需要新建 SA 或者是现有的 SA就能满足该 QoS规则的需求。 这样新建或者选择的 SA的 SPI就能与 QoS规则建立对应关系； 而在 GTP消息中， QoS规则和 TEID又 存在对应关系， 于是 TEID 和 SPI 就建立了对应关系， 或者说是映射 ( MAPPING ) 关系， 参见图 6。

如果不是建立 SPI和 TEID的对应关系， 而是根据 QoS规则建立了 SPI 和五元组的对应关系， 则该对应关系称作 "过滤器" ， 参见图 7。

在 SeGW上生成的映射表 /过滤器用于过滤 /映射下行数据包的， 称作下 行（downlink, DL ) 映射表 /过滤器。

步骤 904: SeGW发送 "创建子 SA请求" 给 HeNB/HNB, 并在消息中 携带了由 SeGW选定的下行 SA的 SPI; HeNB/HNB收到请求后， 选择上行 SA的 SPI, 并通过 "创建子 SA回应" 消息发送给 SeGW。

步骤 905: SeGW在新创建的或者已选择的 SA 中将在 902 步截获的 Sl/Iuh消息发送给 HeNB/HNB„

或者， Sl/Iuh消息发送时未必经过新创建的或者选择的 SA, 但在 Sl/Iuh 消息中携带新创建的或者选择的 SA的 SPI。

步骤 906: HeNB/HNB根据该 Sl/Iuh消息来自哪一个 SA就能判断该

Sl/Iuh消息所要建立的承载上的 IP流信息与 SA的对应关系；

或者 HeNB/HNB根据 Sl/Iuh消息中携带的 SPI, 就能判断该 Sl/Iuh消息 所要建立的承载上的 IP流信息与 SA的对应关系。

HeNB/HNB 根据上述关系釆用同 S805 相同的机制生成上行数据 MAPPING表。

步骤 907: 因为在 902步 SeGW获取了 Sl/Iuh消息内容， 并在 904步建 立了 SA, 获取了对应的 SPI, SeGW生成下行 MAPPING表；

步骤 908: 根据上述操作， SeGW可以同时生成上下行 QoS规则和 SPI 的对应关系 , 并通过通知请求消息上 ^艮给 HeNB/HNB PF。

SeGW通过 T 1接口的 "通知请求 "消息向 HeNB/HNB PF上报上下行 " SPI 和 QoS对应关系 " 。 HeNB/HNB PF向 SeGW回复应答消息；

HeNB/HNB PF通过 S9*接口报告给固网 BPCF, 由 BPCF或者 BPCF委 托其他固网网元为传输在不同 IPsec隧道中的数据包保证 QoS。 注：如果是静态建立 SA的场景，可以釆用在步骤 S908上 ^艮该对应关系 , 也可以釆用一种优化方式， 即该 SPI和 QoS规则的对应关系可以在初始建立 完所有 SA的时候就上 PF。

步骤 909: HeNB/HNB向 EPS核心网回应 Sl/Iuh接口的 GTP消息。

实施例三： SeGW不解析 Sl/Iuh消息， 基于 T1T2架构 （图 10 ) 步骤 1001 : UE发起附着/ PDN连接建立操作， 无线侧及核心网的相关处 理， 此是现有技术。

步骤 1002: 终端通过 HeNB/HNB接入到 EPS/UMTS之后， 无论是附着， PDN连接建立、 终端发起的或者是网络侧发起的专有承载建立 ， 最终都会由 网络侧发送对应的消息给 HeNB/HNB ,该消息为 Sl/Iuh接口的 GTP控制信令。 即图中所示的消息： 初始上下文建立请求 /附着接受 /承载建立请求 /PDN连接 接受， 如消息中携带了所要创建 /修改 /释放的承载所对应的 QoS规则和上下 行 TEID、 五元组等信息， 也即 IP数据流信息。

步骤 1003: HeNB/HNB根据从 GTP消息中获取相关信息， 并根据相关 策略决定创建新 SA (动态方案）或者选择 SA (动态或者静态方案）

如果是创建新的 SA, HeNB/HNB发送 IKEv2消息的 "创建子 SA请求" 给 SeGW, 并在消息中携带了由 HeNB/HNB选定的上行 SA的 SPI。

HeNB/HNB从 Sl/Iuh接口的 GTP消息中获取了 QoS规则、 TEID和 /或五 元组信息， HeNB HNB根据 QoS规则能判断将该 GTP承载对应到哪个无线 承载上， 即和无线承载标识 RB-ID建立了对应关系（现有技术 )； HeNB/HNB 自身配置的信息，判断接收到的 QoS规则是否需要新建 SA或者是现有的 SA 就能满足该 QoS规则的需求。 这样新建或者选择的 SA的 SPI就能与 QoS规 则建立对应关系；如此一来 RB-ID和 SPI就通过 QoS规则建立了对应关系（映 射关系 /映射表） ， 如图 5所示。

如果不是建立 SPI和 RB-ID的对应关系， 而是根据 QoS规则建立了 SPI 和五元组的对应关系， 则该对应关系称作 "过滤器" ， 参见图 7。

在 HeNB/HNB上生成的映射表 /过滤器用于过滤 /映射上行数据包， 称作 上行（uplink, UL ) 映射表 /过滤器。

步骤 1004: HeNB/HNB发送 "创建子 SA请求" 给 SeGW, 并在消息中 携带了由 HeNB/HNB选定的上行 SA的 SPI; SeGW收到请求后， 选择下行 SA的 SPI, 并通过 "创建子 SA回应" 消息发送给 HeNB/HNB。

步骤 1005: HeNB/HNB通过 T 1接口向 HeNB/HNB PF上报上行 SPI和

QoS的对应关系， 并携带下行的 QoS规则；

步骤 1006: HeNB/HNB PF向 SeGW发送下行 QoS规则；

步骤 1007, SeGW根据下行的 QoS规则选择一个 SA,并建立 SPI和 QoS 的对应关系， 即下行的 SPI和 QoS的对应关系。

步骤 1008， SeGW通过 T2接口向 He B/HNBPF上 4艮下行的 SPI和 QoS 的对应关系。

HeNB/HNB PF将 1008步和 1005步获取的上下行 SPI和 QoS的对应关系 后， 对两会话上报的对应关系作关联（现有技术， 同图 8 ) , 并通过 S9*接口 报告给固网 BPCF,由 BPCF或者 BPCF委托其他固网网元为传输在不同 IPsec 隧道中的数据包保证 QoS。

步骤 1009: HeNB/HNB向 EPS核心网回应 Sl/Iuh接口的 GTP消息。

实施例四： SeGW不解析 Sl/Iuh消息， 基于 T1T2架构 （图 11 ) 步骤 1101 : UE发起附着/ PDN连接建立操作， 无线侧及核心网的相关处 理， 此是现有技术。

步骤 1102: 终端通过 HeNB/HNB接入到 EPS/UMTS之后， 无论是附着， PDN连接建立、 终端发起的或者是网络侧发起的专有承载建立 ， 最终都会由 网络侧发送对应的消息给 HeNB/HNB ,该消息为 Sl/Iuh接口的 GTP控制信令。 即图中所示的消息： 初始上下文建立请求 /附着接受 /承载建立请求 /PDN连接 接受， 如消息中携带了所要创建 /修改 /释放的承载所对应的 QoS规则和上下 行 TEID、 五元组等信息， 也即 IP数据流信息。

步骤 1103: HeNB/HNB根据从 GTP消息中获取相关信息， 并根据相关 策略决定创建新 SA (动态方案）或者选择 SA (动态或者静态方案） 如果是创建新的 SA, HeNB/HNB发送 IKEv2消息的 "创建子 SA请求" 给 SeGW, 并在消息中携带了由 HeNB/HNB选定的上行 SA的 SPI。

HeNB/HNB从 Sl/Iuh接口的 GTP消息中获取了 QoS规则、 TEID和 /或五 元组信息， HeNB HNB根据 QoS规则能判断将该 GTP承载对应到哪个无线 承载上， 即和无线承载标识 RB-ID建立了对应关系（现有技术 )； HeNB/HNB 自身配置的信息，判断接收到的 QoS规则是否需要新建 SA或者是现有的 SA 就能满足该 QoS规则的需求。 这样新建或者选择的 SA的 SPI就能与 QoS规 则建立对应关系；如此一来 RB-ID和 SPI就通过 QoS规则建立了对应关系（映 射关系 /映射表） ， 如图 5所示。

如果不是建立 SPI和 RB-ID的对应关系， 而是根据 QoS规则建立了 SPI 和五元组的对应关系， 则该对应关系称作 "过滤器" ， 参见图 7。 上行（uplink, UL ) 映射 /过滤器。

步骤 1104: HeNB/HNB发送 "创建子 SA请求" 给 SeGW, 并在消息中 携带了由 HeNB/HNB选定的上行 SA的 SPI; SeGW收到请求后， 选择下行 SA的 SPI, 并通过 "创建子 SA回应" 消息发送给 HeNB/HNB。

步骤 1105: 在 1104步之后， HeNB/HNB可以获取下行 SA的 SPI, 并且 HeNB/HNB获取了下行的 QoS规则， HeNB/HNB可以生成下行 QoS和 SPI 的对应关系。

HeNB/HNB通过 T1接口向 HeNB/HNB PF上报上行和下行的 SPI和 QoS 的对应关系；

HeNB/HNB PF将 1105步获取的上下行 SPI和 QoS的对应关系后， 通过 S9*接口报告给固网 BPCF , 由 BPCF或者 BPCF委托其他固网网元为传输在 不同 IPsec隧道中的数据包保证 QoS。

步骤 1106: He B/HNBPF向 SeGW发送下行 QoS规则和 SPI的对应关 系；

步骤 1107: SeGW根据下行的 QoS规则， 并建立下行 MAPPING表或者 过滤器。 步骤 1008: He B/HNB向 EPS核心网回应 Sl/Iuh接口的 GTP消息。

实施例五：

以上是实例中， 上下行的映射表 /过滤器， SPI和 QoS的对应关系的生成 都是由 HeNB/HNB和 SeGW分别生成的， 或者是有 HeNB/HNB分别生成上 下行的， 通过 PF中介通告给对端 SeGW。 最终由 HeNB/HNB和 SeGW分别 将 SPI和 QoS的对应关系上报个 PF最后到固网（ T1T2架构 ) ,或者由 SeGW 上报给 PF最后到固网 （T1T3架构） 。 以下的方案可以在前述实施例的流程 才匡架下， #文如下描述的处理， 形成新的实施例。

1 ) 作为针对 T1T3架构的另外一种实现方式， SeGW和 HeNB/HNB可 以分别生成各自的映射表 /过滤器和 "SPI和 QoS的对应关系" ， HeNB/HNB 将上行的 "SPI和 QoS的对应关系" 通过扩展的 IKEv2消息发送给 SeGW, 并由 SeGW通过 T1接口上报给 PF最后到固网。

2 )针对 SeGW不解析 Sl/Iuh消息的情况， HeNB/HNB可以获取了 Sl/Iuh 消息的内容， 并通过扩展的 IKEv2消息发送给 SeGW, 供 SeGW生成下行映 射^/过滤器和下行 SPI和 QoS的对应关系。

3 ) 作为一种具体实现， 当 HeNB/HNB生成了上行 "SPI和 QoS的对应 关系"但无法向 PF直接上报时（T1T3架构， 无 T2接口）， SeGW可以基于 "反映射" 上行数据获取上行 "SPI和 QoS的对应关系" 。 当 SeGW生成 / 获取了上行" SPI和 QoS的对应关系"后，但无法通告 HeNB/HNB, HeNB/HNB 可以基于 "反映射" 下行数据制获取上行 "SPI和 QoS的对应关系" 。 也就 是说， SeGW和 HeNB/HNB可以通过反映射机制协商 "SPI和 QoS的对应关 系，， 。

所述的反映射是指： 当 SeGW或者 HeNB/HNB接受到对端（HeNB/HNB 或者 SeGW )的数据包后，用该数据包外层封装的 IPSec头的 SPI去查找与其 成对产生的 SPI, 作为反向的 SPI, 把数据包对应的 QoS规则、 TEID, 五元 组等信息做反向处理： 上 /下行 QoS/TEID映射为下 /上行 QoS/TEID, 五元组 信息中的源 /目的地址 /端口号交换。之后把查找到的 SPI和反向处理后的 QoS 规则、 TEID, 五元组等信息作关联， 上述就是反映射机制。 通过在这样的操 作， 就可以生成对端的 "映射表 /过滤器" 和 "SPI和 QoS的对应关系" 。

本领域普通技术人员可以理解上述方法中的 全部或部分步骤可通过程序 来指令相关硬件完成， 所述程序可以存储于计算机可读存储介质中， 如只读 存储器、 磁盘或光盘等。 可选地， 上述实施例的全部或部分步骤也可以使用 一个或多个集成电路来实现， 相应地， 上述实施例中的各模块 /单元可以釆用 硬件的形式实现， 也可以釆用软件功能模块的形式实现。 本发明不限制于任 何特定形式的硬件和软件的结合。

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

工业实用性

本发明实施例能够保证终端在从 He B/HNB接入时，对不同的业务实现 QoS区分， 对 QoS要求高的业务， 优先满足其 QoS需求， 提高用户体验。