首页 / 专利库 / 专利权 / 第I章 / 国际申请 / 修改 / 业务流修改流程

业务流修改流程

阅读:464发布:2020-05-13

专利汇可以提供业务流修改流程专利检索,专利查询,专利分析的服务。并且本 发明 公开了一种业务流 修改 流程,包括以下步骤:S302,当业务流状态机收到修改消息时,生成本地业务流修改状态机,发送业务流修改消息给本地业务流修改状态机,并跃迁到本地修改状态;S304,本地业务流修改状态机向远端业务流修改状态机发送业务流修改 请求 消息,并跃迁到业务流修改响应等待状态;以及S306,本地业务流修改状态机在接收到来自远端业务流修改状态机的业务流修改响应消息时,跃迁到维持状态,启动特定时长的第二 定时器 ,并在第二定时器超时后向业务流状态机发送业务流修改成功或业务流修改失败消息,并结束自身。通过本发明,可以有效提高空口链路效率,并可以保证服务 质量 、节约空口带宽。,下面是业务流修改流程专利的具体信息内容。

1. 一种业务流修改流程,其特征在于,包括以下步骤:S302,当业务流状态机收到修改消息时,生成本地业务流修改状态机,发送业务流修改消息给所述本地业务流修改状态机,并跃迁到本地修改状态;S304,所述本地业务流修改状态机向远端业务流修改状态机发送业务流修改请求消息,并跃迁到业务流修改响应等待状态;以及S306,所述本地业务流修改状态机在接收到来自所述远端业务流修改状态机的业务流修改响应消息时,跃迁到维持状态,启动特定时长的第二定时器,并在所述第二定时器超时后向所述业务流状态机发送业务流修改成功或业务流修改失败消息,并结束自身。
2. 根据权利要求1所述的业务流修改流程,其特征在于,所述本 地业务流修改状态机在向所述远端业务流修改状态机发送所 述业务流修改请求消息的同时,启动特定时长的第 一定时器, 以在所述第 一 定时器超时前没有收到所述业务流修改响应消 息的情况下,重新向所述远端业务流修改状态机发送所述业务 流4务改请求消息。
3. 根据权利要求2所述的业务流修改流程,其特征在于,在所述 第一定时器超时,且所述本地业务流修改状态机重新发送所述 业务流^修改二清求消息的次tt大于特定阔值后仍没有收到所述 业务流修改响应消息的情况下,所述本地业务流修改状态才几跃 迁到重试用尽状态,并启动所述第二定时器。
4. 4艮据纟又利要求3所述的业务流+务改流程,其特4正在于,在所述 本地业务流修改状态机在所述第二定时器超时之前收到所述 业务流》务改响应消息的情况下,所述本;也业务流-修改状态枳J夭 迁到所述维持状态。
5. 才艮据4又利要求3所述的业务流1"奮改流禾呈,其特4正在于,所述本 地业务流〗奮改状态4几在收到业务流远端^奮改消息的情况下,4亭 止所述第二定时器,并结束自身。
6. 才艮据权利要求1至5中任一项所述的业务流1奮改流程,其特4正 在于,在所述步骤S306中,所述本地业务流》务改状态机还向 所述远端业务流修改状态机发送业务流修改确认消息。
7. 根据;f又利要求6所述的业务流^修改流程,其特4正在于,所述本 地业务流修改状态机通过比较业务流数据区中的参数来决定 在所述业务流修改请求消息中携带的参数。
8 —种业务流修改流程,其特;f正在于,包括以下步骤:S402,当处于正常状态的业务流状态4几收到来自本地业务 流》务改状态才几的业务流^修改i青求时,生成远端业务流<务改状态 机,将所述业务流修改请求透传给所述远端业务流修改状态 机,并跃迁到远端修改状态;S404,所述远端业务流修改状态机判断是否支持本次修 改,根据判断结果向所述本地业务流修改状态4几发送业务流》, 改响应消息,并3夭迁到业务流》务改确^人等待状态;S406,在所述远端业务流^修改状态4几收到来自所述本;也业 务流〗奮改状态才几的业务流-修改确i人消息时,向所述业务流4犬态 机发送业务流修改成功或业务流修改失败消息,并跃迁到维持 a大态;以及 S408,所述业务流状态机收到所述业务流修改成功或业务 流l奮改失败消息后,3夭迁到所述正常状态,并向所述远端业务 流^修改状态才几发送业务流^f'务改完成消息。
9. 才艮据权利要求8所述的业务流^修改流程,其特;f正在于,处于所 述维持状态的所述远端业务流-修改状态4几收到所述业务流^f奮 改完成消息后,继续处于所述维持状态。
10. 才艮据4又利要求9所述的业务流^奮改流程,其特4正在于,处于所 述业务流<务改确认等待状态的所述远端业务流4奮改状态才几才艮 据所述业务流-修改确i人消息的确i人值向所述业务流状态才几发 送所述业务流#~改成功或业务流^修改失败消息。
11. 根据权利要求10所述的业务流修改流程,其特征在于,所述 远端业务流》务改状态才几在向所述本地业务流》务改状态才几发送 所述业务流{奮改响应消息的同时,启动特定时长的第三定时 器,以在所述第三定时器超时前没收到所述业务流修改确i人消 息的情况下,重新向所述本地业务流修改状态4几发送所述业务 流小务改响应消息。
12. 根据权利要求11所述的业务流修改流程,其特征在于,所述 远端业务流^修改4几状态才几在il夭迁到所述维持状态的同时,启动 第E^I^^并在所述第四定时器超时的情况下,结束自身。
13. 根据权利要求12所述的业务流修改流程,其特征在于,处于 所述维持状态的所述远端业务流^修改状态才几在收到业务流本 ;也删除消息时,3夭迁到释》文业务流状态。
14. 根据权利要求12所述的业务流修改流程,其特征在于,处于 所述维持状态的所述远端业务流z修改状态纟几在收到业务流删 除完成、业务流远端删除、业务流本地修改、或业务流远端》务 改消息的情况下,结束自身。

说明书全文

业务流^"改^W呈技术领域本发明涉及通信领i成,更具体地涉及一种业务流-修改流程。 背景技术在WiMAX系统中,基站(Base Station,简称BS)和移动台 (Subscriber Station,筒称SS)通过业务流j务改请求(DSC-REQ) 消息来发起对业务流的修改。 一次成功的业务流修改(DSC)包括 对业务流参数、接纳(Admitted)和(或)激活(Active)服务质量 (Quality of Service,简称QoS )参数集(set )的修改。如果DSC-REQ 中4叉含有Admitted QoS Set,那么该业务流的Active QoS Set就3皮置 为空(NULL),业务流处于非激活态。如果DSC-REQ中两个参数 集都不包含(即QoS Parameter Set type 4皮置为000 ),那么该业务流 的Admitted和Active QoS Set都^皮置为NULL,业务流^皮去4妻纳。 如果DSC-REQ中两个参数集都包含,那么首先检查Admitted QoS Set是否合法。如果接纳控制通过,再4企查Active QoS Set是否是 Admitted QoS Set的子集。如果检查都通过,那么DSC-REQ中的这 两个集合就是业务流的新Admitted和Active QoS Set。如果某一才企 查失败,那么这次DSC失败,业务流回到原4大态。在802.16e协议中,明确给出了 DSC的流程。当本地业务流修 改(DSC-Local)状态4几(以下简称LDSC )处于业务流"修改响应等 4寺(DSC画RSP Pending )或重i式用尽(Retries Exhausted)状态时, 如果收到业务流修改响应(DSC-RSP)消息,就会向远端发送业务

流修改确认(DSC-ACK)消息,并向业务流(SF)状态机发送业务 济u/修改成功(DSC Succeeded ) /业务Wi/修改失败(DSC Failed)消息, 并跃迁到维持(Holding )状态。SF状态机收到DSC Succeeded/DSC Failed后,会立即发送业务流修改完成(SF Changed )消息给LDSC, 并跃迁到正常(Nominal)状态。处于Holding状态的LDSC收到 SF Changed后会停止T10定时器,并结束自身。问题在于,如果远 端没有"欠到DSC-ACK,那么它会重新发送DSC-RSP。此时?无然 LDSC状态才几已经结束,因此即使收到DSC-RSP,该消息也不会3皮 处理。远端T8超时最大次数后,它就会发起释》丈。也就是说,Holding 状态实际上是一个瞬态,并没有起到处理重传消息的作用,这显然 与其设计意图不符合。如果按上面的分析,为了使LDSC在Holding状态能处理重传 消息,SF状态机将不发送SF Changed或LDSC收到SF Changed后 继续处于Holding状态。^f旦是,当SF状态机收到DSC Succeeded/DSC Failed消息后会i?夭迁到Nominal状态,所以本地上层的触发才几制可 以立刻再次发起4奮改。在这种情况下,就同时出现了两个业务流》l" 改处理(DSC transaction ),这与协i义上^见定的一个BS或SS在某一 时刻只能有一个DSC transaction相悖。远端业务流^奮改(DSC-Remote)状态机(以下简称RDSC)在 开始(Begin )状态收到DSC-REQ后,首先判断是否支持这次^修改。 如果不支持,贝'J RDSC发送DSC Failed给SF状态才几和DSC-RSP 给远端,并3夭迁到业务流修改确认等待(DSC-ACK Pending )状态。 SF状态机收到DSC Failed会3夭迁到Nominal状态,并发送SF Changed给RDSC。问题在于,协议中并没有对SF Changed消息进 行处理。更重要的是,如果该DSC-RSP丢失,远端会重发DSC-REQ。 由于此时SF状态机已经i沃迁到了 Nominal状态,它将会创建一个 新的RDSC,尽管这两条DSC-REQ都源自于同一次j奮改。而且因

为前一次的RDSC并没有结束(处于DSC-ACK Pending状态),所 以出玉见了两个DSC transaction共存的情况。另外,由于业务流的参数(TLV)比较多,占用了较大的空口 带宽,因此,如果某个参凝:值没有变化,在DSC-REQ消息中将不 携带该参数。远端收到DSC-REQ消息后,仅对变化的字段做相应 的<多改。这样就有效地节约了空口带宽。发明内容鉴于以上所述的一个或多个问题,本发明提供了 一种业务流修 改流程。根据本发明的一种业务流修改流程,包括以下步骤:S302,当 业务流状态机收到修改消息时,生成本地业务流修改状态机,发送 业务流修改消息给本地业务流修改状态机,并跃迁到本地修改状态; S304,本地业务流^修改状态4几向远端业务流^修改状态才几发送业务流 修改请求消息,并跃迁到业务流修改响应等待状态;以及S306,本 地业务流z修改状态才几在4妾收到来自远端业务流〗多改状态才几的业务流 修改响应消息时,跃迁到维持状态,启动特定时长的第二定时器, 并在第二定时器超时后向业务流状态机发送业务流修改成功或业务 流z修改失败消息,并结束自身。其中,本地业务流^修改状态4几在向远端业务流《奮改状态4几发送 业务流修改请求消息的同时,启动特定时长的第一定时器,以在第 一定时器超时前没有收到业务流修改响应消息的情况下,重新向远 端业务流^修改状态才几发送业务流^修改^清求消息。其中,在第一定时器超时,且本地业务流^修改a犬态才几重新发送 业务流修改请求消息的次数大于特定阈值后仍没有收到业务流<奮改 响应消息的情况下,本地业务流修改状态机跃迁到重试用尽状态,并启动第二定时器。其中,在本地业务流修改状态机在第二定时器 超时之前收到业务流修改响应消息的情况下,本地业务流修改状态 机跃迁到维持状态。可选地,在本地业务流修改状态机收到业务流 远端修改消息的情况下,停止第二定时器,并结束自身。其中,在步骤S306中,本地业务流修改状态才几还向远端业务 流^修改状态才凡发送业务流^奮改确iU肖息。其中,本地业务流-修改状 态一几通过比4交业务流凄t据区中的参凄t来决定在业务流^修改请求消息 中携带的参数。相应地,远端的业务流修改流程包括以下步骤:S402,当处于 正常状态的业务流状态才几收到来自;^地业务流〗'f改4犬态冲几的业务;危 修改请求时,生成远端业务流修改状态机,将业务流修改请求透传 给远端业务流》务改状态才几,并跃迁到远端4务改状态;S404,远端业 务流修改状态机判断是否支持本次修改,根据判断结果向本地业务 流修改状态机发送业务流修改响应消息,并跃迁到业务流修改确认 等待状态;S406,在远端业务流修改状态机收到来自本地业务流修 改状态机的业务流修改确认消息时,向业务流状态机发送业务流修 改成功或业务流修改失败消息,并跃迁到维持状态;以及S408,业 务流状态4几"欠到业务流<多改成功或业务流<奮改失败消息后,^夭迁到 正常状态,并向远端业务流修改状态机发送业务流修改完成消息。其中,处于维持状态的远端业务流修改状态机收到业务流修改 完成消息后,继续处于维持状态。处于业务流修改确认等待状态的 远端业务流修改状态机根据业务流修改确认消息的确认值向业务流 状态纟几发送业务流^奮改成功或业务流?修改失败消息。远端业务流〈奮 改状态机在向本地业务流修改状态机发送业务流修改响应消息的同 时,启动特定时长的第三定时器,以在第三定时器超时前没收到业 务流^奮改确iU肖息的情况下,重新向本地业务流^务改状态4几发送业 务流Y奮改响应消息。

其中,远端业务流修改机状态机在跃迁到维持状态的同时,启 动第四定时器,并在第四定时器超时的情况下,结束自身。另外, 处于维持状态的远端业务流修改状态机在收到业务流本地删除消息 时,^夭迁到释》丈业务流状态。处于维持状态的远端业务流修改状态 才几在收到业务流删除完成、业务流远端删除、业务流本i也^f'务改、或 业务流远端》务改消息的情况下,结束自身。通过本发明,可以有效提高空口链路效率,并可以保证服务质 量、节约空口带宽。附图说明此处所说明的附图用来提供对本发明的进一步理解,构成本申 请的一部分,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:图1是业务流^修改本地处理(DSC-Local Transaction)的习犬态 转换图;图2是业务流^修改远端处理(DSC-Remote Transaction )的习犬态转换图;图3是才艮据本发明实施例的一种业务流4f改流禾呈的流程图;图4是才艮据本发明实施例的另 一种业务流〗奮改流程的流程图;图5是LDSC在DSC-RSP Pending状态收到DSC-RSP后的信 令处理优4b流程图;图6是LDSC在Retries Exhausted状态收到SF Change-Remote 和DSC-RSP后的信令处理优化流程图;图7是LDSC在维持(Holding Down )状态收到T10超时消息 后的信令处理优化流程图;图8为RDSC在Begin状态的信令处理优化流程图;以及图9是RDSC在维持习犬态收到SF Change-Remote 、 SF Delete-Local和SF Changed后的信令优化处理流程图。具体实施方式为了解决现有技术中存在的一个或多个问题,本发明提出了以 下解决方案:当LDSC处于DSC-RSP Pending或Retries Exhausted 状态时,如果收到DSC-RSP,仅向远端发送DSC-ACK,并跃迁到 Holding状态(如图1和图2)。在Holding状态,如果TIO超时, 则LDSC根据所保存的DSC-ACK消息中的确认值(Confirm Code, 简称CC )向SF状态机发送DSC Succeeded/DSC Failed消息,并结 束自身(如图3 )。 SF状态机收到消息跃迁到Nominal状态。从而, 即^f吏本地上层立即发起1奮改,也不会出现两个DSC transaction共存 的情况,而消息的丟失重传也可以处理。同样,如果RDSC收到了 SF Changed就结束自身,那么Holding 状态也是形同虚设。因此可以改成收到SF Changed后,RDSC继续 处于Holding状态,直到T10超时或收到业务流删除完成(SF Deleted )/业务流远端删除(SF Delete-Remote )/业务流本地》务改(SF Change-Local) /业务流远端々务改(SF Change-Remote)消息后结束 自身(如图5)。下面参考附图,详细说明本发明的具体实施方式。参考图3,简要说明根据本发明实施例的本地业务流修改流程。 如图3所示,该流禾呈包括以下步骤:S302,当业务流状态^L收到

修改消息时,生成本地业务流^修改状态才几,发送业务流^修改消息给本地业务流^修改状态才几,并3夭迁到本地^修改状态;S304,本地业务 流+务改状态才几向远端业务流#~改状态才几发送业务流l务改i貪求消息, 并跃迁到业务流》务改响应等待状态;以及S306,本地业务流》务改状 态才几在4妾收到来自远端业务流Y夢改状态才几的业务流Y奮改响应消息 时,跃迁到维持状态,启动特定时长的第二定时器,并在第二定时 器超时后向业务流状态机发送业务流修改成功或业务流修改失败消 息,.并结束自身。其中,本地业务流^修改状态4几在向远端业务流^修改状态才几发送 业务流〗奮改请求消息的同时,启动特定时长的第一定时器,以在第 一定时器超时前没有收到业务流》务改响应消息的情况下,重新向远 端业务流修改状态一几发送业务流4务改请求消息。其中,在第一定时器超时,且本地业务流-修改状态4几重新发送 业务流修改请求消息的次数大于特定阈值后仍没有收到业务流修改 响应消息的情况下,本地业务流修改状态机跃迁到重试用尽状态, 并启动第二定时器。其中,在本地业务流修改状态机在第二定时器超时之前收到业务流4务改响应消息的情况下,本地业务流i"奮改状态 机跃迁到维持状态。可选地,在本地业务流修改状态机收到业务流 远端修改消息的情况下,停止第二定时器,并结束自身。其中,在步骤S306中,本地业务流^修改状态才几还向远端业务 流修改状态机发送业务流修改确认消息。其中,本地业务流修改状 态机通过比较业务流数据区中的参数来决定在业务流修改请求消息 中携带的参数。参考图4,简要说明根据本发明实施例的远端业务流修改流程。 如图4所示,该流程包括以下步骤:S402,当处于正常状态的业务 流状态机收到来自本地业务流修改状态机的业务流修改请求时,生 成远端业务流修改状态机,将业务流修改请求透传给远端业务流修改状态机,并跃迁到远端修改状态;S404,远端业务流修改状态枳j 判断是否支持本次修改,根据判断结果向本地业务流修改状态机发 送业务流修改响应消息,并跃迁到业务流修改确认等待状态;S406, 在远端业务流》f改状态才几收到来自本地业务流^奮改状态才几的业务流 4奮?文确i人消息时,向业务流状态4几发送业务流^奮改成功或业务流寸奮 改失败消息,并3夭迁到维持状态;以及S408,业务流状态才;M丈到业 务流修改成功或业务流修改失败消息后,遂夭迁到正常状态,并向远 端业务流修改状态机发送业务流修改完成消息。其中,处于维持状态的远端业务流〗奮改状态才几收到业务流-修改 完成消息后,继续处于维持状态。处于业务流修改确认等待状态的 远端业务流修改状态机根据业务流修改确认消息的确认值向业务流 状态一几发送业务流^修改成功或业务流^奮改失败消息。远端业务流+务 改状态才几在向本地业务流^修改状态4几发送业务流^修改响应消息的同 时,启动特定时长的第三定时器,以在第三定时器超时前没收到业 务流》务改确认消息的情况下,重新向本地业务流〗奮改状态才几发送业 务流》务改响应消息。其中,远端业务流修改机状态机在跃迁到维持状态的同时,启 动第四定时器,并在第四定时器超时的情况下,结束自身。另外, 处于维持状态的远端业务流修改状态机在收到业务流本地删除消息 时,跃迁到释放业务流状态。处于维持状态的远端业务流修改状态 才几在收到业务流删除完成、业务流远端删除、业务流本i&修改、或 业务流远端修改消息的情况下,结束自身。也就是说,SF状态机收到修改(Change)消息,生成LDSC 状态机,发送业务流修改(SF Change )消息给LDSC,然后跃迁到 本地4务改(Changing Local)状态。LDSC发送业务流修改请求 (DSC-REQ)消息纟会远端,启动定时器T7, 3夭迁到业务流-修改响

应等待(DSC-RSP Pending )状态。如果在DSC画RSP Pending状态, LDSC收到业务流修改响应(DSC-RSP)消息,则停止定时器T7, 发送业务流修改确认(DSC-ACK)消息给远端,启动定时器TIO, 并3夭迁到维持(Holding)状态。在DSC-RSP Pending状态,如果 T7超时且DSC-REQ重发次数超过最大次凄t,贝'J LDSC启动定时器 T10,—跃迁到重i式用尽(Retries Exhausted )4犬态。在Retries Exhausted 状态,如果LDSC收到DSC-RSP消息,则停止T10,发送DSC-ACK 纟合远端,并再次启动TIO, 3夭迁到Holding习犬态。在Holding d犬态, 如果T10超时,则LDSC发送业务流》务改成功(DSC Succeeded) 或业务流修改失败(DSC Failed)消息给SF状态机,并结束自身。SF状态机在Nominal状态收到DSC-REQ消息,生成RDSC状 态冲几,并透传DSC-REQ症合RDSC,然后3夭迁到远程^,改(Changing Remote)状态。在开始(Begin)状态,RDSC首先判断是否支持本 次修改,然后根据判断结果发送DSC-RSP给远端,并启动T8,跃 迁到DSC-ACK Pending状态。在DSC-ACK Pending状态,如果 RDSC收到了 DSC-ACK,则停止T8,根据DSC-ACK的CC值发 送DSC Succeeded或DSC Failed纟合SF状态才几,并启动T10, 3夭迁 到Holding状态。SF状态才几收到DSC Succeeded或DSC Failed后3夭 迁到Nominal状态,并发送SF Changed给RDSC。 RDSC收到SF Changed继续处于Holding状态。在Holding状态,如果RDSC收到 SF Deleted/SF Delete-Remote/SF Change-Local/SF Change-Remote或 T10超时消息,则结束自身。参考图5,说明LDSC在DSC-RSP Pending状态收到DSC-RSP 后的信令处理流程。如图5所示,该流程包4舌以下步骤:S502, LDSC收到DSC-RSP,该消息携带远端l奮改的结果。S504, LDSC停止定时器T7。S506, LDSC判断DSC-RSP的结果,如果不为OK进行步骤 S508,反之进行步骤S510或S512。S508, i殳置CC大于0,表示修-改失败。S510,如果本地是SS,并且此次修改要求增加上行带宽,此时 修改策略和调度参数。S512,如果本地是BS,此时修改调度参数。S514, i殳置CC等于O,表示^"改成功。S516,发送DSC-ACK。S518,启动定时器TIO。S520, 4呆存所发送的DSC-ACK,并i?夭迁到Holding Down状态。参考图6, i兌明LDSC在Retries Exhausted状态收到SF Change-Remote (仅SS )和DSC-RSP后的信令处理流程。如图6 所示,该流禾呈包i舌以下步-骤:S602, SS收到SF Change-Remote,该消息表示远端BS已经发 起修改,因此SS必须终止自己发起的修改。S604, LDSC停止TIO。S606, LDSC发送DSC Ended给SF状态才几,结束自身。 S608, LDSC收到DSC-RSP,该消息携带远端<*改的结果。 S610, LDSCM亭止TIO。S612, LDSC判断DSC-RSP的结果.,如果不为OK进行步骤 S614,反之进4亍步-骤S616或S618。S614, 设置CC大于0,表示l'务改失败。S616,如果本地是SS,并且此次〗奮改要求增加上^f于带宽,此时 修改策略和调度参数。S618,如果本地是BS,此时修改调度参数。S620, 设置CC等于O,表示〗奮改成功。S622,发送DSC-ACK。S624,启动定时器TIO。S626, 4呆存所发送的DSC-ACK,并3夭迁到Holding Down状态。参考图7,说明LDSC在Holding Down状态收到TIO超时消息 后的信令处理流程。如图7所示,该流程包括以下步骤:S702, LDSC收到TIO超时消息,该消息表示此次修改已经完成。S704,判断DSC-ACK消息中的CC值,如果为0进行步骤S706, 反之进行步骤S708。S706, LDSC发送DSC Succeeded消息纟合SF状态才几。S708, LDSC发送DSC Failed消息纟会SF习夫态才几。S710, LDSC发送DSC Ended消息给SF状态机,结束自身。 参考图8,说明RDSC在Begin状态的信令处理流程。如图8 所示,该流#呈包4舌以下步-骤:S802, RDSC收到DSC-REQ消息,该消息中携带需要进^H'务 改的参数(包括业务流的通用参数、QoS参数集、CS参数和ARQ 参数等)。S804,如果本地是BS,则RDSC发送请求收到确认(DSX-RVD ) 消息给远端。S806, RDSC保存QoS参数。S808, RDSC根据DSC-REQ中的参数判断是否支持该次修改。 如果不支持进行步骤S810,反之则进行步骤S812。S810,-没置CC大于0,表示々f改失败。S812,开始使用新的业务流参数。S814, i殳置CC等于0,表示^奮改成功。S816,发送DSC-RSP消息给远端。S818,启动定时器T8。S820,保存所发送的DSC-RSP。S822,设置DSC-RSP的最大重传次数,RDSC跃迁到DSC-ACK Pending状态。

参考图9 , i兌明RDSC在Holding Down状态收到SF Change-Remote 、 SF Delete-Local和SF Changed后的4言令处理充禾呈。 如图9所示,该流程包括以下步骤:S902, RDSC 4欠到SF Change-Remote消息,该消息表明远端已 经发起新一4仑的i^改,因此应该结束本次l资改。S904,停止TIO。S906, SRDSC发送DSC Ended消息并结束自身。S908, RDSC收到SF Delete-Local消息,该消息表明本地上层 已经发起释放。RDSC跃迁到Deleting SF状态。S910, RDSC 4欠到SF Changed消息后继续处于Holding 一犬态。本发明优化了业务流的改流程, <吏得重传的消息 (DSC-RSP/DSC-ACK )得以处理,避免了由此导致的异常释力文; 修改了流程中与协议不兼容的部分(两个DSC transaction共存等); 减少了 DSC-REQ消息中的编码字段,降低了空口开销。以上所述仅为本发明的实施例而已,并不用于限制本发明,对 于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本 发明的精神和原则之内,所作的任何修改、等同替换、改进等,均 应包含在本发明的权利要求范围之内。

相关专利内容
标题 发布/更新时间 阅读量
修改图表 2020-05-11 305
修改命令 2020-05-11 446
修改带式胶带 2020-05-13 179
修改比特流 2020-05-12 695
修改对话窗口 2020-05-13 593
修改液笔 2020-05-11 350
引导过程修改 2020-05-13 886
修改笔 2020-05-11 82
错字修改笔 2020-05-12 309
错字修改笔 2020-05-12 675
高效检索全球专利

专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台,是提供专利分析,专利查询,专利检索等数据服务功能的知识产权数据服务商。

我们的产品包含105个国家的1.26亿组数据,免费查、免费专利分析。

申请试用

分析报告

专利汇分析报告产品可以对行业情报数据进行梳理分析,涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度,系统通过AI智能系统对图表进行解读,只需1分钟,一键生成行业专利分析报告。

申请试用

QQ群二维码
意见反馈