CN101345903B - Umts或gprs通信网络告知业务平台当前无线承载信息的方法 - Google Patents
Umts或gprs通信网络告知业务平台当前无线承载信息的方法 Download PDFInfo
- Publication number
- CN101345903B CN101345903B CN 200710043755 CN200710043755A CN101345903B CN 101345903 B CN101345903 B CN 101345903B CN 200710043755 CN200710043755 CN 200710043755 CN 200710043755 A CN200710043755 A CN 200710043755A CN 101345903 B CN101345903 B CN 101345903B
- Authority
- CN
- China
- Prior art keywords
- qos
- ggsn
- application server
- user
- report
- 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.)
- Active
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
一种UMTS或GPRS网络告知业务平台当前无线承载信息的方法，GGSN通过已经建立的TCP或UDP连接告知业务平台服务器当前连接的QoS信息即无线承载速率信息，为业务平台实时地根据无线承载速率调整业务编码速率创造条件。所述方法在GGSN节点新增四个处理流程，(A)QoS初始报告程序流程、(B)QoS更新报告流程、(C)QoS报告链路删除用户流程、(D)删除QoS报告链路流程。本发明的优点是核心网GGSN可以第一时间将QoS的变化情况告知业务平台服务器，实时性较好；SGSN发给GGSN的QoS参数包含了网络分配的无线承载速率，业务平台服务器无需再作估计，准确度高，效果好；对终端无附加的软硬件要求，满足相关业务普及的需求；不针对特定业务平台，适用范围广；无线承载无需传输附加信息，为业务的传输增加了资源。
Description
技术领域
本发明涉及移动通信技术领域，特别涉及一种UMTS或GPRS通信网络告知业务平台当前无线承载信息的方法。
技术背景
随着移动通信技术的发展，无线信道的承载能力越来越强，以前无法提供的多媒体业务成为了当今业务发展的热点。
然而，由于移动网络用户位置的不确定性，带来了无线信道环境的复杂性(信号传播路径、阻挡情况、干扰情况的变化)。移动网络会根据无线信道链路质量的变化情况，相应地改变承载速率，以达到节约网络资源开销的目的。这种网络资源的分配策略具备较多的合理性，但同时也给多媒体业务带来了不稳定的因素。这是因为多媒体业务采用一定的编码速率进行业务编码，如果业务使用过程中，无线信道的承载速率发生变化，则无法保证业务编码速率与承载速率的匹配。以流媒体业务为例，如果将高编码速率的业务发送给低承载速率的网络，就会造成业务停顿现象，从而影响用户的业务感受；而将低编码速率的业务发送给高承载速率的网络，就不能充分利用网络资源，造成浪费。因此，只有让业务平台实时的知晓无线信道的承载速率，选择编码速率与之相匹配的业务，才能使网络资源得到最有效的利用，同时使业务效果达到最优。
目前的一些标准和技术方法提出了一些解决方案，但都不能彻底的实现上述目标。
3GPP R6版本的TS26.234标准中对流媒体业务RTSP协议的SETUP及PLAY request消息定义了3GPP-Link-Char头信息，携带业务相关的PDP上下文所预设的保证带宽(GBW)、最大带宽MBW、最大传输时延MTD等QoS参数。客户端向服务器上报SETUP及PLAY request消息，告知服务器当前会话所使用的无线链路服务质量。服务器可以根据这些参数来设置业务编码速率和链路响应。在会话期间，若PDP上下文发生更新，即QoS参数有所改变，客户端则将通过SET_PARAMETER或OPTIONS request消息，携带〃3GPP-Link-Char〃头信息，以告知服务器当前会话的无线链路服务质量变化情况。该方案存在以下缺点：
1.该方案针对使用RTSP协议的流媒体业务，应用范围有限。
2.需要客户端具备相应的软件功能，即将PDP上下文中的QoS参数用RSTP协议的相关消息告知服务。
3.根据TS.23.060标准中的定义，业务建立时，无线承载与核心网络的QoS都由SGSN协商决定；业务进行中，发生RAB修改后，即无线承载速率变化后，无论是终端或网络发起业务请求，都由SGSN来初始化PDP上下文的修改流程。按此流程，终端将在核心网之后完成PDP上下文的修改，然后再由终端发起RTSP协议消息，告知服务器无线承载的变化情况。这样必然给服务器准备业务造成一定的时延，影响用户的业务感受。目前业内另一种解决方案是利用RTCP协议来进行承载速率的估计。该方案提出可以利用终端周期性上报的RTCP RR包，服务器根据RTCP RR包中的fraction lost(相邻的RTCP RR包之间的丢包数)和interarrival jitter(RTP数据包网络抖动时间)来判定承载速率和业务速率的匹配情况。如果丢包和抖动高于某个预设门限，则说明网络速率低于业务速率，需要降低业务速率；如果丢包和抖动低于某个预设门限，则说明网络速率高于业务速率，可以提高业务速率。该方案的缺点有以下几点：
1.该方案针对使用RTCP协议的业务，应用范围有限。
2.需要终端周期性上报RTCP RR包，占用了额外的无线信道资源和终端处理开销。上报周期短则资源开销大，留给业务使用的资源相应减少；上报周期长，则服务器不能及时掌握无线承载的速率情况，无法对业务速率进行及时地调整。
3.服务器不直接获知无线承载速率，采用间接估计，准确度不高。
发明内容
本发明的目的是针对已有技术中存在的缺陷，提供一种UMTS或GPRS通信网络告知业务平台当前无线承载信息的方法。基于核心网信令，向业务平台告知UMTS和GSM网络无线承载实时速率，业务平台根据网络当前的无线承载速率及时地调整业务速率。本发明的方法GGSN(网关GPRS支持节点)通过已经建立的TCP(传输控制协议)或UDP(用户数据报协议)连接告知业务平台服务器当前连接的QoS(服务质量参数)信息即无线承载速率信息，其特征在于所述方法在GGSN节点新增四个处理流程，(A)QoS初始报告程序流程、(B)QoS更新报告流程、(C)QoS报告链路删除用户流程、(D)删除QoS报告链路流程。所述(A)QoS初始报告程序流程包括下列步骤：
(101)GGSN收到GTP-U-UNIT-DATA.request信息；
(102)GGSN判断业务数据中DestinationIP Address是否属于QoS报告签约服务器地址；
(103)GGSN根据GTP-U-UNIT-DATA.request信息的TEID找到对应的PDPContext；
(104)判断PDP Context中是否存在Destination IP Address对应的Appl icationServer地址；
(105)在PDP Context中添加Application Server地址；
(106)判断是否存在QoS报告连接；
(107)建立QoS报告链路；
(108)在QoS报告链路的用户清单中添加用户；
(109)发送QoS报告；
(110)回到GGSN现有GTP-U-UNIT-DATA.request处理流程。所述(B)QoS更新报告流程包括下列步骤：
(201)GGSN收到SGSN发来的Update PDP Context request信息；
(202)根据TEID找到PDP Context，查找Application Server地址；
(203)判断是否存在Application Server地址；
(204)通过QoS报告链路向业务平台的应用服务器发送QoS报告；
(205)回到GGSN现有的Update PDP Context request信息处理流程。所述(C)QoS报告链路删除用户流程包括下列步骤：
(301)用户终端结束该平台的业务；
(302)业务平台通过QoS报告链路向GGSN发送删除用户信息；
(303)GGSN在收到删除用户消息后，根据消息中的MSISDN找到该用户的PDPContext；
(304)GGSN根据消息中的Application Server Address删除PDP Context中的Application Server Address：
(305)在GGSN的该QoS报告链路的用户清单中删除该用户。
所述(D)删除QoS报告链路流程包括下列步骤：
(401)GGSN收到SGSN的Delete PDP Context Request消息；
(402)GGSN根据TEID找到PDP Context，然后在查找Application Server Address；
(403)在Application Server Address对应的QoS报告链路用户清单中删除该用户；
(404)判断GGSN的QoS报告链路用户清单中用户数是否为零；
(405)释放该QoS报告链路；
(406)回到GGSN现有的Delete PDP Context Request消息处理流程。
所述方法根据3GPP R4及后续版本TS.23.060标准中的定义，分组业务建立和进行时，无线承载与核心网络的QoS都由SGSN协商决定，SGSN会及时地使用GTP协议消息CREATE PDP CONTEXT或UPDATE PDP CONTEXT通知GGSN。只要GGSN及时地将PDP上下文的QoS变化情况通知业务平台，就可为业务平台实时地根据无线承载速率调整业务编码速率创造条件。
GGSN与业务平台服务器建立TCP或UDP的连接，用于QoS信息的实时传送。GGSN一旦收到SGSN发出的UPDATE PDP CONTEXT消息，就使用任何一种常用的通信协议(如SIP或FTP或HTTP等协议)，通过已经建立的TCP或UDP连接告知业务平台服务器当前连接的QoS信息即无线承载速率信息。
本发明的优点是：
1、核心网SGSN、GGSN较终端先知晓PDP上下文的QoS参数，即无线承载的速率。GGSN可以第一时间将QoS的变化情况告知业务平台服务器，实时性较好。
2、SGSN发给GGSN的QoS参数包含了网络分配的无线承载速率，业务平台服务器无需再作估计，准确度高，效果好。
3、对终端无附加的软硬件要求，满足相关业务普及的需求。
4、不针对特定业务平台，适用范围广。
5、无线承载无需传输附加信息，为业务的传输增加了资源，以达到节约网络资源，改善用户业务感受的效果。
附图说明
图1已有技术中的UMTS网络PDP Context激活流程；
图2已有技术中的GPRS网络PDP Context激活流程；
图3已有技术中的UMTS网络SGSN发起的初始PDP Context修改流程；
图4已有技术中的终端发起业务请求的流程；
图5已有技术中的GTP-U的用户面协议栈；
图6本发明中的QoS初始报告消息流程；
图7本发明中的QoS初始报告程序流程；
图8本发明中的QoS更新报告消息流程；
图9本发明中的QoS更新报告程序流程；
图10本发明中的QoS报告链路删除用户消息流程；
图11本发明中的QoS报告链路删除用户程序流程；
图12本发明中的释放QoS报告链路消息流程；
图13本发明中的释放QoS报告链路程序流程；
具体实施方式
实施例一
本发明通过对SGSN与GGSN间GTP消息的处理，得到目前网络为用户终端分配的QoS参数(含无线承载速率)。通过建立GGSN与业务平台服务器间的连接，将当前的QoS参数传送给业务平台服务器。业务平台根据无线承载速率进行业务编码速率选择等工作，从而使业务内容和承载速率达到匹配，获得最佳的网络资源利用率和用户业务感受。
根据3GPP TS23.060标准的定义，在建立分组数据业务时，SGSN会使用Create PDPContext消息告诉GGSN当前网络为用户分配的QoS Profile。在无线承载建立后，SSGN会用Update PDP Context消息告诉GGSN当前无线网接入网与核心网协商后的QoSProfile。图1为UMTS网络中该流程的描述，图2为GPRS网络中该流程的描述。
在分组数据业务使用过程中，无论是发生用户发起的PDP Context修改，还是网络侧SGSN或GGSN发起的PDP Context修改；无论修改原因是移动性管理的切换还是O&M，都由SGSN初始PDP Context修改流程。在修改流程中，SGSN会先向GGSN发起Update PDPContext，然后再向用户终端发起Modify PDP Context。图3为UMTS网络SGSN初始PDPContext修改流程的描述。
因此，按照3GPP TS23.060标准的定义，GGSN会在用户终端之前知道网络分配和修改的PDP Context内容。
另外，依据3GPP TS23.060标准的定义，GGSN在PDP Context建立后，GGSN中就保存了PDP Context的相关数据，详见下列表1：
表1 GGSN PDP上下文
| 域 | 描述 |
| IMSI | 国际移动用户识别号(Intemational Mobile Subscriber Identity.) |
| NSAPI | 网络层业务接入点识别号(Network layer Service Access Point Identifier.) |
| MSISDN | 移动用户基本的ISDN号(The basic MSISDN ofthe MS.) |
| PDP Type | PDP类型，例如PPP或IP(PDP type；e.g.PPP or IP.) |
| PDP Address | PDP地址，例如IP地址(PDP address；e.g.an IP address.) |
| Dynamic Address | 指示PDP地址是静态地址还是动态地址(Indicates whether PDP Address isstatic or dynamic.) |
| APN in Use | 当前使用的APN(The APN Network Identifier currently used.) |
| TEID | 隧道端点识别号(Tunnel Endpoint Identifier.) |
| TFT | 传输流量模版(Traffic flow template.) |
| QoS ProfileNegotiated | 协商后的服务质量概况(The quality of service profile negotiated.) |
| SGSN Address | 为当前用户提供服务SGSN的地址(The IP address ofthe SGSN currentlyservingthis MS.) |
| MNRG | 指示移动用户是否在HLR中被标记为分组域不可达(Indicates whether theMS is marked as not reachable for PS at the HLR.) |
| Recovery | 指示SGSN是否正在执行数据库恢复(Indicates ifthe SGSN is performingdatabase recovery.) |
| GTP-SND | 下一个发送给SGSN的下行N-PDU的GTP-U序列号(GTP-U sequencenumber ofthe next downlink N-PDU to be sent to the SGSN.) |
| GTP-SNU | 下一个从SGSN接收的上行N-PDU的GTP-U序列号(GTP-U sequencenumber ofthe next uplink N-PDU to be receivedfrom the SGSN.) |
| Charging Id | SGSN和GGSN产生计费记录的识别号(Charging identifier，identifiescharging records generated by SGSN and GGSN.) |
| ChargingCharacteristics | PDP上下文的计费特征(例如标准的、预付费、统一费率、热计费等)The charging characteristicsfor this PDP context，e.g.normal，prepaid，flat-rate，and/orhot billing. |
| Trace Reference | 识别记录或采集纪律用于跟踪的参考号(Identifies a record or a collectionof records for a particular trace.) |
| Trace Type | 指示跟踪的类型(Indicates the type oftrace.) |
| Trigger Id | 启动跟踪实体的识别号(Identifies the entity that initiated the trace.) |
| OMC Identity | 接收跟踪记录的OMC识别号(Identifies the OMC that shall receive the tracerecord(s).) |
| Prohibit PayloadCompression | 指示SGSN将协商不对PDP上下文进行数据压缩(Indicates that the SGSNshould negotiate no data compression for this PDP context.) |
| SGSN support forCGI/SAI/RAIchange reporting | 指示SGSN支持CGI/SAI/RAI改变报告流程(Indicated that the SGSNserving the MS supports procedures for reporting CGI/SAI/RAI changesaccording to clause15.1.1a.) |
| CGI/SAI/RAIChange ReportRequired | 指示SGSN是否可以被请求在发送给GGSN的PDP上下文中携带CGI/SAIor RAI的变化信息(Denotes whether the SGSN is requested to sendchanges in CGI/SAI or RAI to the GGSN associated with this PDP Context.) |
| BCM | 协商后的承载控制模式(The negotiated Bearer Control Mode.) |
| DTI | 指示SGSN是否可以建立当前PDP上下文在RNC和GGSN间的直传用户面(Indicates whether SGSN has established direct user plane tunnel betweenRNC and GGSN for this PDP Context.) |
表1中的QoS Profile Negotiated是当前无线网接入网与核心网协商后的QoS Profile，包含了当前承载速率的配置信息，详见表2：
表2 QoS Profile Negotiated的字段
| 域 | 描述 |
| Traffic class | 用于UMTS承载业务优化的应用类型，例如会话类、流类、交互类、背景类(type of application for which the UMTS bearer service isoptimised.e.g.conversational＇or＇streaming＇or＇interactive＇or＇background＇) |
| Maximum bitrate | 在一个SAP一个时间周期内最大传输比特数(maximum number ofbitsdelivered by UMTS and to UMTS at a SAP within a period of time，divided by the duration of the period.) |
| Delivery order | 指示UMTS承载是否可以提供SDU按序发送(indicates whether theUMTS bearer shall provide in-sequence SDU delivery or not.) |
| Maximum SDU size | 网络可以满足的协商后QoS的最大SDU尺寸(the maximumSDU sizefor which the network shall satisfythe negotiated QoS.) |
| SDU formatinformation | SDU准确尺寸的清单(list ofpossible exact sizes of SDUs) |
| SDU error ratio | 指示有部分的SDU丢失或出错，SDU错误率仅为传输而定义(Indicatesthe fraction of SDUs lost or detected as erroneous.SDU error ratio isdefined onlyfor conforming traffic.) |
| Residual bit errorratio | 指示未检测SDU传输中出错比特。如果没有要求错误检测，则残留比特错误率指示SDU传输中的比特错误率(Indicates the undetected biterror ratio in the delivered SDUs.If no error detection is requested，Residual bit error ratio indicates the bit error ratio in the deliveredSDUs.) |
| Delivery oferroneous SDUs | 指示在已检测到SDU出错后是否继续发送或放弃(Indicates whetherSDUs detected as erroneous shall be delivered or discarded.) |
| Transfer delay | 指示一个承载业务的生命期内所有SDU传输时延中95％时延的最大值，时延定义为从一个SAP请求SDU传输到另一个SAP收到(Indicatesmaximum delay for95th percentile of the distribution of delay for alldelivered SDUs during the lifetime of a bearer service，where delay foran SDU is defined as the time from a request to transfer an SDU at oneSAP to its delivery at the other SAP.) |
| Guaranteed bit rate | 一个时间周期内UMTS在一个SAP上保证的传输比特数(guaranteednumber ofbits delivered by UMTS at a SAP within a period of time(provided that there is data to deliver)，divided by the duration of theperiod.) |
| Traffic handlingpriority | 指定UMTS承载的SDU与其它承载SDU的相对重要性(specifies therelative importance for handling of all SDUs belonging to the UMTSbearer compared to the SDUs of other bearers.) |
| Allocation/Retention priority | 指定与其他UMTS承载在承载分配和保持上的相对重要性。分配和保持优先级是一个签约属性，不需要与终端协商，并且SGSN或GGSN可以改变该属性值。specifies the relative importance compared to otherUMTS bearers for allocation and retention of the UMTS bearer.TheAllocation/Retention Priority attribute is a subscription attribute which isnot negotiated from the mobile terminal，but the value might be changedeither by the SGSN or the GGSN network element. |
表2中Maximum bit rate为最大的承载速率、Guaranteed bit rate为保证的承载速率、Transfer delay为传输时延。
为了实现本发明的功能，需要对GGSN内的PDP Context进行字段的新增，增加Application Server Address，Application Server Address可设置多个，以满足用户终端一个PDP Context连接多个业务平台的需求，详见表3：
表3 GGSN PDP上下文新增字段
| Field | Description |
| Application Server l Address | 应用平台1的IP地址(The Application Server1Address；e.g.an IP Address) |
| Application Server n Address | 应用平台N的IP地址(The Application Server nAddress；e.g.an IP Address) |
在PDP Context建立后，用户终端会进入初始业务请求流程，见图4。用户终端通过Upiink PDU流程将业务数据上传至GGSN，由GGSN进行业务数据的转发。Uplink PDU流程采用GTP-U协议，GTP-U协议分为控制面消息和用户面消息。SGSN使用用户面消息GTP-U-UNIT-DATA.request向GGSN上传业务数据。根据3GPP TS23.060定义的协议栈结构，GGSN会对GTP-U的业务数据进行解析，获取业务数据的Destination IP Address，即是业务平台应用服务器的IP地址，见图5。这个IP地址和GTP-U消息中的TEID是本发明的两个重要参数。TEID在一次PDP Context中是唯一的，即可以用TEID将同一PDPContext的GTP-C和GTP-U消息关联起来。
为实现本发明的功能，需在GGSN节点新增四个处理流程。第一个处理流程是QoS初始报告流程，消息流程见图6，程序流程见图7。
QoS初始报告程序流程包含以下步骤内容：
101：GGSN收到GTP-U-UNIT-DATA.request消息。
102：GGSN判断GTP-U-UNIT-DATA.request消息的业务数据中Destination IP Address是否属于GGSN内的QoS报告签约服务器列表中的Gateway Server address，GGSN内的QoS报告签约服务器列表格式见表7。如果不属于，则转到110；如果属于，则找到对应的Application Server Address并转到103。
103：GGSN根据GTP-U-UNIT-DATA.request消息的TEID找到对应的PDP Context。
104：GGSN查看该Destination IP Address对应的Appl ication Server Address是否存在于PDP Context中。如果存在，则转到110；如果不存在，则转到105。
105：将GTP-U-UNIT-DATA.request消息中业务数据的Destination IP Address对应的Application Server Address添加到对应PDP Context中的Appl ication ServerAddress中。
106：判断是否存在QoS报告连接，如果是不存在，则执行步骤107，如果存在，则执行步骤108。
107：GGSN建立与业务平台应用服务器的QoS报告链路，然后执行108。
108：在GGSN的QoS报告链路的用户清单中添加用户。该表格为本发明的内容，需要在GGSN中新增。详见表4：
表4 QoS报告链路用户清单格式
| Field | Description |
| Link ID | QoS报告链路识别号(QoS Report Link Identify) |
| Application Server Address | 应用平台的IP地址(The Application Server IP Address) |
| MSISDN | 移动用户的ISDN号(The basic MSISDN ofthe MS.) |
109：GGSN通过QoS报告链路发送QoS报告给业务平台应用服务器。
QoS报告格式详见表5：
表5 QoS报告的消息格式
| Field | Description |
| MSISDN | 移动用户的ISDN号(The basic MSISDN ofthe MS.) |
| PDP Type | PDP类型(PDP type；e.g.PPP orIP.) |
| PDP Address | PDP地址(PDP address；e.g.an IP address.) |
| QoS Profile Negotiated | 协商后的业务质量概况(The quality of service profilenegotiated.) |
110：回到GGSN现有的GTP-U-UNIT-DATA.request消息处理流程。
第二个流程是QoS更新报告流程，消息流程见图8，程序流程见图9。程序流程的具体步骤内容如下：
201：GGSN收到SGSN发来的Update PDP Context request消息。
202：根据TEID找到PDP Context，查找Application Server地址。
203：判断是否存在Application Server地址，如果存在则转到204，如果不存在则转到步骤205。
204：通过QoS报告链路向业务平台的应用服务器发送QoS报告。
205：回到GGSN现有的Update PDP Context request消息处理流程。
第三个流程是QoS报告链路删除用户流程，消息流程见图10，程序流程见图11。程序流程具体步骤内容如下：
301：用户终端结束该平台的业务。
302：业务平台通过QoS报告链路向GGSN发送删除用户消息，消息格式详见表6：
表6 QoS报告链路删除用户的消息格式
| Field | Description |
| Application Server Address | 应用平台的IP地址(The Application Server IP Address) |
| MSISDN | 移动用户的ISDN号(The basic MSISDN ofthe MS.) |
| Reason | 删除用户的原因(The Reason ofDelete SubscriberOperation) |
303：GGSN在收到删除用户消息后，根据消息中的MSISDN找到该用户的PDP Context。
304：GGSN根据消息中的Application Server Address删除PDP Context中的ApplicationServer Address。
305：在GGSN的该QoS报告链路的用户清单中删除该用户。
第四个流程是删除QoS报告链路流程，消息流程见图12，程序流程见图13。程序流程具体步骤内容如下：
401：GGSN收到SGSN的Delete PDP Context Request消息。
402：GGSN根据TEID找到PDP Context，然后在查找Application Server Address。
403：在Application Server Address对应的QoS报告链路用户清单中删除该用户。
404：判断GGSN的QoS报告链路用户清单中用户数是否为0，如果否则转到406，如果是则转到步骤405。
405：释放该QoS报告链路。
406：回到GGSN现有的Delete PDP Context Request消息处理流程。
Claims (1)
1.一种UMTS或GPRS通信网络告知业务平台应用服务器当前无线承载信息的方法，GGSN(网关GPRS支持节点)通过已经建立的TCP(传输控制协议)或UDP(用户数据报协议)连接告知业务平台应用服务器当前连接的QoS(服务质量)信息及无线承载速率信息，其特征在于所述方法在GGSN节点新增四个处理流程，(A)QoS初始报告程序流程、(B)QoS更新报告流程、(C)QoS报告链路删除用户流程、(D)删除QoS报告链路流程，所述(A)QoS初始报告程序流程包括下列步骤：
(101)GGSN收到GTP-U-UNIT-DATA.request信息；
(102)GGSN判断GTP-U-UNIT-DATA.request信息的业务数据中Destination IP Address是否属于QoS报告签约服务器地址，如果不属于，则转到110，如果属于；则找到对应的Application Server地址并转到103；
(103)GGSN根据GTP-U-UNIT-DATA.request信息的TEID找到对应的PDP Context；
(104)判断PDP Context中是否存在Destination IP Address对应的Application Server地址，如果存在，则转到110，如果不存在，则转到105；
(105)在PDP Context中添加Application Server地址；
(106)判断是否存在QoS报告连接，如果是不存在，则执行步骤107，如果存在，则执行步骤108；
(107)GGSN建立与业务平台应用服务器的QoS报告链路；
(108)在QoS报告链路的用户清单中添加用户；
(109)发送QoS报告；
(110)回到GGSN现有GTP-U-UNIT-DATA.request处理流程；
所述(B)QoS更新报告流程包括下列步骤：
(201)GGSN收到SGSN发来的Update PDP Context request信息；
(202)根据TEID找到PDP Context，查找Application Server地址；
(203)判断是否存在Application Server地址，如果存在则转到204，如果不存在则转到步骤205；
(204)通过QoS报告链路向业务平台应用服务器发送QoS报告；
(205)回到GGSN现有的Update PDP Context request信息处理流程；
所述(C)QoS报告链路删除用户流程包括下列步骤：
(301)用户终端结束该业务平台应用服务器的业务；
(302)业务平台应用服务器通过QoS报告链路向GGSN发送删除用户信息；
(303)GGSN在收到删除用户消息后，根据消息中的MSISDN找到该用户的PDP Context；
(304)GGSN根据消息中的Application Server地址删除PDP Context中的Application Server地址；
(305)在GGSN的该QoS报告链路的用户清单中删除该用户；
所述(D)删除QoS报告链路流程包括下列步骤：
(401)GGSN收到SGSN的Delete PDP Context Request消息；
(402)GGSN根据TEID找到PDP Context，然后再查找Application Server地址；
(403)在Application Server地址对应的QoS报告链路用户清单中删除该用户；
(404)判断GGSN的QoS报告链路用户清单中用户数是否为零，如果否，则转到406，如果是，则转到步骤405；
(405)释放该QoS报告链路；
(406)回到GGSN现有的Delete PDP Context Request消息处理流程。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN 200710043755 CN101345903B (zh) | 2007-07-13 | 2007-07-13 | Umts或gprs通信网络告知业务平台当前无线承载信息的方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN 200710043755 CN101345903B (zh) | 2007-07-13 | 2007-07-13 | Umts或gprs通信网络告知业务平台当前无线承载信息的方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101345903A CN101345903A (zh) | 2009-01-14 |
| CN101345903B true CN101345903B (zh) | 2012-12-05 |
Family
ID=40247770
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN 200710043755 Active CN101345903B (zh) | 2007-07-13 | 2007-07-13 | Umts或gprs通信网络告知业务平台当前无线承载信息的方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101345903B (zh) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101990325B (zh) * | 2009-07-31 | 2013-04-24 | 华为技术有限公司 | 确定及维护多跳网络服务质量参数的方法、装置和系统 |
| CN102594694B (zh) * | 2012-03-06 | 2016-01-06 | 北京中创信测科技股份有限公司 | 数据分流方法和设备 |
| CN104618967B (zh) * | 2015-01-30 | 2018-06-05 | 上海华为技术有限公司 | 一种通信方法、相关装置和系统 |
| CN109561473B (zh) * | 2017-09-25 | 2021-01-15 | 华为技术有限公司 | 一种通信资源的释放方法及装置、非暂态计算机存储介质 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1705296A (zh) * | 2004-05-28 | 2005-12-07 | 华为技术有限公司 | 一种保证业务服务质量的数据包传输方法 |
| CN1859212A (zh) * | 2006-03-15 | 2006-11-08 | 华为技术有限公司 | 一种由网络控制服务质量请求的方法 |
-
2007
- 2007-07-13 CN CN 200710043755 patent/CN101345903B/zh active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1705296A (zh) * | 2004-05-28 | 2005-12-07 | 华为技术有限公司 | 一种保证业务服务质量的数据包传输方法 |
| CN1859212A (zh) * | 2006-03-15 | 2006-11-08 | 华为技术有限公司 | 一种由网络控制服务质量请求的方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN101345903A (zh) | 2009-01-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1258152B1 (en) | Method of call control to minimize delays in launching multimedia or voice calls in a packet-switched radio telecommunications network | |
| CN102223663B (zh) | 一种获取网络负荷的方法及系统 | |
| US7574196B2 (en) | Method and a system for charging a streaming connection in a mobile packet radio system | |
| EP1332627B1 (en) | Method and apparatus for coordinated charging of services in a multimedia session | |
| US6854014B1 (en) | System and method for accounting management in an IP centric distributed network | |
| US8301114B2 (en) | Offline charging for sessions over a 3GPP network and a WLAN access network | |
| EP1382214B1 (en) | Binding information for ip media flows | |
| US7889662B2 (en) | Charging in telecommunications network | |
| US20060168303A1 (en) | Method and apparatus for coordinating charging for services provided in a multimedia session | |
| CN101715182B (zh) | 一种流量控制方法、系统和设备 | |
| US8867471B2 (en) | Method, device, and system for reporting radio access network element information | |
| KR20100131000A (ko) | Ｌｔｅ／ｅｐｃ 통신 네트워크 및 그 네트워크에서의 차징 수행 방법 | |
| WO2009024048A1 (en) | A method, network system, pdn gw and accounting system for managing accounting | |
| EP1642425A1 (en) | Data transfer optimization in packet data networks | |
| CN103119981A (zh) | 服务质量控制方法和设备 | |
| US7286475B2 (en) | GPRS system and in-zone node apparatus, and bearer setting method used therefor | |
| CN101345903B (zh) | Umts或gprs通信网络告知业务平台当前无线承载信息的方法 | |
| US20070195801A1 (en) | Context-based processing of data flows | |
| US20050169191A1 (en) | Accounting system and method based on network service quality in a mobile communication system | |
| WO2010066157A1 (zh) | 计费方法、计费装置、计费网关和计费系统 | |
| KR100812676B1 (ko) | 이동통신 시스템에서의 컨텐츠별 과금 데이터 생성 방법 | |
| CN100433890C (zh) | 应用动态业务质量控制的移动数据业务实现方法 | |
| Ouyang et al. | An analysis of traffic and throughput for UMTS packet core networks | |
| CN102223619A (zh) | 一种漫游场景下的资源策略决策方法和系统 | |
| EP1832042B1 (en) | Method for providing a bearer service to a mobile station in a telecommunications system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant |