CN1581744A - 为mbms业务提供多种qos的方法 - Google Patents
为mbms业务提供多种qos的方法 Download PDFInfo
- Publication number
- CN1581744A CN1581744A CNA031438318A CN03143831A CN1581744A CN 1581744 A CN1581744 A CN 1581744A CN A031438318 A CNA031438318 A CN A031438318A CN 03143831 A CN03143831 A CN 03143831A CN 1581744 A CN1581744 A CN 1581744A
- Authority
- CN
- China
- Prior art keywords
- qos
- ggsn
- sgsn
- message
- carrying
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/30—Resource management for broadcast services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
- H04W28/18—Negotiating wireless communication parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
- H04W28/24—Negotiating SLA [Service Level Agreement]; Negotiating QoS [Quality of Service]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/50—Allocation or scheduling criteria for wireless resources
- H04W72/54—Allocation or scheduling criteria for wireless resources based on quality criteria
- H04W72/543—Allocation or scheduling criteria for wireless resources based on quality criteria based on requested quality, e.g. QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/26—Network addressing or numbering for mobility support
Abstract
本发明提出了在宽带码分多址移动通信系统的多媒体广播与组播业务中,一种为MBMS业务提供多个QOS的方法。本发明为MBMS业务提供了多个QOS,极大提高了下行网络节点接入MBMS业务的机会和能力,提高了网络资源利用效率,下行网络节点可以调整自己可用的资源。
Description
技术领域
本发明涉及在WCDMA通信系统中为MBMS业务提供多种QOS的方法。
背景技术
多媒体广播和组播业务(以下简称MBMS)是第三代伙伴计划(以下简称3GPP)正在进行标准化的一项新业务。MBMS业务是一种单向的点对多点的业务,这种业务的最大特点是它可以有效的利用无线资源和网络资源。
为了更好的说明MBMS业务,图1描述了提供MBMS的系统结构,图2作为例子描述了下行网络结点向上行网络结点申请注册MBMS业务的流程。
如图1所示,MBMS网络结构以通用分组无线业务(以下简称GPRS)核心网为基础,并增加了新的网络单元。101广播和组播业务中心(以下简称BM-SC)是MBMS系统的业务控制中心。102网关GPRS支持节点(以下简称GGSN)和103服务GPRS支持节点(以下简称SGSN)构成了MBMS业务的传输网络,为数据的传输提供路由。104陆地无线接入网(以下简称RAN)在空中接口上为MBMS服务提供无线资源。105用户设备(以下简称UE)是用来接收数据的终端设备。106归属位置寄存器(以下简称HLR)保存与用户有关的数据,可以提供用户鉴权等服务。107 Gn/Gp表示SGSN和GGSN之间的接口。108 Gi表示BM-SC和GGSN之间的接口并且接口上的协议栈是基于互联网协议(以下简称IP协议)。109 Gmb表示BM-SC和GGSN之间的接口并且接口协议是专用于传递MBMS信令参数的。MBMS业务所用的无线资源不是用户专用的,而是由此业务的所有用户共享的。需要说明的是,MBMS业务是单向下行业务,也即MBMS数据的传输顺序是从BM-SC至GGSN,GGSN至SGSN,SGSN至RNC,然后RNC再通过空中接口将MBMS数据传输给UE。对MBMS业务来说,GGSN是BM-SC的下行节点,BM-SC可以向多个GGSN发送数据;SGSN是GGSN的下行节点,GGSN可以向多个SGSN发送数据;RNC是SGSN的下行节点,SGSN可以向多个RNC发送数据。
当BM-SC决定发送MBMS数据前,BM-SC会先发送会话开始消息以便建立相应的网络资源。BM-SC发送会话开始消息给多个GGSN,然后GGSN发送MBMS会话开始消息给多个SGSN,然后SGSN再发送MBMS会话开始通知消息给多个RNC,每个下行网络节点在收到其上行网络节点的消息后,会发送相应的反馈消息给上行网络节点以建立网络资源,这个过程在本发明中的实现部分有详细说明,这里想要说明的是一个下行网络节点要想收到上行网络节点的MBMS消息或MBMS数据,下行网络节点要先向其上行网络节点申请注册MBMS业务,图2作为例子描述了现有技术中下行网络节点向其上行网络节点注册MBMS业务的流程。
在上述图2的201中,RNC向SGSN发送RNC注册MBMS请求消息,该消息包含:Service ID(业务标志),RNC的地址。
在上述图2的202中,SGSN在收到RNC发送的注册请求消息后,如果SGSN也还没有向其上行节点(即GGSN)注册过MBMS业务,则SGSN向GGSN发送SGSN注册MBMS请求消息,该消息包含参数:Service ID(业务标志),SGSN的地址;否则,SGSN直接跳到步骤206。
在上述图2的203中,GGSN在收到SGSN发送的注册请求消息后,如果GGSN也还没有向其上行节点(即BM-SC)注册过MBMS业务,则GGSN向BM-SC发送GGSM注册MBMS请求消息,该消息包含参数:Service ID(业务标志),GGSN的地址;否则,GGSN直接跳到步骤205。
在上述图2的204中,BM-SC在203中收到GGSN发送的注册请求消息后,将GGSN地址记录到自己的对该MBMS业务(由收到的GGSN消息中的Service ID标志)的业务上下文中,然后BM-SC向GGSN发送GGSN注册MBMS应答消息。
在上述图2的205中,GGSN在收到204中BM-SC发送的应答消息后,GGSN建立该MBMS业务的业务上下文,并将在202中收到的消息中的SGSN的地址记录到自己的MBMS业务上下文中,然后GGSN向SGSN发送SGSN注册MBMS应答消息。
在上述图2的206中,SGSN在收到205中GGSN发送的应答消息后,SGSN建立该MBMS业务的业务上下文,并将在201中收到的消息中的RNC的地址记录到自己的MBMS业务上下文中,然后SGSN向RNC发送RNC注册MBMS应答消息。RNC收到该应答消息后,也建立MBMS业务上下文。至此,注册过程结束,需要说明的是,在上述图2中从202至205的过程,也可以是由UE激活MBMS业务引起的,并且这时由于UE发送的消息是通过RNC传送给SGSN的,所以SGSN可以隐含地将RNC注册到自己的MBMS业务上下文中,即在这种情况下不需要步骤201和206,由于这是现有技术,在此不在赘述。
现有MBMS业务中只提供一种QOS,所以当一次会话开始时,如果某一网络节点(如RNC,SGSN或GGSN)不支持提供的QOS,由于MBMS业务不允许QOS协商,则只能放弃MBMS业务,这样做不仅浪费了网络资源,而且使网络节点提供MBMS业务的可能性不高。
发明内容
本发明的目的是提供一种方法,使得当一次会话开始时,一个MBMS业务提供了多种QOS,这样即使某一网络节点不能支持其中最好的QOS,但它可以选择合适自己的较低的QOS,这样做使得网络节点能够选择QOS,大大提高了其使用MBMS业务的机会和能力,同时节省了网络资源。
为实现上述目的,一种为MBMS业务提供多个QOS的方法,包括步骤:
(1)BM-SC开始一次会话并发送会话开始消息给GGSN,该会话开始消息包含多个QOS参数;
(2)GGSN收到步骤(1)中BM-SC发送的会话开始消息后,选择自己能够支持的QOS并为之分配TEID,然后向BM-SC发送会话开始应答消息,该会话开始应答消息包含参数TEID及QOS;
(3)BM-SC收到步骤(2)中GGSN发送的会话开始应答消息后,保存该消息中的参数TEID和QOS,这样标志GGSN和BM-SC之间关联该QOS的承载建立成功;
(4)GGSN在步骤(2)中发送完会话开始应答消息后,紧接着向SGSN发送MBMS会话开始消息,该MBMS会话开始消息包含多个QOS参数;
(5)SGSN收到步骤(4)中GGSN发送的MBMS会话开始消息后,选择自己能够支持的QOS并为之分配TEID,然后向GGSN发送会话开始应答消息,该会话开始应答消息包含参数TEID及QOS;
(6)GGSN收到步骤(5)中SGSN发送的MBMS会话开始应答消息后,保存该消息中的参数TEID和QOS,这样标志SGSN和GGSN之间关联该QOS的承载建立成功;
(7)SGSN在步骤(5)中发送完MBMS会话开始应答消息后,紧接着向RNC发送MBMS会话开始通知消息,该MBMS会话开始通知消息包含多个QOS参数;
(8)RNC收到步骤(7)中SGSN发送的MBMS会话开始通知消息后,选择自己能够支持的QOS并为之分配TEID,然后RNC统计UE数目并根据该QOS分配空中资源;
(9)RNC完成步骤(8)后,向SGSN发送MBMS会话开始通知应答消息,该消息包含RNC在步骤(8)中选择的QOS和TEID参数;
(10)SGSN收到步骤(9)中RNC发送的MBMS会话开始通知应答消息后,保存该消息中的参数TEID和QOS,这样标志RNC和SGSN之间关联该QOS的承载建立成功。
本发明为MBMS业务提供了多个QOS,极大提高了下行网络节点接入MBMS业务的机会和能力,提高了网络资源利用效率,下行网络节点可以调整自己可用的资源。
附图说明
图1是MBMS系统的逻辑结构图;
图2是现有技术中,下行网络节点向其上行网络节点申请注册MBMS业务的过程;
图3是本发明中,MBMS业务的一次会话开始的过程;
图4是本发明中,RNC和SGSN之间更新承载的第一种过程;
图5是本发明中,RNC和SGSN之间更新承载的第二种过程;
图6是本发明中,SGSN和GGSN之间建立新承载的第一种过程;
图7是本发明中,SGSN和GGSN之间建立新承载的第二种过程;
图8是本发明中,SGSN和GGSN之间删除承载的过程;
图9是本发明中,GGSN和BM-SC之间建立新承载的第一种过程;
图10是本发明中,GGSN和BM-SC之间建立新承载的第二种过程;
图11是本发明中,GGSN和BM-SC之间删除承载的过程。
具体实施方式
本发明主要由三部分够成:
在一次会话过程中,RNC和SGSN之间,SGSN和GGSN之间,以及GGSN和BM-SC之间建立新的承载的过程
在一次会话过程中,RNC和SGSN之间,SGSN和GGSN之间,以及GGSN和BM-SC之间释放旧的承载的过程
名词解释:
QOS:服务质量。在本发明中表示服务质量参数,它包含一些属性,如服务类型、承载比特速率等,这些属性用来定制一个承载的特性。
TEID:承载标志。在网络节点之间(如GGSN和SGSN之间)建立的承载需要用TEID去标志它。
下行承载:指用来传输下行数据的承载。下行数据是指数据的发送是沿着上行节点至下行节点的方向进行,即BM-SC至GGSN,GGSN至SGSN,及SGSN至RNC和UE。
BM-SC发送某一MBMS业务的数据是以“会话”为单位进行的,在某一MBMS业务的会话开始时BM-SC会先发送“会话开始”消息,在等待一定的时间以便网络有足够的时间准备网络资源后BM-SC发送真正的数据,在一次会话过程中,BM-SC可以发送多次数据,在BM-SC准备结束一次“会话”时,BM-SC会发送“会话结束”消息以便释放网络资源。一次会话过程的时间可以很长(几天)也可以很短(几分钟),这取决于该MBMS业务的需要。
图3描述了本发明中BM-SC开始一次会话的过程,在图3的301中,BM-SC中的MBMS业务上下文主要包括参数:
Service ID(业务标志)
■QOS1
■QOS2
■.....
■QOSn
■GGSN1信息
-地址
-QOS&TEID List
●(QOS1,TEID1)
●...........
●(QOSn,TEIDn)
■........
BM-SC中的业务上下文是由运营商通过O&M(运行与维护)功能建立的,并且对每一个MBMS业务,都有一个相应的业务上下文与之对应。其中,Service ID唯一标志该业务上下文所对应的MBMS业务。Service Area(业务区域参数)表示使用该MBMS业务的区域,可以详细到小区范围。QOS List是一个参数组,它包括一到多个QOS参数,用QOS1到QOSn表示,QOS1表示的服务质量最高,即提供MBMS业务的网络设备,如果能支持QOS1则其提供的MBMS业务质量最好;QOSn表示的服务质量最低,从QOS1到QOSn,其表示的服务质量逐渐降低,即从QOS1到QOSn按服务质量降序排列。GGSN List是一个参数组,因为BM-SC下面会有多个GGSN,所以在这个参数组里,BM-SC为每一个注册MBMS业务的GGSN分配一个信息项来保存该GGSN的相关信息。每一个GGSN的信息在GGSN第一次发注册请求后生成,但在每个GGSN第一次发注册请求后,BM-SC中保存的该GGSN信息中只有地址项表示GGSN的地址,而QOS&TEID List为空,因为,TEID和QOS要在BM-SC发送会话开始消息后,GGSN在会话开始应答消息中提供TEID和GGSN选择的QOS,如上述图3的304所示。其中,TEID是GGSN生成的数据承载地址,QOS是GGSN从BM-SC发送的会话消息中包含的QOSList中选择的一个QOS。一个TEID和一个QOS对应,QOS&TEID List表示,如果GGSN选择了多个QOS,则相应的GGSN应该为每个QOS分配一个唯一的TEID与之对应。
在上述图3的302中,BM-SC发送会话开始消息给GGSN。会话开始消息主要包含参数:
QOS List
■QOS1
■QOS2
■.......
■QOSn
Service ID唯一标志会话开始的业务。Service Area表示该业务要进行的业务区域范围。QOS List表示该业务所支持的所有的QOS(用从QOS1到QOSn表示),其中QOS1表示的服务质量最好,QOSn表示的服务质量最低,从QOS1到QOSn,其表示的服务质量按降序排列。
在上述图3的303中,GGSN收到上述302中从BM-SC发送的会话开始消息后,根据其中的Service ID找到对应的MBMS业务上下文,并将参数Service Area和QOS List保存到自己的MBMS业务上下文的对应项中去。GGSN中的业务上下文是在GGSN在上述图2所示发注册消息并得到BM-SC应答后建立起来的,主要包括参数:
Service ID(业务标志)
Service Area(业务区域)
■QOS1
■QOS2
■.......
■QOSn
■SGSN1信息
-地址
-QOS&TEID List
●(QOSh,TEIDh)
●.....
●(QOSn,TEIDn)
■.....
■(QOSm,TEIDm)
■.........
■(QOSn,TEIDn)
其中Service ID是在上下文建立时就保存的参数项,Service Area和QOSList是在收到BM-SC发送的会话开始消息后才保存到上下文中。SGSN List是一个参数组,因为GGSN下面会有多个SGSN,所以在这个参数组里,GGSN为每一个注册MBMS业务的SGSN分配一个信息项来保存该SGSN的相关信息。每个SGSN的信息包括:地址,QOS&TEID List参数。每个SGSN的信息是SGSN第一次向GGSN发注册请求后被GGSN加入的,但只有地址项被GGSN记录,而QOS&TEID List为空。SGSN List中的SGSN信息项下的QOS&TEID Lists是一个参数组,该参数组包含多个二元参数,每个二元参数包括QOS和TEID两个参数。当GGSN在所述图3的305向SGSN发送MBMS会话开始消息后,每当GGSN收到来自该SGSN的一个MBMS会话开始应答消息后,GGSN就将该MBMS会话开始应答消息中的QOS和TEID参数作为二元项加入到其业务上下文中该SGSN对应的QOS&TEID List中去。
在上述图3的304中,GGSN从BM-SC提供的QOS List中选择自己能支持的最高的QOS(假设为QOSm,则QOSm应属于QOS1到QOSn之间的某一个QOS,即1≤m≤n),并分配一个TEID(假设为TEIDm),该TEID与该QOS一一对应。此时GGSN中的MBMS业务上下文中的Local QOS&TEIDList项为空,于是GGSN将Local QOS&TEID List中新增加一个二元项(QOSm,TEIDm)。GGSN的业务上下文中的Local QOS&TEID List的作用是,保存本节点(GGSN)与其上行网络结点(BM-SC)之间建立的每一个承载的TEID及与之关联的QOS。之后GGSN将自己刚刚选择的QOSm和TEIDm在会话开始应答消息中发送给BM-SC。BM-SC收到GGSN发送的会话开始应答消息后,会在其业务上下文中的GGSN List中找到该GGSN对应的GGSN信息项中的QOS&TEID List,然后在其中增加一个二元项(QOSm,TEIDm),这意味着在该GGSN和BM-SC之间建立了一条由TEIDm标志的新的下行数据承载。需要注意的是,GGSN可能在以后的步骤中向BM-SC返回多个会话开始应答消息,每一个会话开始应答消息中都包括二元项(QOS,TEID),其中的QOS和TEID都是唯一的,它们都被保存在BM-SC中的业务上下文中对应该GGSN的QOS&TEID List中去,这样当BM-SC在步骤314中给GGSN发送数据时,如果在BM-SC和该GGSN之间建立了多个由不同的TEID标志的下行数据承载,则BM-SC对每个由TEID唯一标志的下行数据承载要用与该TEID对应的QOS发送一份数据。
在上述图3的305中,GGSN向SGSN发送MBMS会话开始消息,该消息主要包含参数:
Service ID
■QOSm
■.......
■QOSn
Service ID唯一标志会话开始的业务。Service Area表示该业务要进行的业务区域范围。QOS List表示该业务支持的一到多个QOS。需要说明的是,由于GGSN从BM-SC在302中发送的会话开始消息中的QOS List中选择的QOS是GGSN能支持的最高的QOS,即QOSm(QOSm属于QOS1到QOSn之间,即1≤m≤n),所以GGSN在向SGSN发送的MBMS会话开始消息中包含的QOS List范围是从QOSm到QOSn。
在上述图3的306中,SGSN收到上述305中从GGSN发送的MBMS会话开始消息后,根据其中的Service ID找到对应的MBMS业务上下文,并将参数Service Area和QOS List保存到自己的MBMS业务上下文的对应项中去。SGSN中的业务上下文是在SGSN在上述图2所示发注册消息并得到GGSN应答后建立起来的,主要包括参数:
Service ID(业务标志)
■QOSm
■.......
■QOSn
RNC-List(RNC信息列表)
■RNC1信息
-地址
-QOS
-TEID
■RNC2信息
-地址
-QOS
-TEID
■......
Local QOS&TEID List
■(QOSh,TEIDh)
■.........
■(QOSn,TEIDn)
其中Service ID是在上下文建立时就保存的参数项,Service Area和QOSList是在收到GGSN发送的MBMS会话开始消息后才保存到上下文中。由于GGSN发送的MBMS会话开始消息中的QOS List中的QOS的范围是如上述305中所述的从QOSm到QOSn(1≤m≤n),所以SGSN中保存的QOS List参数中的QOS的范围也是从QOSm到QOSn。RNC List是一个参数组,因为SGSN下面会有多个RNC,所以在这个参数组里,SGSN为每一个注册MBMS业务的RNC分配一个信息项来保存该RNC的相关信息。每个RNC的信息包括:地址,QOS,TEID。对于每个RNC,在SGSN第一次将该RNC注册为需要MBMS业务的RNC时,SGSN将该RNC的信息保存下来,但此时只有地址项被SGSN记录,而QOS和TEID为空。需要注意的是,SGSN中保存的RNC List中的每个RNC的信息中,QOS及TEID只有一个,这是因为,在每个RNC和SGSN之间,RNC只会选择一个QOS并为该QOS分配TEID及建立Iu接口(RNC和SGSN之间的接口)上的由该TEID标志的下行数据承载及Uu接口(RNC和UE之间的空中接口)上的空中资源,而不象在Gn接口(SGSN和GGSN之间的接口)上可能有多个QOS和对应每个QOS的下行数据承载,这在后面的步骤中会进行说明。当SGSN在所述图3的308中向RNC发送MBMS会话开始通知消息后,每当SGSN在所述图3的311中收到某个RNC发送的MBMS会话开始通知应答消息后,SGSN就将该MBMS会话开始通知应答消息中的QOS和TEID保存到其业务上下文中该RNC信息项中去。
在上述图3的307中,SGSN从GGSN提供的QOS List中选择自己能支持的最高的QOS(假设为QOSk,则QOSk应属于QOSm到QOSn之间的某一个QOS,即m≤k≤n),并分配一个TEID(假设为TEIDk),该TEID与该QOS一一对应。此时SGSN中的MBMS业务上下文中的Local QOS&TEIDList为空,于是SGSN将Local QOS&TEID List中新增加一个二元项(QOSk,TEIDk)。SGSN的业务上下文中的Local QOS&TEID List的作用是,保存本节点(SGSN)与其上行网络结点(GGSN)之间建立的每一个承载的TEID及与之关联的QOS。之后,SGSN将自己刚刚选择的QOSk和TEIDk在MBMS会话开始应答消息中发送给GGSN。GGSN收到SGSN发送的MBMS会话开始应答消息后,会在其业务上下文中的SGSN List中找到该SGSN对应的SGSN信息项中的QOS&TEID List,然后在其中增加一个二元项(QOSk,TEIDk),这意味着在该SGSN和GGSN之间建立了一条由TEIDk标志的新的下行数据承载。需要注意的是,SGSN可能在以后的步骤中向GGSN返回多个会话开始应答消息,每一个会话开始应答消息中都包括二元项(QOS,TEID),其中的QOS和TEID都是唯一的,它们都被保存在GGSN中的业务上下文中对应该SGSN的QOS&TEID List中去,这样当在步骤314中GGSN收到BM-SC发送的数据并传递给SGSN时,如果在GGSN和该SGSN之间建立了多个由不同的TEID标志的下行数据承载,则GGSN对每个由TEID唯一标志的下行数据承载要用与该TEID对应的QOS发送一份数据。
在上述图3的308a中,GGSN会进一步比较:如果在307中收到的消息中的QOSk与自己在Local QOS&TEID List中保存的所有二元项(QOS,TEID)中的QOS都不相同,说明GGSN还没有为该QOS在GGSN与BM-SC之间建立过下行数据承载,则GGSN为该QOSk分配一个新的TEIDh,并将(QOSk,TEIDh)保存在Local QOS&TEID List中,然后GGSN向BM-SC发送会话开始应答消息,该消息包含参数:QOS(QOSk),TEID(TEIDh)。BM-SC收到该消息后,会和上述304中一样,将二元项(QOS,TEID)保存在该GGSN对应的QOS&TEID List中去,这意味着在BM-SC和GGSN之间又建立了一条新的由TEID(TEIDh)标志的下行数据承载。
在上述图3的308b中,SGSN向RNC发送MBMS会话开始通知消息,该消息主要包含参数:
Service Area(业务区域)
QOS List
■QOSk
■........
■QOSn
Service ID唯一标志会话开始的业务。Service Area表示该业务要进行的业务区域范围。QOS List表示该业务支持的一到多个QOS。需要说明的是,由于SGSN从GGSN在305中发送的MBMS会话开始消息中的QOS List中选择的QOS是SGSN能支持的最高的QOS,即QOSk(QOSk属于QOSm到QOSn之间,即m≤k≤n),所以SGSN在向RNC发送的MBMS会话开始通知消息中包含的QOS List范围是从QOSk到QOSn。
在上述图3的309中,RNC收到上述308b中从SGSN发送的MBMS会话开始通知消息后,如果RNC中还没有关于该MBMS业务的业务上下文,则RNC直接建立MBMS业务上下文并将MBMS会话开始通知消息中的所有参数保存到业务上下文中,如果RNC中已经有了关于该MBMS业务的MBMS业务上下文,则RNC根据其中的Service ID找到对应的MBMS业务上下文,并将参数Service Area和QOS List保存到自己的MBMS业务上下文的对应项中去。RNC中的MBMS业务上下文主要包括参数:
Service ID(业务标志)
Service Area(业务区域)
QOS List
■QOSk
■.......
■QOSn
QOS
其中Service ID是在上下文建立时就保存的参数项,Service Area和QOSList是收到SGSN发送的MBMS会话开始通知消息后才保存到上下文中。由于SGSN发送的MBMS会话开始通知消息中的QOS List中的QOS的范围是如上述308b中所述的从QOSk到QOSn(m≤k≤n),所以RNC中保存的QOS List参数中的QOS的范围也是从QOSk到QOSn。RNC根据自己当时的资源情况,决定从QOSk到QOSn中选择自己能支持的最大的QOS(QOSn≤QOS≤QOSk),并分配TEID与该QOS对应,然后将QOS和TEID保存到业务上下文中。
在上述图3的310中,RNC通过空中寻呼来对使用MBMS业务的UE数目进行统计,并根据统计结果分配空中接口资源。
在上述图3的311中,RNC将在上述309中选择的QOS和TEID在MBMS会话开始通知应答消息中发送给SGSN。需要注意的是,在RNC和SGSN之间为每个MBMS业务只建立一条由TEID标志的下行数据承载,而在SGSN和GGSN之间,以及GGSN与BM-SC之间为每个MBMS业务可能建立多条下行数据承载。
在上述图3的312中,SGSN收到RNC发送的MBMS会话开始通知应答消息后,会在其业务上下文中的RNC List中找到该RNC对应的RNC信息项,然后保存QOS和TEID,这意味着在该SGSN和RNC之间建立了一条由该TEID标志的下行数据承载。然后SGSN进一步比较:如果该消息中所含的QOS与自己在Local QOS&TEID List中保存的所有二元项(QOS,TEID)中的QOS都不相同,说明SGSN还没有为该QOS在SGSN与GGSN之间建立过下行数据承载,则SGSN为该QOS分配一个新的TEID,并将该QOS和TEID以二元项的形式(QOS,TEID)保存在Local QOS&TEID List中,并将该二元项在MBMS会话开始应答消息中发送给GGSN。
在上述图3的313中,如果GGSN收到SGSN发送的MBMS会话开始通知应答消息,会在其业务上下文中的SGSN List中找到该SGSN对应的SGSN信息项中的QOS&TEID List,然后将该消息中的QOS和TEID保存为一个新的二元项(QOS,TEID),这意味着在该SGSN和GGSN之间建立了一条TEID标志的新的下行数据承载。然后,GGSN进一步判断,如果该消息中所含的QOS与自己在Local QOS&TEID List中保存的所有二元项(QOS,TEID)中的QOS都不相同,说明GGSN还没有为该QOS在GGSN与BM-SC之间建立过下行数据承载,则GGSN为该QOS分配一个新的TEID,并将该QOS和TEID以二元项的形式(QOS,TEID)保存在Local QOS&TEID List中,并将该二元项在会话开始应答消息中发送给BM-SC。BM-SC收到GGSN发送的消息后,会和上述304中一样,将二元项(QOS,TEID)保存在该GGSN对应的QOS&TEID List中去,这意味着在BM-SC和GGSN之间又建立了一条新的由TEID标志的下行数据承载。
在上述图3的314中,BM-SC在上述301中发送会话开始消息之后若干时间(该时间长度可以由运营商配置,其长度应当足够下面的节点GGSN,SGSN及RNC准备资源),BM-SC发送真正的MBMS数据,该数据经由BM-SC和GGSN之间建立的数据承载发送,如果BM-SC和GGSN之间建立了多条数据承载,则每个承载发送一份数据并且发送数据所用的QOS要和该承载对应的QOS一致。GGSN收到MBMS数据后通过GGSN和SGSN之间建立的数据承载发送,如果GGSN和SGSN之间建立了多条数据承载,则每个承载发送一份数据并且发送数据所用的QOS要和该承载对应的QOS一致。SGSN收到MBMS数据后通过SGSN和RNC之间建立的数据承载发送,由于在SGSN和RNC之间只有一条数据承载,所以SGSN对每个RNC只发送一份数据,发送该数据所用的QOS要和该承载对应的QOS一致。RNC收到MBMS数据后,再通过空中接口将其发送给UE。
在一次会话过程开始时,如果RNC当时的资源紧张,RNC可能会选择较低的QOS来建立承载,即在上述图3的309中RNC会选择一个较低的QOS并分配TEID,然后在311中将QOS和TEID通过消息发送给SGSN。如果在一次会话过程中(即会话还没有结束),由于RNC下面的UE数目减少或RNC提供的MBMS业务数目减少或别的原因,RNC的可用资源提高,RNC会和SGSN交互,要求为某一MBMS业务建立新的承载,该承载有更高的QOS,同时释放已有的承载,图4描述了实现该过程的第一种方法,图5描述了实现该过程的第二种方法。
在上述图4的401中,由于RNC的可用资源提高,RNC检查为某一MBMS业务建立的承载的QOS,如果发现该QOS小于自己保存在业务上下文(即如图3中309所示的业务上下文)中的QOS List中的最大的QOS,并且自己应该能支持比该QOS更高的QOS,则RNC将该MBMS业务的业务标志及该承载的TEID在MBMS承载更新请求消息中发送给SGSN。
在上述图4的402中,SGSN收到RNC发送的消息后,如果SGSN接受该RNC的请求,则SGSN找到保存在自己的业务上下文中的,该RNC在RNC List中对应的RNC信息项,然后SGSN删除该RNC信息项中的QOS和TEID值,并向RNC发送MBMS承载更新应答消息,该消息包含参数:Cause,Cause表示成功或失败,在这里Cause表示成功。如果SGSN不接受该RNC的请求,则SGSN不做其它的动作,只是向RNC发送MBMS承载更新应答消息,该消息包含参数:Cause,在这里,Cause表示失败。RNC收到SGSN发送的MBMS承载更新应答消息后,如果其中的Cause表示成功, RNC删除保存在自己的上下文中的QOS和TEID,这意味着RNC和SGSN之间以前建立的承载已被删除;如果Cause表示失败,则RNC不做其它动作。
在上述图4的403中,如果在402中,SGSN已经接受了RNC的请求,则SGSN检查保存在自己的业务上下文中的QOS List,并从其中SGSN能支持的最高的QOS到QOSn以QOS List的形式通过MBMS会话开始通知消息发送给RNC,在该消息中还包括Service ID。
在上述图4的404中,RNC收到上述403中SGSN发送的消息后,RNC根据其中的Service ID找到对应的MBMS业务上下文,并将参数QOS List保存到自己的MBMS业务上下文的对应项中去。RNC根据自己的资源情况,决定从SGSN在上述403中发送的QOS List中选择自己能支持的最大的QOS并分配TEID,然后将QOS和TEID保存到自己的业务上下文中去。然后RNC通过空中寻呼来对使用MBMS业务的UE数目进行统计,并根据统计结果重新分配空中接口资源。
在上述图4的405中,RNC将在上述404中选择的QOS和分配的TEID在MBMS会话开始通知应答消息中发送给SGSN,RNC在该MBMS会话开始通知应答消息中还包括另一个参数:Cause,Cause表示原因,即成功或失败的原因。SGSN收到RNC发送的消息后,如果该消息中的参数Cause表示成功,SGSN将其中的QOS和TEID保存到自己的业务上下文中该RNC对应的信息项中,这意味着RNC和SGSN之间建立了一条新的有更高QOS的承载;如果该消息中的参数Cause表示失败,则SGSN舍弃该消息中收到的参数,并不做进一步动作。
作为RNC要求更改承载的另一种方法,图5描述的过程与图4描述的过程的主要区别在于,图5的过程中,其消息中传输的参数略有不同,其目的在于RNC可以主动要求新建立的承载的QOS,当然该QOS也要从RNC保存的QOS List中选择。
在上述图5的501中,由于RNC的可用资源提高,RNC检查为某一MBMS业务建立的承载的QOS,如果发现该QOS小于自己保存在业务上下文(即如图4中409所示的业务上下文)中的QOS List中的最大的QOS,并且自己应该能支持比该QOS更高的QOS,则RNC从QOS List中重新选择自己能支持的最高的QOS,并且将自己选择的最高的QOS和MBMS业务的业务标志及该承载的TEID在MBMS承载更新请求消息中发送给SGSN。MBMS承载更新请求消息中的New QOS即为RNC重新选择的最高的QOS。
在上述图5的502中,SGSN收到RNC发送的消息后,如果SGSN接受该RNC的请求,则SGSN找到保存在自己的业务上下文中的,该RNC在RNC List中对应的RNC信息项,然后SGSN删除该RNC信息项中的QOS和TEID值,并向RNC发送MBMS承载更新应答消息,该消息包含参数:Cause,Cause表示成功或失败,在这里Cause表示成功。如果SGSN不接受该RNC的请求,则SGSN不做其它的动作,只是向RNC发送MBMS承载更新应答消息,该消息包含参数:Cause,在这里,Cause表示失败。RNC收到SGSN发送的MBMS承载更新应答消息后,如果其中的Cause表示成功,RNC删除保存在自己的上下文中的QOS和TEID,这意味着RNC和SGSN之间以前建立的承载已被删除;如果Cause表示失败,则RNC不做其它动作。
在上述图5的503中,如果在502中,SGSN已经接受了RNC的请求,则SGSN将在上述501中收到的消息中的参数New QOS以及MBMS的业务标志一起通过MBMS会话开始通知消息发送给RNC。
在上述图5的504中,RNC收到上述503中SGSN发送的消息后,RNC根据其中的Service ID找到对应的MBMS业务上下文,并为该消息中的参数QOS分配TEID,然后将该QOS和TEID保存到自己的业务上下文中去。然后RNC通过空中寻呼来对使用MBMS业务的UE数目进行统计,并根据统计结果重新分配空中接口资源。
在上述图5的505中,RNC将在上述504中新分配的TEID在MBMS会话开始通知应答消息中发送给SGSN,RNC在该MBMS会话开始通知应答消息中还包括另一个参数:Cause,Cause表示原因,即成功或失败的原因。SGSN收到RNC发送的消息后,如果该消息中的参数Cause表示成功,则SGSN将其中的TEID以及在上述501中收到的消息中的New QOS保存到自己的业务上下文中该RNC对应的信息项中,这意味着RNC和SGSN之间建立了一条新的有更高QOS的承载;如果该消息中的参数Cause表示失败,则SGSN舍弃该消息中的TEID及在上述501中收到的消息中的NewQOS,并不做进一步的动作。
在图4及图5描述的过程后,在RNC及SGSN之间释放了原有的数据承载的同时建立了新的数据承载,由于新的承载关联了新的QOS而SGSN在该承载上发送的数据来源于上行节点GGSN,所以SGSN需要检查自己是否与GGSN之间也建立了相应的承载(其QOS匹配RNC与SGSN之间新建立承载的QOS),如果该承载未建立,则SGSN需要和GGSN进行交互以建立新的承载;同时,由于SGSN与RNC之间释放了原有的承载,SGSN需要检查释放的承载的QOS,如果SGSN与它控制的所有的RNC之间建立的所有承载都没有关联已释放承载的QOS,则SGSN需要与GGSN交互以便释放SGSN与GGSN之间关联该QOS的数据承载。SGSN与GGSN交互建立承载的过程有两种方法:图6描述了第一种方法,图7描述了第二种方法。SGSN与GGSN交互释放承载的过程如图8所示。
图6描述了SGSN与GGSN之间交互建立承载的第一种方法,在上述图6的601中,由于SGSN在上述图4或图5所示的过程中与RNC之间释放了旧的承载并建立了新的承载的同时,新的承载关联了新的QOS,SGSN检查该QOS,如果SGSN与GGSN之间所有的承载都没有关联该QOS,则SGSN通过向GGSN发送MBMS承载建立请求消息发起承载建立过程,该消息包含参数:Service ID(业务标志),QOS,其中的QOS正是SGSN想要为之建立承载的QOS。
在上述图6的602中,GGSN收到SGSN发送的消息后,如果GGSN接受该请求,GGSN向SGSN发送MBMS承载建立应答,该消息包含参数:Cause,Cause表示原因,即成功或失败的原因。
在上述图6的603中,如果在602中GGSN已经接受了SGSN的请求,则GGSN向SGSN发送MBMS会话开始消息,该消息用来建立GGSN与SGSN之间的数据承载,该消息包含参数:Service ID(业务标志),QOS。其中的QOS正是上述601中SGSN在MBMS承载建立请求消息中要求的QOS。
在上述图6的604中,SGSN收到GGSN在603中发送的消息后,SGSN分配TEID与该QOS关联,同时把TEID和QOS作为二元项保存到自己的Local QOS&TEID List中,然后SGSN向GGSN发送MBMS会话开始应答消息,该消息包含参数:QOS和TEID,TEID是SGSN刚刚分配的TEID,而QOS是603中GGSN发送的消息中包含的QOS。GGSN收到SGSN发送的MBMS会话开始应答消息后,将QOS和TEID保存到该SGSN在SGSN List中对应的信息项中去,这样在SGSN和GGSN之间,一个新的由TEID标志并关联QOS的承载就建立了。
图7描述了SGSN与GGSN之间交互建立承载的第二种方法,在上述图7的701中,由于SGSN在上述图4或图5所示的过程中与RNC之间释放了旧的承载并建立了新的承载的同时,新的承载关联了新的QOS,SGSN检查该QOS,如果SGSN与GGSN之间所有的承载都没有关联该QOS,则SGSN通过向GGSN发送MBMS承载建立请求消息发起承载建立过程,该消息包含参数:Service ID(业务标志),QOS,及TEID,其中的QOS正是SGSN想要为之建立承载的QOS,而TEID是SGSN为该承载分配的标志。
在上述图7的702中,GGSN收到SGSN发送的MBMS会话开始应答消息后,将QOS和TEID保存到该SGSN在SGSN List中对应的信息项中去,并向SGSN发送MBMS承载建立应答消息,该消息包含参数:Cause(成功或失败的原因),这样在SGSN和GGSN之间,一个新的由TEID标志并关联QOS的承载就建立了。
图8描述了SGSN与GGSN交互释放承载的过程,在上述图8的801中,由于SGSN在上述图5或图6所示的过程中与RNC之间建立了新的承载的同时释放了旧的与QOS关联的承载,如果SGSN检查后发现SGSN与RNC之间所有的承载都没有关联该QOS,说明没有承载在使用该QOS,则SGSN也要相应释放在SGSN和GGSN之间关联该QOS的承载,所以SGSN向GGSN发送MBMS承载释放请求消息,该消息包含参数:Service ID,TEID,NSAPI。TEID标志要释放的承载,NSAPI与TEID一起标志要释放的关联该承载的参数,即QOS等。
在上述图8的802中,GGSN收到SGSN发送的MBMS承载释放请求消息后,根据该消息中包含的参数找到SGSN对应的信息项,并删除其中的QOS和TEID,然后GGSN向SGSN发送MBMS承载释放应答消息,该消息包含参数:Cause(成功或失败的原因)。SGSN收到GGSN发送的该消息后,也相应删除对应的QOS和TEID,这样在SGSN和GGSN之间关联未用QOS的由TEID标志的承载被删除。
在图6或图7描述的过程后,在SGSN及GGSN之间建立了新的数据承载,由于新的承载关联了新的QOS而GGSN在该承载上发送的数据来源于其上行节点BM-SC,所以GGSN需要检查自己是否与BM-SC之间也建立了相应的承载(其QOS匹配SGSN与GGSN之间新建立承载的QOS),如果该承载未建立,则GGSN需要和BM-SC进行交互以建立新的承载。SGSN与GGSN交互建立承载的过程有两种方法:图9描述了第一种方法,图10描述了第二种方法。
图9描述了GGSN与BM-SC之间交互建立承载的第一种方法,在上述图9的901中,由于GGSN在上述图6或图7所示的过程中与SGSN之间建立了新的承载,新的承载关联了新的QOS,GGSN检查该QOS,如果GGSN与BM-SC之间所有的承载都没有关联该QOS,则GGSN通过向BM-SC发送承载建立请求消息发起承载建立过程,该消息包含参数:Service ID(业务标志),QOS,其中的QOS正是GGSN想要为之建立承载的QOS。
在上述图9的902中,BM-SC收到GGSN发送的消息后,如果BM-SC接受该请求,BM-SC向GGSN发送承载建立应答消息,该消息包含参数:Cause,Cause表示原因,即成功或失败的原因。
在上述图9的903中,如果在902中BM-SC已经接受了GGSN的请求,则BM-SC向GGSN发送会话开始消息,该消息用来建立BM-SC与GGSN之间的数据承载,该消息包含参数:Service ID(业务标志),QOS。其中的QOS正是上述901中GGSN在承载建立请求消息中要求的QOS。
在上述图9的904中,GGSN收到BM-SC在903中发送的消息后,GGSN分配TEID与该QOS关联,同时把TEID和QOS作为二元项保存到自己的Local QOS&TEID List中,然后GGSN向BM-SC发送会话开始应答消息,该消息包含参数:QOS和TEID,TEID是GGSN刚刚分配的TEID,而QOS是903中BM-SC发送的消息中包含的QOS。BM-SC收到GGSN发送的会话开始应答消息后,将QOS和TEID保存到该GGSN在GGSN List中对应的信息项中去,这样在GGSN和BM-SC之间,一个新的由TEID标志并关联QOS的承载就建立了。
图10描述了GGSN与BM-SC之间交互建立承载的第二种方法,在上述图10的1001中,由于GGSN在上述图6或图7所示的过程中与SGSN之间建立了新的承载,新的承载关联了新的QOS,GGSN检查该QOS,如果GGSN与BM-SC之间所有的承载都没有关联该QOS,则GGSN通过向BM-SC发送承载建立请求消息发起承载建立过程,该消息包含参数:ServiceID(业务标志),QOS,及TEID,其中的QOS正是GGSN想要为之建立承载的QOS,而TEID是GGSN为该承载分配的标志。
在上述图10的1002中,BM-SC收到GGSN发送的会话开始应答消息后,将QOS和TEID保存到该GGSN在GGSN List中对应的信息项中去,并向GGSN发送承载建立应答消息,该消息包含参数:Cause(成功或失败的原因),这样在GGSN和BM-SC之间,一个新的由TEID标志并关联QOS的承载就建立了。
图11描述了GGSN与BM-SC交互释放承载的过程,在上述图11的1101中,由于GGSN在上述图8所示的过程中与SGSN之间释放了旧的与QOS关联的承载,如果GGSN检查后发现GGSN与SGSN之间所有的承载都没有关联该QOS,说明没有承载在使用该QOS,则GGSN也要相应释放在GGSN和BM-SC之间关联该QOS的承载,所以GGSN向BM-SC发送承载释放请求消息,该消息包含参数:Service ID,TEID,NSAPI。TEID标志要释放的承载,NSAPI与TEID一起标志要释放的关联该承载的参数,即QOS等。在上述图11的1102中,BM-SC收到GGSN发送的承载释放请求消息后,根据该消息中包含的参数找到GGSN对应的信息项,并删除其中的QOS和TEID,然后BM-SC向GGSN发送承载释放应答消息,该消息包含参数:Cause(成功或失败的原因)。GGSN收到BM-SC发送的该消息后,也相应删除对应的QOS和TEID,这样在GGSN和BM-SC之间关联未用QOS的由TEID标志的承载被删除。
Claims (13)
1.一种为MBMS业务提供多个QOS的方法,包括步骤:
(1)BM-SC开始一次会话并发送会话开始消息给GGSN,该会话开始消息包含多个QOS参数;
(2)GGSN收到步骤(1)中BM-SC发送的会话开始消息后,选择自己能够支持的QOS并为之分配TEID,然后向BM-SC发送会话开始应答消息,该会话开始应答消息包含参数TEID及QOS;
(3)BM-SC收到步骤(2)中GGSN发送的会话开始应答消息后,保存该消息中的参数TEID和QOS,这样标志GGSN和BM-SC之间关联该QOS的承载建立成功;
(4)GGSN在步骤(2)中发送完会话开始应答消息后,紧接着向SGSN发送MBMS会话开始消息,该MBMS会话开始消息包含多个QOS参数;
(5)SGSN收到步骤(4)中GGSN发送的MBMS会话开始消息后,选择自己能够支持的QOS并为之分配TEID,然后向GGSN发送会话开始应答消息,该会话开始应答消息包含参数TEID及QOS;
(6)GGSN收到步骤(5)中SGSN发送的MBMS会话开始应答消息后,保存该消息中的参数TEID和QOS,这样标志SGSN和GGSN之间关联该QOS的承载建立成功;
(7)SGSN在步骤(5)中发送完MBMS会话开始应答消息后,紧接着向RNC发送MBMS会话开始通知消息,该MBMS会话开始通知消息包含多个QOS参数;
(8)RNC收到步骤(7)中SGSN发送的MBMS会话开始通知消息后,选择自己能够支持的QOS并为之分配TEID,然后RNC统计UE数目并根据该QOS分配空中资源;
(9)RNC完成步骤(8)后,向SGSN发送MBMS会话开始通知应答消息,该消息包含RNC在步骤(8)中选择的QOS和TEID参数;
(10)SGSN收到步骤(9)中RNC发送的MBMS会话开始通知应答消息后,保存该消息中的参数TEID和QOS,这样标志RNC和SGSN之间关联该QOS的承载建立成功。
2.按权利要求1所述的方法,其特征在于还包括步骤:
如果GGSN和SGSN之间建立的承载所关联的QOS没有关联任何GGSN和BM-SC之间的承载,则GGSN新分配一个TEID,并向BM-SC发送又一个会话开始应答消息,该会话开始应答消息包含参数TEID及QOS;
BM-SC收到GGSN发送的会话开始应答消息后,保存该消息中的参数TEID和QOS,这样标志GGSN和BM-SC之间关联该QOS的承载建立成功。
3.按权利要求1所述的方法,其特征在于还包括步骤:
如果RNC和SGSN之间建立的承载所关联的QOS没有关联任何SGSN和GGSN之间的承载,则SGSN新分配一个TEID,并向GGSN发送又一个会话开始应答消息,该会话开始应答消息包含参数TEID及QOS;
GGSN收到SGSN发送的会话开始应答消息后,保存该消息中的参数TEID和QOS,这样标志SGSN和GGSN之间关联该QOS的承载建立成功。
4.按权利要求1所述的方法,其特征在于还包括步骤:
如果SGSN和GGSN之间建立的承载所关联的QOS没有关联任何GGSN和BM-SC之间的承载,则GGSN新分配一个TEID,并向BM-SC发送又一个会话开始应答消息,该会话开始应答消息包含参数TEID及QOS;
BM-SC收到GGSN发送的会话开始应答消息后,保存该消息中的参数TEID和QOS,这样标志GGSN和BM-SC之间关联该QOS的承载建立成功。
5.按权利要求1所述的方法,其特征在于还包括RNC发起更新QOS的步骤:
(1)RNC向SGSN发送MBMS承载更新请求消息,该消息包含参数TEID,或参数QOS,该QOS是RNC要求的新QOS;
(2)SGSN收到(1)中RNC发送的消息后,SGSN向RNC发送MBMS承载更新应答消息;
(3)SGSN向RNC发送MBMS会话开始通知消息,如果在步骤(1)中RNC发送的MBMS承载更新请求消息中包含了QOS,则MBMS会话开始通知消息唯一包含该RNC要求的QOS,如果在步骤(1)中RNC发送的MBMS承载更新请求消息中不包含QOS,则MBMS会话开始通知消息包含多个QOS参数;
(4)如果在步骤(1)中RNC发送的MBMS承载更新请求消息中包含了QOS,RNC进行UE数目统计及根据该QOS配置空中资源过程;否则RNC在步骤
(3)中SGSN发送的MBMS会话开始通知消息中选择一个QOS,并进行UE数目统计及根据该QOS配置空中资源过程;
(5)RNC向SGSN发送MBMS会话开始通知应答消息,该消息包含参数TEID,如果在步骤(1)中RNC发送的MBMS承载更新请求消息中包含了QOS,则该消息中不包含参数QOS;否则,该消息中还要包含参数QOS,即RNC选定的QOS。
6.按权利要求1所述的方法,其特征在于还包括SGSN发起更新QOS的步骤:
(1)SGSN发起建立关联某一QOS的承载;
(2)SGSN发起删除关联某一QOS的承载。
7.按权利要求1所述的方法,其特征在于还包括GGSN发起更新QOS的步骤:
(1)GGSN发起建立关联某一QOS的承载;
(2)GGSN发起删除关联某一QOS的承载。
8.按权利要求6所述的方法,其特征在于所述的SGSN发起建立关联某一QOS的承载包括步骤:
(1)SGSN向GGSN发送MBMS承载建立请求消息,该消息包含参数ServiceID和QOS;
(2)GGSN向SGSN发送MBMS承载建立应答消息;
(3)GGSN向SGSN发送MBMS会话开始消息,该消息包含参数Service ID和QOS;
(4)SGSN向GGSN发送MBMS会话开始应答消息,该消息包含参数TEID和QOS。
9.如权利要求6所述的方法,其特征在于所述的SGSN发起建立关联某一QOS的承载包括步骤:
(1)SGSN向GGSN发送MBMS承载建立请求消息,该消息包含参数ServiceID,QOS及TEID;
(2)GGSN向SGSN发送MBMS承载建立应答消息。
10.如权利要求6所述的方法,其特征在于所述的SGSN发起删除关联某一QOS承载的方法包括步骤:
(1)SGSN向GGSN发送MBMS承载释放请求消息,该消息包含参数ServiceID,TEID,NSAPI;
(2)GGSN向SGSN发送MBMS承载释放应答消息。
10.按权利要求7所述的方法,其特征在于所述的GGSN发起建立关联某一QOS的承载包括步骤:
(1)GGSN向BM-SC发送承载建立请求消息,该消息包含参数Service ID和QOS;
(2)BM-SC向GGSN发送承载建立应答消息;
(3)BM-SC向GGSN发送会话开始消息,该消息包含参数Service ID和QOS;
(4)GGSN向BM-SC发送会话开始应答消息,该消息包含参数TEID和QOS。
11.按权利要求7所述的方法,其特征在于所述的GGSN发起建立关联某一QOS的承载包括步骤:
(1)GGSN向BM-SC发送承载建立请求消息,该消息包含参数Service ID,QOS及TEID;
(2)BM-SC向GGSN发送承载建立应答消息。
12.按权利要求7所述的方法,其特征在于所述的GGSN发起删除关联某一QOS的承载包括步骤:
(1)GGSN向BM-SC发送承载释放请求消息,该消息包含参数Service ID,TEID,NSAPI;
(2)BM-SC向GGSN发送承载释放应答消息。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA031438318A CN1581744A (zh) | 2003-07-31 | 2003-07-31 | 为mbms业务提供多种qos的方法 |
PCT/KR2004/001930 WO2005013514A1 (en) | 2003-07-31 | 2004-07-30 | Method of providing multiple qos for mbms service |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA031438318A CN1581744A (zh) | 2003-07-31 | 2003-07-31 | 为mbms业务提供多种qos的方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN1581744A true CN1581744A (zh) | 2005-02-16 |
Family
ID=34109566
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA031438318A Pending CN1581744A (zh) | 2003-07-31 | 2003-07-31 | 为mbms业务提供多种qos的方法 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN1581744A (zh) |
WO (1) | WO2005013514A1 (zh) |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2006045252A1 (fr) * | 2004-10-28 | 2006-05-04 | Huawei Technologies Co., Ltd. | Procede et systeme permettant de commander une session d'un service de diffusion/multidiffusion multimedia |
WO2007095855A1 (fr) * | 2006-02-23 | 2007-08-30 | Huawei Technologies Co., Ltd. | Procédé et entité réseau de négociation d'un paramètre de type média |
CN100435595C (zh) * | 2005-08-31 | 2008-11-19 | 上海贝尔阿尔卡特股份有限公司 | 支持MBMS QoS候选集的网络设备、用户设备及方法 |
CN100459797C (zh) * | 2005-07-05 | 2009-02-04 | 华为技术有限公司 | 无线接入网络中提供区别服务的实现方法 |
WO2009049529A1 (fr) * | 2007-10-11 | 2009-04-23 | Huawei Technologies Co., Ltd. | Procédé d'établissement de support de charge et dispositif associé |
CN1956451B (zh) * | 2005-10-28 | 2010-05-12 | 华为技术有限公司 | 一种实现多媒体广播/组播业务中会话开始的方法 |
CN101060416B (zh) * | 2006-04-21 | 2010-05-12 | 北京三星通信技术研究有限公司 | 建立和更新隧道传输的方法 |
CN101175297B (zh) * | 2006-10-31 | 2010-12-08 | 大唐移动通信设备有限公司 | 3g长期演进系统中多媒体广播业务的资源配置方法与系统 |
CN1964524B (zh) * | 2005-11-11 | 2011-04-06 | 上海贝尔阿尔卡特股份有限公司 | 基于mbms安全机制的bcast服务的业务保护和内容保护系统 |
CN101330648B (zh) * | 2007-09-19 | 2011-12-07 | 中兴通讯股份有限公司 | 恢复广播模式的多媒体广播组播业务的方法 |
CN101925136B (zh) * | 2007-10-11 | 2012-09-05 | 华为技术有限公司 | 承载建立方法及相关装置 |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2074842B1 (en) * | 2006-10-12 | 2018-10-03 | Telefonaktiebolaget LM Ericsson (publ) | Efficient mbms backbone distribution using one tunnel approach |
KR101203462B1 (ko) | 2006-10-27 | 2012-11-21 | 삼성전자주식회사 | 와이브로/와이맥스 망을 이용한 멀티캐스트/브로드캐스트서비스 제공 시스템 및 그 방법 |
JP4930516B2 (ja) | 2007-01-30 | 2012-05-16 | 日本電気株式会社 | 移動通信システム、マルチキャストデータ配信方法、コアネットワークノード、アクセスネットワークノード、および端末 |
EP2127428A1 (en) | 2007-03-22 | 2009-12-02 | Telefonaktiebolaget LM Ericsson (PUBL) | A system and method of reporting in-service performance statistics in layered networks |
CN101370174B (zh) * | 2007-08-13 | 2012-03-07 | 中兴通讯股份有限公司 | 长期演进架构下的多媒体广播多播业务接入方法 |
CN101378541B (zh) * | 2007-08-29 | 2011-11-30 | 中兴通讯股份有限公司 | 一种多媒体广播多播业务的动态信道分配方法 |
CN101631344B (zh) * | 2008-07-16 | 2011-10-05 | 华为技术有限公司 | 隧道管理方法、装置及通信系统 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020062379A1 (en) * | 2000-11-06 | 2002-05-23 | Widegren Ina B. | Method and apparatus for coordinating quality of service requirements for media flows in a multimedia session with IP bearer services |
US20030039232A1 (en) * | 2001-08-22 | 2003-02-27 | Alessio Casati | Method of sending a multicast message in such as a GPRS/UMTS network, and a mobile telecommunications network |
US6701155B2 (en) * | 2002-01-11 | 2004-03-02 | Nokia Corporation | Network initialized packet data protocol context activation for multicast/broadcast services |
-
2003
- 2003-07-31 CN CNA031438318A patent/CN1581744A/zh active Pending
-
2004
- 2004-07-30 WO PCT/KR2004/001930 patent/WO2005013514A1/en active Application Filing
Cited By (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2006045252A1 (fr) * | 2004-10-28 | 2006-05-04 | Huawei Technologies Co., Ltd. | Procede et systeme permettant de commander une session d'un service de diffusion/multidiffusion multimedia |
CN100459797C (zh) * | 2005-07-05 | 2009-02-04 | 华为技术有限公司 | 无线接入网络中提供区别服务的实现方法 |
CN100435595C (zh) * | 2005-08-31 | 2008-11-19 | 上海贝尔阿尔卡特股份有限公司 | 支持MBMS QoS候选集的网络设备、用户设备及方法 |
CN1956451B (zh) * | 2005-10-28 | 2010-05-12 | 华为技术有限公司 | 一种实现多媒体广播/组播业务中会话开始的方法 |
CN1964524B (zh) * | 2005-11-11 | 2011-04-06 | 上海贝尔阿尔卡特股份有限公司 | 基于mbms安全机制的bcast服务的业务保护和内容保护系统 |
CN101026614B (zh) * | 2006-02-23 | 2011-05-18 | 华为技术有限公司 | 一种媒体类型参数的协商方法 |
WO2007095855A1 (fr) * | 2006-02-23 | 2007-08-30 | Huawei Technologies Co., Ltd. | Procédé et entité réseau de négociation d'un paramètre de type média |
CN101060416B (zh) * | 2006-04-21 | 2010-05-12 | 北京三星通信技术研究有限公司 | 建立和更新隧道传输的方法 |
CN101175297B (zh) * | 2006-10-31 | 2010-12-08 | 大唐移动通信设备有限公司 | 3g长期演进系统中多媒体广播业务的资源配置方法与系统 |
CN101330648B (zh) * | 2007-09-19 | 2011-12-07 | 中兴通讯股份有限公司 | 恢复广播模式的多媒体广播组播业务的方法 |
WO2009049529A1 (fr) * | 2007-10-11 | 2009-04-23 | Huawei Technologies Co., Ltd. | Procédé d'établissement de support de charge et dispositif associé |
CN101409951B (zh) * | 2007-10-11 | 2010-08-25 | 华为技术有限公司 | 承载建立方法及相关装置 |
US8243675B2 (en) | 2007-10-11 | 2012-08-14 | Huawei Technologies Co., Ltd. | Method and system for setting up a bearer |
CN101925136B (zh) * | 2007-10-11 | 2012-09-05 | 华为技术有限公司 | 承载建立方法及相关装置 |
US8331306B2 (en) | 2007-10-11 | 2012-12-11 | Huawei Technologies Co., Ltd. | Method and system for setting up a bearer |
US8989116B2 (en) | 2007-10-11 | 2015-03-24 | Huawei Technologies Co., Ltd. | Method and system for setting up a bearer |
US9871678B2 (en) | 2007-10-11 | 2018-01-16 | Huawei Technologies Co., Ltd. | Method and system for setting up a bearer |
US10938601B2 (en) | 2007-10-11 | 2021-03-02 | Huawei Technologies Co., Ltd. | Method and system for setting up a bearer |
Also Published As
Publication number | Publication date |
---|---|
WO2005013514A1 (en) | 2005-02-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN1297126C (zh) | 在移动通信系统中建立信令连接的方法 | |
CN1284394C (zh) | 用于在移动通信系统中发送和接收控制消息的方法 | |
CN1268143C (zh) | 移动通信系统中多媒体广播/多播服务的设备和方法 | |
CN1581744A (zh) | 为mbms业务提供多种qos的方法 | |
CN1499760A (zh) | 多媒体广播与组播业务在Iu接口的信令承载连接方法 | |
CN1852551A (zh) | 基于移动网络的组播业务数据的实现方法 | |
CN1266898C (zh) | 一种实现多媒体广播/组播服务业务激活的方法 | |
CN1751458A (zh) | 在无线通信网络中用于支持无线终端的移动性的装置和方法 | |
CN1476198A (zh) | 利用小区广播的mbms的业务广告或业务指示的方法 | |
CN1476260A (zh) | 多媒体广播与组播业务点对点信道和点对多点信道的转换方法 | |
CN1620766A (zh) | 适用于在umts中的mbms数据预定发送的方法 | |
CN1592167A (zh) | 支持mbms后向兼容性的方法 | |
CN1684414A (zh) | 一种多媒体广播/组播业务的会话开始方法 | |
CN1748386A (zh) | 在多媒体广播/多播业务中管理用于寻呼用户设备的业务环境的方法 | |
CN1692578A (zh) | 发送反馈信息的上行链路公共信道 | |
CN101043755A (zh) | 移动通信系统中准入判断的方法、系统及装置 | |
CN1852500A (zh) | 一种即按即通系统及实现即按即通业务的方法 | |
CN1513274A (zh) | 无线网络系统及无线通信控制方法 | |
CN1859305A (zh) | 一种多媒体广播/组播业务中建立gtp隧道的方法 | |
CN100344095C (zh) | 一种集群语音业务的计费关联和计费管理方法 | |
CN101043431A (zh) | 一种缩短多方通话业务建立时间的方法与系统 | |
CN1856137A (zh) | 一种确定集中控制服务器的方法及系统 | |
CN1956451A (zh) | 一种实现多媒体广播/组播业务中会话开始的方法 | |
CN1956413A (zh) | 一种mbms中组播业务去激活的方法和系统 | |
CN1956450A (zh) | 一种实现多媒体广播/组播业务通知的方法及装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
WD01 | Invention patent application deemed withdrawn after publication |