CN111601297B - 拥塞解决方法、业务开通方法、服务器和终端 - Google Patents

Abstract

本发明公开了一种拥塞解决方法、业务开通方法、服务器和终端,拥塞解决方法包括：若确定终端的业务开通失败，则依据当前排队的终端数目和运营商服务器的处理能力，生成开通失败响应，开通失败响应包括排队时间；发送开通失败响应给终端，以使终端依据排队时间，重新发送业务开通请求，直至终端的业务开通成功为止。保证在多用户同时申请业务开通时，能够给各个终端分配一个合理的排队时间，进而减轻运营商服务器的处理压力，降低形成网络拥塞的风险，同时，保证终端开通业务的成功率，提升用户体验度。

Description

拥塞解决方法、业务开通方法、服务器和终端

技术领域

本发明涉及通信技术领域，具体涉及一种拥塞解决方法、业务开通方法、服务器和终端。

背景技术

第五代移动通信网络(The 5th Generation Mobile Networks，5G)中的语音通话功能还只能通过长期演进语音承载(Voice over Long-Term Evolution，VoLTE)来实现，在移动通信网络侧和互联网技术(Internet Technology，IT)支撑系统侧，预埋IP多媒体子系统(Internet Protocol Multimedia Subsystem，IMS)的接入点(Access Point Name，APN)。归属签约用户服务器(Home Subscriber Server，HSS)支持VoLTE自动开通功能，HSS可通过数据配置控制该自动开通功能的开启和关闭。

当用户所使用的智能终端支持VoLTE功能时，用户打开智能终端上的VoLTE开关后，该智能终端将会触发反向签约，智能终端会自动完成VoLTE的业务开通。若短时间内出现大量请求开通VoLTE业务的签约请求时，会在应用服务器(Application Server，AS)和信息化系统(Install Operate and Maintain，IOM)之间形成大量的开通请求，导致在IOM侧存在严重的排队现象，还可能导致用户开通VoLTE业务失败，在现有技术中，对于开通失败的用户，系统会统一配置用户的智能终端在预设时长(例如，5分钟)之后再发起重新注册请求，但在该预设时长之后还会由于排队用户过多而导致开通VoLTE业务失败，导致用户体验度差。

发明内容

为此，本发明提供一种拥塞解决方法、业务开通方法、服务器和终端，以解决现有技术中由于需要开通特定业务的用户较多而导致的网络拥塞问题以及开通特定业务失败而使得用户体验度差的问题。

为了实现上述目的，本发明第一方面提供一种拥塞解决方法，包括：若确定终端的业务开通失败，则依据当前排队的终端数目和运营商服务器的处理能力，生成开通失败响应，开通失败响应包括排队时间；发送开通失败响应给终端，以使终端依据排队时间，重新发送业务开通请求，直至终端的业务开通成功为止。

在一些具体实现中，依据当前排队的终端数目和运营商服务器的处理能力，生成开通失败响应，包括：依据当前排队的终端数目和运营商服务器在预设时长内能够开通的终端的数目，确定排队时间；依据排队时间生成开通失败响应，开通失败响应包括终端的标识。

在一些具体实现中，依据当前排队的终端数目和运营商服务器在预设时长内能够开通的终端的数目，确定排队时间，包括：依据以下公式，计算获得排队时间；

其中，T表示排队时间，M表示当前排队的终端数目，N表示运营商服务器在预设时长内能够开通的终端的数目，N是大于或等于1且小于或等于100的整数，n是大于或等于3且小于或等于100的整数。

在一些具体实现中，依据排队时间生成开通失败响应，包括：将排队时间写入到开通失败响应中的属性设置参数中。

在一些具体实现中，在若确定终端的业务开通失败，则依据当前排队的终端数目和运营商服务器的处理能力，生成开通失败响应步骤之前，还包括：接收终端发送的业务开通请求；判断终端的业务是否开通成功。

为了实现上述目的，本发明第二方面提供一种业务开通方法，包括：响应于运营商服务器返回的开通失败响应，获取运营商服务器配置的排队时间；依据排队时间，重新发送业务开通请求给运营商服务器，直至运营商服务器返回开通成功响应为止。

在一些具体实现中，响应于运营商服务器返回的开通失败响应，获取运营商服务器配置的排队时间，包括：若确定开通失败响应中的生效标识是表征排队时间生效，则获取运营商服务器配置的排队时间；否则，若确定生效标识是表征排队时间无效，则确定排队时间等于预设阈值。

在一些具体实现中，在响应于运营商服务器返回的开通失败响应，获取运营商服务器配置的排队时间步骤之前，还包括：发送业务开通请求给运营商服务器。

为了实现上述目的，本发明第三方面提供一种运营商服务器，包括：生成模块，用于在确定终端的业务开通失败时，依据当前排队的终端数目和运营商服务器的处理能力，生成开通失败响应，开通失败响应包括排队时间；发送模块，用于发送开通失败响应给终端，以使终端依据排队时间，重新发送业务开通请求，直至将终端的业务成功开通为止。

为了实现上述目的，本发明第四方面提供一种终端，包括：获取模块，用于响应于运营商服务器返回的开通失败响应，获取运营商服务器配置的排队时间；重发模块，用于依据排队时间，重新发送业务开通请求给运营商服务器，直至运营商服务器返回开通成功响应为止。

本发明具有如下优点：在确定终端的业务开通失败时，依据当前排队的终端数目和运营商服务器的处理能力，生成开通失败响应，进而发送包含有排队时间的开通失败响应给终端，使得终端能够根据该排队时间，重新发送业务开通请求，直至运营商服务器将终端的业务成功开通为止。保证在多用户同时申请业务开通并且运营商服务器处理不过来时，能够给各个终端分配一个合理的排队时间，进而减轻运营商服务器的处理压力，降低形成网络拥塞的风险，同时，保证终端开通业务的成功率，提升用户体验度。

附图说明

附附图用来提供对本公开实施例的进一步理解，并且构成说明书的一部分，与本公开的实施例一起用于解释本公开，并不构成对本公开的限制。通过参考附图对详细示例实施例进行描述，以上和其它特征和优点对本领域技术人员将变得更加显而易见，在附图中：

图1为本申请实施例一中的一种拥塞解决方法流程图。

图2为本申请实施例二中的一种拥塞解决方法流程图。

图3为本申请实施例三中的一种业务开通方法流程图。

图4为本申请实施例四中的一种运营商服务器的组成方框图。

图5为本申请实施例五中的一种终端的组成方框图。

图6为本申请实施例六中的一种业务处理系统的组成方框图。

图7为本申请实施例六中的业务处理系统在确定产生拥塞时的工作方法流程图。

在附图中：

401：生成模块 402：发送模块

501：获取模块 502：重发模块

610：运营商服务器 620：终端

611：基站 612：移动管理实体

613：查询呼叫会话控制功能实体 630：归属签约用户服

640：应用服务器 务器

650：安全操作维护服务器

具体实施方式

以下结合附图对本申请的具体实施方式进行详细说明。应当理解的是，此处所描述的具体实施方式仅用于说明和解释本申请，并不用于限制本申请。对于本领域技术人员来说，本申请可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本申请的示例来提供对本申请更好的理解。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

实施例一

本申请实施例提供了一种拥塞解决方法，该方法可应用于运营商服务器。如图1所示，包括：

步骤110，若确定终端的业务开通失败，则依据当前排队的终端数目和运营商服务器的处理能力，生成开通失败响应。

其中，开通失败响应包括排队时间。需要说明的是，当运营商服务器接收到终端发送的业务开通请求时，会先查看当前排队的终端数目，然后根据其自身的处理能力(例如，每秒内能够开通的终端的数目)，判断是否能够成功开通该终端的业务，若不能开通成功，则依据当前排队的终端数目和运营商服务器的处理能力，生成开通失败响应，否则，若当前运营商服务器有足够的能力可以处理目前进行排队的终端，则依照排队次序，为各个终端开通对应的业务。

步骤120，发送开通失败响应给终端。

需要说明的是，当终端接收到开通失败响应后，该终端会等待500秒，然后再发送业务开通请求给运营商服务器，直至运营商服务器将该终端的业务开通成功为止。其中的500秒即为该终端当前的排队时间，该排队时间也可以是1分钟、5分钟等不同的时长，可根据实际情况具体设置，其他未说明的排队时间也在本申请的保护范围之内，在此不再赘述。

在本实施例中，通过在确定终端的业务开通失败时，依据当前排队的终端数目和运营商服务器的处理能力，生成开通失败响应，进而发送包含有排队时间的开通失败响应给终端，使得终端能够根据该排队时间，重新发送业务开通请求，直至运营商服务器将终端的业务成功开通为止。保证在多用户同时申请业务开通并且运营商服务器处理不过来时，能够给各个终端分配一个合理的排队时间，进而减轻运营商服务器的处理压力，降低形成网络拥塞的风险，同时，保证终端开通业务的成功率，提升用户体验度。

本申请实施例提供了另一种可能的实现方式，其中，步骤110中的依据当前排队的终端数目和运营商服务器的处理能力，生成开通失败响应，可采用以下步骤实现，具体包括步骤111～112。

步骤111，依据当前排队的终端数目和运营商服务器在预设时长内能够开通的终端的数目，确定排队时间。

具体地，若当前排队的终端数目大于运营商服务器在预设时长内能够开通的终端的数目，则后续新来的终端需要进行排队，以等待运营商服务器的处理。其中的排队时间可依据以下公式计算获得。

其中，T表示排队时间，M表示当前排队的终端数目，N表示运营商服务器在预设时长内能够开通的终端的数目，N是大于或等于1且小于或等于100的整数，n是大于或等于3且小于或等于100的整数。T_iretry的单位可以是秒、分或其他时间单位。其他未举例说明的时间单位也在本申请的保护范围之内，可根据实际情况设置，再次不在赘述。

例如，当M等于10，N等于5，i等于6时，则T_iretry＝3，即表示第6个终端需要在2秒之后，再重新发送业务开通请求给运营商服务器，因此时已经有5个终端在等待运营商服务器的处理，因此，需要该第6个终端等待2秒。

若当前排队的终端数目小于或等于运营商服务器在预设时长内能够开通的终端的数目，则说明运营商服务器还能够处理得过来，则无需生成排队时间，运营商服务器按照先后顺序，对终端的业务开通请求进行处理。

步骤112，依据排队时间生成开通失败响应。

其中，开通失败响应包括终端的标识。

在一些具体实现中，将排队时间写入到开通失败响应中的属性设置参数中。

例如，开通失败响应可包括后续重传(Retry-After)头域，该Retry-After头域中包括ICSCF参数(ICSCFPARA1)，该ICSCFPARA1包括32个比特(Binary Digit，BIT)，其中第16～31BIT定义为“属性取值设置”类参数，可将排队时间写入到ICSCFPARA1的第16～31 BIT中，使得终端在接收到该开通失败响应时，通过对该开通失败响应消息的解析，获得排队时间，减少终端重复发送业务开通请求的次数，进而减轻运营商服务器的处理压力，降低形成网络拥塞的风险，同时，保证终端开通业务的成功率，提升用户体验度。

实施例二

图2为本申请实施例提供的一种拥塞解决方法，本实施例与实施例一的区别在于：在生成开通失败响应之前，还需要判断终端的业务是否开通成功。

具体地，该方法可应用于运营商服务器。如图2所示，可包括如下步骤。

步骤210，接收终端发送的业务开通请求。

例如，用户所使用的智能终端可能在初始设置时都包括支持VoLTE功能的模块，当用户需要使用开通VoLTE业务时，只需在终端上将该VoLTE功能模块的开关打开即可。而在网络侧，需要提前预埋IP多媒体子系统(Internet Protocol Multimedia Subsystem，IMS)的接入点(Access Point Name，APN)。以保证在用户打开智能终端上的VoLTE功能模块的开关时，可自动发送业务开通请求给运营商服务器。

步骤220，判断终端的业务是否开通成功。

需要说明的是，当运营商服务器接收到各个终端发送的业务开通请求时，会先查看当前排队的终端数目，然后根据其自身的处理能力(例如，每秒内能够开通的终端的数目)，判断是否能够成功开通终端的业务，若不能开通成功，则进入步骤230，否则，依序为各个终端开通对应的业务。

步骤230，若确定终端的业务开通失败，则依据当前排队的终端数目和运营商服务器的处理能力，生成开通失败响应。

步骤240，发送开通失败响应给终端。

需要说明的是，本实施例中的步骤230～240，与实施例一中的步骤110～120的内容相同，在此不再赘述。

在本实施例中，通过接收终端发送的业务开通请求，并判断终端的业务是否开通成功，使得能够提前预判是否产生了网络拥塞；然后在确定终端的业务开通失败时，依据当前排队的终端数目和运营商服务器的处理能力，生成开通失败响应，发送包含有排队时间的开通失败响应给终端，使得终端能够根据该排队时间，重新发送业务开通请求，直至运营商服务器将终端的业务成功开通为止。保证在多用户同时申请业务开通并且运营商服务器处理不过来时，能够给各个终端分配一个合理的排队时间，进而减轻运营商服务器的处理压力，降低形成网络拥塞的风险，同时，保证终端开通业务的成功率，提升用户体验度。

实施例三

本申请实施例提供了一种业务开通方法，该方法可应用于终端。如图3所示，具体包括如下步骤。

步骤310，响应于运营商服务器返回的开通失败响应，获取运营商服务器配置的排队时间。

在一些具体实现中，若确定开通失败响应中的生效标识是表征排队时间生效，则获取运营商服务器配置的排队时间；否则，若确定生效标识是表征排队时间无效，则确定排队时间等于预设阈值。

具体地，当开通失败响应中的生效标识是表征排队时间生效时，终端可对开通失败响应进行解析，获得运营商服务器配置的排队时间，该排队时间的取值范围可以是0～65535，单位是秒；当生效标识是表征排队时间无效时，则使用默认值(例如300秒)作为排队时间，即表示终端需要等待300秒，在300秒之后，才能再次重新发送业务开通请求给运营商服务器。

在一些具体实现中，在步骤310之前，还包括：发送业务开通请求给运营商服务器。

需要说明的是，终端在确认需要开通某项业务时，会自动发送业务开通请求给运营商服务器，使得运营商服务器能够自动为该终端开通对应的业务。但是运营商服务器的处理能力有限，若同时有多个终端同时申请业务开通时，并且请求开通业务的终端的数量超过了运营商服务器的处理能力时，会产生网络拥塞，容易造成业务开通失败而带来不好的客户体验。因此，需要调整终端在运营商服务器上的排队时间，进而执行步骤320，提升客户体验度。

步骤320，依据排队时间，重新发送业务开通请求给运营商服务器，直至运营商服务器返回开通成功响应为止。

具体地，当终端等待了排队时间(例如，400秒)之后，会再次发送业务开通请求给运营商服务器，直到运营商服务器将该终端的业务成功开通为止。

在本实施例中，通过从运营商服务器反馈的开通失败响应中，获取运营商服务器配置的排队时间，并依据该排队时间，再次发送业务开通请求给运营商服务器，使得能够调整发送业务开通请求的频率，减少发送业务开通请求的次数，减轻运营商服务器的处理压力，避免形成网络拥塞；同时，使得业务开通的成功率得到保障，提升用户体验度。

实施例四

图4为本申请实施例提供的一种运营商服务器的结构示意图，该服务器的具体实施可参见实施例一或实施例二的相关描述，重复之处不再赘述。值得说明的是，本实施方式中的服务器的具体实施不局限于以上实施例，其他未说明的实施例也在本服务器的保护范围之内。

如图4所示，该运营商服务器具体包括：生成模块401用于在确定终端的业务开通失败时，依据当前排队的终端数目和运营商服务器的处理能力，生成开通失败响应，开通失败响应包括排队时间；发送模块402用于发送开通失败响应给终端，以使终端依据排队时间，重新发送业务开通请求，直至将终端的业务成功开通为止。

不难发现，本实施方式为与实施例一或实施例二相对应的装置实施例，本实施方式可与实施例一或实施例二互相配合实施。实施例一或实施例二中提到的相关技术细节在本实施方式中依然有效，为了减少重复，这里不再赘述。相应地，本实施方式中提到的相关技术细节也可应用在实施例一或实施例二中。

实施例五

图5为本申请实施例提供的一种终端的结构示意图，该终端的具体实施可参见实施例三的相关描述，重复之处不再赘述。值得说明的是，本实施方式中的终端的具体实施不局限于以上实施例，其他未说明的实施例也在本终端的保护范围之内。

如图5所示，该终端具体包括：获取模块501用于响应于运营商服务器返回的开通失败响应，获取运营商服务器配置的排队时间；重发模块502用于依据排队时间，重新发送业务开通请求给运营商服务器，直至运营商服务器返回开通成功响应为止。

不难发现，本实施方式为与实施例三相对应的装置实施例，本实施方式可与实施例三互相配合实施。实施例三中提到的相关技术细节在本实施方式中依然有效，为了减少重复，这里不再赘述。相应地，本实施方式中提到的相关技术细节也可应用在实施例三中。

值得一提的是，本实施方式中所涉及到的各模块均为逻辑模块，在实际应用中，一个逻辑单元可以是一个物理单元，也可以是一个物理单元的一部分，还可以以多个物理单元的组合实现。此外，为了突出本申请的创新部分，本实施方式中并没有将与解决本申请所提出的技术问题关系不太密切的单元引入，但这并不表明本实施方式中不存在其它的单元。

实施例六

本申请实施例提供了一种业务处理系统，如图6所示，包括：运营商服务器610、终端620、归属签约用户服务器(Home Subscriber Server，HSS)630、应用服务器(Application Server，AS)640和安全操作维护服务器(Install Operate and MaintainServer，IOM)650。其中，运营商服务器610包括基站611、移动管理实体(MobilityManagement Entity，MME)612和查询呼叫会话控制功能实体(Interrogating CallSession Control Function，I-CSCF)613。

具体地，图7是该业务处理系统在确定产生拥塞时的工作方法流程图，如图7所示，具体包括如下步骤。

步骤701，终端620发送IMS注册请求给运营商服务器610。

具体地，在运营商服务器610内部，业务开通请求首先由基站611从终端620处接收到，然后基站611将该业务开通请求转发给MME 612，进而MME 612转发该业务开通请求给I-CSCF 613，然后I-CSCF 613再转发给HSS 630。

需要说明的是，在步骤701之前，在移动通信网络侧和互联网技术(InternetTechnology，IT)支撑系统侧，需要提前预埋IP多媒体子系统(Internet ProtocolMultimedia Subsystem，IMS)的接入点(Access Point Name，APN)。具体地，通过AS 640、HSS 630和IOM 650之间的信息交互完成预埋。

步骤702，运营商服务器610根据当前排队的终端数目和其处理能力，判断是否能够为终端620成功开通业务。

需要说明的是，若确定为终端620开通业务失败，则进入步骤703，否则，结束流程。

步骤703，运营商服务器610根据当前排队的终端数目和运营商服务器610的处理能力，生成开通失败响应。

需要说明的是，运营商服务器在接收到IMS注册请求后，由于当前需要开通业务的终端用户很多，若当前排队的终端数目大于运营商服务器610的处理能力，则表示运营商服务器610不能及时的处理终端620的IMS注册请求，运营商服务器610会根据以下公式，计算获得排队时间；然后将该排队时间写入到生成的注册失败响应“404 Not Found”中。

其中，T表示排队时间，M表示当前排队的终端数目，N表示运营商服务器在预设时长(例如，1秒)内能够开通的终端的数目，i表示第i个终端，N是大于或等于1且小于或等于100的整数，n是大于或等于3且小于或等于100的整数。

步骤704，运营商服务器610发送携带有排队时间的开通失败响应给终端620。

在一个具体实现中，其中的排队时间可以是I-CSCF 613依据步骤703中的公式计算获得的，然后I-CSCF 613将该排队时间写入到注册失败响应中，并发送该注册失败响应给MME 612，使得MME 612转发该注册失败响应给基站611，进而基站611再将该注册失败响应发送给终端620。

具体地，注册失败响应包括后续重传(Retry-After)头域，该Retry-After头域中包括ICSCF参数(ICSCFPARA1)，该ICSCFPARA1的第16～31 BIT定义为“属性取值设置”类参数，可将排队时间写入到ICSCFPARA1的第16～31 BIT中。

其中，“属性取值设置”类参数用于控制I-CSCF在VoLTE自动开户场景下，终端用户的等待时间(即排队时间)。仅当ICSCFPARA1的第6BIT设置为“1”时，该等待时间才生效，其取值范围是0～65535，单位是秒；当ICSCFPARA1的第6 BIT设置为“0”时，则使用默认值(例如300秒)作为排队时间，即表示终端620需要等待300秒，在300秒之后，才能再次重新发起IMS注册请求。

需要说明的是，当终端620等待了排队时间(例如，500秒)之后，会再次发送IMS注册请求给运营商服务器610，即进入步骤701。如此循环，直到运营商服务器610将该终端620的IMS注册业务成功开通为止。

在本实施例中，通过在确定终端的业务开通失败时，依据当前排队的终端数目和运营商服务器的处理能力，生成开通失败响应，进而发送包含有排队时间的开通失败响应给终端，使得终端能够根据该排队时间，重新发送业务开通请求，直至运营商服务器将终端的业务成功开通为止。保证在多用户同时申请业务开通时，能够给各个终端分配一个合理的排队时间，以降低终端重复发送业务开通请求的次数，进而减轻运营商服务器的处理压力，降低形成网络拥塞的风险，同时，保证终端开通业务的成功率，提升用户体验度。

可以理解的是，以上实施方式仅仅是为了说明本发明的原理而采用的示例性实施方式，然而本发明并不局限于此。对于本领域内的普通技术人员而言，在不脱离本发明的精神和实质的情况下，可以做出各种变型和改进，这些变型和改进也视为本发明的保护范围。

Claims (8)

1.一种拥塞解决方法，其特征在于，所述方法包括：

若确定终端的业务开通失败，则依据当前排队的终端数目和运营商服务器的处理能力，生成开通失败响应，包括：

依据所述当前排队的终端数目和所述运营商服务器在预设时长内能够开通的终端的数目，确定排队时间；

依据所述排队时间生成所述开通失败响应，所述开通失败响应包括所述终端的标识、排队时间和生效标识，其中所述生效标识表征所述排队时间是否生效；

若所述生效标识表征排队时间生效，则所述排队时间是根据所述运营商服务器在预设时长内能够开通的终端的数目确定的排队时间；若所述生效标识表征排队时间无效，则所述排队时间是预设阈值；

发送所述开通失败响应给所述终端，以使所述终端依据所述排队时间，重新发送业务开通请求，直至所述终端的业务开通成功为止。

2.根据权利要求1所述的方法，其特征在于，所述依据所述当前排队的终端数目和所述运营商服务器在预设时长内能够开通的终端的数目，确定排队时间，包括：

依据以下公式，计算获得所述排队时间；

其中，T表示所述排队时间，M表示所述当前排队的终端数目，N表示所述运营商服务器在预设时长内能够开通的终端的数目，N是大于或等于1且小于或等于100的整数，n是大于或等于3且小于或等于100的整数。

3.根据权利要求1所述的方法，其特征在于，所述依据所述排队时间生成所述开通失败响应，包括：

将所述排队时间写入到所述开通失败响应中的属性设置参数中。

4.根据权利要求1至3中任一项所述的方法，其特征在于，在所述若确定终端的业务开通失败，则依据当前排队的终端数目和运营商服务器的处理能力，生成开通失败响应步骤之前，还包括：

接收所述终端发送的业务开通请求；

判断所述终端的业务是否开通成功。

5.一种业务开通方法，其特征在于，所述方法包括：

响应于运营商服务器返回的开通失败响应，获取所述运营商服务器配置的排队时间，包括：

若确定所述开通失败响应中的生效标识是表征所述排队时间生效，则获取所述运营商服务器配置的排队时间；

否则，若确定所述生效标识是表征所述排队时间无效，则确定所述排队时间等于预设阈值；

依据所述排队时间，重新发送业务开通请求给所述运营商服务器，直至所述运营商服务器返回开通成功响应为止。

6.根据权利要求5所述的方法，其特征在于，在所述响应于运营商服务器返回的开通失败响应，获取所述运营商服务器配置的排队时间步骤之前，还包括：

发送所述业务开通请求给运营商服务器。

7.一种运营商服务器，其特征在于，包括：

生成模块，用于在确定终端的业务开通失败时，依据当前排队的终端数目和运营商服务器的处理能力，生成开通失败响应，所述开通失败响应包括所述终端的标识、排队时间和生效标识，其中所述生效标识表征所述排队时间是否生效；

计算模块，用于依据所述当前排队的终端数目和所述运营商服务器在预设时长内能够开通的终端的数目，确定排队时间；

第一确定模块，用于若所述生效标识表征排队时间生效，则所述排队时间是根据所述运营商服务器在预设时长内能够开通的终端的数目确定的排队时间；若所述生效标识表征排队时间无效，则所述排队时间是预设阈值；

发送模块，用于发送所述开通失败响应给所述终端，以使所述终端依据所述排队时间，重新发送业务开通请求，直至将所述终端的业务成功开通为止。

8.一种终端，其特征在于，包括：

获取模块，用于响应于运营商服务器返回的开通失败响应，获取所述运营商服务器配置的排队时间；

第二确定模块，用于若确定所述开通失败响应中的生效标识是表征所述排队时间生效，则获取所述运营商服务器配置的排队时间；否则，若确定所述生效标识是表征所述排队时间无效，则确定所述排队时间等于预设阈值；

重发模块，用于依据所述排队时间，重新发送业务开通请求给所述运营商服务器，直至所述运营商服务器返回开通成功响应为止。

Images