CN101043504A - 网络侧服务流的创建、删除和更改的方法 - Google Patents
网络侧服务流的创建、删除和更改的方法 Download PDFInfo
- Publication number
- CN101043504A CN101043504A CN 200610058593 CN200610058593A CN101043504A CN 101043504 A CN101043504 A CN 101043504A CN 200610058593 CN200610058593 CN 200610058593 CN 200610058593 A CN200610058593 A CN 200610058593A CN 101043504 A CN101043504 A CN 101043504A
- Authority
- CN
- China
- Prior art keywords
- request
- data channel
- sfm
- service flow
- resource request
- 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.)
- Granted
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
本发明公开了一种网络侧服务流的创建方法,该方法包括:在锚服务流授权实体Anchor SFA决定进行网络侧服务流的创建后,网络侧执行:Anchor SFA向服务流管理实体SFM发送资源请求及相关参数,SFM决定准入后向移动台MS发起服务流创建请求,MS保留相关参数后向SFM返回动态服务流创建响应消息;SFM向Anchor SFA发送资源请求响应;该方法进一步包括:Anchor SFA向SFM发送数据通道建立请求及相关参数,网络中各节点将根据所述参数建立数据通道;SFM向Anchor SFA返回数据通道建立请求响应消息,Anchor SFA向SFM发送确认消息;SFM向MS发送服务流创建确认信息。同时本发明还公开了一种网络侧服务流的删除及更改方法。
Description
●技术领域:
本发明涉及无线城域网中服务流技术领域,尤其涉及一种网络侧服务流的创建、删除和更改的方法。
●背景技术:
微波接入全球网络(WiMAX)是一种基于IEEE 802.16标准的无线城域网技术。WiMAX网络逻辑架构如图1所示,主要由三个部分组成即客户端(MSS/SS)、接入业务网(ASN)和连接业务网(CSN)包括策略服务器(PF)、认证、授权和计费服务器(AAA Server)、应用服务器(AF)等等逻辑实体。目前正在制定中的WiMAX标准草案定义的QoS参考模型如下图2所示。
其中SFM是位于ASN中负责服务流的准入控制、创建、激活、修改和删除的服务流管理实体,由准入控制AC和与AC相关联的本地资源信息库组成。SFA是位于ASN中的服务流授权实体,主要是对申请的服务流进行认证和授权动作。每个MS/SS只对应一个AnchorSFA,Anchor SFA负责和PF之间的交互。与SFM直接交互的SFA称之为Serving SFA。Serving SFA与Anchor SFA可能是同一个实体,当它们不是同一实体时,在它们之间可能还存在多个SFA,用于RelayQoS相关的原语。这些SFA称为Relay SFA。Serving SFA与Anchor SFA在任何时候必须是相互知晓的。Anchor SFA根据本地策略数据库LPD执行ASN级别的策略管理。AF是位于归属NSP中的应用服务实体。MS/SS通过应用层协议与AF直接交互。AF可以向PF发起WiMAX服务流请求,以触发PF向ASN发送资源预留请求(RR-Request)。PF是位于归属NSP中的策略服务实体。与之相关联的还有用户信息库,其中包含允许接入的服务策略和相应预制的QoS参数。
网络侧业务流创建包含预制流创建和其它网络侧应用服务流创建。共同点都是由网络侧发起,面向用户创建服务流。现有的标准草案中网络侧服务流创建流程如图3所示。
网络侧服务流创建过程通过资源预留消息(RR)完成,对应的空口消息为动态服务流创建消息(DSA-Request/Reponse/Acknowledge)。但是这个过程完成后,仅仅建立了空口连接,ASN网络内的数据通道(Data Path)并未建立,业务还无法正常传输。
由上述可以看出,现有的标准草案中网络侧服务流创建过程不完整,无法实现数据传输,而且现有的标准草案中对网络侧服务流的更改和删除也没有给出具体实施过程。
●发明内容:
有鉴于此,本发明的主要目的在于提供一种网络侧服务流的创建、删除和更改的方法,该方法包括:
一种网络侧服务流的创建方法,在锚服务流授权实体Anchor SFA决定进行网络侧服务流的创建后,网络侧执行:
资源请求过程:Anchor SFA向服务流管理实体SFM发送资源请求及相关参数,SFM决定准入后向移动台MS发起服务流创建请求,MS保留相关参数后向SFM返回动态服务流创建请求响应消息;
资源请求响应过程:SFM向Anchor SFA发送资源请求响应;
其中,该方法进一步包括:
如果数据通道还未建立,或数据通道是基于服务流的,则需要数据通道建立请求过程:Anchor SFA向SFM发送数据通道建立请求及相关参数,网络中各节点将根据所述参数建立数据通道;
数据通道建立请求响应过程:SFM向Anchor SFA返回数据通道建立请求响应消息,Anchor SFA向SFM发送确认消息;
空口确认过程:SFM向MS发送服务流创建确认信息。
其中,所述资源请求过程、资源请求响应过程、数据通道建立请求过程、数据通道建立请求响应过程和空口确认过程依次独立执行。
其中,所述资源请求过程、空口确认过程、资源请求响应过程、数据通道建立请求过程和数据通道建立请求响应过程依次独立执行。
其中,首先同时执行所述资源请求过程和所述数据通道建立请求过程,然后同时执行所述资源请求响应过程和所述数据通道建立请求响应过程,最后执行空口确认。
其中,所述资源请求过程和数据通道建立请求过程同时执行具体为:
SFM收到来自Anchor SFA的包括资源请求、数据通道建立请求及相关参数的流请求后,保存其中有关数据通道建立的信息,根据所述参数和本地准入策略向移动台MS发起服务流创建请求,MS保留相关参数后向SFM返回动态服务流创建请求响应消息。
其中,所述资源请求响应过程和数据通道建立请求响应过程同时执行具体为:
SFM将数据通道建立请求响应消息、资源请求响应及相关参数一起作为流请求响应返回Anchor SFA,Anchor SFA向SFM返回流确认信息。
其中,首先同时执行所述资源请求过程和所述数据通道建立请求过程,然后执行空口确认,最后同时执行所述资源请求响应过程和所述数据通道建立请求响应过程。
其中,所述资源请求过程和数据通道建立请求过程同时执行具体为:
SFM收到来自Anchor SFA的包括资源请求、数据通道建立请求及相关参数的流请求后,保存其中有关数据通道建立的信息,根据所述参数和本地准入策略向移动台MS发起服务流创建请求DSA-Request,MS保留相关参数后向SFM返回动态服务流创建请求响应消息。
其中,所述资源请求响应过程和数据通道建立请求响应过程同时执行具体为:
SFM将数据通道建立请求响应消息、资源请求响应及相关参数一起作为流请求响应返回Anchor SFA,Anchor SFA向SFM返回流确认信息。
其中,该方法包括:
资源请求过程:Anchor SFA向服务流管理实体SFM发送资源请求及相关参数,SFM收到资源请求后根据所述参数和本地准入策略向移动台MS发起服务流删除请求,MS保留相关参数后向SFM返回动态服务流删除请求响应消息;
资源请求响应过程:SFM向Anchor SFA发送资源请求响应;
空口确认过程:SFM向MS发送服务流删除确认信息。
其中,该方法进一步包括:
如果数据通道是基于服务流创建的,或没有其它服务流使用,则需要进行数据通道删除请求过程:Anchor SFA向SFM发送数据通道删除请求及相关参数,网络中各节点将根据所述参数删除数据通道;
数据通道删除请求响应过程:SFM向Anchor SFA返回数据通道删除响应消息,Anchor SFA向SFM发送确认消息。
其中,所述资源请求过程、资源请求响应过程、数据通道删除请求过程、数据通道删除请求响应过程和空口确认过程依次独立执行。
其中,所述资源请求过程、空口确认过程、资源请求响应过程、数据通道删除请求过程和数据通道删除请求响应过程依次独立执行。
其中,首先同时执行所述资源请求过程和所述数据通道删除请求过程,然后同时执行所述资源请求响应过程和所述数据通道删除请求响应过程,最后执行空口确认。
其中,所述资源请求过程和数据通道删除请求过程同时执行具体为:
SFM收到来自Anchor SFA的包括资源请求、数据通道删除请求及相关参数的流请求后,保存其中有关数据通道删除的信息,根据所述参数和本地准入策略向移动台MS发起服务流删除请求,MS保留相关参数后向SFM返回动态服务流删除响应消息。
其中,所述资源请求响应过程和数据通道删除请求响应过程同时执行具体为:
SFM将数据通道删除请求响应消息、资源请求响应及相关参数一起作为流请求响应返回Anchor SFA,Anchor SFA向SFM返回流确认信息。
其中,首先同时执行所述资源请求过程和所述数据通道删除请求过程,然后执行空口确认,最后同时执行所述资源请求响应过程和所述数据通道删除请求响应过程。
其中,所述资源请求过程和数据通道删除请求过程同时执行具体为:
SFM收到来自Anchor SFA的包括资源请求、数据通道删除请求及相关参数的流请求后,保存其中有关数据通道删除的信息,根据所述参数和本地准入策略向移动台MS发起服务流删除请求,MS保留相关参数后向SFM返回动态服务流删除响应消息。
其中,所述资源请求响应过程和数据通道删除请求响应过程同时执行具体为:
SFM将数据通道删除请求响应消息、资源请求响应及相关参数一起作为流请求响应返回Anchor SFA,Anchor SFA向SFM返回流确认信息。
其中,该方法包括:
Anchor SFA向服务流管理实体SFM发送资源请求及相关参数,SFM收到资源请求后根据所述参数和本地准入策略向移动台MS发起服务流更改请求;
SFM收到来自MS的服务流更改请求响应后,向Anchor SFA发送资源请求响应;
SFM向MS发送服务流更改确认信息。
其中,该方法进一步包括:
Anchor SFA向服务流管理实体SFM发送资源请求及相关参数,SFM收到资源请求后根据所述参数和本地准入策略向移动台MS发起服务流更改请求;
SFM收到来自MS的服务流更改响应后,向MS发送服务流更改确认信息;
SFM向Anchor SFA发送资源请求响应。
可见,采用本发明提供的方法不仅在现有标准草案基础上,提供了一种网络侧服务流的创建、删除和更改的方法。可以在服务流创建后即可实现数据传输,而且在此基础上提供了一种网络侧服务流更改和删除的具体实施过程,大大体高了对网络侧服务流操作的灵活性。
●附图说明:
图1是WiMAX网络逻辑架构图
图2是WiMAX中的QoS参考模型
图3是现有草案中的网络侧服务流创建流程
图4a是本发明中服务流创建方式1中上行业务流程图。
图4b是本发明中服务流创建方式1中下行业务流程图。
图5是本发明中服务流创建方式2的流程图。
图6a是本发明中服务流创建方式3中上行业务流程图。
图6b是本发明中服务流创建方式3中下行业务流程图。
图7是本发明中服务流创建方式4的流程图。
图8a是本发明中服务流删除方式1中下行业务流程图。
图8b是本发明中服务流删除方式1中上行业务流程图。
图9是本发明中服务流删除方式2的流程图。
图10a是本发明中服务流删除方式3中下行业务流程图。
图10b是本发明中服务流删除方式3中上行业务流程图。
图11是本发明中服务流删除方式4的流程图。
图12a是本发明中服务流更改方式1中上行业务流程图。
图12b是本发明中服务流更改方式1中下行业务流程图。
图13是本发明中服务流更改方式2中流程图。
●具体实施方式:
本发明提供了一种网络侧服务流的创建、删除和更改的方法,该方法基于WiMAX网络标准草案中定义的对服务质量(QoS,Quality ofService)参考模型。当网络侧发起动态业务增加(DSA)、动态业务变更(DSC)和动态业务删除(DSD)这样的服务流管理请求时,该方法不仅在现有标准草案的基础上,使动态业务增加(DSA)创建过程更加完整,而且还提供了动态业务变更(DSC)和动态业务删除(DSD)的完整过程。头压缩参数和资源预留类型参数是本发明中的两个重要参数。
1.头压缩参数用于支持用户与网络通信时的数据压缩算法。具体实现技术包括PHS(参见IEEE 802.16d/e)、ROHC(参见RFC3095)、ECRTP(参见RFC3545)这三种压缩技术。具体压缩技术的选择在MS入网时与网络侧协商决定,服务流创建时携带的头压缩参数应包含响应压缩技术要求的参数集。
2.资源预留类型参数用于支持RSVP协议。如果MS与网络侧协商结果支持RSVP,则在服务流创建时携带的资源预留类型参数应包含RSVP协议要求的参数集。
下面结合附图对本发明作进一步的详细说明。
实施例1:
本实施例根据待创建业务流的方向决定R1和R6接口的建立顺序。当业务流为上行方向时,先建R6接口再建R1接口,流程参加图4a;当业务流为下行方向时,先建R1接口再建R6接口,流程参见图4b。
网络侧服务流创建过程包括:
步骤401:
锚服务流授权实体(Anchor SFA)在移动台(MS)入网注册完成后,网络侧会进行服务流的创建。当网络侧通过V/H PF向Anchor SFA发出资源请求,或者Anchor SFA自己决定进行服务流的创建,将触发网络侧服务流的创建过程。网络侧服务流创建被触发后,服务流请求通过V/H-PF向Anchor SFA发起,或服务流请求直接由Anchor SFA发起。Anchor SFA应用本地策略并向SFM发起服务流请求消息,消息中携带资源请求的QoS参数集、头压缩规则参数、资源预留类型参数等相关参数和创建请求信息。如果服务流请求是从V/H-PF发起的,则这些参数从PF下发,Anchor SFA保存相应参数。
步骤402:
Serving SFA收到资源请求消息后,根据其应用服务策略决定是否满足资源请求。如果不满足,则直接向Anchor SFA返回资源请求响应消息,消息中携带失败结果,结束创建过程;否则,根据资源请求消息中的参数要求预留资源,并保存相应参数。然后向服务流管理实体(SFM)发送资源请求消息。
步骤403:
SFM收到资源请求消息后,应用本地准入策略并向MS发起动态服务流创建请求(DSA请求),消息中携带QoS参数集、头压缩规则参数和资源预留类型参数,MS保存相应参数
步骤404:
MS收到DSA请求消息,保存相应的QoS参数、SFID、CID和头压缩参数,然后向SFM返回动态服务流创建请求响应消息(DSA请求响应),其中携带创建结果。
步骤405:
SFM收到DSA请求响应后,如果请求创建的业务流是下行方向则如图4b所示,直接向MS发起动态服务流确认(DSA确认)消息,完成空口创建,然后再向网络侧发起资源请求响应;如果请求创建的业务流是上行方向则如图4a所示,直接向网络侧的Serving SFA发起Resource-Response,该消息中携带资源请求的结果。
步骤406:
Serving SFA向Anchor SFA返回资源请求响应,其中携带资源请求的结果。
步骤407:
当Anchor SFA收到资源请求响应消息,如果服务流请求由V/H-PF发起,则还需由Anchor SFA将该消息发送到V/H-PF,消息中携带资源请求结果和相应参数。然后判断如果数据通道是否是基于服务流的或数据通道还未建立,是则向SFM发起数据通道建立过程;否则还需判断业务流是否是上行方向,如果是还需向MS发起DSA确认,完成R1接口创建。数据通道建立过程由Anchor SFA向Serving SFA发起。
步骤408:
Serving SFA向SFM转发数据通道建立请求消息。消息其中携带通道的相关信息。
步骤409:
当SFM收到数据通道建立请求消息后,向Serving SFA返回数据通道建立请求响应消息,其中携带数据通道建立结果。
步骤410:
Serving SFA收到数据通道建立请求响应消息后再转发给AnchorSFA。
步骤411:
Anchor SFA收到数据通道建立请求响应消息后,如果创建成功则向Serving SFA发送数据通道确认消息,否则释放之前分配的资源。
步骤412:
Serving SFA向SFM转发数据通道确认消息。此时R6接口数据通道就建立好了。
步骤413:
SFM收到数据通道确认后,完成了R6接口创建。如果业务流是上行方向,SFM还需向MS发送DSA确认消息,完成R1接口建立。
实施例2:
本实施例从实现的角度考虑,通常R1接口建立的时间较长,那么可以先建R1接口,再建R6接口。此时如果业务是上行方向且R1接口先建立完成,则BS需要缓存来自MS的数据直到R6接口建立完成,流程参见图5,网络侧服务流创建过程包括:
步骤501~步骤504的执行顺序和步骤401~步骤404的执行顺序相同,这里不再重复。
步骤505:
SFM收到DSA请求响应后,向MS发送动态服务流确认消息(DSA确认),以完成空口建立。
步骤506~步骤513的执行过程和步骤405~步骤412的执行过程一样,这里不再重复。
实施例3:
本实施例根据待创建业务流的方向决定R1和R6接口的建立顺序。当业务流为上行方向时,先建R6接口再建R1接口,流程参加图6a;当业务流为下行方向时,先建R1接口再建R6接口,流程参见图6b,网络侧服务流创建过程包括:
步骤601:
锚服务流授权实体(Anchor SFA)在移动台(MS)入网注册完成后,网络侧会进行服务流的创建。当网络侧通过V/H PF向Anchor SFA发出流请求,或者Anchor SFA自己决定进行服务流的创建,将触发网络侧服务流的创建过程。网络侧服务流创建被触发后,流请求通过V/H-PF向Anchor SFA发起,或服务流请求直接由Anchor SFA发起。Anchor SFA应用本地策略并向SFM发起服务流请求消息,消息中携带资源预留请求的QoS参数集、头压缩规则参数、资源预留类型参数和创建请求等相关信息。如果流请求是从V/H-PF发起的,则这些参数从PF下发,Anchor SFA保存相应参数。同时Anchor SFA还要判断数据通道是否是基于服务流的或数据通道还未建立,如果是则向SFM发起数据通道建立过程,Anchor SFA向SFM发起的流请求消息中则将同时携带数据通道的相应参数,用于数据通道的建立。
步骤602:
Serving SFA收到流请求消息后,根据其应用服务策略决定是否满足资源请求。如果不满足,则直接向Anchor SFA返回流请求响应消息,消息中携带失败结果,结束创建过程;否则,根据流请求消息中的参数要求预留资源、建立数据通道,并保存相应参数。然后向服务流管理实体(SFM)发送流请求消息。
步骤603:
SFM收到流请求消息后,应用本地准入策略并向MS发起动态服务流创建请求(DSA请求),消息中携带QoS参数集、头压缩规则参数和资源预留类型参数,MS保存相应参数
步骤604:
MS收到DSA请求消息,保存相应的QoS参数、SFID、CID和头压缩参数,然后向SFM返回动态服务流创建请求响应消息(DSA请求响应),其中携带创建结果。
步骤605:
SFM收到DSA请求响应后,如果请求创建的业务流是下行方向则如图6b所示,直接向MS发起动态服务流确认(DSA确认)消息,完成空口创建,然后再向网络侧发起资源请求响应;如果请求创建的业务流是上行方向则如图6a所示,直接向网络侧的Serving SFA发起资源请求响应,该消息中携带资源请求的结果。
步骤606:
Serving SFA向Anchor SFA返回流请求响应,其中携带资源预留和数据通道建立的结果。
步骤607:
当Anchor SFA收到流请求响应,如果流请求由V/H-PF发起,则流请求响应还需由Anchor SFA发送到V/H-PF,消息中携带资源预留结果和相应参数,然后V/H-PF向Anchor SFA返回流确认消息(Flow确认);否则直接由Anchor SFA向Serving SFA返回Flow确认。
步骤608:
Serving SFA收到Flow确认消息后向SFM发送Flow确认消息。
步骤609:
SFM收到Flow确认消息后还再向MS发起动态服务流确认(DSA确认)消息,完成空口创建。
实施例4:
本实施例从实现的角度考虑,通常R1接口建立的时间较长,那么是否先建R1接口,再建R6接口。此时如果业务是上行方向且R1接口先建立完成,则BS需要缓存来自MS的数据直到R6接口建立完成,流程参见图7,网络侧服务流创建过程包括:
步骤701~步骤704的执行过程和步骤601~步骤604的执行过程一样,这里不再重复了。
步骤705:
SFM收到DSA请求响应后,向MS发送动态服务流确认消息(Flow确认),以完成空口建立。
步骤706~步骤709的执行过程和步骤605~步骤608的执行过程一样,这里不再重复。
实施例5:
本实施例根据待删除业务流的方向决定R1和R6接口的删除顺序。当业务流为下行方向时,先删R6接口再删R1接口,流程参加图8a;当业务流为上行方向时,先删R1接口再删R6接口,流程参见图8b,网络侧服务流删除过程包括:
步骤801~步骤804的执行顺序与步骤401~步骤404的执行顺序相同,只是请求/响应消息中携带参数不同,执行的功能也不同,但流程是一样的,这里将不再重复。
步骤805:
SFM收到DSD请求响应后,如果请求删除的业务流是上行方向则如图8b所示,直接向MS发起动态服务流删除确认(DSD确认),完成空口删除,然后再向网络侧发起资源请求响应;如果请求删除的业务流是下行方向则如图8a所示,直接向网络侧的Serving SFA发起资源请求响应,该消息中携带资源请求的结果。
步骤806~步骤813的执行顺序和步骤406~步骤413的执行顺序相同,只是请求/响应消息中携带参数不同,执行的功能也不同,但流程是一样的,这里将不再重复。另外,在步骤807中,当Anchor SFA收到资源请求响应之后(如果还需向PF发送资源请求响应,则在这之后),判断如果数据通道是否是基于服务流的或已无其它服务流使用,是则向SFM发起数据通道删除过程
实施例6:
本实施例从实现的角度考虑,通常R1接口删除的时间较长,那么是否先删R1接口,再删R6接口。参见图9,网络侧服务流删除过程包括:
步骤901~步骤904的执行顺序与步骤801~步骤802的执行顺序相同,这里将不再重复。
步骤905:
SFM收到DSD请求响应后,SFM向MS发起DSD确认完成空口删除。
步骤906~步骤913的执行顺序和步骤806~步骤813的执行顺序相同,这里将不再重复。
实施例7:
本实施例根据待删除业务流的方向决定R1和R6接口的删除顺序。当业务流为下行方向时,先删R6接口再删R1接口,流程参见图10a;当业务流为上行方向时,先删R1接口再删R6接口,流程参见图10b,网络侧服务流删除过程包括:
步骤1001~步骤1004的执行顺序和步骤601~步骤604的执行顺序是相同的,只是请求/响应消息中携带参数不同,执行的功能也不同,但流程是一样的,这里将不再重复。另外,在步骤1001在AnchorSFA发起流请求时,判断如果数据通道是否是基于服务流的或已无其它服务流使用,是则向SFM发起数据通道删除过程,在流请求消息中携带数据通道删除所需的信息。
步骤1005:
SFM收到DSD请求响应后,如果该业务流是上行方向,则SFM向MS发起DSD确认完成空口删除,然后再向网络侧发起流请求响应,参见图10b;如果该业务流是下行方向,则SFM直接向网络侧发起流请求响应,参见图10a。
步骤1006~步骤1009的执行顺序和步骤606~步骤609的执行顺序是相同的,只是请求/响应消息中携带参数不同,执行的功能也不同,但流程是一样的,这里将不再重复。
实施例8
本实施例从实现的角度考虑,通常R1接口删除的时间较长,那么是否先删R1接口,再删R6接口,流程参见图11,网络侧服务流删除过程包括:
步骤1101~步骤1104的执行顺序与步骤1001~步骤1004的执行顺序相同,这里将不再重复。
步骤1105:
SFM收到DSD请求响应后,SFM向MS发送动态服务流确认消息(DSD确认),以完成空口删除。
步骤1106~步骤1109的执行顺序和步骤1006~步骤1009的执行顺序相同,这里将不再重复。
实施例9:
本实施例根据待更改业务流的方向决定R1和R6接口的更改顺序。当业务流为上行方向时,先更改R6接口再更改R1接口,流程参加图12a;当业务流为下行方向时,先更改R1接口再更改R6接口,流程参见图12b,网络侧服务流更改过程包括:
步骤1201~步骤1204的执行顺序和步骤401~步骤404的执行顺序是一样的,只是消息中携带的参数不同,执行的功能不同,但流程是一样的,这里不再重复。
步骤1205:
SFM收到DSC-Response后,如果请求更改的业务流是下行方向则如图12b所示,直接向MS发起动态服务更改流确认(DSC确认)消息,完成空口更改,然后再向网络侧发起资源请求响应;如果请求更改的业务流是上行方向则如图12a所示,直接向网络侧的ServingSFA发起资源请求响应,该消息中携带资源请求的结果。
步骤1206:
Serving SFA将资源请求响应转发给Anchor SFA。
步骤1206:
SFM向MS发送服务流更改确认信息(DS确认)。
实施例10:
本实施例从实现的角度考虑,通常R1接口删除的时间较长,那么是否先更改R1接口,再更改R6接口。参见图13,网络侧服务流更改过程包括:
步骤1301~步骤1304的执行顺序和步骤1201~步骤1204的执行顺序是一样的,这里不再重复。
步骤1305:
SFM收到DSC请求响应后,SFM向MS发起DSC确认,完成空口更改。
步骤1306:
SFM向Serving SFA发起资源请求响应。
步骤1307:
Serving SFA将资源请求响应转发给Anchor SFA。
Claims (21)
1、一种网络侧服务流的创建方法,在锚服务流授权实体AnchorSFA决定进行网络侧服务流的创建后,网络侧执行:
资源请求过程:Anchor SFA向服务流管理实体SFM发送资源请求及相关参数,SFM决定准入后向移动台MS发起服务流创建请求,MS保留相关参数后向SFM返回动态服务流创建请求响应消息;
资源请求响应过程:SFM向Anchor SFA发送资源请求响应;
其特征在于,该方法进一步包括:
如果数据通道还未建立,或数据通道是基于服务流的,则需要数据通道建立过程,该过程包括数据通道建立请求过程和数据通道建立请求响应过程;
数据通道建立请求过程:Anchor SFA向SFM发送数据通道建立请求及相关参数,网络中各节点将根据所述参数建立数据通道;
数据通道建立请求响应过程:SFM向Anchor SFA返回数据通道建立请求响应消息,Anchor SFA向SFM发送确认消息;
空口确认过程:SFM向MS发送服务流创建确认信息。
2、根据权利要求1所述的方法,其特征在于,所述资源请求过程、资源请求响应过程、数据通道建立请求过程、数据通道建立请求响应过程和空口确认过程依次独立执行。
3、根据权利要求1所述的方法,其特征在于,所述资源请求过程、空口确认过程、资源请求响应过程、数据通道建立请求过程和数据通道建立请求响应过程依次独立执行。
4、根据权利要求1所述的方法,其特征在于,首先同时执行所述资源请求过程和所述数据通道建立请求过程,然后同时执行所述资源请求响应过程和所述数据通道建立请求响应过程,最后执行空口确认。
5、根据权利要求4所述的方法,其特征在于,所述资源请求过程和数据通道建立请求过程同时执行具体为:
SFM收到来自Anchor SFA的包括资源请求、数据通道建立请求及相关参数的流请求后,保存其中有关数据通道建立的信息,根据所述参数和本地准入策略向移动台MS发起服务流创建请求,MS保留相关参数后向SFM返回动态服务流创建请求响应消息。
6、根据权利要求4所述的方法,其特征在于,所述资源请求响应过程和数据通道建立请求响应过程同时执行具体为:
SFM将数据通道建立请求响应消息、资源请求响应及相关参数一起作为流请求响应返回Anchor SFA,Anchor SFA向SFM返回流确认信息。
7、根据权利要求1所述的方法,其特征在于,首先同时执行所述资源请求过程和所述数据通道建立请求过程,然后执行空口确认,最后同时执行所述资源请求响应过程和所述数据通道建立请求响应过程。
8、根据权利要求7所述的方法,其特征在于,所述资源请求过程和数据通道建立请求过程同时执行具体为:
SFM收到来自Anchor SFA的包括资源请求、数据通道建立请求及相关参数的流请求后,保存其中有关数据通道建立的信息,根据所述参数和本地准入策略向移动台MS发起服务流创建请求DSA-Request,MS保留相关参数后向SFM返回动态服务流创建请求响应消息。
9、根据权利要求7所述的方法,其特征在于,所述资源请求响应过程和数据通道建立请求响应过程同时执行具体为:
SFM将数据通道建立请求响应消息、资源请求响应及相关参数一起作为流请求响应返回Anchor SFA,Anchor SFA向SFM返回流确认信息。
10、一种网络侧服务流的删除方法,其特征在于,该方法包括:
资源请求过程:Anchor SFA向服务流管理实体SFM发送资源请求及相关参数,SFM收到资源请求后根据所述参数和本地准入策略向移动台MS发起服务流删除请求,MS保留相关参数后向SFM返回动态服务流删除请求响应消息;
资源请求响应过程:SFM向Anchor SFA发送资源请求响应;
空口确认过程:SFM向MS发送服务流删除确认信息。
11、根据权利要求10所述方法,其特征在于,该方法进一步包括:
如果数据通道是基于服务流创建的,或没有其它服务流使用,则需要进行数据通道删除过程,该过程包括数据通道删除请求过程和数据通道删除请求响应过程;
数据通道删除请求过程:Anchor SFA向SFM发送数据通道删除请求及相关参数,网络中各节点将根据所述参数删除数据通道;
数据通道删除请求响应过程:SFM向Anchor SFA返回数据通道删除响应消息,Anchor SFA向SFM发送确认消息。
12、根据权利要求11所述的方法,其特征在于,所述资源请求过程、资源请求响应过程、数据通道删除请求过程、数据通道删除请求响应过程和空口确认过程依次独立执行。
13、根据权利要求11所述的方法,其特征在于,所述资源请求过程、空口确认过程、资源请求响应过程、数据通道删除请求过程和数据通道删除请求响应过程依次独立执行。
14、根据权利要求11所述的方法,其特征在于,首先同时执行所述资源请求过程和所述数据通道删除请求过程,然后同时执行所述资源请求响应过程和所述数据通道删除请求响应过程,最后执行空口确认。
15、根据权利要求14所述的方法,其特征在于,所述资源请求过程和数据通道删除请求过程同时执行具体为:
SFM收到来自Anchor SFA的包括资源请求、数据通道删除请求及相关参数的流请求后,保存其中有关数据通道删除的信息,根据所述参数和本地准入策略向移动台MS发起服务流删除请求,MS保留相关参数后向SFM返回动态服务流删除响应消息。
16、根据权利要求14所述的方法,其特征在于,所述资源请求响应过程和数据通道删除请求响应过程同时执行具体为:
SFM将数据通道删除请求响应消息、资源请求响应及相关参数一起作为流请求响应返回Anchor SFA,Anchor SFA向SFM返回流确认信息。
17、根据权利要求11所述的方法,其特征在于,首先同时执行所述资源请求过程和所述数据通道删除请求过程,然后执行空口确认,最后同时执行所述资源请求响应过程和所述数据通道删除请求响应过程。
18、根据权利要求17所述的方法,其特征在于,所述资源请求过程和数据通道删除请求过程同时执行具体为:
SFM收到来自Anchor SFA的包括资源请求、数据通道删除请求及相关参数的流请求后,保存其中有关数据通道删除的信息,根据所述参数和本地准入策略向移动台MS发起服务流删除请求,MS保留相关参数后向SFM返回动态服务流删除响应消息。
19、根据权利要求17所述的方法,其特征在于,所述资源请求响应过程和数据通道删除请求响应过程同时执行具体为:
SFM将数据通道删除请求响应消息、资源请求响应及相关参数一起作为流请求响应返回Anchor SFA,Anchor SFA向SFM返回流确认信息。
20、一种网络侧服务流的更改方法,其特征在于,该方法包括:
Anchor SFA向服务流管理实体SFM发送资源请求及相关参数,SFM收到资源请求后根据所述参数和本地准入策略向移动台MS发起服务流更改请求;
SFM收到来自MS的服务流更改请求响应后,向Anchor SFA发送资源请求响应;
SFM向MS发送服务流更改确认信息。
21、根据权利要求20所述的方法,其特征在于,该方法进一步包括:
Anchor SFA向服务流管理实体SFM发送资源请求及相关参数,SFM收到资源请求后根据所述参数和本地准入策略向移动台MS发起服务流更改请求;
SFM收到来自MS的服务流更改请求响应后,向MS发送服务流更改确认信息;
SFM向Anchor SFA发送资源请求响应。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2006100585932A CN101043504B (zh) | 2006-03-22 | 2006-03-22 | 网络侧服务流的创建、删除和更改的方法 |
PCT/CN2007/000935 WO2007107123A1 (fr) | 2006-03-22 | 2007-03-22 | Procédé de traitement et dispositif de communication pour flux de service dynamique et pour flux de service côté réseau |
US12/212,808 US8254317B2 (en) | 2006-03-22 | 2008-09-18 | Method for processing dynamic service flows and network-side service flows and a communication apparatus |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2006100585932A CN101043504B (zh) | 2006-03-22 | 2006-03-22 | 网络侧服务流的创建、删除和更改的方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101043504A true CN101043504A (zh) | 2007-09-26 |
CN101043504B CN101043504B (zh) | 2011-08-10 |
Family
ID=38808692
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2006100585932A Expired - Fee Related CN101043504B (zh) | 2006-03-22 | 2006-03-22 | 网络侧服务流的创建、删除和更改的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101043504B (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2012130021A1 (zh) * | 2011-03-31 | 2012-10-04 | 北京新岸线无线技术有限公司 | 业务流删除方法及装置 |
CN101345679B (zh) * | 2008-08-21 | 2013-01-16 | 中兴通讯股份有限公司 | 动态业务的QoS保证方法、***以及AAA和Anchor SFA |
CN105472658A (zh) * | 2012-03-06 | 2016-04-06 | 广东新岸线计算机***芯片有限公司 | 业务流删除方法和装置 |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6134434A (en) * | 1997-12-08 | 2000-10-17 | Qualcomm Incorporated | System and method for providing service negotiation in a communications network |
CN100433890C (zh) * | 2003-12-22 | 2008-11-12 | 华为技术有限公司 | 应用动态业务质量控制的移动数据业务实现方法 |
-
2006
- 2006-03-22 CN CN2006100585932A patent/CN101043504B/zh not_active Expired - Fee Related
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101345679B (zh) * | 2008-08-21 | 2013-01-16 | 中兴通讯股份有限公司 | 动态业务的QoS保证方法、***以及AAA和Anchor SFA |
WO2012130021A1 (zh) * | 2011-03-31 | 2012-10-04 | 北京新岸线无线技术有限公司 | 业务流删除方法及装置 |
CN103688492A (zh) * | 2011-03-31 | 2014-03-26 | 北京新岸线移动多媒体技术有限公司 | 业务流删除方法及装置 |
CN105472658A (zh) * | 2012-03-06 | 2016-04-06 | 广东新岸线计算机***芯片有限公司 | 业务流删除方法和装置 |
Also Published As
Publication number | Publication date |
---|---|
CN101043504B (zh) | 2011-08-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101043755A (zh) | 移动通信***中准入判断的方法、***及装置 | |
CN1898973A (zh) | 用于促进an间hrpd硬切换的方法和装置 | |
CN1852384A (zh) | 一种策略和计费规则决策的实现方法 | |
CN1852551A (zh) | 基于移动网络的组播业务数据的实现方法 | |
CN1499760A (zh) | 多媒体广播与组播业务在Iu接口的信令承载连接方法 | |
CN101061672A (zh) | 通信***、无线局域网基站控制装置和无线局域网基站装置 | |
CN101064938A (zh) | 移动终端在3gpp与非3gpp接入***之间切换时应用mip的方法 | |
CN1620766A (zh) | 适用于在umts中的mbms数据预定发送的方法 | |
CN101043661A (zh) | PoC业务媒体请求的处理方法及装置 | |
CN101064645A (zh) | 单一设备同时支持多个无线局域网的方法 | |
CN101035049A (zh) | 管理无线局域网和移动网之间的互通的方法和相关的设备 | |
CN101047974A (zh) | 一种演进网络***及该***切换时数据传输方法 | |
CN1819580A (zh) | 通信装置、通信控制装置和通信*** | |
CN1859728A (zh) | 网络中激活态an之间软切换及会话迁移的实现方法 | |
CN101047958A (zh) | 3gpp演进网络中漫游场景下用户网络附着方法及*** | |
CN101061734A (zh) | 移动通信***、移动台及无线基站 | |
CN1893304A (zh) | 在无线通信***中提供服务质量保证的实现方法 | |
CN1812344A (zh) | 一种实现负载均衡的方法和*** | |
CN1513274A (zh) | 无线网络***及无线通信控制方法 | |
CN101043401A (zh) | 一种网络服务流标识的分配、更新方法 | |
CN1581744A (zh) | 为mbms业务提供多种qos的方法 | |
CN101039261A (zh) | 用户终端接入网络及承载建立过程的处理方法、***及装置 | |
CN1901742A (zh) | 一种信道切换方法 | |
CN101060703A (zh) | 用户设备切换时的策略和计费控制方法 | |
CN1878388A (zh) | 通信网络中数据传输服务质量的确定方法 |
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 | ||
C17 | Cessation of patent right | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20110810 Termination date: 20130322 |