专利名称：一种基于分组数据流计费的对话号分配方法
技术领域：
本发明涉及分组数据计费领域，特别是指一种基于分组数据流计费的对话号分配方法。
背景技术：
随着分组数据业务应用的逐渐广泛，如何准确合理地对分组数据业务进行计费，已成为运营商普遍关注的问题。
图1示出了分组数据协议上下文(PDP Context，Packet Data ProtocolContext)激活、数据传输、去激活流程图，如图1所示，在通用分组无线业务(GPRS，General Packet Radio Service)中，激活PDP Context、与外部分组数据网络(PDN，Packet Data Network)进行数据交互、去激活该PDPContext的实现过程包括以下步骤步骤101移动终端(MS)向服务通用分组无线业务支持节点(SGSN，Serving GPRS Support Node)发送PDP Context激活请求(Activate PDPContext Request)，该Activate PDP Context Request中携带有网络层业务访问点标识(NSAPI，Network Layer Service Access Point Identifier)、PDP类型、接入点名称(APN，Access Point Name)、要求的服务质量(QoS)参数、事务标识(TI，Transaction Identifier)等信息，其中，NSAPI在SGSN和网关通用分组无线业务支持节点(GGSN，Gateway GPRS Support Node)之间作为隧道标识(TID，Tunnel Identifier)的组成部分，用于标识PDPContext；PDP类型包括端对端协议(PPP，Peer-Peer Protocol)类型、网际协议(IP，Internet Protocol)类型等；APN可由MS向SGSN提供，SGSN根据APN寻址到相应GGSN，GGSN根据APN确定MS所要访问的外部网络，MS也可不向SGSN提供APN，此时，由SGSN根据MS用户的签约信息选择缺省的APN；QoS参数为MS指定的分组数据业务所要达到的质量要求；TI用于MS标识某个PDP context。
步骤102SGSN收到Activate PDP Context Request后，与MS进行安全性检查和加密，该步骤为可选步骤。
步骤103SGSN根据APN解析GGSN的地址信息，如果SGSN能够根据APN解析出GGSN的地址信息，则为PDP Context创建TEID，该TEID可为国际移动用户标识(IMSI，International Mobile Subscriber Identity)与NSAPI的组合，然后SGSN向GGSN发送PDP Context创建请求(Create PDPContext Request)，该PDP Context创建请求中携带有PDP类型、PDP地址、APN、QoS参数、TEID、选择模式等，其中，PDP地址可为MS的IP地址，为可选参数，PDP Context创建请求中可不携带PDP地址，此时，在后续的处理过程中，可由GGSN为MS分配IP地址，也可由最终与MS建立连接的PDN为MS分配IP地址；选择模式是指APN的选择模式，即APN是由MS选定的还是由SGSN选定的。如果SGSN无法根据APN解析出GGSN的地址信息，则SGSN拒绝MS发起的PDP Context激活请求。
步骤104GGSN收到PDP Context创建请求后，根据APN确定外部PDN，然后分配计费标识(Charging ID)、启动计费，并且协商QoS，如果GGSN能够满足QoS参数的服务质量要求，则向SGSN返回PDP Context创建响应(Create PDP Context Response)，该PDP Context创建响应中携带有TEID、PDP地址、链路承载(Backbone Bearer)协议、商定的QoS参数、Charging ID等信息。如果GGSN无法满足QoS参数的服务质量要求，则GGSN拒绝SGSN发起的PDP Context创建请求，然后SGSN拒绝MS发起的PDP Context激活请求。
步骤105SGSN收到PDP Context创建响应后，在PDP Context中插入用于标识PDP Context的NSAPI和GGSN地址信息，并根据商定的QoS参数选择无线优先权，然后向MS返回PDp Context激活响应(Activate PDPContext Accept)，该PDP Context激活响应中携带有PDP类型、PDP地址、TI、商定的QoS参数、无线优先权、PDP配置选项等信息。并且，SGSN启动计费。MS收到PDP Context激活响应，就已经建立了MS与GGSN直接的路由，可以进行分组数据的传输了。
步骤106MS通过SGSN、GGSN与PDN进行分组数据的交互。
步骤107结束分组数据交互后，MS向SGSN发送PDP Context去激活请求(Deactivate PDP Context Request)，该PDP Context去激活请求中携带有TI。
步骤108SGSN收到PDP Context去激活请求后，与MS进行安全性检查和加密，该步骤为可选步骤。
步骤109～步骤111SGSN向GGSN发送PDP Context删除请求(DeletePDP Context Request)，该PDP Context删除请求中携带有TEID。GGSN收到PDP Context删除请求后，结束对MS的计费，删除对应于TEID的PDPContext，然后向SGSN发送PDP Context删除响应(Delete PDP ContextResponse)，该PDP Context删除响应中携带有TEID。SGSN收到PDP Context删除响应后，结束对MS的计费，删除对应于TEID的PDP Context，然后向MS发送PDP Context去激活响应(Deactivate PDP Context Response)，该PDP Context去激活响应中携带有TI。MS收到PDP Context去激活响应后，删除对应于TI的PDP Context。
由图1描述的实现过程可见，当前的GPRS计费系统中，由于计费的起始点设置在PDP Context激活时，计费的终止点设置在PDP Context删除时，因此只能根据PDP Context传输的数据流量进行计费，或是根据PDP Context处于激活状态的时间长度进行计费。然而，在实际应用中，MS与PDN进行数据交互后，该MS可以基于一个激活的PDP Context进行多种业务，也就是说，如果PDN能够提供多种业务，如电子邮件(Email)收发业务、基于无线应用协议的(WAP，Wireless Application Protocol)的浏览业务、基于文件传输协议(FTP，File Transfer Protocol)的文件传输等业务，则MS在与该PDN建立传输通道后，可通过一个激活的PDP Context承载该PDN能够提供的各种业务。但是，运营商对于各种业务的计费模式很可能采用不同的计费方式，如对于Email收发业务可基于Email接收和发送事件的触发按次计费，对于WAP浏览业务可根据流量计费，对于文件传输业务也可根据流量计费，WAP浏览业务的费率与文件传输业务的费率却不尽相同，这样，根据现有的GPRS计费系统，根本无法对同一PDP Context承载的不同业务进行区分计费。
针对上述情况，第三代合作伙伴计划(3GPP，The 3rd GenerationPartnership Project)目前正在讨论如何实现基于IP数据流的计费(FBC，FlowBased Charging)。对于一个分组数据业务而言，MS的用户使用该业务时，传输和接收到的所有IP数据流(IP Flow)，也可为IP分组包(IP packet)，总称为业务数据流(Service Data Flow)，即业务数据流是多个IP数据流组成的集合，因此基于IP数据流的计费能够真实反映某个业务数据流对资源的占用情况。基于IP数据流的计费可被认为是通过一些类似筛子的过滤器将同一PDP Context中承载的不同业务的IP数据流分别筛选出来，然后针对不同过滤器过滤出的IP数据流进行分别计费，以达到对不同的业务数据流分别计费的目的。这样，基于IP数据流的计费粒度要远远小于基于一个PDPContext的计费粒度，粒度可看作是筛子孔的大小，基于一个PDP Context的计费粒度是一个PDP Context就是一个筛子孔，而基于IP数据流的计费粒度则是一个IP业务数据流则为一个筛子孔，即针对一个PDP Context中包含多个筛子孔，因此，基于IP数据流的计费与比基于一个PDP Context的计费相比，基于IP数据流的计费能够为运营商或业务提供者提供更为丰富的计费手段。
3GPP中对FBC的系统结构、功能要求以及消息交互流程等方面均进行了描述，支持在线计费的FBC系统结构如图2A所示，基于移动网络增强逻辑的客户化应用(CAMEL，Customised Application for Mobile NetworkEnhanced Logic)的业务控制点(SCP，Service Control Point)201和基于业务数据流计费的信用控制功能实体(CCF，Service Data Flow Based CreditControl Function)202组成了在线计费系统(OCS，Online Charging System)206。CCF 202通过Ry接口与基于业务数据流计费的计费规则功能实体(CRF，Service Data Flow Based Charging Rule Function)203互通，CRF 203通过Rx接口与应用功能实体(AF，Application Function)204互通，CRF 203通过Gx接口与传输面功能实体(TPF，Traffic Plane Function)205互通，CCF 202通过Gy接口与TPF 205互通。
支持离线计费的FBC系统结构如图2B所示，CRF 203通过Rx接口与AF 204互通，CRF 203通过Gx接口与TPF 205互通，TPF 205通过Gz接口分别与计费网关功能实体(CGF，Charging Gateway Function)207和计费采集功能实体(CCF，Charging Collection Function)208互通。
TPF 205承载IP数据流，当IP数据流的承载建立时，TPF 205通过Gx接口向CRF 203发送计费规则请求，该计费规则请求中携带有与用户和MS相关的信息、承载特性以及与网络相关的信息等，其中与用户和MS相关的信息可为移动台国际号码(MSISDN)、国际移动用户标识(IMSI)等，与网络相关的信息可为移动网络编码(MNC)、移动国家码(MCC)等。另外，由于在IP数据流传输过程中，会对承载进行修改，如对QoS参数进行重新协商，当用户使用同一业务的QoS参数不同时，计费规则可能不同，如QoS参数下降相应的费率也下降。此时，TPF 205可在承载修改时，重新向CRF 203发送计费规则请求，请求新的计费规则；CRF 203根据TPF 205提供的上述输入信息选择适当的计费规则，并向TPF 205返回选定的计费规则，计费规则中包括计费机制、计费类型、计费键、业务数据流过滤器、计费规则优先级等信息。其中，计费机制可为采用在线计费还是离线计费；计费类型可为基于时间长度进行计费还是基于数据流量进行计费；计费键是与计费费率相关的参数，CRF 203可不直接向TPF 205提供计费费率，而只是向TPF 205提供与计费费率相关的参数；业务数据过滤器用于指示TPF 205对哪些IP数据流进行过滤，然后TPF 205根据计费规则对过滤出的IP数据流进行计费。业务数据过滤器可包含IP5元组，IP5元组可包括源/目的IP地址、源/目的端口号(Port Number)、协议标识(Protocol ID)等信息，例如，CRF 203指示TPF 205对源地址为10.0.0.1、目的地址为10.0.0.2、源/目的端口号为20、协议类型为传输控制协议(TCP)的IP数据流进行过滤，并根据计费规则对过滤出的IP数据流进行计费。
CRF 203可向TPF 205提供触发事件(Event Trigger)，用以要求TPF 205在特定事件发生时，向CRF 205请求新的计费规则，如CRF 203要求TPF 205在某些承载进行修改的事件发生时，向CRF 203请求新的计费规则。
CRF 203除了根据TPF 205提供的输入信息选择适当的计费规则之外，CRF 203还可根据AF 204或OCS 206的输入信息选择适当的计费规则，如AF 204通知CRF 203用户当前使用的业务类型，CRF 203根据该业务类型选择相应的计费规则。
OCS 206由SCP 201和CCF(Service Data Flow Based Credit ControlFunction)202两个功能实体组成，其中，CCF(Service Data Flow Based CreditControl Function)202是执行信用控制的功能实体，仅应用于在线计费系统，可通过在现有的OCS 206中增加新的功能来实现。在在线计费过程中，CCF(Service Data Flow Based Credit Control Function)202对用户信用进行管理和控制，当用户使用业务时，CCF(Service Data Flow Based Credit ControlFunction)202对该用户信用池中的信用进行鉴权，并通过Gy接口向TPF 205下发用户能够使用的信用。
对应于GPRS网络，TPF 205为GGSN，AF为PDN中的一个业务网关或业务服务器，CRF 203为新增的逻辑实体。TPF 205为计费规则的执行点，CRF 203为计费规则的控制点。
目前，规范中定义了在CRF和TPF之间通过对话的方式进行通信，并且不同对话通过对话号进行标识，即当承载建立时，TPF向CRF请求计费规则，通过对话号标识TPF和CRF之间建立的对话。在后续承载修改、承载删除的过程中，TPF需要向CRF重新请求计费规则时，TPF通过对话号标识当前计费规则请求是基于先前建立的对话之间的对应关系；同样地，CRF需要主动向TPF提供计费规则时，如CRF收到AF或OCS提供的用于确定计费规则的输入信息，CRF也需要通过对话号标识当前提供的计费规则与先前建立的对话之间的对应关系。
在两个实体间建立对话的意义在于在两个实体间建立状态机，这样，两个实体在进行后续交互时可直接使用状态机中的数据，而无需在每次交互时都提供相关信息。例如，承载建立时，TPF需向CRF提供用户信息、承载属性、网络信息等相关信息，TPF与CRF之间建立对话后，TPF和CRF均会存储这些相关信息，在TPF与CRF之间后续的交互过程中，如承载修改、承载删除等过程，发送方无需再向接收方提供这些相关信息，而是仅仅提供对话号标识出相应的对话即可。
虽然规范中定义了在CRF和TPF之间通过对话的方式进行通信，但规范中并未指出用于标识对话的对话号是如何分配的，导致了现有流程在实现上的不确定性。
发明内容
有鉴于此，本发明的目的在于提供一种基于分组数据流计费的对话号分配方法，使得基于分组数据流计费的各流程的实现更为完整。
为了达到上述目的，本发明提供了一种基于分组数据流计费的对话号分配方法，该方法包含以下步骤A1、消息发送方分配对话号。
所述步骤A1之后进一步包括
B1、消息发送方向消息接收方提供分配的对话号。
所述消息发送方为TPF。
所述消息接收方为CRF，所述步骤B1为TPF向CRF提供分配的对话号，所述对话号携带在计费规则请求中。
所述步骤B1之后进一步包括CRF向TPF提供计费规则时，进一步向TPF提供所述对话号。
所述消息接收方为OCS，所述步骤B1为TPF向OCS提供分配的对话号，所述对话号携带在信用请求中。
所述步骤B1之后进一步包括CRF向TPF返回用户的信用时，进一步向TPF提供所述对话号。
所述步骤B1之后进一步包括消息发送方和消息接收方通过所述对话号，标识一次对话中消息发送方和消息接收方之间交互的信息。
本发明还提供了一种基于分组数据流计费的对话号分配方法，该方法包含A2、消息接收方分配对话号。
所述步骤A2之后进一步包括B2、消息接收方向消息发送方提供分配的对话号。
所述消息接收方为CRF。
所述消息接收方为CRF，所述步骤B2为CRF向TPF提供分配的对话号，所述对话号携带在提供计费规则的消息中。
所述消息接收方为OCS。
所述消息发送方为TPF，所述步骤B2为OCS向TPF提供分配的对话号，所述对话号携带在提供用户信用的消息中。
所述步骤B2之后进一步包括消息发送方和消息接收方通过所述对话号，标识一次对话中消息发送方和消息接收方之间交互的信息。
本发明又提供了一种基于分组数据流计费的对话号分配方法，该方法包含以下步骤A3、消息发送方分配第一部分对话号；B3、消息接收方分配第二部分对话号，所述第一部分对话号和第二部分对话号构成完整对话号。
所述步骤A3进一步包括消息发送方向消息接收方提供分配的第一部分对话号；所述步骤B3为消息接收方分配第二部分对话号，将分配的第二部分对话号与接收的第一部分对话号构成完整对话号。
所述步骤B3之后进一步包括C3、消息接收方向消息发送方提供完整对话号。
所述消息发送方为TPF，所述消息接收方为CRF，所述步骤A3为TPF向CRF提供分配的第一部分对话号，所述第一部分对话号携带在计费规则请求中。
所述步骤C3为CRF向TPF提供完整对话号，所述完整对话号携带在提供计费规则的消息中。
所述消息发送方为TPF，所述消息接收方为OCS，所述步骤A3为TPF向OCS提供分配的第一部分对话号，所述第一部分对话号携带在信用请求中。
所述步骤C3为OCS向TPF提供完整对话号，所述完整对话号携带在提供用户信用的消息中。
所述步骤C3之后进一步包括消息发送方和消息接收方通过所述对话号，标识一次对话中消息发送方和消息接收方之间交互的信息。
根据本发明，在基于分组数据流的计费中，明确了对话号的分配实体，通过对话号能够唯一标识消息发送方和消息接收方之间的对话，使得基于分组数据流计费的各流程的实现更为完整。并且，本发明中提供了多种对话号的分配方法，为实际应用提供了灵活的选择。
图1示出了PDP Context激活、数据传输、去激活流程图；图2A示出了支持在线计费的FBC系统结构图；图2B示出了支持离线计费的FBC系统结构图；图3示出了消息发送方分配对话号的过程示意图；图4示出了消息接收方分配对话号的过程示意图；图5示出了消息发送方和消息接收方共同分配对话号的过程示意图；图6示出了对话号的一种应用实例示意图；图7示出了对话号的另一种应用实例示意图。
具体实施例方式
为使本发明的目的、技术方案和优点更加清楚，下面结合附图对本发明作进一步的详细描述。
本发明中，在基于分组数据流计费的实现过程中，建立对话时，可由消息发送方分配对话号，然后提供给消息接收方；也可由消息接收方分配对话号，然后提供给消息发送方，两方之间后续的交互过程中，消息发送方和消息接收方使用分配的对话号标识二者之间一次对话中交互的信息。以上所述的消息发送方是指最初发送消息的一方。以上所述的消息发送方为TPF，消息接收方为CRF；或消息接收方为TPF，消息接收方为OCS，等等。
为保证分配的对话号的唯一性，分配的对话号可为分配对话号的网络实体的地址信息与随机数的组合，分配方的地址信息可为IP地址或七号信令网中网络实体的地址信息。
图3示出了消息发送方分配对话号的过程示意图，如图3所示，消息发送方分配对话号的实现过程包括以下步骤步骤301用户设备(UE)向TPF发送承载建立请求(Establish BearerService Request)，在GPRS网络中，则是GGSN收到Create PDP ContextRequest。
步骤302TPF收到承载建立请求后，为当前对话分配对话号，然后向CRF发送计费规则请求(Request Charging Rules)，该计费规则请求中携带有供CRF确定计费规则的输入信息和分配的对话号。
步骤303CRF收到计费规则请求后，根据该计费规则请求中携带的输入信息，还可根据AF提供的相关输入信息，如果为在线计费方式，也可根据OCS提供的相关输入信息，选择适当的计费规则。
步骤304CRF选择了适当的计费规则后，向TPF返回提供计费规则(Provision Charging Rules)，作为计费规则请求的响应，该提供计费规则中可携带有选定的计费规则、计费规则操作指示和TPF在步骤302中分配的对话号，通过该对话号标识当前计费规则响应与先前计费规则请求之间的对应关系。
步骤305TPF收到提供计费规则后，根据对话号索引到相应的对话，并根据计费规则操作指示对CRF选定的计费规则进行相应操作，如果为在线计费方式，则继续执行步骤306～步骤308，如果为离线计费方式，则直接执行步骤308。
步骤306TPF根据计费规则中的在线计费指示，为当前对话分配对话号，然后向OCS发送信用请求(Credit Request)，向OCS请求用户的信用信息。
步骤307OCS收到信用请求后，确定用户的信用，然后向TPF返回信用响应(Credit Response)，如果OCS确定出用户的信用，则该信用响应中携带有用户的信用和TPF在步骤306中分配的对话号；如果OCS未确定出用户的信用，则该信用响应中可携带有差错原因值和TPF在步骤306中分配的对话号，通过该对话号标识当前信用响应与先前信用请求之间的对应关系。
步骤308TPF向UE返回承载建立响应(Establish Bearer ServiceAccept)，如果TPF能够根据已有信息建立承载，如OCS返回了用户的信用，则该承载建立响应为承载建立成功响应，TPF接受UE发起的承载建立请求，并继续后续的承载建立流程；如果TPF无法根据已有信息建立承载，如OCS未返回用户的信用，则该承载建立响应为承载建立失败响应，TPF拒绝UE发起的承载建立请求。
图4示出了消息接收方分配对话号的过程示意图，如图4所示，消息接收方分配对话号的实现过程包括以下步骤步骤401与步骤301相同。
步骤402TPF收到承载修改请求后，向CRF发送计费规则请求，该计费规则请求中携带有供CRF确定计费规则的输入信息。
步骤403与步骤303相同。
步骤404CRF选择了适当的计费规则后，为当前对话分配对话号，向TPF返回提供计费规则，该提供计费规则中可携带有选定的计费规则、计费规则操作指示和分配的对话号。
步骤405与步骤305相同。
步骤406TPF根据计费规则中的在线计费指示，向OCS发送信用请求，向OCS请求用户的信用。
步骤407OCS收到信用请求后，确定用户的信用，并为当前对话分配对话号，然后向TPF返回信用响应，如果OCS确定出用户的信用，则该信用响应中携带有用户的信用和分配的对话号；如果OCS未确定出用户的信用，则该信用响应中可携带有差错原因值和分配的对话号。
步骤408与步骤308相同。
由于网络组网的原因，消息发送方和接收方可能不属于同一网络中，因此，发送方和接收方之间的对话号需要保证全球唯一，这样不同实体分配的对话号才不会重复，通信实体才能通过对话号正确索引到相应的对话。通常，消息发送方和接收方可通过在标识自身网络实体的地址信息上增加随机分配的序列号的方式进行对话号的分配，此时分配的对话号是全球唯一的。但是，由于用于标识网络实体地址的信息内容都比较多，如果以分配对话号的网络实体的地址信息作为对话号的一部分，则将使得对话号所含内容过多，而在每条传送的消息中都会携带对话号，可能会过多占用消息传送实体的资源，因此，可由消息发送方和消息接收方共同分配对话号，例如，消息发送方将分配的自身实体中能够唯一标识一次对话的标识信息作为部分对话号，填写在完整对话号的固定位置上，如当完整对话号为消息中的一个参数时，消息发送方固定地将分配的部分对话号填写在完整对话号参数的前3位；又如，当完整对话号为消息中的两个参数时，消息发送方将分配的部分对话号填写在消息中的消息发送方对话号参数上，然后向消息接收方提供其分配的部分对话号，消息接收方将分配的自身实体中能够唯一标识一次对话的标识信息作为部分对话号，填写在完整对话号的固定位置上，如当完整对话号为消息中的一个参数时，消息接收方固定地将分配的部分对话号填写在完整对话号参数的后3位；又如，当完整对话号为消息中的两个参数时，消息接收方将分配的部分对话号填写在消息中的消息接收方对话号参数上。通过消息发送方和消息接收方共同分配的部分对话号构成完整的对话号，用以在消息发送方和消息接收方之间传递，标识一次对话中消息发送方和消息接收方二者之间一次对话中交互的信息。
图5示出了消息发送方和消息接收方共同分配对话号的过程示意图，如图5所示，消息发送方和消息接收方共同分配对话号的实现过程包括以下步骤步骤501与步骤301相同。
步骤502TPF收到承载建立请求后，为当前对话分配部分对话号，然后向CRF发送计费规则请求，该计费规则请求中携带有供CRF确定计费规则的输入信息和分配的部分对话号。
步骤503与步骤303相同。
步骤504CRF选择了适当的计费规则后，为当前对话分配部分对话号，与TPF在步骤502中分配的部分对话号构成完整对话号，向TPF返回提供计费规则，该提供计费规则中可携带有选定的计费规则、计费规则操作指示和TPF与CRF共同分配的完整对话号。
步骤505与步骤305相同。
步骤506TPF为当前对话分配部分对话号，然后向OCS发送信用请求，向OCS请求用户的信用信息。
步骤507OCS收到信用请求后，确定用户的信用，并为当前对话分配部分对话号，与TPF在步骤306中分配的部分对话号构成完整对话号，然后向TPF返回信用响应，如果OCS确定出用户的信用，则该信用响应中携带有用户的信用和TPF与OCS共同分配的完整对话号；如果OCS未确定出用户的信用，则该信用响应中可携带有差错原因值和TPF与OCS共同分配的完整对话号。
步骤508与步骤308相同。
为描述方便，在以上每幅附图中将TPF与OCS之间分配对话号的方式，描述为与TPF与CRF之间分配对话号的方式相同，实际应用中，TPF与OCS之间分配对话号的方式与TPF与CRF之间分配对话号的方式无任何关系，可相同也可不同，均可任意选取具体的对话号分配方式。
图6示出了对话号的一种应用实例示意图，如图6所示，本实例中，承载修改时，可应用先前分配的对话号标识一次对话中消息发送方与消息接收方之间交互的信息，具体描述如下步骤601UE向TPF发送承载修改请求(Modify Bearer ServiceRequest)，在GPRS网络中，则是GGSN收到PDP Context更新请求(UpdatePDP Context Request)。
步骤602TPF收到承载修改请求后，向CRF发送计费规则请求，该计费规则请求中携带有供CRF确定计费规则的输入信息和先前分配的对话号，用以标识当前消息与先前建立的对话之间的对应关系。
步骤603～步骤604CRF收到计费规则请求后，根据该计费规则请求中携带的输入信息，还可根据AF提供的相关输入信息，选择适当的计费规则，然后向TPF返回提供计费规则，该提供计费规则中可携带有选定的计费规则、计费规则操作指示和相应对话号。
步骤605TPF收到提供计费规则后，根据对话号索引到相应的对话，并根据计费规则操作指示对CRF选定的计费规则进行相应操作，如果为在线计费方式，则继续执行步骤606～步骤608，如果为离线计费方式，则直接执行步骤608。
步骤606～步骤607TPF根据计费规则中的在线计费指示，向OCS发送信用控制请求(Credit Control Request)，向OCS请求用户的信用，该信用控制请求中携带有先前分配的对话号，用以标识当前消息与先前建立的对话之间的对应关系。OCS收到信用控制请求后，确定用户的信用，然后向TPF返回信用控制响应(Credit Control Response)，如果OCS确定出用户的信用，则该信用控制响应中携带有用户的信用和相应对话号，如果OCS未确定出用户的信用，则该信用控制响应中可携带有差错原因值和相应对话号。
步骤608TPF向UE返回承载修改响应(Modify Bearer Service Accept)，如果TPF能够根据已有信息对承载进行修改，如OCS返回了用户的信用，则该承载修改响应为承载修改成功响应，TPF接受UE发起的承载修改请求，并继续后续的承载修改流程；如果TPF无法根据已有信息对承载进行修改，如OCS未返回用户的信用，则该承载修改响应为承载修改失败响应，TPF拒绝UE发起的承载修改请求。
图7示出了对话号的另一种实例应用示意图，如图7所示，本实例中，CRF主动向TPF下发计费规则时，可应用先前分配的对话号标识一次对话中消息发送方与消息接收方之间交互的信息，具体描述如下
步骤701CRF收到某个内部或外部的触发事件(Internal or ExternalTrigger Event)，以及与该事件相关的信息，如AF向CRF发送计费规则选择输入信息的事件。
步骤702CRF根据获取的输入信息选择适当的计费规则。这些输入信息可为AF提供的计费相关输入信息，例如，用户使用AF提供的某一业务，该业务对计费有特殊要求，如计费费率与其他业务的计费费率不同，因此，AF向CRF提供与该业务相关的计费输入信息；也可为TPF提供的计费相关输入信息。
步骤703如果计费规则发生变化，CRF向TPF发送提供计费规则，该提供计费规则中可携带有选定的计费规则、计费规则操作指示和先前分配的对话号，用以标识当前消息与先前建立的对话之间的对应关系。
步骤704TPF收到提供计费规则后，根据对话号索引到相应的对话，并根据计费规则操作指示对CRF选定的计费规则进行相应操作，如果为在线计费方式，则继续执行步骤705～步骤706。
步骤705～步骤706TPF根据计费规则中的在线计费指示，向OCS发透信用请求，向OCS请求用户的信用信息，该信用请求中携带有先前分配的对话号，用以标识当前消息与先前建立的对话之间的对应关系。OCS收到信用请求后，确定用户的信用，然后向TPF返回信用响应，如果OCS确定出用户的信用，则该信用响应中携带有用户的信用和相应对话号，如果OCS未确定出用户的信用，则该信用响应中可携带有差错原因值和相应对话号。
总之，以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。
权利要求
1.一种基于分组数据流计费的对话号分配方法，其特征在于，该方法包含A1、消息发送方分配对话号。
2.根据权利要求1所述的方法，其特征在于，所述步骤A1之后进一步包括B1、消息发送方向消息接收方提供分配的对话号。
3.根据权利要求1或2所述的方法，其特征在于，所述消息发送方为TPF。
4.根据权利要求3所述的方法，其特征在于，所述消息接收方为CRF，所述步骤B1为TPF向CRF提供分配的对话号，所述对话号携带在计费规则请求中。
5.根据权利要求4所述的方法，其特征在于，所述步骤B1之后进一步包括CRF向TPF提供计费规则时，进一步向TPF提供所述对话号。
6.根据权利要求3所述的方法，其特征在于，所述消息接收方为OCS，所述步骤B1为TPF向OCS提供分配的对话号，所述对话号携带在信用请求中。
7.根据权利要求6所述的方法，其特征在于，所述步骤B1之后进一步包括CRF向TPF返回用户的信用时，进一步向TPF提供所述对话号。
8.根据权利要求2所述的方法，其特征在于，所述步骤B1之后进一步包括消息发送方和消息接收方通过所述对话号，标识一次对话中消息发送方和消息接收方之间交互的信息。
9.一种基于分组数据流计费的对话号分配方法，其特征在于，该方法包含A2、消息接收方分配对话号。
10.根据权利要求9所述的方法，其特征在于，所述步骤A2之后进一步包括B2、消息接收方向消息发送方提供分配的对话号。
11.根据权利要求9或10所述的方法，其特征在于，所述消息接收方为CRF。
12.根据权利要求11所述的方法，其特征在于，所述消息接收方为CRF，所述步骤B2为CRF向TPF提供分配的对话号，所述对话号携带在提供计费规则的消息中。
13.根据权利要求9或10所述的方法，其特征在于，所述消息接收方为OCS。
14.根据权利要求13所述的方法，其特征在于，所述消息发送方为TPF，所述步骤B2为OCS向TPF提供分配的对话号，所述对话号携带在提供用户信用的消息中。
15.根据权利要求10所述的方法，其特征在于，所述步骤B2之后进一步包括消息发送方和消息接收方通过所述对话号，标识一次对话中消息发送方和消息接收方之间交互的信息。
16.一种基于分组数据流计费的对话号分配方法，其特征在于，该方法包含以下步骤A3、消息发送方分配第一部分对话号；B3、消息接收方分配第二部分对话号，所述第一部分对话号和第二部分对话号构成完整对话号。
17.根据权利要求16所述的方法，其特征在于，所述步骤A3进一步包括消息发送方向消息接收方提供分配的第一部分对话号；所述步骤B3为消息接收方分配第二部分对话号，将分配的第二部分对话号与接收的第一部分对话号构成完整对话号。
18.根据权利要求17所述的方法，其特征在于，所述步骤B3之后进一步包括C3、消息接收方向消息发送方提供完整对话号。
19.根据权利要求18所述的方法，其特征在于，所述消息发送方为TPF，所述消息接收方为CRF，所述步骤A3为TPF向CRF提供分配的第一部分对话号，所述第一部分对话号携带在计费规则请求中。
20.根据权利要求19所述的方法，其特征在于，所述步骤C3为CRF向TPF提供完整对话号，所述完整对话号携带在提供计费规则的消息中。
21.根据权利要求18所述的方法，其特征在于，所述消息发送方为TPF，所述消息接收方为OCS，所述步骤A3为TPF向OCS提供分配的第一部分对话号，所述第一部分对话号携带在信用请求中。
22.根据权利要求21所述的方法，其特征在于，所述步骤C3为OCS向TPF提供完整对话号，所述完整对话号携带在提供用户信用的消息中。
23.根据权利要求18所述的方法，其特征在于，所述步骤C3之后进一步包括消息发送方和消息接收方通过所述对话号，标识一次对话中消息发送方和消息接收方之间交互的信息。
全文摘要
本发明公开了一种基于分组数据流计费的对话号分配方法，该方法包含消息发送方分配对话号；或消息接收方分配对话号；或消息发送方分配第一部分对话号，消息接收方分配第二部分对话号，所述第一部分对话号和第二部分对话号构成完整对话号。所述消息发送方为TPF，消息接收方为CRF；或消息接收方为TPF，消息接收方为OCS等等。两方之间后续的交互过程中，消息发送方和消息接收方使用分配的对话号标识二者之间一次对话中交互的信息。根据本发明提出的方法，明确了对话号的分配实体，通过对话号能够唯一标识消息发送方和消息接收方之间的对话，使得基于分组数据流计费的各流程的实现更为完整。
文档编号H04L12/14GK1735021SQ20041005842
公开日2006年2月15日 申请日期2004年8月11日 优先权日2004年8月11日
发明者段小琴 申请人:华为技术有限公司