JP7740368B2

JP7740368B2 - サーバ内データ転送装置、サーバ内データ転送方法およびプログラム

Info

Publication number: JP7740368B2
Application number: JP2023565685A
Authority: JP
Inventors: 廣名取; 圭藤本; 育生大谷; 奨悟斎藤
Original assignee: Nippon Telegraph and Telephone Corp; NTT Inc USA
Current assignee: NTT Inc; NTT Inc USA
Priority date: 2021-12-06
Filing date: 2021-12-06
Publication date: 2025-09-17
Anticipated expiration: 2041-12-06
Also published as: WO2023105578A1; JPWO2023105578A1

Description

本発明は、サーバ内データ転送装置、サーバ内データ転送方法およびプログラムに関する。

ＮＦＶ（Network Functions Virtualization：ネットワーク機能仮想化）による仮想化技術の進展などを背景に、サービス毎にシステムを構築して運用することが行われている。また、上記サービス毎にシステムを構築する形態から、サービス機能を再利用可能なモジュール単位に分割し、独立した仮想マシン（ＶＭ：Virtual Machineやコンテナなど）環境の上で動作させることで、部品のようにして必要に応じて利用し運用性を高めるといったＳＦＣ（Service Function Chaining）と呼ばれる形態が主流となりつつある。

仮想マシンを構成する技術としてLinux（登録商標）とＫＶＭ（kernel-based virtual machine）で構成されたハイパーバイザー環境が知られている。この環境では、ＫＶＭモジュールが組み込まれたHost OS（物理サーバ上にインストールされたＯＳをHost OSと呼ぶ）がハイパーバイザーとしてカーネル空間と呼ばれるユーザ空間とは異なるメモリ領域で動作する。この環境においてユーザ空間にて仮想マシンが動作し、その仮想マシン内にGuest OS（仮想マシン上にインストールされたＯＳをGuest OSと呼ぶ）が動作する。

Guest OSが動作する仮想マシンは、Host OSが動作する物理サーバとは異なり、（イーサネット（登録商標）カードデバイスなどに代表される）ネットワークデバイスを含むすべてのＨＷ（hardware）が、ＨＷからGuest OSへの割込処理やGuest OSからハードウェアへの書き込みに必要なレジスタ制御となる。このようなレジスタ制御では、本来物理ハードウェアが実行すべき通知や処理がソフトウェアで擬似的に模倣されるため、性能がHost OS環境に比べ、低いことが一般的である。

この性能劣化において、特にGuest OSから自仮想マシン外に存在するHost OSや外部プロセスに対して、ＨＷの模倣を削減し、高速かつ統一的なインターフェイスにより通信の性能と汎用性を向上させる技術がある。この技術として、virtioというデバイスの抽象化技術、つまり準仮想化技術が開発されており、すでにLinux（登録商標）を始め、FreeBSD（登録商標）など多くの汎用ＯＳに組み込まれ、現在利用されている（特許文献１，２参照）。

virtioでは、コンソール、ファイル入出力、ネットワーク通信といったデータ入出力に関して、転送データの単一方向の転送用トランスポートとして、リングバッファで設計されたキューによるデータ交換をキューのオペレーションにより定義している。そして、virtioのキューの仕様を利用して、それぞれのデバイスに適したキューの個数と大きさをGuest OS起動時に用意することにより、Guest OSと自仮想マシン外部との通信を、ハードウェアエミュレーションを実行せずにキューによるオペレーションだけで実現することができる。

サーバ内のデータ転送技術としてNew API(NAPI)、ＤＰＤＫ（Data Plane Development Kit）、ＫＢＰ（Kernel Busy Poll）がある。

New API(NAPI)は、パケットが到着するとハードウェア割込要求の後、ソフトウェア割込要求によりパケット処理を行う（非特許文献１参照）（後記図１５参照）。

ＤＰＤＫは、アプリケーションが動作するユーザスペースでパケット処理機能を実現し、ユーザスペースからpollingモデルでパケット到着時に即時刈取りを行う（非特許文献２参照）。詳細には、ＤＰＤＫは、従来Linux kernel（登録商標）が行っていたＮＩＣ（Network Interface Card）の制御をユーザ空間で行うためのフレームワークである。Linux kernelにおける処理との最大の違いは、ＰＭＤ（Pull Mode Driver）と呼ばれるポーリングベースの受信機構を持つことである。通常、Linux kernelでは、ＮＩＣへのデータの到達を受けて、割込が発生し、それを契機に受信処理が実行される。一方、ＰＭＤは、データ到達の確認や受信処理を専用のスレッドが継続的に行う。コンテキストスイッチや割込などのオーバーヘッドを排除することで高速なパケット処理を行うことができる。ＤＰＤＫは、パケット処理のパフォーマンスとスループットを大幅に高めて、データプレーン・アプリケーション処理に多くの時間を確保することを可能にする。ただし、ＤＰＤＫは、ＣＰＵ（Central Processing Unit）やＮＩＣなどのコンピュータ資源を占有的に使用する。

非特許文献３には、サーバ内ネットワーク遅延制御装置（ＫＢＰ：Kernel Busy Poll）が記載されている。ＫＢＰは、kernel内でpollingモデルによりパケット到着を常時監視する。これにより、softIRQを抑止し、低遅延なパケット処理を実現する。

［New API(NAPI)によるＲｘ側パケット処理］
図１５は、Linux kernel 2.5/2.6より実装されているNew API(NAPI)によるＲｘ側パケット処理の概略図である（非特許文献１参照）。
図１５に示すように、New API(NAPI)は、OS７０（例えば、Host OS）を備えるサーバ上で、ユーザが使用可能なuser space６０に配置されたデータ処理ＡＰＬ１を実行し、OS７０に接続されたＨＷ１０のＮＩＣ１１とデータ処理ＡＰＬ１との間でパケット転送を行う。

OS７０は、kernel７１、Ring Buffer７２、およびDriver７３を有し、kernel７１は、プロトコル処理部７４を有する。
Kernel７１は、OS７０（例えば、Host OS）の基幹部分の機能であり、ハードウェアの監視やプログラムの実行状態をプロセス単位で管理する。ここでは、kernel７１は、データ処理ＡＰＬ１からの要求に応えるとともに、ＨＷ１０からの要求をデータ処理ＡＰＬ１に伝える。Kernel７１は、データ処理ＡＰＬ１からの要求に対して、システムコール（「非特権モードで動作しているユーザプログラム」が「特権モードで動作しているカーネル」に処理を依頼）を介することで処理する。
Kernel７１は、Socket７５を介して、データ処理ＡＰＬ１へパケットを伝達する。Kernel７１は、Socket７５を介してデータ処理ＡＰＬ１からパケットを受信する。

Ring Buffer７２は、Kernel７１が管理し、サーバ中のメモリ空間にある。Ring Buffer７２は、Kernel７１が出力するメッセージをログとして格納する一定サイズのバッファであり、上限サイズを超過すると先頭から上書きされる。

Driver７３は、kernel７１でハードウェアの監視を行うためデバイスドライバである。なお、Driver７３は、kernel７１に依存し、作成された（ビルドされた）カーネルソースが変われば、別物になる。この場合、該当ドライバ・ソースを入手し、ドライバを使用するOS上で再ビルドし、ドライバを作成することになる。

プロトコル処理部７４は、ＯＳＩ（Open Systems Interconnection）参照モデルが定義するＬ２（データリンク層）／Ｌ３（ネットワーク層）／Ｌ４（トランスポート層）のプロトコル処理を行う。

Socket７５は、kernel７１がプロセス間通信を行うためのインターフェイスである。Socket７５は、ソケットバッファを有し、データのコピー処理を頻繁に発生させない。Socket７５を介しての通信確立までの流れは、下記の通りである。1.サーバ側がクライアントを受け付けるソケットファイルを作成する。2.受付用ソケットファイルに名前をつける。3.ソケット・キューを作成する。4.ソケット・キューに入っているクライアントからの接続の最初の1つを受け付ける。5.クライアント側ではソケットファイルを作成する。6.クライアント側からサーバへ接続要求を出す。7.サーバ側で、受付用ソケットファイルとは別に、接続用ソケットファイルを作成する。通信確立の結果、データ処理ＡＰＬ１は、kernel７１に対してread()やwrite()などのシステムコールを呼び出せるようになる。

以上の構成において、Kernel７１は、ＮＩＣ１１からのパケット到着の知らせを、ハードウェア割込（hardIRQ）により受け取り、パケット処理のためのソフトウェア割込（softIRQ）をスケジューリングする。
上記、Linux kernel 2.5/2.6より実装されているNew API(NAPI)は、パケットが到着するとハードウェア割込（hardIRQ）の後、ソフトウェア割込（softIRQ）により、パケット処理を行う。図１５に示すように、割込モデルによるパケット転送は、割込処理（図１５の符号ａ参照）によりパケットの転送を行うため、割込処理の待ち合わせが発生し、パケット転送の遅延が大きくなる。

以下、NAPI Rx側パケット処理概要について説明する。
［New API(NAPI)によるＲｘ側パケット処理構成］
図１６は、図１５の破線で囲んだ箇所におけるNew API(NAPI)によるＲｘ側パケット処理の概要を説明する図である。
<Device driver>
図１６に示すように、Device driverには、ネットワークインターフェースカードであるNIC１１（物理NIC）、NIC１１の処理要求の発生によって呼び出され要求された処理（ハードウェア割込）を実行するハンドラであるhardIRQ８１、およびソフトウェア割込の処理機能部であるnetif_rx８２が配置される。

<Networking layer>
Networking layerには、netif_rx８２の処理要求の発生によって呼び出され要求された処理（ソフトウェア割込）を実行するハンドラであるsoftIRQ８３、ソフトウェア割込（softIRQ）の実体を行う制御機能部であるdo_softirq８４が配置される。また、ソフトウェア割込（softIRQ）を受けて実行するパケット処理機能部であるnet_rx_action８５、ＮＩＣ１１からのハードウェア割込がどのデバイスのものであるかを示すネットデバイス（net_device）の情報を登録するpoll_list８６、sk_buff構造体（Kernel７１が、パケットがどうなっているかを知覚できるようにするための構造体）を作成するnetif_receive_skb８７、Ring Buffer７２が配置される。

<Protocol layer>
Protocol layerには、パケット処理機能部であるip_rcv８８、arp_rcv８９等が配置される。

上記netif_rx８２、do_softirq８４、net_rx_action８５、netif_receive_skb８７、ip_rcv８８、およびarp_rcv８９は、Kernel７１の中でパケット処理のために用いられるプログラムの部品（関数の名称）である。

［New API(NAPI)によるＲｘ側パケット処理動作］
図１６の矢印（符号）ｂ～ｍは、Ｒｘ側パケット処理の流れを示している。
NIC１１のhardware機能部１１ａ（以下、NIC１１という）が、対向装置からフレーム内にパケット（またはフレーム）を受信すると、ＤＭＡ（Direct Memory Access）転送によりＣＰＵを使用せずに、Ring Buffer７２へ到着したパケットをコピーする（図１６の符号ｂ参照）。このRing Buffer７２は、サーバの中にあるメモリ空間で、Kernel７１（図１５参照）が管理している。

しかし、NIC１１が、Ring Buffer７２へ到着したパケットをコピーしただけでは、Kernel７１は、そのパケットを認知できない。そこで、NIC１１は、パケットが到着すると、ハードウェア割込（hardIRQ）をhardIRQ８１に上げ（図１６の符号ｃ参照）、netif_rx８２が下記の処理を実行することで、Kernel７１は、当該パケットを認知する。なお、図１６の楕円で囲んで示すhardIRQ８１は、機能部ではなくハンドラを表記する。

netif_rx８２は、実際に処理をする機能であり、hardIRQ８１（ハンドラ）が立ち上がると（図１６の符号ｄ参照）、poll_list８６に、ハードウェア割込（hardIRQ）の中身の情報の１つである、ＮＩＣ１１からのハードウェア割込がどのデバイスのものであるかを示すネットデバイス（net_device）の情報を保存して、キューの刈取りを登録する（図１６の符号ｇ参照）。ここで、キューの刈取りとは、バッファに溜まっているパケットの中身を参照して、そのパケットの処理を、次に行う処理を考慮してバッファから該当するキューのエントリを削除することである。具体的には、netif_rx８２は、Ring Buffer７２にパケットが詰め込まれたことを受けて、NIC１１のドライバを使って、以後のキューの刈取りをpoll_list８６に登録する（図１６の符号ｅ参照）。これにより、poll_list８６には、Ring Buffer７２にパケットが詰め込まれたことによる、キューの刈取り情報が登録される。

このように、図１６の<Device driver>において、NIC１１は、パケットを受信すると、ＤＭＡ転送によりRing Buffer７２へ到着したパケットをコピーする。また、NIC１１は、hardIRQ８１（ハンドラ）を上げ、netif_rx８２は、poll_list８６にnet_deviceを登録し、ソフトウェア割込（softIRQ）をスケジューリングする。
ここまでで、図１６の<Device driver>におけるハードウェア割込の処理は停止する。

その後、netif_rx８２は、poll_list８６に積まれているキューに入っている情報（具体的にはポインタ）を用いて、Ring Buffer７２に格納されているデータを刈取ることを、ソフトウェア割込（softIRQ）でsoftIRQ８３（ハンドラ）に上げ（図１６の符号ｆ参照）、ソフトウェア割込の制御機能部であるdo_softirq８４に通知する（図１６の符号ｇ参照）。

do_softirq８４は、ソフトウェア割込制御機能部であり、ソフトウェア割込の各機能を定義（パケット処理は各種あり、割込処理はそのうちの一つ。割込処理を定義する）している。do_softirq８４は、この定義をもとに、実際にソフトウェア割込処理を行うnet_rx_action８５に、今回の（該当の）ソフトウェア割込の依頼を通知する（図１６の符号ｈ参照）。

net_rx_action８５は、softIRQの順番がまわってくると、poll_list８６に登録されたnet_deviceをもとに（図１６の符号ｉ参照）、Ring Buffer７２からパケットを刈取るためのポーリングルーチンを呼び出し、パケットを刈取る（図１６の符号ｊ参照）。このとき、net_rx_action８５は、poll_list８６が空になるまで刈取りを続ける。
その後、net_rx_action８５は、netif_receive_skb８７に通達をする（図１６の符号ｋ参照）。

netif_receive_skb８７は、sk_buff構造体を作り、パケットの内容を解析し、タイプ毎に後段のプロトコル処理部７４（図１５参照）へ処理をまわす。すなわち、netif_receive_skb８７は、パケットの中身を解析し、パケットの中身に応じて処理をする場合には、<Protocol layer>のip_rcv８８に処理を回し（図１６の符号ｌ）、また、例えばＬ２であればarp_rcv８９に処理をまわす（図１６の符号ｍ）。

図１７は、映像（３０ＦＰＳ）のデータ転送例である。図１７に示すワークロードは、転送レート３５０Ｍｂｐｓで、３０ｍｓごとに間欠的にデータ転送を行っている。

図１８は、非特許文献３に記載のＫＢＰにおける、busy poll threadが使用するＣＰＵ使用率を示す図である。
図１８に示すように、ＫＢＰでは、kernel threadはbusy pollを行うために、ＣＰＵコアを専有する。図１７に示す間欠的なパケット受信であっても、ＫＢＰでは、パケット到着有無に関わらず常にＣＰＵを使用するため、消費電力が大きくなる課題がある。

次に、ＤＰＤＫシステムについて説明する。
［ＤＰＤＫシステム構成］
図１９は、アクセラレータ１２０を備えるＨＷ１１０の制御を行うＤＰＤＫシステムの構成を示す図である。
ＤＰＤＫシステムは、ＨＷ１１０、ＯＳ１４０、user space（ユーザ空間）１６０上に配置されたデータ高速転送ミドルウェアであるＤＰＤＫ１５０、データ処理ＡＰＬ１を有する。
データ処理ＡＰＬ１は、ＡＰＬの実行に先立って行われるパケット処理である。
ＨＷ１１０は、データ処理ＡＰＬ１との間でデータ送受信の通信を行う。以下の説明において、図１９に示すように、データ処理ＡＰＬ１が、ＨＷ１１０からのパケットを受け取るデータの流れをＲｘ側受信と称し、データ処理ＡＰＬ１が、ＨＷ１１０にパケットを送信するデータの流れをＴｘ側送信と称する。

ＨＷ１１０は、アクセラレータ１２０と、通信ネットワークに接続するためのＮＩＣ１３０（物理NIC）と、を備える。
アクセラレータ１２０は、ＣＰＵからの入力をもとに、特定の演算を高速に行う計算ユニットハードウェアである。アクセラレータ１２０は、具体的には、ＧＰＵ（Graphics Processing Unit）やＦＰＧＡ（Field Programmable Gate Array）等のＰＬＤ（Programmable Logic Device）である。図１９では、アクセラレータ１２０は、複数のＣｏｒｅ（Ｃｏｒｅプロセッサ）１２１、データを先入れ先出しのリスト構造で保持するＲｘキュー（queue：待ち行列）１２２およびＴｘキュー１２３を備える。

アクセラレータ１２０にデータ処理ＡＰＬ１の処理の一部をオフロードし、ソフトウェア（ＣＰＵ処理）のみでは到達できない性能や電力効率を実現する。
ＮＦＶ（Network Functions Virtualization）やＳＤＮ（Software Defined Network）を構成するデータセンタなど、大規模なサーバクラスタにおいて、上記のようなアクセラレータ１２０を適用するケースが想定される。

ＮＩＣ１３０は、ＮＷインターフェイスを実現するＮＩＣハードウェアであり、データを先入れ先出しのリスト構造で保持するＲｘキュー１３１およびＴｘキュー１３２を備える。ＮＩＣ１３０は、例えば通信ネットワークを介して対向装置１７０に接続され、パケット送受信を行う。
なお、ＮＩＣ１３０は、例えばアクセラレータ付きのＮＩＣであるＳｍａｒｔＮＩＣであってもよい。ＳｍａｒｔＮＩＣは、処理能力が落ちる原因となるＩＰパケット処理など、負荷のかかる処理をオフロードしてＣＰＵの負荷を軽減することができるＮＩＣである。

ＤＰＤＫ１５０は、ＮＩＣの制御をuser space１６０で行うためのフレームワークであり、具体的にはデータ高速転送ミドルウェアからなる。ＤＰＤＫ１５０は、ポーリングベースの受信機構であるＰＭＤ（Poll Mode Driver）１５１（データ到着をポーリングモードまたは割込モードで選択可能なドライバ）を有する。ＰＭＤ１５１は、データ到達の確認や受信処理を専用のスレッドが継続的に行う。

ＤＰＤＫ１５０は、ＡＰＬが動作するuser space１６０でパケット処理機能を実現し、user space１６０からpollingモデルでパケット到着時に即時刈取りを行うことで、パケット転送遅延を小さくすることを可能にする。すなわち、ＤＰＤＫ１５０は、polling（ＣＰＵでキューをbusy poll）によりパケットの刈取りを行うため、待ち合わせがなく遅延小である。

特開２０１５－１９７８７４号公報特開２０１８－３２１５６号公報

New API Intel, ［online］,［令和３年１１月５日検索］,インターネット〈http://lwn.net/2002/0321/a/napi-howto.php3〉 "リソース設定(NIC) ～DPDK入門第6回～," NTTテクノクロス, ［online］,［令和３年１１月５日検索］,インターネット〈https://www.ntt-tx.co.jp/column/dpdk_blog/190610/〉 Kei Fujimoto, Kenichi Matsui, Masayuki Akutsu, "KBP: Kernel Enhancements for Low-Latency Networking without Application Customization in Virtual Server", IEEE CCNC 2021.

しかしながら、割込モデルとポーリングモデルによるパケット転送のいずれについても下記課題がある。
割込モデルは、ＨＷからイベント（ハードウェア割込）を受けたkernelがパケット加工を行うためのソフトウェア割込処理によってパケット転送を行う。このため、割込モデルは、割込（ソフトウェア割込）処理によりパケット転送を行うので、他の割込との競合や、割込先ＣＰＵがより優先度の高いプロセスに使用されていると待ち合わせが発生し、パケット転送の遅延が大きくなるといった課題がある。この場合、割込処理が混雑すると、更に待ち合わせ遅延は大きくなる。

割込モデルにおいて、遅延が発生するメカニズムについて補足する。
一般的なkernelは、パケット転送処理はハードウェア割込処理の後、ソフトウェア割込処理にて伝達される。
パケット転送処理のソフトウェア割込が発生した際に、下記条件（１）～（３）においては、上記のソフトウェア割込処理を即時に実行することができない。このため、ksoftirqd（ＣＰＵ毎のカーネルスレッドであり、ソフトウェア割込の負荷が高くなったときに実行される）等のスケジューラにより調停され、割込処理がスケジューリングされることにより、ｍｓオーダの待ち合わせが発生する。
（１）他のハードウェア割込処理と競合した場合
（２）他のソフトウェア割込処理と競合した場合
（３）優先度の高い他プロセスやkernel thread（migration thread等）、割込先ＣＰＵが使用されている場合
上記条件では、前記ソフトウェア割込処理を即時に実行することができない。

<割込処理競合に起因したネットワーク遅延>
パケット処理のためのソフトウェア割込と、他の処理のためのソフトウェア割込（disk I/O、swapなど）が競合すると、ソフトウェア割込用のスケジューラ（ksoftirqd）がソフトウェア割込の実行頻度を調停する。
ソフトウェア割込の競合発生について説明する。Ksoftirqdは、ソフトウェア割込処理をスケジューリングする。ksoftirqdに処理が移譲されると、config_hzの頻度(ms程度)でソフトウェア割込が実行される。この待ち時間に起因して、msオーダのパケット転送遅延が発生する。

<New API(NAPI)による課題>
New API(NAPI)によるパケット処理についても同様に、図１６の破線囲みｎに示すように、割込処理（softIRQ）の競合に起因し、ｍｓオーダのＮＷ遅延が発生する。

<ＤＰＤＫの課題>
ＤＰＤＫでは、kernel threadはpolling（ＣＰＵでキューをbusy poll）を行うために、ＣＰＵコアを専有するので、図１７に示す間欠的なパケット受信であっても、ＤＰＤＫでは、パケット到着有無に関わらず、ＣＰＵを常に１００％使用するため、消費電力が大きくなる課題がある。

<ＫＢＰの課題>
ＫＢＰについても、上記ＤＰＤＫと同様の課題がある。
上述したように、ＫＢＰは、kernel内でpollingモデルによりパケット到着を常時監視することで、softIRQを抑止し、低遅延なパケット処理を実現することができる。
しかし、パケット到着を常時監視するkernel threadがＣＰＵコアを専有し、常にＣＰＵタイムを使用するため、消費電力が高くなる課題がある。図１７および図１８を参照して、ワークロードとＣＰＵ使用率の関係について説明する。
図１８に示すように、ＫＢＰでは、kernel threadはbusy pollを行うために、ＣＰＵコアを専有する。図１７に示す間欠的なパケット受信であっても、ＫＢＰでは、パケット到着有無に関わらず常にＣＰＵを使用するため、消費電力が大きくなる課題がある。

このように、ＤＰＤＫは、user spaceでpollingモデルを実現するためsoftIRQ競合は発生しない、また、ＫＢＰは、kernel内でpollingモデルを実現するためsoftIRQ競合は発生しないので、低遅延なパケット転送が可能である。しかしながら、ＤＰＤＫおよびＫＢＰは、いずれもパケット到着有無に関わらず、常にパケット到着監視のためにＣＰＵリソースを無駄使いし、消費電力が大きくなる課題がある。

このような背景を鑑みて本発明がなされたのであり、本発明は、低遅延性を維持しつつ、ＣＰＵ使用率を削減して省電力化を可能とすることを課題とする。

前記した課題を解決するため、Pollingモデルによるパケット転送を行うデータ転送部のPollingスレッドに対して、Sleep制御を行うサーバ内データ転送装置であって、前記パケット転送におけるトラフィック特性情報を収集するトラフィック特性情報収集部と、前記トラフィック特性情報収集部から受け取った前記トラフィック特性情報をもとに、前記Pollingスレッドをパケットの到着確率が所定閾値以上のタイミングで起床させ、それ以外はSleepさせるPollingスケジュール情報を生成するPolling判定部と、前記Polling判定部から時刻同期情報と前記Pollingスケジュール情報を受け取り、前記時刻同期情報および前記Pollingスケジュール情報をもとに、Pollingに必要な時刻と時間を示すPollingスケジュールを前記Pollingスレッドに配信して当該Pollingスレッドを前記Pollingスケジュールで指示した時間だけPollingさせるPolling指示部と、を備え、前記トラフィック特性情報収集部は、上位アプリケーションから時間および周波数領域のチャンネル割り当て情報を収集し、前記トラフィック特性情報として前記Polling判定部へ伝達することを特徴とするサーバ内データ転送装置とした。

本発明によれば、低遅延性を維持しつつ、ＣＰＵ使用率を削減して省電力化を図ることができる。

本発明の実施形態に係るサーバ内データ転送システムの概略構成図である。本発明の実施形態に係るサーバ内データ転送システムのデータ到着パターン例に応じた、チャンネル例、データ到着の特徴およびPolling判定部によるSleep制御対応策を説明する図である。本発明の実施形態に係るサーバ内データ転送システムのトラフィック特性情報収集部から得た時間・周波数領域へのチャンネル割り当て情報例を示す図である。本発明の実施形態に係るサーバ内データ転送システムの動作を説明する図である。本発明の実施形態に係るサーバ内データ転送システムのデータ高速転送ミドルウェアとの連携によるパケットの到着統計のトラフィック特性の取得を説明する図である。本発明の実施形態に係るサーバ内データ転送システムのトラフィック特性情報収集部のトラフィック特性情報収集処理１を示すフローチャートである。本発明の実施形態に係るサーバ内データ転送システムのトラフィック特性情報収集部のトラフィック特性情報収集処理２を示すフローチャートである。本発明の実施形態に係るサーバ内データ転送システムのPolling判定部におけるSleep制御スケジュール決定処理を示すフローチャートである。本発明の実施形態に係るサーバ内データ転送システムの統計情報例に応じた、データの特徴例、特徴から推察できることおよびPolling判定部によるSleep制御対応策を説明する図である。本発明の実施形態に係るサーバ内データ転送システムのPolling判定部のPollingスケジュール情報配信処理を示すフローチャートである。本発明の実施形態に係るサーバ内データ転送システムのPolling判定部のPolling可否決定のロジックを示すサブルーチンである。本発明の実施形態に係るサーバ内データ転送システムのPolling指示部の動作を示すフローチャートである。本発明の実施形態に係るサーバ内データ転送システムのデータ高速転送ミドルウェアの動作を示すフローチャートである。本発明の実施形態に係るサーバ内データ転送システムのサーバ内データ転送装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。 Linux kernel 2.5/2.6より実装されているNew API(NAPI)によるＲｘ側パケット処理の概略図である。図１５の破線で囲んだ箇所におけるNew API(NAPI)によるＲｘ側パケット処理の概要を説明する図である。映像（３０ＦＰＳ）のデータ転送例を示す図である。非特許文献３に記載のＫＢＰにおける、busy poll threadが使用するＣＰＵ使用率を示す図である。アクセラレータを備えるＨＷの制御を行うＤＰＤＫシステムの構成を示す図である。

以下、図面を参照して本発明を実施するための形態（以下、「本実施形態」という）におけるサーバ内データ転送システム等について説明する。
（実施形態）
［全体構成］
図１は、本発明の実施形態に係るサーバ内データ転送システムの概略構成図である。図１９と同一構成部分には、同一符号を付している。
図１に示すように、サーバ内データ転送システム１０００は、ＨＷ１１０と、メモリ１８０と、Pollingモデルによるパケット転送を行うデータ高速転送ミドルウェア３００（データ転送部）と、データ高速転送ミドルウェア３００のPollingスレッドに対して、Sleep制御を行うSleep制御ミドルウェアであるサーバ内データ転送装置２００と、user spaceで実行されるプログラムであるApplications２（上位アプリケーション）と、を有する。

ＨＷ１１０は、対向装置１７０に接続するためのＮＩＣ１３０（物理NIC）を備える。ＮＩＣ１３０は、ＮＷインターフェイスを実現するＮＩＣハードウェアであり、例えば通信ネットワークを介して対向装置１７０に接続され、パケット送受信を行う。
ＨＷ１１０は、Applications２との間でデータ送受信の通信を行う。Applications２が、ＨＷ１１０からのパケットを受け取るデータの流れをＲｘ側受信と称し、Applications２が、ＨＷ１１０にパケットを送信するデータの流れをＴｘ側送信と称する。

ＨＷ１１０は、アクセラレータを備えていてもよい。このアクセラレータは、ＣＰＵからの入力をもとに、特定の演算を高速に行う計算ユニットハードウェアであり、例えばＧＰＵ（Graphics Processing Unit）やＦＰＧＡ（Field Programmable Gate Array）等のＰＬＤ（Programmable Logic Device）である。

メモリ１８０は、データを先入れ先出しのリスト構造で保持するＲｘキュー（queue：待ち行列）１８１およびＴｘキュー１８２を格納するレジスタである。

［サーバ内データ転送装置２００］
サーバ内データ転送装置２００は、トラフィック特性情報収集部２１０と、Polling判定部２２０と、Polling指示部２３０と、を備える。

<トラフィック特性情報収集部２１０>
トラフィック特性情報収集部２１０は、トラフィック特性情報（チャンネル割り当て情報（後記）と、Sleep制御スケジュールに用いることができる統計情報（過去に到着したパケット情報等）とがある）を収集し、Polling判定部２２０へ伝達する。

具体的には、トラフィック特性情報収集部２１０は、Applications２から時間・周波数領域へのチャンネル割り当て情報を収集し（図４の符号ｓ参照）、Polling判定部２２０へトラフィック特性情報（図１の符号ｏ参照）として伝達する。
また、トラフィック特性情報収集部２１０は、データ高速転送ミドルウェア３００と連携し、時系列によるパケット到着頻度の特徴などの、Sleep制御スケジュールに用いることができる情報を、データ高速転送ミドルウェア３００から収集し、Polling判定部２２０へトラフィック特性情報（図１の符号ｏ参照）として伝達する。

なお、トラフィック特性情報収集部２１０が、チャンネル割り当て情報（トラフィック特性情報）をApplications２から収集する例は、後記図４の符号ｓに示されており、Sleep制御スケジュールに用いることができる統計情報（トラフィック特性情報）をデータ高速転送ミドルウェア３００から情報収集する例は、後記図４の符号ｔに示されている。

<Polling判定部２２０>
Polling判定部２２０は、トラフィック特性情報収集部２１０から受け取ったトラフィック特性情報をもとに、データ高速転送ミドルウェア３００のPollingThread３１０をパケットの到着確率が所定閾値以上のタイミングで起床させ、それ以外はSleepさせるPollingスケジュール情報を生成し、Polling指示部２３０へ時刻同期情報と共に伝達する（図１の符号ｐ参照）。

上記パケットの到着確率の所定閾値について述べる。
所定閾値は、ユースケースに応じて、本システムの運用者が決定し、例えばテーブル値として記憶部（図示省略）に記憶する。Polling判定部２２０は、パケットの到着確率と記憶部に記憶したテーブル値とを比較し、パケットの到着確率が所定閾値以上の場合、PollingThread３１０を起床させるPollingスケジュール情報を生成する。すなわち、
（１）
ユースケースＡにおいては、「９９％以上のパケットの到着確率でパケットが到着するタイミングで起床させる」という基準でスケジュール情報を生成する
ユースケースＢにおいては、「８０％以上のパケットの到着確率でパケットが到着するタイミングで起床させる」という基準でスケジュール情報を生成する
ユースケースＣにおいては、「５０％以上のパケットの到着確率でパケットが到着するタイミングで起床させる」という基準でスケジュール情報を生成する
等である。

（２）
運用者は、確率０から１（０％から１００％）の範囲であらかじめ閾値を決定できる。確率の閾値は、０または１もありうるとし、事実上、確率を適用しない（すべて適用する）こともある。例えば、特定ＵＥ等については、確率を適用しない除外規定があるなどである。

（３）
運用者は、動的にこの閾値（上記の例では、閾値９９％、閾値８０％、閾値５０％）を変更することができる。

<Polling指示部２３０>
Polling指示部２３０は、Polling判定部２２０から時刻同期情報とPollingスケジュール情報を受け取り、時刻同期情報およびPollingスケジュール情報をもとに、Pollingに必要な時刻と時間を示すPollingスケジュールをPollingThread３１０に配信してPollingThread３１０をトリガし、当該PollingThread３１０をPollingスケジュールで指示した時間だけPollingさせる。
具体的には、Polling指示部２３０は、データ高速転送ミドルウェア３００のPollingスレッド（PollingThread）３１０へPollingスケジューリング（図１の符号ｑ参照）を指示する。後記するように、Polling指示部２３０が、PollingThread３１０に指示するPollingスケジューリングは、Polling指示部２３０が、PollingThread３１０を実際に起床させるトリガである。

［データ高速転送ミドルウェア３００］
データ高速転送ミドルウェア３００は、Pollingモデルによるパケット転送を行うデータ転送部である。データ高速転送ミドルウェア３００は、プログラムの実行単位であるPollingThread３１０を複数有する。PollingThread３１０は、Polling指示部２３０からのPollingスケジューリングによってSleepから起床し、Pollingモデルによるパケット転送を行う。PollingThread３１０は、Polling指示部２３０からのPollingスケジューリングを受け、パケットの到着確率が所定値以上のタイミングで起床し、それ以外はSleepする（図１の符号ｒ参照）。

［特性に応じたトラフィックのカテゴライズ］
サーバ内データ転送装置２００は、データ高速転送ミドルウェア３００内のPollingスレッドをパケットの到着確率が所定値以上のタイミングで起床させ、それ以外はSleepさせる。このような制御を実現するため、データ到着パターンの特性をカテゴライズしておく（図２参照）。
例えば、ＲＡＮ（Radio Access Network）ユースケースでは、トラフィックを、特性に応じてカテゴライズし、そのそれぞれのカテゴリに対してPollingの必要有無を定めることができる。

データ到着パターンとそれに応じたSleep制御対応策の例について説明する。
Sleep制御スケジュールに用いることができるトラフィック特性情報（図１の符号ｏ参照）を収集できるユースケースとしてＲＡＮがある。ＲＡＮの無線信号は、チャンネル毎にデータ到着パターンに特徴がある。それらの特徴毎に適するSleep制御スケジュールを定めることが可能である。

図２は、データ到着パターン例に応じた、チャンネル例、データ到着の特徴およびPolling判定部２２０によるSleep制御対応策を説明する図である。
データ到着パターン例には、１．いつデータが到着するか予測不可の場合、２．データ到着タイミングを予測可能な場合とそうでない場合、３．データ到着タイミングを予測可能な場合がある。

１．いつデータが到着するか予測不可の場合のチャンネル例は、ＰＲＡＣＨ（Physical Random Access Channel）（第１チャンネル）があり、データ到着の特徴は、「いつデータが到着するか予測不可」である。Polling判定部２２０によるSleep制御対応策は、Sleep状態で待機し、パケットが届いた際にはハードウェア割り込みにより起床する。ＰＲＡＣＨに届くパケットは多少の遅延時間は許容されるため、Pollingで待機する必要はないものとする。Pollingで待機していると、ハードウェア割り込みからの起床がないので、低遅延となる。また、いつデータが到着するか予測不可の場合は、一般に、多少の遅延時間は許容されるカテゴリに属している。このため、Pollingで待機する必要はなく、ハードウェア割り込みにより起床する。

２．予測可能な場合と予測不可の場合の両方の可能性があるときのチャンネル例は、ＰＵＳＣＨ（Physical Uplink Shared Channel）（第２チャンネル）があり、データ到着の特徴は、「ＵＥ（User Equipment）が帰属してない場合はデータが到着しない、ＵＥが帰属している場合はデータが到着する可能性がある」である。

ＵＥの帰属について説明する。ＵＥは、例えば基地局のネットワークに接続される携帯端末である。携帯端末のネットワーク側は、ユーザの携帯端末が使用可能な周波数領域と時間領域で分けられたリソースで通信することを事前に通知してあり、該当携帯端末はその周波数領域と時間領域で通信可能であることが分かっている。ＵＥの帰属とは、基地局が指定した周波数領域と時間領域に該当携帯端末が属しているこという（携帯端末が使用している／していないは問わない）をいう。ここで、基地局が指定した周波数領域と時間領域に割り当てられているからといって、必ずしも該当携帯端末が、基地局が指定した周波数領域と時間領域に帰属していて通信を行って来るかどうかは分からない（ＵＥが帰属していれば、そのリソースを使って通信が行われる場合と通信が行われない場合とがある）。ＵＥの帰属していないとは、リソースは割り当てられているがどの携帯端末もそのリソースを使っていない場合をいう（割り当てられたリソースを使って通信が行われることはない）。

Polling判定部２２０によるSleep制御対応策は、ＵＥが帰属していない場合はSleepを行う。ＵＥが帰属していない場合は、そもそもデータが到着しない場合であるため、Sleepを行う。
また、ＵＥが帰属している場合は更に、ＵＥのこれまでのパケット送信特性等の情報に応じた制御も可能である。例えば、ＵＥは帰属しているが、該当ＵＥはデータ送信確率が１％（１％は、一例であり限定されない。）に満たないため、PollingではなくSleepを行う。

３．いつデータが到着するか予測可能な場合のチャンネル例は、ＳＲＳ（Sounding Reference Signal）（第３チャンネル）があり、データ到着の特徴は、「信号を受信するサブフレーム内のタイミングが確定している」である。Polling判定部２２０によるSleep制御対応策は、データが到着する直前にPollingを開始する。Pollingを開始すると、ハードウェア割り込みからの起床がないので、低遅延となる。
いつデータが到着するか予測可能な場合のチャンネル例（「ＳＲＳ」）は、上記２．のＵＥの帰属とは、無関係である。ＳＲＳは、時刻同期のために基地局が発する同期信号や基地局が情報を得るために送信する信号であり、ＵＥの使用状況やＵＥの帰属とは、無関係に、特定の時間・周波数領域を使って信号を送信する。いつデータが到着するか予測可能であるため、データが到着する直前にPollingを開始する。

なお、図２に示すデータ到着パターン特性のカテゴライズを用いたSleep制御スケジュール決定については、図８により後記する。

トラフィック特性情報収集部２１０によるトラフィック特性情報について説明する。
図３は、トラフィック特性情報の一例である、トラフィック特性情報収集部２１０から得た時間・周波数領域へのチャンネル割り当て情報を示す図である。
図３に示すチャンネル割り当て情報は、基準：hh時mm分ss秒xxxxから各時間領域1-80[usec]、81-160[usec]、161-240[usec]、321-400[usec]、401-480[usec]ごとに、周波数領域K-L[Hz]、L-M[Hz]、M-N[Hz]、N-O[Hz]、O-P[Hz]で割り当てられたチャンネルで示される。

321-400[usec]、401-480[usec]とM-N[Hz]、N-O[Hz]、O-P[Hz]で割り当てられたチャンネルは、同期信号などの最も優先度の高いＳＲＳである。このＳＲＳは、特定の時間・周波数領域を使って送信される信号（なお、説明の便宜上、ＳＲＳをチャンネルと呼ぶ。）であり、いつデータが到着するか予測可能である。
また、81-160[usec]、161-240[usec]、321-400[usec]とM-N[Hz]、N-O[Hz]、O-P[Hz]で割り当てられたチャンネルは、ＰＵＳＣＨである。このＰＵＳＣＨは、データ到着タイミングを予測可能な場合とそうでない場合のチャンネルである。
また、1-80[usec]、81-160[usec]、161-240[usec]、321-400[usec]、401-480[usec]の全時間帯に亘ってL-M[Hz]で割り当てられたチャンネルは、ＰＲＡＣＨである。このＰＲＡＣＨは、いつデータが到着するか予測不可の場合のチャンネルである。
なお、図３において空欄は、チャンネル割り当て情報がない状態である。

例えば、周波数領域L-M[Hz]では、時間帯域に関係なく（1-80[usec]、81-160[usec]、161-240[usec]、321-400[usec]、401-480[usec]の全時間帯で）チャンネルＰＵＳＣＨが割り当てられる。
また、周波数領域M-N[Hz]、N-O[Hz]、O-P[Hz]M-N[Hz]では、1-80[usec]ではチャンネル割り当て情報がなく、81-160[usec]、161-240[usec]、321-400[usec]ではチャンネルＰＵＳＣＨが割り当てられ、161-240[usec]、321-400[usec]ではＳＲＳが割り当てられる。

以下、上述のように構成されたサーバ内データ転送システムの動作を説明する。
［全体動作］
図４は、サーバ内データ転送システムの動作を説明する図である。図１と同一構成部分には、同一符号を付している。
図４に示すApplications２は、例えばＬ１／Ｌ２Application（物理層／データリンク層を対象とするデータ処理アプリケーション）である。
データ高速転送ミドルウェア３００は、時系列によるパケット到着頻度の情報を保持する共有メモリ３２０を有する。共有メモリ３２０は、各ＵＥが割り当てられているリソースブロックに実際にパケットが到着した回数を格納する。共有メモリ３２０は、パケットの到着統計をSleep制御スケジュールに用いることができる統計情報としてトラフィック特性情報収集部２１０に伝達する。

トラフィック特性情報収集部２１０は、例えばＲＡＮへの適用例では以下のようにトラフィック特性情報を収集する。すなわち、トラフィック特性情報収集部２１０は、定期的にＬ１／Ｌ２Applicationから時間・周波数領域へのチャンネル割り当て情報を取得する。また、トラフィック特性情報収集部２１０は、時刻同期を行い、チャンネル割り当て情報と時刻の情報を合わせてPolling判定部２２０に情報を受け渡す。

トラフィック特性情報収集部２１０は、共有メモリ３２０を介してパケット到着頻度の情報を収集し、トラフィック特性情報としてPolling判定部２２０へ伝達する。

図５は、データ高速転送ミドルウェア３００との連携によるパケットの到着統計のトラフィック特性の取得を説明する図である。図５において、「＋」は各ＵＥにパケットが到着した回数を示している。例えば、ＵＥ１は、ＵＥ１が割り当てられているリソースブロックに実際にパケットが到着した回数が４である。同様に、ＵＥ２は、パケットが到着した回数が２、ＵＥ３は、パケットが到着した回数が５である。
データ高速転送ミドルウェア３００は、各ＵＥが割り当てられているリソースブロックに実際にパケットが到着した回数を収集し、共有メモリ３２０に格納する。データ高速転送ミドルウェア３００は、共有メモリ３２０に格納された情報をトラフィック特性情報収集部２１０に伝達する（図４の符号ｔ参照）。

Polling判定部２２０は、トラフィック特性情報収集部２１０から受け取ったトラフィック特性情報（図３参照）をもとに、データ高速転送ミドルウェア３００のPolling Thread（Pollingスレッド）３１０をパケットの到着確率が所定値以上のタイミングで起床させ、それ以外はSleepさせるPollingスケジュール情報を生成して、Polling指示部２３０へ伝達する（図４の符号ｐ参照）。

Polling指示部２３０は、Polling判定部２２０から時刻同期情報とPollingスケジュール情報を受け取り、時刻同期情報およびPollingスケジュール情報をもとに、Pollingが必要な時刻と時間を示すPollingスケジュールをデータ高速転送ミドルウェア３００のPollingThread３１０へPollingスケジューリング（図４の符号ｑ参照）に配信して当該PollingスレッドをPollingスケジュールで指示した時間だけPollingさせる。

［トラフィック特性情報収集部２１０の動作］
<トラフィック特性情報収集処理１>
図６は、トラフィック特性情報収集部２１０のトラフィック特性情報収集処理１を示すフローチャートである。図６は、トラフィック特性情報収集部２１０が、Ｌ１／Ｌ２Application（上位アプリケーション）から時間・周波数領域へのチャンネル割り当て情報を取得する（図４の符号ｓ参照）場合の処理フローである。
ステップＳ１１でトラフィック特性情報収集部２１０（図４参照）は、Ｌ１／Ｌ２Applicationからトラフィック特性情報としてチャンネル割り当て情報を定期的に（もしくは、チャンネル割り当てパターンが変更されるタイミングで）収集を行う。

ステップＳ１２でトラフィック特性情報収集部２１０は、時刻同期を行い、チャンネル割り当て情報を時間軸に沿った形にする。すなわち、図３に示すように、トラフィック特性情報収集部２１０は、チャンネル割り当て情報を、基準：hh時mm分ss秒xxxxから時間軸に沿って配置する。

ステップＳ１３でトラフィック特性情報収集部２１０は、時刻同期されたチャンネル割り当て情報をPolling判定部２２０（図４参照）に配信して本フローの処理を終了する。

<トラフィック特性情報収集処理２>
図７は、トラフィック特性情報収集部２１０のトラフィック特性情報収集処理２を示すフローチャートである。図７は、トラフィック特性情報収集部２１０が、データ高速転送ミドルウェア３００からパケットの到着統計を取得する（図４の符号ｔ参照）場合の処理フローである。
ステップＳ２１でトラフィック特性情報収集部２１０（図４参照）は、データ高速転送ミドルウェア３００（図４参照）が収集し、共有メモリ３２０（図４参照）に書き込んだ各ＵＥのパケット到着頻度の情報を定期的に収集する。

ステップＳ２２でトラフィック特性情報収集部２１０（図４参照）は、「ＵＥのＩＤ：パケット到着頻度情報」の形でデータを成形する。パケット到着頻度情報は、
１．これまで全ての到着割合
２．直前の共有メモリ３２０（図４参照）からデータ収集時の到着割合
の２種類を保持する。
トラフィック特性情報収集部２１０は、このパケット到着頻度情報を用いて、後記図９の「直前に割り当てられたリソースを使い通信を行ったＵＥであること」「リソースが割り当てられるのが初回のＵＥであること」を判断することができる。なお、初回のＵＥであることは、ＵＥに割り振られているＩＤをもとに、すべてのパケット到着割合と直前のパケット到着割合を取得し、直前のパケット到着がなければ初回のＵＥであると判断する（例えば、ＵＥのＩＤがそもそも記録されていない場合は初回の通信であると判断する）。

ステップＳ２３でトラフィック特性情報収集部２１０は、チャンネル割り当て情報（図３参照）をPolling判定部２２０に配信（図４の符号ｏ参照）する際、チャンネル割り当て情報にＰＵＳＣＨのチャンネルが含まれていれば、同時に「ＵＥのＩＤ：パケット到着頻度情報」の情報を配信して本フローの処理を終了する。

<データ到着タイミング情報の補正>
データ到着タイミング情報の補正について説明する。
図１に示す対向装置１７０と時刻同期がとれていないことや、対向装置１７０内で一定のデータ処理時間が発生すること等が原因で、トラフィック特性情報収集部２１０（図１および図４参照）がPolling判定部２２０に渡すタイミング情報と実際のデータ到着タイミング情報の間に、定常的あるいはデータサイズ等に応じた規則的差分が生じる場合がある。この場合、データ高速転送ミドルウェア３００（図１および図４参照）が実際のパケット到着時刻をトラフィック特性情報収集部２１０に送付し、トラフィック特性情報収集部２１０がその差分を補正することによって対応してもよい。
以上、トラフィック特性情報収集部２１０の動作について説明した。

［Polling判定部２２０の動作］
ＲＡＮユースケースにおいて、トラフィック特性情報収集部２１０から、図３に示す時間・周波数領域へのチャンネル割り当て情報が得られた場合、Polling判定部２２０は以下のようにSleep制御スケジュールを決定し、決定したSleep制御スケジュールをもとにPollingスケジュール情報を生成する。

<Sleep制御スケジュール決定処理>
図８は、Polling判定部２２０におけるSleep制御スケジュール決定処理を示すフローチャートである。本フローは、図２に示すデータ到着パターン特性のカテゴライズを用いてSleep制御スケジュールを決定する。

ステップＳ３１でPolling判定部２２０は、各時間領域に対して、周波数領域のチャンネル割り当て情報を走査（本明細書において、走査とは、トラフィック特性情報（図３参照）を、基準から時間的終端まで時間的に順に確認していくことをいう）する。

ステップＳ３２でPolling判定部２２０は、該当時間のいずれかの周波数ブロックに「パケットが到着することがわかっている」チャンネル（図３のトラフィック特性情報の場合、「ＳＲＳ」）が割り当てられているか否かを判別する。Polling判定部２２０は、例えば、図３に示すトラフィック特性情報を、基準から時間的終端（1-80[usec]から401-480[usec]）まで走査したときに、「ＳＲＳ」が周波数領域M-N[Hz]、N-O[Hz]、O-P[Hz]で、かつ、時間領域321-400[usec]、401-480[usec]で割り当てられていることを判別する。

該当時間のいずれかの周波数ブロックに「パケットが到着することがわかっている」チャンネル（「ＳＲＳ」）が割り当てられていない場合（Ｓ３２：Ｎｏ）、ステップＳ３３に進み、割り当てられている場合（Ｓ３２：Ｙｅｓ）、ステップＳ３５に進む。

ステップＳ３３でPolling判定部２２０は、該当時間のいずれかの周波数ブロックに「ＵＥの帰属有無によって、パケットが来るか来ないかに依存する」チャンネル（図３のトラフィック特性情報の場合、「ＰＵＳＣＨ」）が割り当てられているか否かを判別する。Polling判定部２２０は、例えば、図３に示すトラフィック特性情報を、基準から時間的終端（1-80[usec]から401-480[usec]）まで走査したときに、「ＰＵＳＣＨ」が周波数領域M-N[Hz]、N-O[Hz]、O-P[Hz]で、かつ、時間領域81-160[usec]、161-240[usec]、241-320[usec]で割り当てられていることを判別する。

該当時間のいずれかの周波数ブロックに「ＵＥの帰属有無によって、パケットが来るか来ないかに依存する」チャンネル（「ＰＵＳＣＨ」）が割り当てられていない場合（Ｓ３３：Ｎｏ）、ステップＳ３４に進み、割り当てられている場合（Ｓ３３：Ｙｅｓ）、ステップＳ３６に進む。

ステップＳ３４でPolling判定部２２０は、該当時間はデータ高速転送ミドルウェア３００内のPollingスレッドをSleepさせ、パケット到着時には割り込みモードで起動させるSleep制御スケジュール決定を行って本フローの処理を終了する。すなわち、上記ステップＳ３３において、「ＰＵＳＣＨ」が割り当てられていない場合、ステップＳ３４でPolling判定部２２０は、Sleep状態で待機し、パケットが届いた際にはハードウェア割り込みにより起床する。

一方、上記ステップＳ３２で（「ＳＲＳ」）が割り当てられている場合、ステップＳ３５でPolling判定部２２０は、該当時間は起床し、Pollingによってパケット到着を待機して本フローの処理を終了する。Polling判定部２２０は、該当時間は起床し、データが到着する直前にPollingを開始することで、ハードウェア割り込みからの起床を回避し、低遅延を実現できる。

上記ステップＳ３３で（「ＰＵＳＣＨ」）が割り当てられている場合、ステップＳ３６でPolling判定部２２０は、ＵＥが帰属しているか否かを判別する。

上記ステップＳ３６でＵＥが帰属していない場合、ステップＳ３７でPolling判定部２２０は、該当時間はSleepして本フローの処理を終了する。ＵＥが帰属していない場合は、（「ＰＵＳＣＨ」）が割り当てられてたとしてもそもそもデータが到着しない場合であるため、Polling判定部２２０は、該当時間はデータ高速転送ミドルウェア３００内のPollingスレッドをSleepさせるSleep制御スケジュール決定を行って本フローの処理を終了する。

一方、上記ステップＳ３６でＵＥが帰属している場合、ステップＳ３８でPolling判定部２２０は、該当ＵＥの特性や統計に応じたロジック（図９で後記するロジック）を適用して本フローの処理を終了する。

以上の処理により、サーバ内データ転送装置２００は、データ高速転送ミドルウェア３００内のPollingスレッドをパケットの到着確率が所定閾値以上のタイミングで起床させ、それ以外はSleepさせることができる（「ステップＳ３４のSleep制御スケジュール決定」参照）。Polling判定部２２０は、パケットの到着確率が著しく低いときは、Sleepさせるのが妥当であると判断する。

しかしながら、パケットの到着確率が著しく低くSleepさせた場合において、Sleep中にパケットが到着してしまうことはありうる。データ高速転送ミドルウェア３００は、パケット到着時に割り込みモードで起床する機能を元々備えている。Sleep中にパケットが到着してしまった場合、データ高速転送ミドルウェア３００は、この機能を使って割り込みモードで起床（ＮＩＣからハードウェア割り込みが立ち上がり、ＮＩＣからの指示によりデータ高速転送ミドルウェア３００が起床）する。ただし、割り込みモードで起床するので、低遅延性は図れない。補足して説明する。

ハードウェア割り込みからの起床は、下記デメリットがある。すなわち、ハードウェア割り込みからの起床の方がPollingに比べて遅延時間が増大する特徴がある。このため、データ高速転送ミドルウェア３００が起床しておいてPollingを開始してパケットを取得した方が、ハードウェア割り込みのコンテキストから起床されるよりも遅延時間が小さくなる。このため、最も理想的なパターンとしては、事前に（特に、パケット到着がある直前に）起床してPollingを開始していることであり、このとき遅延時間が最小となる。最悪、Sleep中で起床できなかった場合でも遅延時間は多少増大したとしても、ハードウェア割り込みによって起床させることはできる。

ちなみに、データ高速転送ミドルウェア３００が起床してPollingしている場合には、データ高速転送ミドルウェア３００側でハードウェア割り込みの立ち上げを禁止する。すなわち、ハードウェア割り込みが起こらなくてもパケットが到着したかどうかはPollingによって検知できている状態であるため、ハードウェア割り込みを立ち上げる必要はなく、禁止する形がとれる（ハードウェア割り込みの立ち上げを禁止した状態でPollingをしている）。

以上のように、Polling判定部２２０は、Sleep制御スケジュールを決定し、決定したSleep制御スケジュールをもとにPollingスケジュール情報を生成する。

図９は、統計情報例に応じた、データの特徴例、特徴から推察できることおよびPolling判定部２２０によるSleep制御対応策を説明する図である。図９は、図８のステップＳ３８の該当ＵＥの特性や統計に応じたロジックを説明する。
統計情報例には、１．該当ユーザの通信のバースト性、２．該当ユーザがライトユーザか否か、３．該当ユーザにリソースが割り当てられるのは初回か否か、４．該当ユーザに対する下りリンクの通信情報がある。以下、順に説明する。

１．統計情報例が該当ユーザの通信のバースト性の場合
データの特徴例は、「該当ＵＥは直前に割り当てられたリソースを使い、通信を行っている」である。このデータ特徴から推察できることは、「前回通信を行っていたＵＥであれば、今回のリソースでもデータを送信してくる確率が高い」ことである。Polling判定部２２０によるSleep制御対応策は、今回のリソースでもデータを送信してくる確率が高いＵＥであると判断してPollingによってパケットを待機する。

２．統計情報例において該当ユーザがライトユーザ（ＵＥが帰属しているにも拘らず、割り当てられたリソースを使って通信を行ったことが殆どないユーザ；初回基地局に同期したのみのユーザなど）か否かの場合
データの特徴例は、「該当ＵＥは割り当てられたリソースをこれまで１％しか使っていない」である。このデータ特徴から推察できることは、「今回のリソースでもデータを送信してくる確率が低い」ことである。Polling判定部２２０によるSleep制御対応策は、このリソースではデータを送信してくる確率が低いＵＥであると判断してSleepによってパケットを待機する。

３．統計情報例が該当ユーザにリソースが割り当てられるのは初回か否かの場合
データの特徴例は、「該当ＵＥによる通信はこれまでなく、新規に割り当て要求を行ってきてその最初の通信である」である。このデータ特徴から推察できることは、「初回であり、データを送信してくる確率が高い」ことである。初回の場合は、上記１．の前回通信を行っていたＵＥの場合と同様にデータを送信してくる確率が高いＵＥであると判断して、Polling判定部２２０によるSleep制御対応策は、Pollingによってパケットを待機する。

４．統計情報例が該当ユーザに対する下りリンク（基地局からＵＥに対してメッセージを送った場合のリンク）の通信情報の場合
データの特徴例は、「下りリンクにて、該当ＵＥに対する何らかの要求メッセージが送られている」である。このデータ特徴から推察できることは、「その要求に応答するべく、直ちにデータを送信してくる確率が高い」ことである。基地局からＵＥに対してメッセージを送った場合、該当ＵＥは基地局に応答する確率が高いと判断して、Polling判定部２２０によるSleep制御対応策は、Pollingによってパケットを待機する。

<Pollingスケジュール情報配信処理>
図１０は、Polling判定部２２０のPollingスケジュール情報配信処理を示すフローチャートである。
ステップＳ４１でPolling判定部２２０は、トラフィック特性情報収集部からチャンネル割り当て情報が配信されることを契機に本プログラムを起動する。

ステップＳ４２でPolling判定部２２０は、トラフィック特性情報収集部２１０がApplications２（図４のＬ１／Ｌ２Application）から収集して、Polling判定部２２０に配信されたチャンネル割り当て情報（図３参照）について時間的なスロットに分割し（図３の例では８０[usec]ごとに分割）、各スロットにどのチャンネルが割り当てられているか走査する。

ステップＳ４３でPolling判定部２２０は、スロットのいずれかの周波数ブロックに「パケットが到着することがわかっている」チャンネル（図３のトラフィック特性情報の場合、「ＳＲＳ」）が含まれるか否かを判別する。ここで、ステップＳ４３は、図８のフローのステップＳ３２に対応し、後記ステップＳ４６は、図８のフローのステップＳ３５に対応する。ステップＳ４３では、パケットが到着することが分かっている時間・周波数領域のチャンネルに、最も優先度の高い「ＳＲＳ」が割り当てられている場合は、ステップＳ４４以降に進まずに、ステップＳ４６に移行する。

スロットのいずれかの周波数ブロックに「パケットが到着することがわかっている」チャンネル（「ＳＲＳ」）が含まれていない場合（Ｓ４３：Ｎｏ）、ステップＳ４４でPolling判定部２２０は、スロットのいずれかの周波数ブロックに「ＵＥの帰属有無によって、パケット到着特性が変わる」チャンネル（図３のトラフィック特性情報の場合、「ＰＵＳＣＨ」）が含まれるか否かを判別する。ここで、ステップＳ４４は、図８のフローのステップＳ３３に対応し、後記ステップＳ４７は、図８のフローのステップＳ３６に対応する。
すなわち、ステップＳ４４では、「ＳＲＳ」の次に優先度の高い「ＰＵＳＣＨ」が割り当てられているか判定し、スロットのいずれかの周波数ブロックに「ＵＥの帰属有無によって、パケット到着特性が変わる」チャンネル（「ＰＵＳＣＨ」）が含まれていない場合（Ｓ４４：Ｎｏ）、ステップＳ４５でPolling判定部２２０は、該当時間はsleepすることを決定し、次の時間的スロットを走査してステップＳ４８に進む。

一方、上記ステップＳ４３でスロットのいずれかの周波数ブロックに「パケットが到着することがわかっている」チャンネル（「ＳＲＳ」）が含まれている場合（Ｓ４３：Ｙｅｓ）、ステップＳ４６でPolling判定部２２０は、該当時間はPollingを行うことを決定し、次の時間的スロットを走査してステップＳ４８に進む。

また、上記ステップＳ４４でスロットのいずれかの周波数ブロックに「ＵＥの帰属有無によって、パケット到着特性が変わる」チャンネル（「ＰＵＳＣＨ」）が含まれている場合（Ｓ４４：Ｙｅｓ）、ステップＳ４７でPolling判定部２２０は、所定ロジック（図１１のサブルーチンに示すロジック）を適用してPolling可否を決定し、次の時間的スロットを走査してステップＳ４８に進む。

ステップＳ４８では、Polling判定部２２０は、与えられたチャンネル割り当て情報の時間的終端（トラフィック特性情報収集部２１０によって定義された時間的終端（トラフィック特性情報収集部２１０が次のどこまでを収集するか定義した時間的区切り）；例えば１ｍｓごとの時間的区切り）であるか否かを判別する。

与えられたチャンネル割り当て情報の時間的終端でない場合（Ｓ４８：Ｎｏ）、上記ステップＳ４２に戻ってチャンネル割り当て情報の時間的終端になるまで上記各ステップを繰り返す。与えられたチャンネル割り当て情報の時間的終端の場合（Ｓ４８：Ｙｅｓ）、ステップＳ４９に進む。

ステップＳ４９でPolling判定部２２０は、各時間的スロットに対してPollingを行うかSleepを行うかをまとめ、時刻情報（時間軸の基準を決めるための情報）と共にPolling指示部に配信して本フローの処理を終了する。例えば、Polling判定部２２０は、各時間的スロット（図８の例では８０[usec]ごとに分割されたスロット）に対して、あるスロットではPollingを行い、他のスロットではSleepを行うなど、８０[usec]ごとの例えば１０回分の情報としてまとめ、まとめた情報（「Polling必要有無の情報」）を時刻情報と共にPolling指示部２３０にPollingスケジュール情報として渡す。

図１１は、Polling判定部２２０のPolling可否決定のロジックを示すサブルーチンである。図１１は、図１０のステップＳ４７のサブルーチンコールにより呼び出され実行される。
ステップＳ５１でPolling判定部２２０は、配信されたチャンネル割り当て情報を走査している際、該当タイムスロットのいずれかの周波数ブロックに「ＵＥの帰属有無によってパケット到着特性が変わるチャンネル」が含まれている場合に本ロジックはトリガ（再設定）される。

ステップＳ５２でPolling判定部２２０は、該当チャンネルのいずれにもＵＥが帰属しているか否かを判別する。
上記ステップＳ５２で該当チャンネルのいずれかにＵＥが帰属している場合（Ｓ５２：Ｙｅｓ）、ステップＳ５３でPolling判定部２２０は、トラフィック特性情報収集部２１０からチャンネル割り当て情報と同時に配信された「ＵＥのＩＤ：パケット到着特性」の情報群のキーに今回帰属しているＵＥが存在するかを確認する。

ステップＳ５４でPolling判定部２２０は、該当ＵＥのＩＤが存在するか否かを判別する。

上記ステップＳ５４で該当ＵＥのＩＤが存在する場合（Ｓ５４：Ｙｅｓ）、ステップＳ５５でPolling判定部２２０は、該当ＵＥが直前に割り当てられたリソースを用いてパケットを送信しているか否かを判別する。

上記ステップＳ５５で該当ＵＥが直前に割り当てられたリソースを用いてパケットを送信していない場合（Ｓ５５：Ｎｏ）、ステップＳ５６でPolling判定部２２０は、該当ＵＥはこれまで割り当てられたリソースを１％しか使っていないか否か、つまり、１％は使っているか否かを判別する。

上記ステップＳ５６で該当ＵＥはこれまで割り当てられたリソースを１％は使っていない場合（Ｓ５６：Ｎｏ）、ステップＳ５７でPolling判定部２２０は、該当時間はPollingを行うことを決定して図１０のステップＳ４７に戻る。

一方、上記ステップＳ５２でPolling判定部２２０は、該当チャンネルのいずれにもＵＥが帰属していない場合（Ｓ５２：Ｎｏ）、ステップＳ５８でPolling判定部２２０は、該当時間はSleepを行うことを決定して図１０のステップＳ４７に戻る。本実施形態では、本フローは、図１０のステップＳ４７のサブルーチンコールにより呼び出され実行される態様としたため、図１０のステップＳ４７に戻るが、図１１の処理を単独で実行するものでもよい。

上記ステップＳ５４で該当ＵＥのＩＤが存在しない場合（Ｓ５４：Ｎｏ）、ステップＳ５９でPolling判定部２２０は、該当時間はSleepを行うことを決定して図１０のステップＳ４７に戻る。

上記ステップＳ５５で該当ＵＥが直前に割り当てられたリソースを用いてパケットを送信している場合（Ｓ５５：Ｙｅｓ）、ステップＳ６０でPolling判定部２２０は、該当時間はPollingを行うことを決定して図１０のステップＳ４７に戻る。

上記ステップＳ５６で該当ＵＥはこれまで割り当てられたリソースを１％は使っている場合（Ｓ５６：Ｙｅｓ）、ステップＳ６１でPolling判定部２２０は、該当時間はSleepを行うことを決定して図１０のステップＳ４７に戻る。
以上、Polling判定部２２０の動作について説明した。

［Polling指示部２３０の動作］
図１２は、Polling指示部２３０の動作を示すフローチャートである。
ステップＳ７１でPolling指示部２３０（図１および図４参照）は、Polling判定部２２０（図１および図４参照）から、時刻同期（例えば図３のように８０[usec]ごとに）された「Polling必要有無の情報」（図１０のステップＳ４９参照）を受け取る。

ステップＳ７２でPolling指示部２３０は、Pollingに必要な時刻と必要な時間をデータ高速転送ミドルウェア３００に配信するとともに、データ高速転送ミドルウェア３００のPolling Thread３１０をトリガ（Polling Thread３１０を起床させる）して本フローの処理を終了する。上記トリガについて述べる。すなわち、Polling指示部２３０は、データ高速転送ミドルウェア３００に対し、Pollingさせる該当時間の直前になったとき、Polling指示部２３０がPolling Thread３１０を起床させる。例えば、Polling指示部２３０は、Polling Thread３１０に対し、次の例えば160[usec]で、Pollingを行いなさい、次の例えば80[usec]間は、Pollingを行いなさい等、Polling開始とPolling時間を指示する。このように、Polling指示部２３０が、Polling Thread３１０を実際に起床させることをトリガ（図１では、トリガを「Pollingスケジューリング」と記載している）という。

［データ高速転送ミドルウェア３００の動作］
図１３は、データ高速転送ミドルウェア３００の動作を示すフローチャートである。
ステップＳ８１でデータ高速転送ミドルウェア３００（図１および図４参照）は、Polling指示部２３０にトリガされることにより、Polling Thread３１０は指示された時間だけPollingを行う。

ステップＳ８２でデータ高速転送ミドルウェア３００は、Pollingが終了した場合、自動的にSleepして本フローの処理を終了する。

［ハードウェア構成］
上記実施形態に係るサーバ内データ転送装置２００は、例えば図１４に示すような構成のコンピュータ９００によって実現される。
図１４は、サーバ内データ転送装置２００の機能を実現するコンピュータ９００の一例を示すハードウェア構成図である。
コンピュータ９００は、ＣＰＵ９０１、ＲＯＭ９０２、ＲＡＭ９０３、ＨＤＤ９０４、通信インターフェイス（Ｉ／Ｆ：Interface）９０６、入出力インターフェイス（Ｉ／Ｆ）９０５、およびメディアインターフェイス（Ｉ／Ｆ）９０７を有する。

ＣＰＵ９０１は、ＲＯＭ９０２またはＨＤＤ９０４に格納されたプログラムに基づいて動作し、図１および図４に示すサーバ内データ転送装置２００の各部の制御を行う。ＲＯＭ９０２は、コンピュータ９００の起動時にＣＰＵ９０１によって実行されるブートプログラムや、コンピュータ９００のハードウェアに依存するプログラム等を格納する。

ＣＰＵ９０１は、入出力Ｉ／Ｆ９０５を介して、マウスやキーボード等の入力装置９１０、および、ディスプレイ等の出力装置９１１を制御する。ＣＰＵ９０１は、入出力Ｉ／Ｆ９０５を介して、入力装置９１０からデータを取得するともに、生成したデータを出力装置９１１へ出力する。なお、プロセッサとしてＣＰＵ９０１とともに、ＧＰＵ（Graphics Processing Unit）等を用いてもよい。

ＨＤＤ９０４は、ＣＰＵ９０１により実行されるプログラムおよび当該プログラムによって使用されるデータ等を記憶する。通信Ｉ／Ｆ９０６は、通信網（例えば、ＮＷ（Network）９２０）を介して他の装置からデータを受信してＣＰＵ９０１へ出力し、また、ＣＰＵ９０１が生成したデータを、通信網を介して他の装置へ送信する。

メディアＩ／Ｆ９０７は、記録媒体９１２に格納されたプログラムまたはデータを読み取り、ＲＡＭ９０３を介してＣＰＵ９０１へ出力する。ＣＰＵ９０１は、目的の処理に係るプログラムを、メディアＩ／Ｆ９０７を介して記録媒体９１２からＲＡＭ９０３上にロードし、ロードしたプログラムを実行する。記録媒体９１２は、ＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto Optical disk）等の光磁気記録媒体、磁気記録媒体、導体メモリテープ媒体又は半導体メモリ等である。

例えば、コンピュータ９００が本実施形態に係る一装置として構成されるサーバ内データ転送装置２００として機能する場合、コンピュータ９００のＣＰＵ９０１は、ＲＡＭ９０３上にロードされたプログラムを実行することによりサーバ内データ転送装置２００の機能を実現する。また、ＨＤＤ９０４には、ＲＡＭ９０３内のデータが記憶される。ＣＰＵ９０１は、目的の処理に係るプログラムを記録媒体９１２から読み取って実行する。この他、ＣＰＵ９０１は、他の装置から通信網（ＮＷ９２０）を介して目的の処理に係るプログラムを読み込んでもよい。

［効果］
以上説明したように、本実施形態に係るサーバ内データ転送装置は、Pollingモデルによるパケット転送を行うデータ転送部（データ高速転送ミドルウェア３００）のPollingスレッド（Polling Thread３１０）に対して、Sleep制御を行うサーバ内データ転送装置２００であって、パケット転送におけるトラフィック特性情報を収集するトラフィック特性情報収集部２１０と、トラフィック特性情報収集部２１０から受け取ったトラフィック特性情報をもとに、Pollingスレッドをパケットの到着確率が所定閾値以上のタイミングで起床させ、それ以外はSleepさせるPollingスケジュール情報を生成するPolling判定部２２０と、Polling判定部２２０から時刻同期情報とPollingスケジュール情報を受け取り、時刻同期情報およびPollingスケジュール情報をもとに、Pollingが必要な時刻と時間を示すPollingスケジュールをPollingスレッドに配信して当該PollingスレッドをPollingスケジュールで指示した時間だけPollingさせるPolling指示部２３０と、を備える。

このようにすることで、Polling判定部２２０は、トラフィック特性情報収集部２１０から受け取ったトラフィック特性情報をもとに、データ高速転送ミドルウェア３００がPollingモードによって受信処理を行うかSleepを行うかを判定し、Pollingスケジュール情報を生成する。Polling指示部２３０は、Polling判定部２２０から受け取った時刻同期情報およびPollingスケジュール情報をもとに、PollingスケジュールをPollingスレッドに配信して指示した時間だけPollingさせる。これにより、データ高速転送ミドルウェア３００内のPollingスレッドをパケットの到着確率が所定閾値以上のタイミングで起床させ、それ以外はSleepさせることができ、データ転送の低遅延性と省電力性を実現することができる。

また、サーバ内データ転送装置２００は、サーバ内のデータ転送遅延を、割込モデルではなくpollingモデルで実現することができ、低遅延化の達成が可能である。例えば、ＲＡＮにおける信号処理のように、トラフィック特性によってSleep制御スケジュールを決定できるユースケースにおいて、サーバ内データ転送装置２００は、Pollingモデルによって受信待機するかSleepするかの判定を行うことで、トラフィック特性に応じた受信スケジュールを行うことができる。これにより、サーバ内データ転送装置２００は、低遅延性を維持しつつ省電力化を図ることができる。

サーバ内データ転送装置２００において、トラフィック特性情報収集部２１０は、上位アプリケーション（Applications２）から時間および周波数領域のチャンネル割り当て情報を収集し、トラフィック特性情報としてPolling判定部２２０へ伝達する。

このように、Ｌ１／Ｌ２Application（上位アプリケーション）は、データ転送のための時間・周波数領域のチャンネル割り当て情報を有している。トラフィック特性情報収集部２１０は、Sleep制御スケジュールに用いる情報を上位アプリケーションから収集することができる。よって、サーバ内データ転送装置２００は、新たな部品等を追加することなく、またアプリケーションを改変することなく、汎用的にトラフィック特性情報を取得することができる。

サーバ内データ転送装置２００において、データ転送部（データ高速転送ミドルウェア３００）は、時系列によるパケット到着頻度の情報を保持する共有メモリ３２０を有し、トラフィック特性情報収集部２１０は、共有メモリ３２０を介してパケット到着頻度の情報を収集し、トラフィック特性情報としてPolling判定部２２０へ伝達する。

このように、トラフィック特性情報収集部２１０は、時系列によるパケット到着頻度の特徴などの、Sleep制御スケジュールに用いる情報をデータ転送部（データ高速転送ミドルウェア３００）から収集することができる。よって、サーバ内データ転送装置２００は、アプリケーションを改変することなく、時系列によるパケット到着頻度の特徴などの、Sleep制御スケジュールに用いる情報を取得することができる。

サーバ内データ転送装置２００において、トラフィック特性情報は、パケット到着パターン（データ到着パターン）が時間領域と周波数領域とで割り当てられたチャンネルを有し、このチャンネルは、パケット到着が予測不可の場合の第１チャンネル（「ＰＲＡＣＨ」）と、パケット到着タイミングを予測可能な場合と予測不可の場合の第２チャンネル（「ＰＵＳＣＨ」）と、パケット到着が予測可能な場合の第３チャンネル（「ＳＲＳ」）と、を有し、Polling判定部２２０は、第１チャンネルの場合、PollingスレッドがSleep状態で待機し、パケットが到着した場合にはハードウェア割り込み割込により起床させるPollingスケジュール情報を生成し、第２チャンネルの場合、PollingスレッドがSleepを行うPollingスケジュール情報を生成し、第３チャンネルの場合、Pollingスレッドがパケットの到着する直前にPollingを開始するPollingスケジュール情報を生成する。

このように、サーバ内データ転送装置２００は、ＲＡＮの無線信号のように、チャンネル毎にデータ到着パターンの特徴毎に、適するSleep制御スケジュールを定めることが可能になる。また、第２チャンネル（「ＰＵＳＣＨ」）のように、ＵＥが帰属しているチャンネルに対しては、該当ユーザからのこれまでのトラフィック統計を反映したsleep制御スケジュールを生成することが可能になる。

［適用例］
サーバ内データ転送システム１０００（図１参照）は、パケット到着頻度などの時間領域における特徴が定まったトラフィックであれば適用可能であるため、ＲＡＮにおける上りリンクのトラフィックのみならず、下りリンクのトラフィック等にも適用が可能である。
また、サーバ内データ転送システム１０００は、ネットワーク対向だけでなく、アクセラレータ対向に対しても適用が可能である。

なお、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上述文書中や図面中に示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行するためのソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣ（Integrated Circuit）カード、ＳＤ（Secure Digital）カード、光ディスク等の記録媒体に保持することができる。

２ Applications（上位アプリケーション）
１１０ＨＷ
１８０メモリ
２００サーバ内データ転送装置
２１０トラフィック特性情報収集部
２２０ Polling判定部
２３０ Polling指示部
３００データ高速転送ミドルウェア（データ転送部）
３１０ Polling Thread（Pollingスレッド）
３２０共有メモリ
１０００サーバ内データ転送システム
ＰＲＡＣＨ（第１チャンネル）
ＰＵＳＣＨ（第２チャンネル）
ＳＲＳ（第３チャンネル）

Claims

Pollingモデルによるパケット転送を行うデータ転送部のPollingスレッドに対して、Sleep制御を行うサーバ内データ転送装置であって、
前記パケット転送におけるトラフィック特性情報を収集するトラフィック特性情報収集部と、
前記トラフィック特性情報収集部から受け取った前記トラフィック特性情報をもとに、前記Pollingスレッドをパケットの到着確率が所定閾値以上のタイミングで起床させ、それ以外はSleepさせるPollingスケジュール情報を生成するPolling判定部と、
前記Polling判定部から時刻同期情報と前記Pollingスケジュール情報を受け取り、前記時刻同期情報および前記Pollingスケジュール情報をもとに、Pollingに必要な時刻と時間を示すPollingスケジュールを前記Pollingスレッドに配信して当該Pollingスレッドを前記Pollingスケジュールで指示した時間だけPollingさせるPolling指示部と、を備え、
前記トラフィック特性情報収集部は、上位アプリケーションから時間および周波数領域のチャンネル割り当て情報を収集し、前記トラフィック特性情報として前記Polling判定部へ伝達する
ことを特徴とするサーバ内データ転送装置。
Pollingモデルによるパケット転送を行うデータ転送部のPollingスレッドに対して、Sleep制御を行うサーバ内データ転送装置であって、
前記パケット転送におけるトラフィック特性情報を収集するトラフィック特性情報収集部と、
前記トラフィック特性情報収集部から受け取った前記トラフィック特性情報をもとに、前記Pollingスレッドをパケットの到着確率が所定閾値以上のタイミングで起床させ、それ以外はSleepさせるPollingスケジュール情報を生成するPolling判定部と、
前記Polling判定部から時刻同期情報と前記Pollingスケジュール情報を受け取り、前記時刻同期情報および前記Pollingスケジュール情報をもとに、Pollingに必要な時刻と時間を示すPollingスケジュールを前記Pollingスレッドに配信して当該Pollingスレッドを前記Pollingスケジュールで指示した時間だけPollingさせるPolling指示部と、を備え、
前記データ転送部は、時系列によるパケット到着頻度の情報を保持する共有メモリを有し、
前記トラフィック特性情報収集部は、前記共有メモリを介してパケット到着頻度の情報を収集し、前記トラフィック特性情報として前記Polling判定部へ伝達する
ことを特徴とするサーバ内データ転送装置。
Pollingモデルによるパケット転送を行うデータ転送部のPollingスレッドに対して、Sleep制御を行うサーバ内データ転送装置であって、
前記パケット転送におけるトラフィック特性情報を収集するトラフィック特性情報収集部と、
前記トラフィック特性情報収集部から受け取った前記トラフィック特性情報をもとに、前記Pollingスレッドをパケットの到着確率が所定閾値以上のタイミングで起床させ、それ以外はSleepさせるPollingスケジュール情報を生成するPolling判定部と、
前記Polling判定部から時刻同期情報と前記Pollingスケジュール情報を受け取り、前記時刻同期情報および前記Pollingスケジュール情報をもとに、Pollingに必要な時刻と時間を示すPollingスケジュールを前記Pollingスレッドに配信して当該Pollingスレッドを前記Pollingスケジュールで指示した時間だけPollingさせるPolling指示部と、を備え、
前記トラフィック特性情報は、パケット到着パターンが時間領域と周波数領域とで割り当てられたチャンネルを有し、
前記チャンネルは、
パケット到着が予測不可の場合の第１チャンネルと、
予測可能な場合と予測不可の場合の両方の可能性があるときの第２チャンネルと、
パケット到着が予測可能な場合の第３チャンネルと、を有し、
前記Polling判定部は、
前記第１チャンネルの場合、前記PollingスレッドがSleep状態で待機し、パケットが到着した場合にはハードウェア割り込み割込により起床させる前記Pollingスケジュール情報を生成し、
前記第２チャンネルの場合、前記PollingスレッドがSleepを行う前記Pollingスケジュール情報を生成し、
前記第３チャンネルの場合、前記Pollingスレッドがパケットの到着する直前にPollingを開始する前記Pollingスケジュール情報を生成する
ことを特徴とするサーバ内データ転送装置。
Pollingモデルによるパケット転送を行うデータ転送部のPollingスレッドに対して、Sleep制御を行うサーバ内データ転送装置のサーバ内データ転送方法であって、
前記パケット転送におけるトラフィック特性情報を収集するトラフィック特性情報収集ステップと、
前記トラフィック特性情報収集ステップで受け取った前記トラフィック特性情報をもとに、前記Pollingスレッドをパケットの到着確率が所定閾値以上のタイミングで起床させ、それ以外はSleepさせるPollingスケジュール情報を生成するPolling判定ステップと、
前記Polling判定ステップから時刻同期情報と前記Pollingスケジュール情報を受け取り、前記時刻同期情報および前記Pollingスケジュール情報をもとに、Pollingに必要な時刻と時間を示すPollingスケジュールを前記Pollingスレッドに配信して当該Pollingスレッドを前記Pollingスケジュールで指示した時間だけPollingさせるPolling指示ステップと、を実行し、
前記トラフィック特性情報収集ステップにおいて、上位アプリケーションから時間および周波数領域のチャンネル割り当て情報を収集し、前記トラフィック特性情報として前記Polling判定ステップへ伝達する
ことを特徴とするサーバ内データ転送方法。
Pollingモデルによるパケット転送を行うデータ転送部のPollingスレッドに対して、Sleep制御を行うサーバ内データ転送装置としてのコンピュータに、
前記パケット転送におけるトラフィック特性情報を収集するトラフィック特性情報収集手順、
前記トラフィック特性情報収集手順から受け取った前記トラフィック特性情報をもとに、前記Pollingスレッドをパケットの到着確率が所定閾値以上のタイミングで起床させ、それ以外はSleepさせるPollingスケジュール情報を生成するPolling判定手順、
前記Polling判定手順から時刻同期情報と前記Pollingスケジュール情報を受け取り、前記時刻同期情報および前記Pollingスケジュール情報をもとに、Pollingに必要な時刻と時間を示すPollingスケジュールを前記Pollingスレッドに配信して当該Pollingスレッドを前記Pollingスケジュールで指示した時間だけPollingさせるPolling指示手順、
を実行させ、
前記トラフィック特性情報収集手順において、上位アプリケーションから時間および周波数領域のチャンネル割り当て情報を収集し、前記トラフィック特性情報として前記Polling判定手順へ伝達する
ことを実行させるためのプログラム。