JP2007219650A - Request preferential receiving method and system - Google Patents

Request preferential receiving method and system Download PDF

Info

Publication number
JP2007219650A
JP2007219650A JP2006036979A JP2006036979A JP2007219650A JP 2007219650 A JP2007219650 A JP 2007219650A JP 2006036979 A JP2006036979 A JP 2006036979A JP 2006036979 A JP2006036979 A JP 2006036979A JP 2007219650 A JP2007219650 A JP 2007219650A
Authority
JP
Japan
Prior art keywords
priority
request
request message
condition
receiving
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
Application number
JP2006036979A
Other languages
Japanese (ja)
Other versions
JP4726067B2 (en
Inventor
Hironori Furuya
裕規 古屋
Hideyuki Kogashira
秀行 小頭
Hajime Nakamura
中村　　元
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
KDDI Corp
Original Assignee
KDDI Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by KDDI Corp filed Critical KDDI Corp
Priority to JP2006036979A priority Critical patent/JP4726067B2/en
Publication of JP2007219650A publication Critical patent/JP2007219650A/en
Application granted granted Critical
Publication of JP4726067B2 publication Critical patent/JP4726067B2/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

<P>PROBLEM TO BE SOLVED: To provide a system for impartially receiving re-access of a refused request message without causing new access concentration. <P>SOLUTION: A request receiving section 101 receives the request message. An acceptance refusing section 102 refuses the acceptance of the request message if the overload state of the system is detected by a load detecting section 3. A preference determining section 103 determines whether the received request message takes precedence. A preferential receiving section 104 preferentially receives the request message which takes precedence. A preferential receiving condition setting section 5 sets preferential receiving conditions for preferentially receiving the re-request of the refused request message later. A message transmitting section 6 transmits a guide message in which the preferential receiving conditions are registered, to a transmission source (a user terminal) of the refused request message. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

本発明は、ネットワーク経由で受信したリクエストを受け付けて処理し、受け付けられなかったリクエストに所定の優先受付条件を設定し、この優先受付条件を満足する再リクエストを優先的に受け付けるリクエスト優先受付方法およびシステムに関する。   The present invention accepts and processes a request received via a network, sets a predetermined priority acceptance condition for a request that has not been accepted, and a request priority acceptance method that preferentially accepts a re-request that satisfies the priority acceptance condition, and About the system.

災害発生時の安否確認のためのリクエスト、あるいはTV番組やラジオ番組でヒットチャートを発表した直後に人気曲の配信を要求するリクエストなど、特定のイベントを契機とするリクエストメッセージは短時間に集中する傾向がある。これらの宛先でリクエストを受け付けるサーバでは、リクエスト数が処理能力を超過すると、超過分についてはサービスの提供が不可能となる。このことは、同サービスを利用するユーザの満足度を低下させると共に、たとえばリクエストが有料コンテンツの配信であれば、コンテンツ提供者にとっては販売機会の損失となる。   Request messages triggered by specific events, such as requests to confirm safety in the event of a disaster or requests to distribute popular songs immediately after releasing a hit chart on a TV program or radio program, are concentrated in a short time Tend. In a server that accepts requests at these destinations, if the number of requests exceeds the processing capability, it becomes impossible to provide a service for the excess. This lowers the satisfaction level of users who use the service, and for example, if the request is distribution of paid content, it results in a loss of sales opportunities for the content provider.

イベントを契機とするアクセスの集中は通常のアクセス量を遙かに凌駕し、例えば10倍や100倍に達する場合もある。したがって、アクセス集中時のピーク時に合わせてサーバ容量を設計してしまうと、時間的に大半を占める通常時には大幅な過剰設備状態を招いてしまう。しかも、このようなアクセス集中は予測が難しいので、たとえ十分と予測される設備を用意できたとしても、その容量を上回るアクセスが集中する可能性を否定できない。   The concentration of access triggered by an event far exceeds the normal access amount, and may reach 10 times or 100 times, for example. Therefore, if the server capacity is designed in accordance with the peak time when the access is concentrated, a large excess of equipment is incurred during normal times, which occupies most of the time. Moreover, since such access concentration is difficult to predict, even if equipment that is predicted to be sufficient can be prepared, the possibility of concentration of access exceeding that capacity cannot be denied.

一方、２００３年１２月に東京・大阪・名古屋で地上デジタル放送が開始され、それ以後、他の地域でも放送が順次開始されると共に、移動体受信端末向けサービスなどが拡充されることになっている。地上デジタル放送で提供される通信放送連携サービスでは、番組内容を契機とした同時大量アクセスの発生が予見されており、上記で指摘した事象が今後ますます顕在化してくることが想定される。   On the other hand, digital terrestrial broadcasting started in December 2003 in Tokyo, Osaka, and Nagoya. After that, broadcasting started in other areas and services for mobile receivers will be expanded. Yes. In the communication / broadcasting cooperation service provided by terrestrial digital broadcasting, the occurrence of simultaneous large-scale access is anticipated triggered by the contents of the program, and it is assumed that the above-mentioned phenomenon will become more apparent in the future.

特許文献１、２には、輻輳が生じるとTCPパケットやUDPパケットを破棄してトラヒックを減じることで輻輳を解消する技術が開示されており、この技術を転用すれば、リクエストメッセージが集中した際に、その一部を破棄することでトラヒック量を減じることができる。
特開２００２−３１４５９２号公報 特開２００３−２３４４３号公報 Patent Documents 1 and 2 disclose a technique for eliminating congestion by discarding TCP packets and UDP packets and reducing traffic when congestion occurs. If this technique is diverted, request messages are concentrated. In addition, the traffic volume can be reduced by discarding a part of the traffic.
Japanese Patent Laid-Open No. 2002-314592 Japanese Patent Laid-Open No. 2003-23443

上記した従来技術はいずれも、リクエストのアクセスが集中してシステムに過剰な負荷が加わると、リクエスト（パケット）を破棄することで負荷の緩和が図られる。しかしながら、破棄されたリクエストは再送信されることになるので、これら再送信の集中によって再び過剰な負荷が発生してしまうという技術課題があった。   In any of the conventional techniques described above, when requests are concentrated and an excessive load is applied to the system, the load can be reduced by discarding the request (packet). However, since the discarded request is retransmitted, there is a technical problem that excessive load occurs again due to the concentration of these retransmissions.

また、従来技術では最初のリクエストも再リクエストも同様に扱われてしまうので、短時間で受け付けられるリクエストがある一方で、長い保留時間を経ても受け付けられないリクエストが生じるなど、リクエストメッセージの受け付けに不公平感が生じるという技術課題もあった。   In the prior art, the first request and re-request are handled in the same way, so there are requests that can be accepted in a short time, but there are requests that can not be accepted even after a long hold time. There was also a technical problem that caused unfairness.

本発明の目的は、上記した従来技術の課題を解決し、アクセスの集中による過負荷等が原因で受付拒否されたリクエストメッセージの再アクセスを、新たなアクセス集中を生じさせることなく公平に受け付けて処理できるリクエスト優先受付方法およびシステムを提供することにある。   The object of the present invention is to solve the above-mentioned problems of the prior art and to accept re-access of a request message rejected due to overload due to concentration of access fairly without causing new access concentration. It is an object of the present invention to provide a request priority receiving method and system that can be processed.

上記した目的を達成するために、本発明は、リクエストメッセージを受け付けて処理し、受け付けられなかったリクエストメッセージに所定の優先受付条件を設定し、当該優先受付条件を満足する再リクエストを優先的に受け付けるリクエスト優先受付システムにおいて、以下のような手段を講じた点に特徴がある。   In order to achieve the above-described object, the present invention receives and processes a request message, sets a predetermined priority reception condition for a request message that has not been received, and gives priority to a re-request that satisfies the priority reception condition. A feature of the request priority receiving system is that the following measures are taken.

(1)リクエストメッセージを受信して受け付けるリクエスト受信手段と、受け付けられたリクエストメッセージを処理するリクエスト処理手段と、前記リクエスト受付および／またはリクエスト処理の負荷を検知する負荷検知手段と、前記検知された負荷が所定の上限値を超えた状態でのリクエストメッセージの受け付けを拒否する受付拒否手段と、前記受付拒否したリクエストメッセージに所定の優先受付条件を設定する優先受付条件設定手段と、前記受付拒否したリクエストメッセージの送信元へ前記優先受付条件を通知する優先受付条件通知手段と、前記優先受付条件を満足するリクエストメッセージを優先的に受け付ける優先受付手段。   (1) a request receiving unit that receives and receives a request message, a request processing unit that processes the received request message, a load detection unit that detects a load of the request reception and / or request processing, and the detected An acceptance refusal means for refusing acceptance of a request message in a state where the load exceeds a predetermined upper limit value, a priority acceptance condition setting means for setting a prescribed priority acceptance condition for the request message rejected, and the acceptance refusal Priority acceptance condition notifying means for notifying the request message transmission source of the priority acceptance condition, and priority acceptance means for preferentially receiving a request message satisfying the priority acceptance condition.

(2)受信したリクエストメッセージが優先対象であるか否かを判定する優先判定手段を含み、前記優先受付手段は、優先対象と判定されたリクエストメッセージのみを優先的に受け付けること。   (2) It includes priority determination means for determining whether or not the received request message is a priority object, and the priority reception means preferentially receives only the request message determined to be the priority object.

(3)優先受付条件設定手段は、リクエストメッセージに設定した優先受付条件を当該リクエストメッセージの送信元IDと対応付けてデータベースに登録し、優先判定手段は、受信したリクエストメッセージの送信元IDと対応付けられた優先受付条件が満足されているリクエストメッセージを優先対象と判定することを特徴とする。   (3) The priority acceptance condition setting means registers the priority acceptance condition set in the request message in the database in association with the transmission source ID of the request message, and the priority determination means corresponds to the transmission source ID of the received request message. A request message that satisfies the attached priority acceptance condition is determined as a priority object.

(4)リクエストメッセージに設定した優先受付条件に所定の関数計算を実行して確認識別子を生成する確認識別子生成手段をさらに具備し、前記優先受付条件通知手段は、前記確認識別子および優先受付条件をリクエストメッセージの送信元へ通知し、前記優先判定手段は、受信したリクエストメッセージの優先受付条件に前記関数計算を実行して求めた確認識別子と当該リクエストメッセージに登録されている確認識別子とを比較し、両者が一致したリクエストメッセージを優先対象と判定することを特徴とする。   (4) It further comprises confirmation identifier generation means for generating a confirmation identifier by executing a predetermined function calculation on the priority reception condition set in the request message, and the priority reception condition notification means includes the confirmation identifier and the priority reception condition. The request message transmission source is notified, and the priority determination unit compares the confirmation identifier obtained by executing the function calculation with the priority reception condition of the received request message and the confirmation identifier registered in the request message. The request message in which both match is determined as a priority object.

(5)優先条件設定手段は、前記優先受付条件として、リクエストメッセージを優先的に受け付ける時間帯を設定することを特徴とする。   (5) The priority condition setting means sets a time zone for preferentially receiving a request message as the priority reception condition.

(6)優先条件設定手段は、前記優先受付条件として、リクエストメッセージを優先的に受け付ける他のリクエスト受信手段のアドレスを設定することを特徴とする。   (6) The priority condition setting means sets the address of another request receiving means for preferentially receiving a request message as the priority reception condition.

(7)優先条件設定手段は、前記優先受付条件として、リクエストメッセージを優先的に受け付ける時間帯および他のリクエスト受信手段のアドレスを設定することを特徴とする。   (7) The priority condition setting means sets a time zone for preferentially receiving a request message and an address of another request receiving means as the priority reception condition.

本発明によれば、以下のような効果が達成される。
上記した特徴(1)によれば、受付拒否されたリクエストメッセージには優先受付条件が設定され、リクエストメッセージの再送信は前記優先受付条件が満足されるように行われる。したがって、優先受付条件をリクエストメッセージのアクセスが分散されるように設定すれば、再送信されるリクエストメッセージの集中を防止できる。そして、優先受付条件を満足するリクエストメッセージは優先的に受け付けられるので、リクエストメッセージの受付機会を公平化できる。 According to the present invention, the following effects are achieved.
According to the feature (1) described above, the priority acceptance condition is set for the request message whose acceptance is rejected, and the request message is retransmitted so that the priority acceptance condition is satisfied. Therefore, if the priority reception conditions are set so that access of request messages is distributed, concentration of request messages to be retransmitted can be prevented. Since the request message that satisfies the priority reception condition is received with priority, the request message reception opportunity can be equalized.

上記した特徴(2)によれば、受信されたリクエストメッセージが優先対象であるか否かが判定されるので、優先対象外のリクエストメッセージが誤って優先対象とされて優先的に受け付けられることを防止できる。   According to the above feature (2), since it is determined whether or not the received request message is a priority object, it is determined that a request message that is not a priority object is erroneously regarded as a priority object and is preferentially accepted. Can be prevented.

上記した特徴(3)によれば、リクエストメッセージの送信元IDと優先受付条件とが対応付けられて管理されるので、リクエストメッセージごとに異なる優先受付条件が設定されていても優先判定を容易に行えるようになる。   According to the above feature (3), since the source ID of the request message and the priority reception condition are managed in association with each other, priority determination can be easily performed even if different priority reception conditions are set for each request message. You can do it.

上記した特徴(4)によれば、リクエストメッセージの送信元IDと優先受付条件との対応関係を管理することなく、リクエストメッセージごとに異なる優先受付条件が設定されていても優先判定を容易に行えるようになる。   According to the above feature (4), it is possible to easily perform priority determination even when different priority reception conditions are set for each request message without managing the correspondence between the request message transmission source ID and the priority reception conditions. It becomes like this.

上記した特徴(5)によれば、優先受付条件として、リクエストメッセージを優先的に受け付ける時間帯が設定されるので、リクエストメッセージの再送信を時間的に分散できるようになる。   According to the feature (5) described above, since the time zone for preferentially receiving the request message is set as the priority reception condition, retransmission of the request message can be distributed over time.

上記した特徴(6)によれば、優先受付条件として、リクエストメッセージを優先的に受け付ける他のリクエスト受信手段のアドレスが設定されるので、リクエストメッセージの再送信を地理的に分散できるようになる。   According to the feature (6) described above, the address of another request receiving unit that preferentially receives a request message is set as the priority reception condition, so that retransmission of request messages can be geographically distributed.

上記した特徴(7)によれば、優先受付条件として、リクエストメッセージを優先的に受け付ける時間帯および他のリクエスト受信手段のアドレスが設定されるので、リクエストメッセージの再送信を時間的および地理的に分散できるようになる。   According to the above feature (7), as the priority reception condition, the time zone for receiving the request message preferentially and the address of other request receiving means are set. Can be distributed.

以下、図面を参照して本発明の最良の実施の形態について詳細に説明する。 図１は、本発明のリクエスト優先受付システムが適用されるコンテンツ配信システムの第１実施形態の構成を示した機能ブロック図である。   DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, the best embodiment of the present invention will be described in detail with reference to the drawings. FIG. 1 is a functional block diagram showing the configuration of a first embodiment of a content distribution system to which the request priority reception system of the present invention is applied.

リクエスト受信部１は、ユーザ端末から送信されたリクエストメッセージを受信する。リクエスト受付部１０１は、受信されたリクエストメッセージを受け付けてリクエスト処理部２へ転送する。受付拒否部１０２は、負荷検知部３によりシステムの過負荷状態が検知されていると、受信されたリクエストメッセージの受け付けを拒否する。優先判定部１０３は、受信されたリクエストメッセージが優先対象であるか否か、さらには優先受付条件を満足しているか否かを判定する。優先受付部１０４は、優先対象であって、かつ優先受付条件を満足すると判定されたリクエストメッセージを、他のリクエストメッセージよりも優先的に受け付けてリクエスト処理部２へ転送する。   The request receiving unit 1 receives a request message transmitted from a user terminal. The request receiving unit 101 receives the received request message and transfers it to the request processing unit 2. The acceptance rejection unit 102 rejects acceptance of the received request message when the load detection unit 3 detects an overload state of the system. The priority determination unit 103 determines whether or not the received request message is a priority target, and further whether or not the priority reception condition is satisfied. The priority receiving unit 104 receives a request message that is a priority object and that is determined to satisfy the priority receiving conditions with priority over other request messages and transfers the request message to the request processing unit 2.

リクエスト処理部２は、前記リクエスト受信部１で正規に受け付けられたリクエストメッセージを処理し、例えば当該リクエストメッセージがコンテンツの配信要求であれば、コンテンツサーバ４からコンテンツを読み出して当該リクエストメッセージの送信元へ配信する。負荷検知部３は、前記リクエスト受信部１の負荷L1および／またはリクエスト処理部２の負荷L2を、例えばリクエスト受付部１０１で受付中のリクエスト数、優先受付部１０４で受付中のリクエスト数、あるいはリクエスト処理部２で処理中のリクエスト数等に基づいて検知し、総負荷Lが所定の上限値Lmaxを超えると、システムが過負荷状態にある旨を前記受付拒否部１０２へ通知する。   The request processing unit 2 processes the request message normally received by the request receiving unit 1. For example, if the request message is a content distribution request, the request processing unit 2 reads the content from the content server 4 and transmits the request message Deliver to. The load detection unit 3 is configured to determine the load L1 of the request reception unit 1 and / or the load L2 of the request processing unit 2, for example, the number of requests being received by the request reception unit 101, the number of requests being received by the priority reception unit 104, or When the request processing unit 2 detects the number of requests being processed and the like, and the total load L exceeds a predetermined upper limit Lmax, the request rejection unit 102 is notified that the system is in an overload state.

優先受付条件設定部５は、受付拒否したリクエストメッセージの再リクエストを後に優先的に受け付けるための優先受付条件を設定する。この優先受付条件としては、リクエストメッセージを優先的に受け付ける時間帯や、リクエストメッセージを優先的に受け付ける他のサーバのアドレスなどを設定できる。メッセージ送信部６は、前記優先受付条件の登録された案内メッセージを、前記受付拒否したリクエストメッセージの送信元（ユーザ端末）へ送信する。優先受付条件管理DB（データベース）７には、前記優先受付条件がリクエストメッセージの送信元IDと対応付けられて登録される。   The priority reception condition setting unit 5 sets priority reception conditions for preferentially receiving a re-request for a request message that has been rejected. As the priority reception condition, a time zone for preferentially receiving a request message, an address of another server for preferentially receiving a request message, and the like can be set. The message transmission unit 6 transmits the guide message in which the priority reception condition is registered to the transmission source (user terminal) of the request message for which the reception is rejected. In the priority reception condition management DB (database) 7, the priority reception conditions are registered in association with the transmission source ID of the request message.

図２は、本実施形態におけるリクエスト優先受付方法を示したフローチャートである。ステップS１において、ユーザ端末から送信されたリクエストメッセージがリクエスト受信部１で受信されると、ステップS２では、優先判定部１０３において、当該リクエストメッセージが優先対象であるか否かが判定される。本実施形態では、受信されたリクエストメッセージの送信元IDが優先受付条件管理DB７に登録されているか否かが判定され、未登録であれば、優先対象外の通常のリクエストメッセージと判定されてステップS３へ進む。   FIG. 2 is a flowchart showing a request priority receiving method according to the present embodiment. In step S1, when the request message transmitted from the user terminal is received by the request reception unit 1, in step S2, the priority determination unit 103 determines whether or not the request message is a priority target. In this embodiment, it is determined whether or not the transmission source ID of the received request message is registered in the priority reception condition management DB 7, and if it is not registered, it is determined as a normal request message that is not a priority target, and the step Proceed to S3.

ステップS３では、前記負荷検知部３により検知されている現在の総負荷Lが、過負荷状態の指標となる上限値Lmaxと比較され、総負荷Lが上限値Lmaxを上回っていなければステップS７へ進む。ステップS７では、当該リクエストメッセージがリクエスト受付部１０１で受け付けられる。ステップS８では、受け付けられたリクエストメッセージがリクエスト処理部２へ転送されて適宜に処理される。   In step S3, the current total load L detected by the load detection unit 3 is compared with an upper limit value Lmax serving as an index of an overload state. If the total load L does not exceed the upper limit value Lmax, the process proceeds to step S7. move on. In step S <b> 7, the request message is received by the request receiving unit 101. In step S8, the accepted request message is transferred to the request processing unit 2 and appropriately processed.

一方、前記ステップS３において、負荷Lが上限値Lmaxを上回っており、システムが過負荷の状態にあると判定されると、前記リクエストメッセージの受付が前記受付拒否部１０２で拒否されてステップS４へ進む。ステップS４では、現在の総負荷Lと他のリクエストメッセージに対して既に設定済みの優先受付条件等とに基づいて、当該リクエストメッセージに優先受付条件が設定される。本実施形態では、優先受付条件として再リクエストの優先受付時間帯が設定される。このとき、例えば時刻t1〜t2の時間帯が既に他の多くのリクエストメッセージの優先受付時間帯として割り当て済みであれば、次の時刻t2〜t3が優先受付時間帯として割り当てられる。   On the other hand, if it is determined in step S3 that the load L exceeds the upper limit Lmax and the system is overloaded, the acceptance of the request message is rejected by the acceptance refusal unit 102 and the process proceeds to step S4. move on. In step S4, based on the current total load L and the priority reception conditions already set for other request messages, the priority reception conditions are set for the request message. In the present embodiment, a priority reception time zone for re-requests is set as the priority reception condition. At this time, for example, if the time zone from time t1 to t2 has already been assigned as the priority reception time zone of many other request messages, the next time t2 to t3 is assigned as the priority reception time zone.

ステップS５では、前記設定された優先受付条件が、前記受付拒否されたリクエストメッセージの送信元IDと対応付けて優先受付条件管理DB７に登録される。ステップS６では、前記優先受付条件の登録された案内メッセージが、前記メッセージ送信部６からリクエストメッセージの送信元へ返信される。   In step S5, the set priority reception condition is registered in the priority reception condition management DB 7 in association with the transmission source ID of the request message rejected. In step S6, the guidance message in which the priority acceptance conditions are registered is returned from the message transmission unit 6 to the transmission source of the request message.

その後、当該案内メッセージを受信したユーザが、指定された優先受付時間帯にリクエストメッセージを再送信し、これがステップS１で受信されると、ステップS２では、その送信元IDが優先受付条件管理サーバ７に既登録と判定されるのでステップS９へ進む。ステップS９では、送信元IDと対応付けられた優先受付時間帯が検知される。そして、現在時刻が当該優先受付時間帯でなければ、優先対象外と判定されてステップS１２へ進み、当該リクエストメッセージが破棄される。これに対して、現在時刻が当該優先受付時間帯であれば、優先受付条件を満足するリクエストメッセージと判定されてステップS１０へ進む。ステップS１０では、前記優先受付部１０４においてリクエストメッセージが優先的に受け付けられる。ステップS１１では、受け付けられたリクエストメッセージがリクエスト処理部２へ転送されて適宜に処理される。   Thereafter, the user who has received the guidance message resends the request message in the designated priority reception time zone, and when this is received in step S1, the source ID is the priority reception condition management server 7 in step S2. Therefore, the process proceeds to step S9. In step S9, a priority reception time zone associated with the transmission source ID is detected. If the current time is not the priority reception time zone, it is determined that the current time is not a priority target, and the process proceeds to step S12, where the request message is discarded. On the other hand, if the current time is the priority reception time zone, it is determined that the request message satisfies the priority reception conditions, and the process proceeds to step S10. In step S10, the priority reception unit 104 receives the request message with priority. In step S11, the accepted request message is transferred to the request processing unit 2 and appropriately processed.

本実施形態によれば、受付拒否されたリクエストメッセージには優先受付条件が設定され、この優先受付条件を満足するリクエストメッセージは優先的に受け付けられるので、再リクエストの集中による輻輳を防止できるのみならず、リクエストメッセージの受付機会を公平化できる。さらに、本実施形態では優先受付条件として、リクエストメッセージを優先的に受け付ける時間帯が設定されるので、リクエストメッセージの再送信を時間的に分散できるようになる。   According to the present embodiment, a priority acceptance condition is set for a rejected request message, and a request message that satisfies this priority acceptance condition is preferentially accepted, so that only congestion due to concentration of re-requests can be prevented. The opportunity to accept request messages can be made fair. Furthermore, in the present embodiment, a time zone for preferentially receiving a request message is set as a priority reception condition, so that retransmission of request messages can be distributed over time.

図３は、本発明のリクエスト優先受付システムが適用されるコンテンツ配信システムの第２実施形態の構成を示した機能ブロック図であり、前記と同一の符号は同一または同等部分を表している。   FIG. 3 is a functional block diagram showing a configuration of a second embodiment of a content distribution system to which the request priority reception system of the present invention is applied, and the same reference numerals as those described above represent the same or equivalent parts.

本実施形態では、上記した第１実施形態と較べて、優先受付条件管理DB７に代えて確認識別子生成部１０を設けた点に特徴がある。この確認識別子生成部１０は、受付拒否した各リクエストメッセージに対して前記優先受付条件部５で設定された優先受付条件（本実施形態では、優先受付時間帯）と、当該リクエストメッセージの送信元IDとをパラメータとする関数計算（例えば、ハッシュ計算）を実行し、その値（ハッシュ値）を優先受付条件の確認識別子として求める。メッセージ送信部６は、前記優先受付条件および確認識別子を含む案内メッセージを送信する。   Compared with the first embodiment described above, the present embodiment is characterized in that a confirmation identifier generation unit 10 is provided instead of the priority reception condition management DB 7. The confirmation identifier generating unit 10 includes a priority reception condition (priority reception time zone in the present embodiment) set by the priority reception condition unit 5 for each request message that has been rejected, and a transmission source ID of the request message. And a function calculation (for example, a hash calculation) using and as a parameter, the value (hash value) is obtained as a confirmation identifier of the priority reception condition. The message transmission unit 6 transmits a guidance message including the priority acceptance condition and the confirmation identifier.

図４は、本実施形態におけるリクエスト優先受付方法を示したフローチャートである。ステップS１において、ユーザ端末から送信されたリクエストメッセージがリクエスト受信部１で受信されると、ステップS２では、優先判定部１０３において、当該リクエストメッセージが優先対象であるか否かが判定される。本実施形態では、受信されたリクエストメッセージに前記確認識別子が登録されているか否かが判定され、未登録であれば、優先対象外の通常のリクエストメッセージと判定されてステップS３へ進む。   FIG. 4 is a flowchart showing a request priority receiving method according to this embodiment. In step S1, when the request message transmitted from the user terminal is received by the request reception unit 1, in step S2, the priority determination unit 103 determines whether or not the request message is a priority target. In the present embodiment, it is determined whether or not the confirmation identifier is registered in the received request message. If it is not registered, it is determined as a normal request message that is not a priority target, and the process proceeds to step S3.

ステップS３では、前記負荷検知部３により検知されている現在の総負荷Lが上限値Lmaxと比較され、総負荷Lが上限値Lmaxを上回っていなければステップS７へ進む。ステップS７では、当該リクエストメッセージがリクエスト受付部１０１で受け付けられる。ステップS８では、受け付けられたリクエストメッセージがリクエスト処理部２へ転送される。   In step S3, the current total load L detected by the load detector 3 is compared with the upper limit value Lmax. If the total load L does not exceed the upper limit value Lmax, the process proceeds to step S7. In step S <b> 7, the request message is received by the request receiving unit 101. In step S8, the accepted request message is transferred to the request processing unit 2.

一方、前記ステップS３において、負荷Lが上限値Lmaxを上回っており、システムが過負荷の状態にあると判定されると、前記リクエストメッセージの受け付けが受付拒否部１０２で拒否されてステップS４へ進む。ステップS４では、優先受付条件として第１実施形態と同様に再リクエストの優先受付時間帯が設定される。ステップS５ａでは、受付拒否されたリクエストメッセージの送信元IDと前記設定された優先受付時間帯とをパラメータとするハッシュ計算が、前記確認識別子生成部１０で実行され、その計算結果（ハッシュ値）が優先受付条件の確認識別子として求められる。ステップS６では、前記優先受付条件および確認識別子の登録された案内メッセージが、前記メッセージ送信部６からリクエストメッセージの送信元へ返信される。   On the other hand, if it is determined in step S3 that the load L exceeds the upper limit Lmax and the system is overloaded, the acceptance of the request message is rejected by the acceptance refusal unit 102 and the process proceeds to step S4. . In step S4, a priority request reception time zone for re-requests is set as the priority reception condition as in the first embodiment. In step S5a, hash calculation using the transmission source ID of the rejected request message and the set priority reception time zone as parameters is executed by the confirmation identifier generation unit 10, and the calculation result (hash value) is obtained. It is obtained as a confirmation identifier for the priority acceptance condition. In step S6, the guidance message in which the priority acceptance condition and the confirmation identifier are registered is returned from the message transmission unit 6 to the transmission source of the request message.

その後、当該案内メッセージを受信したユーザが、指定された優先受付時間帯に前記確認識別子を含むリクエストメッセージを再送信し、これがステップS１で受信されると、ステップS２では、確認識別子が既登録と判定されるのでステップS９ａへ進む。ステップＳ９ａでは、優先判定部１０３において、受信したリクエストメッセージの送信元IDと受信時間帯とをパラメータとする関数計算が同様に実行される。ステップS９ｂでは、この計算結果が前記リクエストメッセージに既登録の確認識別子と比較される。両者が一致すれば当該リクエストメッセージが優先対象と判定されるので、ステップS１０以降へ進んで優先的に受け付けられる。   Thereafter, the user who has received the guidance message retransmits the request message including the confirmation identifier in the designated priority reception time zone, and when this is received in step S1, the confirmation identifier is already registered in step S2. Since it determines, it progresses to step S9a. In step S9a, the priority determination unit 103 similarly performs a function calculation using the transmission source ID of the received request message and the reception time zone as parameters. In step S9b, the calculation result is compared with the confirmation identifier already registered in the request message. If the two match, the request message is determined to be a priority object, so that the process proceeds to step S10 and thereafter and is preferentially accepted.

本実施形態によれば、リクエストメッセージの送信元IDと優先受付条件とを対応付ける優先受付条件管理DB７が不要になるので、システムの構成を簡素化できる。   According to the present embodiment, the priority reception condition management DB 7 that associates the transmission source ID of the request message with the priority reception condition is not necessary, and the system configuration can be simplified.

図５は、本発明のリクエスト優先受付システムが適用されるコンテンツ配信システムの第３実施形態の構成を示した機能ブロック図であり、前記と同一の符号は同一または同等部分を表している。   FIG. 5 is a functional block diagram showing the configuration of the third embodiment of the content distribution system to which the request priority reception system of the present invention is applied. The same reference numerals as those described above represent the same or equivalent parts.

本実施形態では、前記リクエスト受信部１とアドレスの異なる第２のリクエスト受信部８および第２のリクエスト処理部９を設け、前記リクエスト受信部１に設けられていた優先判定部１０３および優先受付部１０４を第２のリクエスト受信部８に移設した点に特徴がある。   In the present embodiment, a second request receiving unit 8 and a second request processing unit 9 having addresses different from those of the request receiving unit 1 are provided, and the priority determining unit 103 and the priority receiving unit provided in the request receiving unit 1 It is characterized in that 104 is moved to the second request receiving unit 8.

図６，７は、本実施形態におけるリクエスト優先受付方法を示したフローチャートであり、図６はリクエスト受信部１側の動作を示し、図７はリクエスト受信部８側の動作を示している。   6 and 7 are flowcharts showing the request priority receiving method in the present embodiment, FIG. 6 shows the operation on the request receiving unit 1 side, and FIG. 7 shows the operation on the request receiving unit 8 side.

図６のステップS１において、ユーザ端末から送信されたリクエストメッセージがリクエスト受信部１で受信されると、ステップS３では、前記負荷検知部３により検知されている総負荷Lが過負荷状態の指標となる上限値Lmaxと比較され、総負荷Lが上限値Lmaxを上回っていなければステップS７へ進む。ステップS７では、当該リクエストメッセージがリクエスト受付部１０１で受け付けられる。ステップS８では、受け付けられたリクエストメッセージがリクエスト処理部２へ転送される。   In step S1 of FIG. 6, when the request message transmitted from the user terminal is received by the request reception unit 1, in step S3, the total load L detected by the load detection unit 3 is an index of an overload state. If the total load L does not exceed the upper limit value Lmax, the process proceeds to step S7. In step S <b> 7, the request message is received by the request receiving unit 101. In step S8, the accepted request message is transferred to the request processing unit 2.

一方、前記ステップS３において、総負荷Lが上限値Lmaxを上回っており、システムが過負荷の状態にあると判定されるとステップS４へ進む。ステップS４では、優先受付条件としてリクエスト受信部８のアドレスが設定される。ステップS５では、リクエストメッセージの送信元IDが優先受付条件管理DB７に登録される。ステップS６では、前記優先受付条件（リクエスト受信部８のアドレス）の登録された案内メッセージが、メッセージ送信部６から前記リクエストメッセージの送信元へ返信される。   On the other hand, if it is determined in step S3 that the total load L exceeds the upper limit Lmax and the system is overloaded, the process proceeds to step S4. In step S4, the address of the request receiving unit 8 is set as the priority reception condition. In step S5, the transmission source ID of the request message is registered in the priority reception condition management DB 7. In step S6, the guide message in which the priority reception condition (address of the request receiving unit 8) is registered is returned from the message transmitting unit 6 to the transmission source of the request message.

その後、当該案内メッセージを受信したユーザが、通知されたリクエスト受信部８の宛先にリクエストメッセージを再送信すると、図７のステップS３１において、このリクエストメッセージがリクエスト受信部８で受信される。ステップS３２では、優先判定部１０３において、受信されたリクエストメッセージの送信元IDが優先受付条件管理DB７に登録されているか否かに基づいて、当該リクエストメッセージが優先対象であるか否かが判定される。   Thereafter, when the user who has received the guidance message retransmits the request message to the notified destination of the request receiving unit 8, the request receiving unit 8 receives the request message in step S31 of FIG. In step S32, the priority determination unit 103 determines whether or not the request message is a priority target based on whether or not the transmission source ID of the received request message is registered in the priority reception condition management DB 7. The

未登録であれば優先対象外と判定されてステップS３５へ進み、当該リクエストメッセージが破棄される。これに対して、既登録であれば優先対象と判定されてステップS３３へ進み、前記優先受付部１０４においてリクエストメッセージが受け付けられる。ステップS３４では、当該リクエストメッセージがリクエスト処理部２へ転送されて適宜に処理される。   If it is not registered, it is determined that it is not subject to priority, and the process proceeds to step S35, where the request message is discarded. On the other hand, if it is already registered, it is determined as a priority object and the process proceeds to step S33, and the priority reception unit 104 receives the request message. In step S34, the request message is transferred to the request processing unit 2 and appropriately processed.

本実施形態によれば、優先受付条件として、リクエストメッセージを優先的に受け付ける他のリクエスト受信手段のアドレスが設定されるので、リクエストメッセージの再送信を地理的に分散できるようになる。   According to the present embodiment, as the priority reception condition, the address of another request receiving unit that receives the request message with priority is set, so that retransmission of the request message can be geographically distributed.

なお、優先受付用のリクエスト受信部８は１つに限定されるものではなく、図８に一例を示した第４実施形態のように、２つあるいはそれ以上設け、例えばシステムの過負荷状態が検知された当初はリクエスト受信部８(a)のアドレスを優先受付先とし、このリクエスト受信部８(a)での優先受付数が上限に達した以降はリクエスト受信部８(b)のアドレスを優先受付先とするようにしても良い。   Note that the priority reception request receiving unit 8 is not limited to one, and two or more request receiving units are provided as in the fourth embodiment shown as an example in FIG. Initially, the address of the request receiving unit 8 (a) is set as the priority receiving destination, and after the number of priority receiving in the request receiving unit 8 (a) reaches the upper limit, the address of the request receiving unit 8 (b) is set. You may make it be a priority reception place.

さらに、上記した第３，第４実施形態では、優先受付条件としてリクエスト受信部８のアドレスを設定するものとして説明したが、本発明はこれのみに限定されるものではなく、第１実施形態をさらに適用し、リクエスト受信部８のアドレスと優先受付時間帯との組み合わせを優先受付条件として設定するようにしても良い。このようにすれば、リクエストメッセージの再送信を時間的および地理的に分散できるようになる。   In the third and fourth embodiments described above, the address of the request receiving unit 8 is set as the priority reception condition. However, the present invention is not limited to this, and the first embodiment is not limited to this. Further, a combination of the address of the request receiving unit 8 and the priority reception time zone may be set as the priority reception condition. In this way, retransmission of request messages can be distributed temporally and geographically.

本発明のリクエスト優先受付システムが適用されるコンテンツ配信システムの第１実施形態の構成を示した機能ブロック図である。It is a functional block diagram showing composition of a 1st embodiment of a contents distribution system to which a request priority reception system of the present invention is applied. 第１実施形態におけるリクエスト受付方法を示したフローチャートである。It is the flowchart which showed the request reception method in 1st Embodiment. 本発明のリクエスト優先受付システムが適用されるコンテンツ配信システムの第２実施形態の構成を示した機能ブロック図である。It is the functional block diagram which showed the structure of 2nd Embodiment of the content delivery system with which the request priority reception system of this invention is applied. 第２実施形態におけるリクエスト受付方法を示したフローチャートである。It is the flowchart which showed the request reception method in 2nd Embodiment. 本発明のリクエスト優先受付システムが適用されるコンテンツ配信システムの第３実施形態の構成を示した機能ブロック図である。It is the functional block diagram which showed the structure of 3rd Embodiment of the content delivery system with which the request priority reception system of this invention is applied. 第３実施形態におけるリクエスト受付方法（その１）を示したフローチャートである。It is the flowchart which showed the request reception method (the 1) in 3rd Embodiment. 第３実施形態におけるリクエスト受付方法（その２）を示したフローチャートである。It is the flowchart which showed the request reception method (the 2) in 3rd Embodiment. 本発明のリクエスト優先受付システムが適用されるコンテンツ配信システムの第４実施形態の構成を示した機能ブロック図である。It is the functional block diagram which showed the structure of 4th Embodiment of the content delivery system with which the request priority reception system of this invention is applied.

符号の説明Explanation of symbols

１…リクエスト受信部，２…リクエスト処理部，３…負荷検知部，４…コンテンツサーバ，５…優先受付条件設定部，６…メッセージ送信部，７…優先受付条件管理DB，１０１…リクエスト受付部，１０２…受付拒否部，１０３…優先判定部，１０４…優先受付部   DESCRIPTION OF SYMBOLS 1 ... Request receiving part, 2 ... Request processing part, 3 ... Load detection part, 4 ... Content server, 5 ... Priority reception condition setting part, 6 ... Message transmission part, 7 ... Priority reception condition management DB, 101 ... Request reception part , 102 ... Acceptance rejection unit, 103 ... Priority determination unit, 104 ... Priority reception unit

Claims (8)

受信したリクエストメッセージを受け付けて処理し、受け付けられなかったリクエストメッセージに所定の優先受付条件を設定し、当該優先受付条件を満足する再リクエストを優先的に受け付けるリクエスト優先受付システムにおいて、
リクエストメッセージを受信して受け付けるリクエスト受信手段と、
受け付けられたリクエストメッセージを処理するリクエスト処理手段と、
前記リクエスト受付および／またはリクエスト処理の負荷を検知する負荷検知手段と、
前記検知された負荷が所定の上限値を超えた状態でのリクエストメッセージの受け付けを拒否する受付拒否手段と、
前記受付拒否したリクエストメッセージに所定の優先受付条件を設定する優先受付条件設定手段と、
前記受付拒否したリクエストメッセージの送信元へ前記優先受付条件を通知する優先受付条件通知手段と、
前記優先受付条件を満足するリクエストメッセージを優先的に受け付ける優先受付手段とを含むことを特徴とするリクエスト優先受付システム。 In the request priority reception system that receives and processes the received request message, sets a predetermined priority reception condition to the request message that has not been received, and preferentially receives a re-request that satisfies the priority reception condition.
A request receiving means for receiving and receiving a request message;
A request processing means for processing the received request message;
Load detection means for detecting the load of the request reception and / or request processing;
An acceptance refusal means for refusing acceptance of a request message in a state where the detected load exceeds a predetermined upper limit;
Priority acceptance condition setting means for setting a predetermined priority acceptance condition for the request message rejected;
Priority acceptance condition notifying means for notifying the priority acceptance condition to the transmission source of the rejected request message;
And a priority receiving unit that preferentially receives a request message that satisfies the priority receiving condition. 受信したリクエストメッセージが優先対象であるか否かを判定する優先判定手段を含み、
前記優先受付手段は、優先対象と判定されたリクエストメッセージのみを優先的に受け付けることを特徴とする請求項1に記載のリクエスト優先受付システム。 Including priority determination means for determining whether or not the received request message is a priority target;
2. The request priority reception system according to claim 1, wherein the priority reception unit preferentially receives only request messages determined to be priority targets. 前記優先受付条件設定手段は、リクエストメッセージに設定した優先受付条件を当該リクエストメッセージの送信元IDと対応付けてデータベースに登録し、
前記優先判定手段は、受信したリクエストメッセージの送信元IDと対応付けられた優先受付条件が満足されているリクエストメッセージを優先対象と判定することを特徴とする請求項２に記載のリクエスト優先受付システム。 The priority reception condition setting means registers the priority reception condition set in the request message in the database in association with the transmission source ID of the request message,
The request priority reception system according to claim 2, wherein the priority determination unit determines that a request message satisfying a priority reception condition associated with a transmission source ID of the received request message is a priority object. . 前記リクエストメッセージに設定した優先受付条件に所定の関数計算を実行して確認識別子を生成する確認識別子生成手段をさらに具備し、
前記優先受付条件通知手段は、前記確認識別子および優先受付条件をリクエストメッセージの送信元へ通知し、
前記優先判定手段は、受信したリクエストメッセージの優先受付条件に前記関数計算を実行して求めた確認識別子と当該リクエストメッセージに登録されている確認識別子とを比較し、両者が一致したリクエストメッセージを優先対象と判定することを特徴とする請求項２に記載のリクエスト優先受付システム。 A confirmation identifier generating means for generating a confirmation identifier by executing a predetermined function calculation on the priority reception condition set in the request message;
The priority reception condition notification means notifies the confirmation identifier and the priority reception condition to the transmission source of the request message,
The priority determination means compares the confirmation identifier obtained by executing the function calculation with the priority reception condition of the received request message and the confirmation identifier registered in the request message, and gives priority to the request message that matches both 3. The request priority reception system according to claim 2, wherein the request priority reception system is determined as a target. 前記優先条件設定手段は、前記優先受付条件として、リクエストメッセージを優先的に受け付ける時間帯を設定することを特徴とする請求項１ないし４のいずれかに記載のリクエスト優先受付システム。   5. The request priority reception system according to claim 1, wherein the priority condition setting unit sets a time zone for preferentially receiving a request message as the priority reception condition. 前記優先条件設定手段は、前記優先受付条件として、リクエストメッセージを優先的に受け付ける他のリクエスト受信手段のアドレスを設定することを特徴とする請求項１または２に記載のリクエスト優先受付システム。   The request priority reception system according to claim 1 or 2, wherein the priority condition setting unit sets an address of another request reception unit that receives a request message with priority as the priority reception condition. 前記優先条件設定手段は、前記優先受付条件として、リクエストメッセージを優先的に受け付ける時間帯および他のリクエスト受信手段のアドレスを設定することを特徴とする請求項１または２に記載のリクエスト優先受付システム。   3. The request priority reception system according to claim 1, wherein the priority condition setting unit sets a time zone for preferentially receiving a request message and an address of another request reception unit as the priority reception condition. . 受信したリクエストメッセージを受け付けて処理し、受け付けられなかったリクエストメッセージに所定の優先受付条件を設定し、当該優先受付条件を満足する再リクエストを優先的に受け付けるリクエスト優先受付方法において、
リクエストメッセージを受信して受け付ける手順と、
受け付けられたリクエストメッセージを処理する手順と、
前記リクエスト受付および／またはリクエスト処理の負荷を検知する手順と、
前記検知された負荷が所定の上限値を超えた状態でのリクエストメッセージの受け付けを拒否する手順と、
前記受付拒否したリクエストメッセージに所定の優先受付条件を設定する手順と、
前記受付拒否したリクエストメッセージの送信元へ前記優先受付条件を通知する手順と、
受信したリクエストメッセージが優先対象であるか否かを判定する手順と、
優先対象と判定されたリクエストメッセージのみを優先的に受け付ける手順とを含むことを特徴とするリクエスト優先受付方法。
In the request priority reception method for receiving and processing a received request message, setting a predetermined priority reception condition for a request message that has not been received, and preferentially receiving a re-request that satisfies the priority reception condition,
Receiving and accepting request messages,
Procedures for processing accepted request messages;
A procedure for detecting a load of the request reception and / or request processing;
A procedure for rejecting acceptance of a request message in a state where the detected load exceeds a predetermined upper limit;
A procedure for setting a predetermined priority acceptance condition for the rejected request message;
A procedure for notifying the priority acceptance condition to the transmission source of the rejected request message;
A procedure for determining whether the received request message is a priority target;
A request priority receiving method, comprising: a step of preferentially receiving only request messages determined to be priority targets.
JP2006036979A 2006-02-14 2006-02-14 Request priority reception method and system Active JP4726067B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2006036979A JP4726067B2 (en) 2006-02-14 2006-02-14 Request priority reception method and system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2006036979A JP4726067B2 (en) 2006-02-14 2006-02-14 Request priority reception method and system

Publications (2)

Publication Number Publication Date
JP2007219650A true JP2007219650A (en) 2007-08-30
JP4726067B2 JP4726067B2 (en) 2011-07-20

Family

ID=38496912

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006036979A Active JP4726067B2 (en) 2006-02-14 2006-02-14 Request priority reception method and system

Country Status (1)

Country Link
JP (1) JP4726067B2 (en)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009223810A (en) * 2008-03-18 2009-10-01 Nomura Research Institute Ltd Flow rate controller
WO2010035652A1 (en) * 2008-09-26 2010-04-01 株式会社エヌ・ティ・ティ・ドコモ Data receiving terminal, data distribution server, data distribution system, and data distribution method
JP2011109456A (en) * 2009-11-18 2011-06-02 Ntt Docomo Inc Communication broadcasting cooperation system
JP2011134284A (en) * 2009-12-25 2011-07-07 Fujitsu Ltd Communication control device, information processing apparatus, communication control system, communication control method and information processing method
WO2011121921A1 (en) * 2010-03-29 2011-10-06 パナソニック株式会社 Communication node and network node
JP2013206179A (en) * 2012-03-28 2013-10-07 Japan Research Institute Ltd Access management server, access management method, and customer terminal thereof

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002189650A (en) * 2000-12-20 2002-07-05 Hitachi Ltd Method and device for controlling computer, and recording medium stored with processing program therefor
JP2002222123A (en) * 2001-01-25 2002-08-09 Ibm Japan Ltd Connection accepting system, accepting server, client terminal, connection acceptance management method, storage medium, and computer program
JP2002259234A (en) * 2001-03-06 2002-09-13 Matsushita Electric Ind Co Ltd Device and program for controlling access
JP2003058499A (en) * 2001-08-10 2003-02-28 Fujitsu Ltd Server, program and medium for managing load

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002189650A (en) * 2000-12-20 2002-07-05 Hitachi Ltd Method and device for controlling computer, and recording medium stored with processing program therefor
JP2002222123A (en) * 2001-01-25 2002-08-09 Ibm Japan Ltd Connection accepting system, accepting server, client terminal, connection acceptance management method, storage medium, and computer program
JP2002259234A (en) * 2001-03-06 2002-09-13 Matsushita Electric Ind Co Ltd Device and program for controlling access
JP2003058499A (en) * 2001-08-10 2003-02-28 Fujitsu Ltd Server, program and medium for managing load

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009223810A (en) * 2008-03-18 2009-10-01 Nomura Research Institute Ltd Flow rate controller
WO2010035652A1 (en) * 2008-09-26 2010-04-01 株式会社エヌ・ティ・ティ・ドコモ Data receiving terminal, data distribution server, data distribution system, and data distribution method
JP2010081397A (en) * 2008-09-26 2010-04-08 Ntt Docomo Inc Data reception terminal, data distribution server, data distribution system, and method for distributing data
CN102165800A (en) * 2008-09-26 2011-08-24 株式会社Ntt都科摩 Data receiving terminal, data distribution server, data distribution system, and data distribution method
RU2502222C2 (en) * 2008-09-26 2013-12-20 Нтт Докомо, Инк. Data receiving terminal, data distribution server, data distribution system and data distribution method
JP2011109456A (en) * 2009-11-18 2011-06-02 Ntt Docomo Inc Communication broadcasting cooperation system
JP2011134284A (en) * 2009-12-25 2011-07-07 Fujitsu Ltd Communication control device, information processing apparatus, communication control system, communication control method and information processing method
WO2011121921A1 (en) * 2010-03-29 2011-10-06 パナソニック株式会社 Communication node and network node
US8886167B2 (en) 2010-03-29 2014-11-11 Panasonic Intellectual Property Corporation Of America Communication node and network node
JP5773988B2 (en) * 2010-03-29 2015-09-02 パナソニック インテレクチュアル プロパティ コーポレーション オブアメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ Communication node and network node
JP2013206179A (en) * 2012-03-28 2013-10-07 Japan Research Institute Ltd Access management server, access management method, and customer terminal thereof

Also Published As

Publication number Publication date
JP4726067B2 (en) 2011-07-20

Similar Documents

Publication Publication Date Title
JP4726067B2 (en) Request priority reception method and system
KR100740874B1 (en) System and method for controlling multimedia broadcast multicast service for load distribution
KR101412235B1 (en) Method and apparatus for screening request to establish sip session
JP4540713B2 (en) PT service restriction method
US8856326B2 (en) Enhanced media control
CN102090042A (en) Message restriction for Diameter servers
US20030081595A1 (en) Method and router for connecting server and client
US8838063B2 (en) Method and apparatus for providing emergency communication service in a wireless communication system
EP3649761B1 (en) User data transported over non-access stratum
JP2000032048A (en) Network system
KR102116066B1 (en) Method and apparatus of access control for connected terminal
CN103125142A (en) Common quality of service enforcement for a group of mobile entities
WO2000014920A2 (en) Method and apparatus for data routing, delivery, and authentication in a packet data network
US10547887B2 (en) Managing wireless transmission capacity
WO2005076549A1 (en) Distribution request control method and unit, and program for distribution request control method
EP1154597B1 (en) Congestion control method and system
US7007087B1 (en) System and method for rejecting services in a information service system
WO2008112398A1 (en) Channel access arbitration mechanism for walkie-talkie devices
US8386777B2 (en) Method and equipment for controlling access to multicast IP flows
US20090005054A1 (en) Status notification method in wireless communication apparatus
EP3308515A1 (en) Protecting iaps from ddos attacks
CN108259408B (en) Information transmission method, server and system
CN106559771A (en) A kind of method and apparatus of wireless terminal fast roaming
JP2010231353A (en) Self-supporting access concentration relaxation system
JP5699202B1 (en) Call processing system, load distribution method, and load distribution program

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20080821

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20101224

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110112

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110314

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110406

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110407

R150 Certificate of patent or registration of utility model

Ref document number: 4726067

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140422

Year of fee payment: 3