(57)【要約】  本発明の実施形態は、サービス多重化方法、サービス多重分離方法、及び関連デバイスを開示する。本方法は、送信デバイスが第１サービスのビットブロックストリームを受信デバイスに送信する段階と、送信デバイスが第１サービスから第２サービスに切り替えてサービス送信すると判定した場合、送信デバイスが少なくとも１つのサービス切り替え指示ビットブロックを受信デバイスに送信する段階と、送信デバイスが第２サービスのビットブロックストリームを受信デバイスに送信する段階とを含む。送信デバイスのサービス切り替えが、現在伝達されているサービスの影響を受けず、サービスが要求に基づいて任意のビットブロックでリアルタイムに切り替えられ得ることが分かる。さらに、サービス切り替え指示ビットブロックが、サービス切り替えを行うために、サービス切り替えを必要とするビットブロックストリーム間に挿入されるので、サービス切り替え処理の遅延及びジッタが減少し、サービス切り替え時の低遅延が保証される。
2020530959.tif 000002
【特許請求の範囲】
【請求項１】
サービス多重化方法であって、
送信デバイスが第１サービスのビットブロックストリームを受信デバイスに送信する段階と、
前記送信デバイスが前記第１サービスから第２サービスに切り替えてサービス送信するかどうかを判定する段階と、
前記送信デバイスが前記第１サービスから前記第２サービスに切り替えてサービス送信すると判定した場合、前記送信デバイスが少なくとも１つのサービス切り替え指示ビットブロックを前記受信デバイスに送信する段階であって、前記少なくとも１つのサービス切り替え指示ビットブロックは、前記第１サービスを前記第２サービスに切り替えてサービス送信することを示すのに用いられる、段階と、
前記送信デバイスが前記第２サービスのビットブロックストリームを前記受信デバイスに送信する段階と
を備える方法。
【請求項２】
前記第１サービスの前記ビットブロックストリームに含まれる任意のビットブロックと、前記第２サービスの前記ビットブロックストリームに含まれる任意のビットブロックと、前記少なくとも１つのサービス切り替え指示ビットブロックのうちのいずれか１つとがＭ１／Ｍ２ビットブロックであり、Ｍ１は各ビットブロック内のペイロードビットの数を表し、Ｍ２は各ビットブロック内のビットの合計数を表し、Ｍ１及びＭ２は正の整数であり、Ｍ２＞Ｍ１である、請求項１に記載の方法。
【請求項３】
送信デバイスが第１サービスのビットブロックストリームを受信デバイスに送信する前記段階の前に、前記方法はさらに、
前記送信デバイスが前記第１サービスの第１サービスデータを取得する段階と、
前記送信デバイスが前記第１サービスデータを符号化して前記第１サービスの前記ビットブロックストリームを生成する段階と
を備え、
前記送信デバイスが前記第２サービスのビットブロックストリームを前記受信デバイスに送信する前記段階の前に、前記方法はさらに、
前記送信デバイスが前記第２サービスの第２サービスデータを取得する段階と、
前記送信デバイスが前記第２サービスデータを符号化して前記第２サービスの前記ビットブロックストリームを生成する段階と
を備える、請求項２に記載の方法。
【請求項４】
前記Ｍ１／Ｍ２ビットブロックが６４Ｂ／６６Ｂビットブロックである場合、少なくとも１つのサービス切り替え指示ビットブロックが存在する、請求項２又は３に記載の方法。
【請求項５】
前記Ｍ１／Ｍ２ビットブロックが８Ｂ／１０Ｂビットブロックである場合、複数のサービス切り替え指示ビットブロックが存在し、前記複数のサービス切り替え指示ビットブロックは、少なくとも１つの特殊ビットブロックと少なくとも１つのデータビットブロックとを含む、請求項２又は３に記載の方法。
【請求項６】
前記少なくとも１つのサービス切り替え指示ビットブロックはさらに指示情報を含み、前記指示情報は、前記第２サービスの、前記受信デバイスに送信される、前記ビットブロックストリームに含まれるビットブロックの数を示すのに用いられる、請求項１から５のいずれか一項に記載の方法。
【請求項７】
前記送信デバイスが少なくとも１つのサービス切り替え指示ビットブロックを前記受信デバイスに送信する前記段階の前に、前記方法はさらに、
前記送信デバイスがターゲット識別子を判定する段階であって、前記ターゲット識別子は前記第２サービスに対応する識別子である、段階と、
前記送信デバイスが前記少なくとも１つのサービス切り替え指示ビットブロックを生成する段階であって、前記少なくとも１つのサービス切り替え指示ビットブロックは前記ターゲット識別子を含み、前記ターゲット識別子は、前記第２サービスの前記ビットブロックストリームをターゲットバッファに保存するよう前記受信デバイスに命令するのに用いられ、前記ターゲットバッファは、前記受信デバイスにより前記ターゲット識別子に割り当てられるバッファである、段階と
を備える、請求項１から６のいずれか一項に記載の方法。
【請求項８】
前記方法はさらに、
前記第１サービスの前記ビットブロックストリーム及び／又は前記第２サービスの前記ビットブロックストリームにアイドルビットブロックが存在すると前記送信デバイスが判定した場合、前記送信デバイスが前記アイドルビットブロックを削除する段階を備える、請求項１から７のいずれか一項に記載の方法。
【請求項９】
サービス多重分離方法であって、
送信デバイスにより送信される少なくとも１つのサービス切り替え指示ビットブロックが受信されたかどうかを受信デバイスが判定する段階であって、前記少なくとも１つのサービス切り替え指示ビットブロックは、前記送信デバイスが第１サービスから第２サービスに切り替えてサービス送信することを示すのに用いられ、前記第１サービスのビットブロックストリームが、前記受信デバイスが前記少なくとも１つのサービス切り替え指示ビットブロックを受信する前に前記受信デバイスにより受信されるビットブロックストリームである、段階と、
前記受信デバイスが前記少なくとも１つのサービス切り替え指示ビットブロックが受信されたと判定した場合、前記受信デバイスが前記少なくとも１つのサービス切り替え指示ビットブロックを受信した後に前記受信デバイスにより受信されるビットブロックストリームが前記第２サービスのビットブロックストリームであると前記受信デバイスが判定する段階と
を備える方法。
【請求項１０】
前記第１サービスの前記ビットブロックストリームに含まれる任意のビットブロックと、前記第２サービスの前記ビットブロックストリームに含まれる任意のビットブロックと、前記少なくとも１つのサービス切り替え指示ビットブロックのうちのいずれか１つとがＭ１／Ｍ２ビットブロックであり、Ｍ１は各ビットブロック内のペイロードビットの数を表し、Ｍ２は各ビットブロック内のビットの合計数を表し、Ｍ１及びＭ２は正の整数であり、Ｍ２＞Ｍ１である、請求項９に記載の方法。
【請求項１１】
前記少なくとも１つのサービス切り替え指示ビットブロックが受信されたと前記受信デバイスが判定する前に、前記方法はさらに、
前記受信デバイスが、前記第１サービスの、前記送信デバイスにより送信される、前記ビットブロックストリームを受信する段階と、
前記受信デバイスが、前記第１サービスの前記ビットブロックストリームを復号して前記第１サービスの第１サービスデータを取得する段階と
を備え、
前記少なくとも１つのサービス切り替え指示ビットブロックが受信されたと前記受信デバイスが判定した後に、前記方法はさらに、
前記受信デバイスが、前記第２サービスの、前記送信デバイスにより送信される、前記ビットブロックストリームを受信する段階と、
前記受信デバイスが、前記第２サービスの前記ビットブロックストリームを復号して前記第２サービスの第１サービスデータを取得する段階と
を備える、請求項１０に記載の方法。
【請求項１２】
前記Ｍ１／Ｍ２ビットブロックが６４Ｂ／６６Ｂビットブロックである場合、少なくとも１つのサービス切り替え指示ビットブロックが存在する、請求項１０又は１１に記載の方法。
【請求項１３】
前記Ｍ１／Ｍ２ビットブロックが８Ｂ／１０Ｂビットブロックである場合、複数のサービス切り替え指示ビットブロックが存在し、前記複数のサービス切り替え指示ビットブロックは、少なくとも１つの特殊ビットブロックと少なくとも１つのデータビットブロックとを含む、請求項１０又は１１に記載の方法。
【請求項１４】
前記少なくとも１つのサービス切り替え指示ビットブロックが受信されたと前記受信デバイスが判定した後に、前記方法はさらに、
前記受信デバイスが前記少なくとも１つのサービス切り替え指示ビットブロックに含まれる指示情報を取得する段階であって、前記指示情報は、前記第２サービスの前記ビットブロックストリームに含まれるビットブロックの数を示すのに用いられる、段階と、
前記受信デバイスが前記指示情報に従って、前記第２サービスの前記ビットブロックストリームに含まれる前記ビットブロックの数を判定する段階と
を備える、請求項１１から１３のいずれか一項に記載の方法。
【請求項１５】
前記少なくとも１つのサービス切り替え指示ビットブロックが受信されたと前記受信デバイスが判定した後に、前記方法はさらに、
前記受信デバイスが、前記少なくとも１つのサービス切り替え指示ビットブロックに含まれるターゲット識別子を取得する段階であって、前記ターゲット識別子は前記第２サービスに対応する識別子である、段階と、
前記受信デバイスが前記第２サービスの前記ビットブロックストリームをターゲットバッファに保存する段階であって、前記ターゲットバッファは、前記受信デバイスにより前記ターゲット識別子に割り当てられるバッファである、段階と
を備える、請求項９から１４のいずれか一項に記載の方法。
【請求項１６】
前記方法はさらに、
前記第１サービスの前記ビットブロックストリーム及び／又は前記第２サービスの前記ビットブロックストリームにアイドルビットブロックが存在すると前記受信デバイスが判定した場合、前記受信デバイスが前記アイドルビットブロックを削除する段階を備える、請求項９から１５のいずれか一項に記載の方法。
【請求項１７】
送信機と前記送信機に接続されたマルチプレクサとを備える送信デバイスであって、
前記送信機は、第１サービスのビットブロックストリームを受信デバイスに送信するように構成され、
前記マルチプレクサは、前記第１サービスから第２サービスに切り替えてサービス送信するかどうかを判定するように構成され、
前記送信機はさらに、前記マルチプレクサが前記第１サービスから前記第２サービスに切り替えてサービス送信すると判定した場合、少なくとも１つのサービス切り替え指示ビットブロックを前記受信デバイスに送信するように構成され、前記少なくとも１つのサービス切り替え指示ビットブロックは、前記第１サービスを前記第２サービスに切り替えてサービス送信することを示すのに用いられ、前記送信機はさらに、前記第２サービスのビットブロックストリームを前記受信デバイスに送信するように構成される、送信デバイス。
【請求項１８】
前記第１サービスの前記ビットブロックストリームに含まれる任意のビットブロックと、前記第２サービスの前記ビットブロックストリームに含まれる任意のビットブロックと、前記少なくとも１つのサービス切り替え指示ビットブロックのうちのいずれか１つとがＭ１／Ｍ２ビットブロックであり、Ｍ１は各ビットブロック内のペイロードビットの数を表し、Ｍ２は各ビットブロック内のビットの合計数を表し、Ｍ１及びＭ２は正の整数であり、Ｍ２＞Ｍ１である、請求項１７に記載の送信デバイス。
【請求項１９】
前記送信機はさらに、前記第１サービスの第１サービスデータを取得し、前記第１サービスデータを符号化して前記第１サービスの前記ビットブロックストリームを生成し、前記第２サービスの第２サービスデータを取得し、前記第２サービスデータを符号化して前記第２サービスの前記ビットブロックストリームを生成するように構成される、請求項１８に記載の送信デバイス。
【請求項２０】
前記Ｍ１／Ｍ２ビットブロックが６４Ｂ／６６Ｂビットブロックである場合、少なくとも１つのサービス切り替え指示ビットブロックが存在する、請求項１８又は１９に記載の送信デバイス。
【請求項２１】
前記Ｍ１／Ｍ２ビットブロックが８Ｂ／１０Ｂビットブロックである場合、複数のサービス切り替え指示ビットブロックが存在し、前記複数のサービス切り替え指示ビットブロックは、少なくとも１つの特殊ビットブロックと少なくとも１つのデータビットブロックとを含む、請求項１８又は１９に記載の送信デバイス。
【請求項２２】
前記少なくとも１つのサービス切り替え指示ビットブロックはさらに指示情報を含み、前記指示情報は、前記第２サービスの、前記受信デバイスに送信される、前記ビットブロックストリームに含まれるビットブロックの数を示すのに用いられる、請求項１７から２１のいずれか一項に記載の送信デバイス。
【請求項２３】
前記マルチプレクサはさらに、ターゲット識別子を判定することであって、前記ターゲット識別子が前記第２サービスに対応する識別子である、判定することと、前記少なくとも１つのサービス切り替え指示ビットブロックを生成することであって、前記少なくとも１つのサービス切り替え指示ビットブロックは前記ターゲット識別子を含み、前記ターゲット識別子は、前記第２サービスの前記ビットブロックストリームをターゲットバッファに保存するよう前記受信デバイスに命令するのに用いられ、前記ターゲットバッファは、前記受信デバイスにより前記ターゲット識別子に割り当てられるバッファである、生成することとを行うように構成される、請求項１７から２２のいずれか一項に記載の送信デバイス。
【請求項２４】
前記マルチプレクサはさらに、前記第１サービスの前記ビットブロックストリーム及び／又は前記第２サービスの前記ビットブロックストリームにアイドルビットブロックが存在すると判定された場合、前記アイドルビットブロックを削除するように構成される、請求項１７から２３のいずれか一項に記載の送信デバイス。
【請求項２５】
受信機と前記受信機に接続されたデマルチプレクサとを備える受信デバイスであって、
前記受信機は、送信デバイスにより送信される少なくとも１つのサービス切り替え指示ビットブロックが受信されたかどうかを判定するように構成され、前記少なくとも１つのサービス切り替え指示ビットブロックは、前記送信デバイスが第１サービスから第２サービスに切り替えてサービス送信することを示すのに用いられ、前記第１サービスのビットブロックストリームが、前記少なくとも１つのサービス切り替え指示ビットブロックが受信される前に受信されるビットブロックストリームであり、
前記デマルチプレクサは、前記少なくとも１つのサービス切り替え指示ビットブロックが受信されたと判定された場合、前記少なくとも１つのサービス切り替え指示ビットブロックが受信された後に受信されるビットブロックストリームが前記第２サービスのビットブロックストリームであると判定するように構成される、受信デバイス。
【請求項２６】
前記第１サービスの前記ビットブロックストリームに含まれる任意のビットブロックと、前記第２サービスの前記ビットブロックストリームに含まれる任意のビットブロックと、前記少なくとも１つのサービス切り替え指示ビットブロックのうちのいずれか１つとがＭ１／Ｍ２ビットブロックであり、Ｍ１は各ビットブロック内のペイロードビットの数を表し、Ｍ２は各ビットブロック内のビットの合計数を表し、Ｍ１及びＭ２は正の整数であり、Ｍ２＞Ｍ１である、請求項２５に記載の受信デバイス。
【請求項２７】
前記受信機はさらに、前記第１サービスの、前記送信デバイスにより送信される、前記ビットブロックストリームを受信するように構成され、
前記デマルチプレクサはさらに、前記第１サービスの前記ビットブロックストリームを復号して前記第１サービスの第１サービスデータを取得するように構成され、
前記受信機はさらに、前記第２サービスの、前記送信デバイスにより送信される、前記ビットブロックストリームを受信するように構成され、
前記デマルチプレクサはさらに、前記第２サービスの前記ビットブロックストリームを復号して前記第２サービスの第１サービスデータを取得するように構成される、請求項２６に記載の受信デバイス。
【請求項２８】
前記Ｍ１／Ｍ２ビットブロックが６４Ｂ／６６Ｂビットブロックである場合、少なくとも１つのサービス切り替え指示ビットブロックが存在する、請求項２６又は２７に記載の受信デバイス。
【請求項２９】
前記Ｍ１／Ｍ２ビットブロックが８Ｂ／１０Ｂビットブロックである場合、複数のサービス切り替え指示ビットブロックが存在し、前記複数のサービス切り替え指示ビットブロックは、少なくとも１つの特殊ビットブロックと少なくとも１つのデータビットブロックとを含む、請求項２６又は２７に記載の受信デバイス。
【請求項３０】
前記デマルチプレクサはさらに、前記少なくとも１つのサービス切り替え指示ビットブロックに含まれる指示情報を取得することであって、前記指示情報は、前記第２サービスの前記ビットブロックストリームに含まれるビットブロックの数を示すのに用いられる、取得することと、前記指示情報に従って、前記第２サービスの前記ビットブロックストリームに含まれる前記ビットブロックの数を判定することとを行うように構成される、請求項２７から２９のいずれか一項に記載の受信デバイス。
【請求項３１】
前記デマルチプレクサはさらに、前記少なくとも１つのサービス切り替え指示ビットブロックに含まれるターゲット識別子を取得することであって、前記ターゲット識別子は前記第２サービスに対応する識別子である、取得することと、前記第２サービスの前記ビットブロックストリームをターゲットバッファに保存することであって、前記ターゲットバッファは、前記受信デバイスにより前記ターゲット識別子に割り当てられるバッファである、保存することとを行うように構成される、請求項２５から３０のいずれか一項に記載の受信デバイス。
【請求項３２】
前記デマルチプレクサはさらに、前記第１サービスの前記ビットブロックストリーム及び／又は前記第２サービスの前記ビットブロックストリームにアイドルビットブロックが存在すると判定された場合、前記アイドルビットブロックを削除するように構成される、請求項２５から３１のいずれか一項に記載の受信デバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、２０１７年８月８日に中国特許庁に出願された「サービス多重化方法、サービス多重分離方法、及び関連デバイス（ＳＥＲＶＩＣＥ  ＭＵＬＴＩＰＬＥＸＩＮＧ  ＭＥＴＨＯＤ，  ＳＥＲＶＩＣＥ  ＤＥＭＵＬＴＩＰＬＥＸＩＮＧ  ＭＥＴＨＯＤ，  ＡＮＤ  ＲＥＬＡＴＥＤ  ＤＥＶＩＣＥ）」と題する中国特許出願第２０１７１０６７１４０２．８号に基づく優先権を主張し、当該中国特許出願はその全体が参照により本明細書に組み込まれる。
【０００２】
本発明は通信技術の分野に関し、具体的には、サービス多重化方法、サービス多重分離方法、及び関連デバイスに関する。
【背景技術】
【０００３】
サービスインタフェースとして、米国電気電子技術者協会（ｉｎｓｔｉｔｕｔｅ  ｏｆ  ｅｌｅｃｔｒｉｃａｌ  ａｎｄ  ｅｌｅｃｔｒｏｎｉｃｓ  ｅｎｇｉｎｅｅｒｓ、ＩＥＥＥ）が規定する８０２．３ベースのイーサネット（登録商標）が、様々なシナリオへの適用に成功している。しかしながら、ネットワーク技術の発展と共に、ネットワークは、より多くのサービスタイプをサポートする必要がある。
【０００４】
先行技術では、フレキシブルイーサネット（ｆｌｅｘ  ｅｔｈｅｒｎｅｔ（登録商標）、ＦｌｅｘＥ）の考えが提案されており、ネットワークが複数のタイプのサービスをサポートすることができる。ｆｌｅｘＥを用いると、複数のサービスを同じ物理リンクに多重化することができる。図１に示すように、ネットワークデバイスは複数の符号化器１０１と多重化モジュール１０２とを含む。ｆｌｅｘＥでは、複数のサービスが当該サービスに対応する符号化器１０１によって符号化され、符号化器１０１は符号化されたコードブロックストリームを多重化モジュール１０２に送信し、多重化モジュール１０２は複数のサービスのコードブロックストリームを多重化することができる。多重化モジュール１０２により用いられる多重化方法が、時分割多重化（ｔｉｍｅ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅｘｉｎｇ、ＴＤＭ）技術である。多重化モジュール１０２は、コードブロックを粒度として用いてタイムスロット分割を行い、タイムスロットのインタリーブを通じて多重化を実施する。多重化モジュール１０２により出力されるサービスデータストリームの具体的な構造の一例が、図２に示され得る。２０個のタイムスロットをサイクルとして用い、タイムスロット位置決めのために１つのｆｌｅｘＥオーバヘッドコードブロックが１０２３サイクルごとに挿入される。具体的なサービス伝達処理では、サービスを伝達する独立したチャネルとして各タイムスロットが用いられてよく、２０個のタイムスロットが２０個のチャネルであり、２０個のサービスを伝達するのに用いられてよい。
【０００５】
ｆｌｅｘＥベースの多重化では、各タイムスロットで搬送されるサービスが予め設定されており、多重化モジュール１０２により出力されるサービスデータストリームに対して、リアルタイムのサービス切り替えを行うことができない。
【発明の概要】
【０００６】
本願は、サービス多重化方法、サービス多重分離方法、及び関連デバイスを提供するため、リアルタイムのサービス切り替えを実装することができ、サービス切り替え時の低遅延を効果的に保証することができる。
【０００７】
本発明の実施形態の第１態様が、以下に挙げる段階を含むサービス多重化方法を提供する。
【０００８】
段階Ａ：送信デバイスが第１サービスのビットブロックストリームと第２サービスのビットブロックストリームとを対応するバッファに入力する。
【０００９】
送信デバイスの受信インタフェースが、第１サービスのビットブロックストリームと第２サービスのビットブロックストリームとを受信するように構成され、送信デバイスは、第１サービスのビットブロックストリームに対応する第１バッファと第２サービスのビットブロックストリームに対応する第２バッファとを判定してよい。
【００１０】
送信デバイスは、第１サービスのビットブロックストリームを、対応する第１バッファに入力し、第２サービスのビットブロックストリームを、対応する第２バッファに入力してよい。
【００１１】
本態様では、第１サービスのビットブロックストリームと第２サービスのビットブロックストリームとは、複数のサービスの、送信デバイスにより受信される、ビットブロックストリームで、受信デバイスに連続的に送信される必要がある任意の２つのビットブロックストリームであってよい。
【００１２】
段階Ｂ：送信デバイスは、第１サービスのビットブロックストリームを受信デバイスに送信する。
【００１３】
送信デバイスは、第１サービスのビットブロックストリームと第２サービスのビットブロックストリームとを受信デバイスに送信する優先順位を判定してよい。
【００１４】
本態様は、第１サービスのビットブロックストリームが第２サービスのビットブロックストリームよりも先に受信デバイスに送信される一例を用いて説明される。
【００１５】
例えば、送信デバイスは、第１サービスのビットブロックストリームの送信待ち時間が第２サービスのビットブロックストリームの送信待ち時間より長いと判定し、次いで、第１サービスのビットブロックストリームが第２サービスのビットブロックストリームよりも先に受信デバイスに送信されると判定する。
【００１６】
第１サービスのビットブロックストリームが第２サービスのビットブロックストリームよりも先に受信デバイスに送信されると送信デバイスが判定した場合、送信デバイスは、第１サービスのビットブロックストリームを受信デバイスに送信してよい。
【００１７】
段階Ｃ：送信デバイスは、第１サービスから第２サービスに切り替えてサービス送信するかどうかを判定し、送信デバイスが第１サービスから第２サービスに切り替えると判定した場合、段階Ｄを行う。
【００１８】
本態様では、送信デバイスは、第１サービスのビットブロックストリーム全体が送信された後に、第２サービスのビットブロックストリームに切り替えて送信すると判定してよい。
【００１９】
別の例では、送信デバイスは、送信デバイスにより予め決定された、第１サービスのビットブロックストリームにおける事前設定データトラフィックが送信された後に、第２サービスのビットブロックストリームに切り替えてサービス送信すると判定してよい。具体的には、送信デバイスが第１サービスのビットブロックストリーム全体を送信する前に、且つ送信デバイスが第１サービスのビットブロックストリームのうち事前設定データトラフィックを送信した後に、送信デバイスは第２サービスのビットブロックストリームに切り替えてサービス送信してよい。
【００２０】
段階Ｄ：送信デバイスは、少なくとも１つのサービス切り替え指示ビットブロックを受信デバイスに送信する。
【００２１】
送信デバイスが第１サービスから第２サービスに切り替えてサービス送信すると判定した場合、送信デバイスは、第１サービスのビットブロックストリームと第２サービスのビットブロックストリームとの間に少なくとも１つのサービス切り替え指示ビットブロックを挿入し、少なくとも１つのサービス切り替え指示ビットブロックを受信デバイスに送信してよい。
【００２２】
少なくとも１つのサービス切り替え指示ビットブロックは、第１サービスを第２サービスに切り替えてサービス送信することを示すのに用いられる。
【００２３】
段階Ｅ：送信デバイスは、第２サービスのビットブロックストリームを受信デバイスに送信する。
【００２４】
送信デバイスは、少なくとも１つのサービス切り替え指示ビットブロックを送信した後に、第２サービスのビットブロックストリームを送信してよい。
【００２５】
送信デバイスは、第１サービスのビットブロックストリームと、少なくとも１つのサービス切り替え指示ビットブロックと、第２サービスのビットブロックストリームとを送信時間に基づいて時系列的に送信することが分かる。
【００２６】
本態様において提供されるサービス多重化方法の有益な効果とは、送信デバイスがリアルタイムのサービス切り替えを任意のビットブロックで要求に基づいて実施できるという点にある。さらに、サービス切り替え指示ビットブロックが、サービス切り替えを行うために、サービス切り替えを必要とするビットブロックストリーム間に挿入されるので、サービス切り替え処理の遅延及びジッタが減少し、サービス切り替え時の低遅延が保証される。
【００２７】
本実施形態では、送信デバイスは、優先順位の低いサービスよりも先に優先順位の高いサービスを送信するように切り替えを行ってよいので、優先順位の高いサービスの早期送信が実施され、優先順位の高いサービスの非常に低い遅延及び非常に低いジッタが保証される。
【００２８】
本実施形態では、サービス多重化がバッファを用いて実装されることで、多重化が専用帯域幅を用いて行われるために生じる帯域幅の浪費及び伝送遅延を効果的に回避することができる。
【００２９】
これらの実施形態の第１態様の任意選択の実装例では、第１サービスのビットブロックストリームに含まれる任意のビットブロックと、第２サービスのビットブロックストリームに含まれる任意のビットブロックと、少なくとも１つのサービス切り替え指示ビットブロックのうちのいずれか１つとが、Ｍ１／Ｍ２ビットブロックである。ここで、Ｍ１は各ビットブロック内のペイロードビットの数を表し、Ｍ２は各ビットブロック内のビットの合計数を表し、Ｍ１及びＭ２は正の整数であり、Ｍ２＞Ｍ１である。
【００３０】
これらの実施形態の第１態様の任意選択の実装例では、段階Ｂを行う前に、送信デバイスはさらに以下に挙げる段階を行う。
【００３１】
段階Ｂ０１：送信デバイスは第１サービスの第１サービスデータを取得する。
【００３２】
本態様の第１サービスは、非イーサネットサービスであってよい。
【００３３】
段階Ｂ０２：送信デバイスは第１サービスデータを符号化して、第１サービスのビットブロックストリームを生成する。
【００３４】
段階Ｅを行う前に、送信デバイスはさらに以下に挙げる段階を行う。
【００３５】
段階Ｅ０１：送信デバイスは第２サービスの第２サービスデータを取得する。
【００３６】
段階Ｅ０２：送信デバイスは第２サービスデータを符号化して、第２サービスのビットブロックストリームを生成する。
【００３７】
本態様では、送信デバイスは異なるタイプのネットワークのデータを多重化するので、送信デバイスは異なるタイプのサービスを多重化することができ、本実施形態のサービス多重化方法は異なるネットワーク環境に適用することができる。
【００３８】
これらの実施形態の第１態様の任意選択の実装例では、Ｍ１／Ｍ２ビットブロックが６４Ｂ／６６Ｂビットブロックであってよい場合、Ｍ２−Ｍ１、すなわち６６−６４は、各ビットブロック内のヘッダ同期ヘッダのビット数を表す。
【００３９】
本態様では、１つ又は複数のサービス切り替え指示ビットブロックが、第１サービスのビットブロックストリームが第２サービスのビットブロックストリームに切り替えられることを示すのに用いられてよい。
【００４０】
サービス切り替え指示ビットブロックは、パラメータＯ０、Ｄ１、Ｄ２、Ｄ３、Ｃ４、Ｃ５、Ｃ６、及びＣ７を含んでよく、パラメータＤ１、Ｄ２、及びＤ３は８ビットのビットデータであり、パラメータＣ４、Ｃ５、Ｃ６、及びＣ７は７ビットのビットデータであり、パラメータＯ０は４ビットの制御コードである。
【００４１】
これらの実施形態の第１態様の任意選択の実装例では、Ｍ１／Ｍ２ビットブロックが８Ｂ／１０Ｂビットブロックである場合、複数のサービス切り替え指示ビットブロックが存在し、複数のサービス切り替え指示ビットブロックは少なくとも１つの特殊ビットブロックと少なくとも１つのデータビットブロックとを含む。
【００４２】
８Ｂ／１０Ｂ符号化では、特殊ビットブロック及びデータビットブロックは、サービス切り替えを示すのに一緒に用いられる必要があることが分かる。
【００４３】
本態様の符号化方式では、サービス切り替え指示ビットブロックがサービス切り替えを示すのに用いられるので、少なくとも１つのサービス切り替え指示ビットブロックを用いてリアルタイムのサービス切り替えを実施することができ、これにより、サービス切り替え処理における遅延及びジッタが減少し、サービス切り替え時の低遅延が保証されることが分かる。
【００４４】
これらの実施形態の第１態様の任意選択の実装例では、少なくとも１つのサービス切り替え指示ビットブロックはさらに指示情報を含み、指示情報は、第２サービスの、受信デバイスに送信される、ビットブロックストリームに含まれるビットブロックの数を示すのに用いられる。
【００４５】
具体的には、サービス切り替え指示ビットブロックが６４Ｂ／６６Ｂビットブロックである場合、指示情報は、サービス切り替え指示ビットブロックストリームに含まれるパラメータＤ１、Ｄ２、Ｄ３、Ｃ４、Ｃ５、Ｃ６、及びＣ７のうちのいずれか１つを用いて伝達されてよく、又は指示情報は、複数のサービス切り替え指示ビットブロックを用いて伝達されてもよい。
【００４６】
本態様では、送信デバイスのサービス多重化処理において、第２サービスのビットブロックストリームに含まれるビットブロックの数が、少なくとも１つのサービス切り替え指示ビットブロックを用いてリアルタイムに通知され得るので、第２サービスのビットブロックストリームに含まれるビットブロックの数を受信デバイスに通知することができ、低遅延が保証される。
【００４７】
これらの実施形態の第１態様の任意選択の実装例では、段階Ｄを行う前に、送信デバイスはさらに以下に挙げる段階を行う。
【００４８】
段階Ｄ０１：送信デバイスはターゲット識別子を判定する。
【００４９】
ターゲット識別子とは、第２サービスに対応する識別子である。
【００５０】
送信デバイスがターゲット識別子を取得する具体的な処理は、以下のとおりであってよい。
【００５１】
送信デバイスは、複数のサービスのうちのいずれか１つに対応する識別子を事前に受信してよく、送信デバイスは、第２サービスに対応するターゲット識別子を判定してよい。
【００５２】
複数のサービスを受信した後に、送信デバイスは、対応する識別子を複数のサービスのうちのいずれか１つに設定してよく、送信デバイスは、設定された識別子から第２サービスに対応するターゲット識別子を判定してよい。
【００５３】
段階Ｄ０２：送信デバイスは、少なくとも１つのサービス切り替え指示ビットブロックを生成する。
【００５４】
少なくとも１つのサービス切り替え指示ビットブロックはターゲット識別子を含み、ターゲット識別子は、第２サービスのビットブロックストリームをターゲットバッファに保存するよう受信デバイスに命令するのに用いられ、ターゲットバッファは受信デバイスによりターゲット識別子に割り当てられるバッファである。
【００５５】
本態様では、ターゲット識別子を含む少なくとも１つのサービス切り替え指示ビットブロックを送信デバイスが受信デバイスに送信すると、受信デバイスは、少なくとも１つのサービス切り替え指示ビットブロックに基づいて、サービスが切り替えられると判定してよく、またターゲット識別子に基づいて、サービスが第２サービスのビットブロックストリームに切り替えられると判定してよいことにより、受信デバイスのサービス処理効率が向上する。
【００５６】
これらの実施形態の第１態様の任意選択の実装例では、本方法はさらに、第１サービスのビットブロックストリーム及び／又は第２サービスのビットブロックストリームにアイドルビットブロックが存在すると送信デバイスが判定した場合、送信デバイスがアイドルビットブロックを削除する段階を含む。
【００５７】
送信デバイスの受信インタフェースが複数のサービスのビットブロックストリームを、対応するバッファｔｘ＿ｂｕｆに入力する前に、送信デバイスは、複数のサービスのビットブロックストリームにアイドルビットブロックが存在するかどうかを判定してよい。本実施形態では、アイドルビットブロックは、イーサネット（登録商標）規格のレートマッチングに用いられる専用制御ビットブロックであり、アイドルビットブロックは、有効なデータ伝送が現在何もない場合に送信されてよい。送信デバイスがアイドルビットブロックを削除した場合、送信デバイスがサービスを送信するのに用いる帯域幅の利用率が向上し得ることが分かる。
【００５８】
本発明の実施形態の第２態様が、以下に挙げる段階を含むサービス多重分離方法を提供する。
【００５９】
段階Ｆ：受信デバイスが、送信デバイスにより送信されるビットブロックストリームを受信する。
【００６０】
段階Ｇ：受信デバイスは、ビットブロックストリームにおいて、送信デバイスにより送信される少なくとも１つのサービス切り替え指示ビットブロックが受信されたかどうかを判定し、少なくとも１つのサービス切り替え指示ビットブロックが受信されたと受信デバイスが判定した場合、段階Ｈを行う。
【００６１】
少なくとも１つのサービス切り替え指示ビットブロックは、送信デバイスが第１サービスから第２サービスに切り替えてサービス送信することを示すのに用いられ、第１サービスのビットブロックストリームが、受信デバイスが少なくとも１つのサービス切り替え指示ビットブロックを受信する前に受信デバイスにより受信されるビットブロックストリームである。
【００６２】
段階Ｈ：受信デバイスは、少なくとも１つのサービス切り替え指示ビットブロックが受信された後に受信されるビットブロックストリームが第２サービスのビットブロックストリームであると判定する。
【００６３】
少なくとも１つのサービス切り替え指示ビットブロックが受信されたと受信デバイスが判定した場合、受信デバイスは、受信デバイスが少なくとも１つのサービス切り替え指示ビットブロックを受信した後に受信デバイスにより受信されるビットブロックストリームが第２サービスのビットブロックストリームであると判定してよい。
【００６４】
本態様では、受信デバイスは、少なくとも１つのサービス切り替え指示ビットブロックに基づいて、サービス切り替えが行われると判定してよく、受信デバイスは、受信デバイスが第１サービスのビットブロックストリームと、少なくとも１つのサービス切り替え指示ビットブロックと、第２サービスのビットブロックストリームとを受信時間に基づいて時系列的に送信すると判定してよいことが分かる。
【００６５】
本態様において提供されるサービス多重化方法の有益な効果とは、受信デバイスが任意のビットブロックでサービス切り替えを判定できるため、サービス切り替え処理における遅延及びジッタが減少しサービス切り替え時の低遅延が保証されるという点にある。本実施形態では、サービス多重分離がバッファを用いて実装されることで、多重分離が専用帯域幅を用いて行われるために生じる帯域幅の浪費及び伝送遅延を効果的に回避することができる。
【００６６】
これらの実施形態の第２態様の任意選択の実装例では、第１サービスのビットブロックストリームに含まれる任意のビットブロックと、第２サービスのビットブロックストリームに含まれる任意のビットブロックと、少なくとも１つのサービス切り替え指示ビットブロックのうちのいずれか１つとが、Ｍ１／Ｍ２ビットブロックである。ここで、Ｍ１は各ビットブロック内のペイロードビットの数を表し、Ｍ２は各ビットブロック内のビットの合計数を表し、Ｍ１及びＭ２は正の整数であり、Ｍ２＞Ｍ１である。
【００６７】
これらの実施形態の第２態様の任意選択の実装例では、段階Ｈを行う前に、受信デバイスはさらに以下に挙げる段階を行う。
【００６８】
段階Ｈ０１：受信デバイスは、第１サービスの、送信デバイスにより送信される、ビットブロックストリームを受信する。
【００６９】
段階Ｈ０２：受信デバイスは、第１サービスのビットブロックストリームを復号して、第１サービスの第１サービスデータを取得する。
【００７０】
段階Ｈを行った後に、受信デバイスはさらに以下に挙げる段階を行う。
【００７１】
段階Ｈ１１：受信デバイスは、第２サービスの、送信デバイスにより送信される、ビットブロックストリームを受信する。
【００７２】
段階Ｈ１２：受信デバイスは、第２サービスのビットブロックストリームを復号して、第２サービスの第１サービスデータを取得する。
【００７３】
本態様では、受信デバイスは異なるタイプのサービスを多重分離できるので、本実施形態におけるサービス多重分離方法は異なるネットワーク環境に適用することができる。
【００７４】
これらの実施形態の第２態様の任意選択の実装例では、Ｍ１／Ｍ２ビットブロックが６４Ｂ／６６Ｂビットブロックであってよい場合、Ｍ２−Ｍ１、すなわち６６−６４は、各ビットブロック内のヘッダ同期ヘッダのビット数を表す。
【００７５】
本態様では、１つ又は複数のサービス切り替え指示ビットブロックが、第１サービスのビットブロックストリームが第２サービスのビットブロックストリームに切り替えられることを示すのに用いられてよい。
【００７６】
サービス切り替え指示ビットブロックは、パラメータＯ０、Ｄ１、Ｄ２、Ｄ３、Ｃ４、Ｃ５、Ｃ６、及びＣ７を含んでよく、パラメータＤ１、Ｄ２、及びＤ３は８ビットのビットデータであり、パラメータＣ４、Ｃ５、Ｃ６、及びＣ７は７ビットのビットデータであり、パラメータＯ０は４ビットの制御コードである。
【００７７】
これらの実施形態の第２態様の任意選択の実装例では、Ｍ１／Ｍ２ビットブロックが８Ｂ／１０Ｂビットブロックである場合、複数のサービス切り替え指示ビットブロックが存在し、複数のサービス切り替え指示ビットブロックは少なくとも１つの特殊ビットブロックと少なくとも１つのデータビットブロックとを含む。
【００７８】
８Ｂ／１０Ｂ符号化では、特殊ビットブロック及びデータビットブロックは、サービス切り替えを示すのに一緒に用いられる必要があることが分かる。
【００７９】
これらの実施形態の第２態様の任意選択の実装例では、段階Ｈを行った後に、受信デバイスはさらに以下に挙げる段階を行う必要がある。
【００８０】
段階Ｈ２１：受信デバイスは、少なくとも１つのサービス切り替え指示ビットブロックに含まれる指示情報を取得する。
【００８１】
指示情報は、第２サービスのビットブロックストリームに含まれるビットブロックの数を示すのに用いられる。
【００８２】
具体的には、サービス切り替え指示ビットブロックが６４Ｂ／６６Ｂビットブロックである場合、指示情報は、サービス切り替え指示ビットブロックストリームに含まれるパラメータＤ１、Ｄ２、Ｄ３、Ｃ４、Ｃ５、Ｃ６、及びＣ７のうちのいずれか１つを用いて伝達されてよく、又は指示情報は、複数のサービス切り替え指示ビットブロックを用いて伝達されてもよい。
【００８３】
段階Ｈ２２：受信デバイスは、指示情報に従って、第２サービスのビットブロックストリームに含まれるビットブロックの数を判定する。
【００８４】
本態様では、サービス多重分離処理において、受信デバイスは、少なくとも１つのサービス切り替え指示ビットブロックを用いて、第２サービスのビットブロックストリームに含まれるビットブロックの数を判定してよく、これにより、サービス多重分離処理において低遅延が保証される。
【００８５】
これらの実施形態の第２態様の任意選択の実装例では、段階Ｈを行った後に、受信デバイスはさらに以下に挙げる段階を行う必要がある。
【００８６】
段階Ｈ３１：受信デバイスは、少なくとも１つのサービス切り替え指示ビットブロックに含まれるターゲット識別子を取得する。
【００８７】
ターゲット識別子とは、第２サービスに対応する識別子である。
【００８８】
段階Ｈ３２：受信デバイスは、第２サービスのビットブロックストリームをターゲットバッファに保存する。
【００８９】
ターゲットバッファは、受信デバイスによりターゲット識別子に割り当てられるバッファである。
【００９０】
本態様では、受信デバイスが、ターゲット識別子を含む少なくとも１つのサービス切り替え指示ビットブロックを受信すると、受信デバイスは、少なくとも１つのサービス切り替え指示ビットブロックに基づいて、サービスが切り替えられると判定してよく、またターゲット識別子に基づいて、サービスが第２サービスのビットブロックストリームに切り替えられると判定してよいことにより、受信デバイスのサービス処理効率が向上する。
【００９１】
これらの実施形態の第２態様の任意選択の実装例では、本方法はさらに、第１サービスのビットブロックストリーム及び／又は第２サービスのビットブロックストリームにアイドルビットブロックが存在すると受信デバイスが判定した場合、受信デバイスがアイドルビットブロックを削除する段階を含む。
【００９２】
受信デバイスが複数のサービスのビットブロックストリームを、対応するバッファｔｘ＿ｂｕｆにバッファリングする前に、受信デバイスは、複数のサービスのビットブロックストリームにアイドルビットブロックが存在するかどうかを判定してよい。本実施形態では、アイドルビットブロックは、イーサネット（登録商標）規格のレートマッチングに用いられる専用制御ビットブロックであり、アイドルビットブロックは、有効なデータ伝送が現在何もない場合に送信されてよい。受信デバイスがアイドルビットブロックを削除した場合、受信デバイスのサービス処理効率が向上し得ることが分かる。
【００９３】
本発明の実施形態の第３態様が、送信機と送信機に接続されたマルチプレクサとを含む送信デバイスを提供する。
【００９４】
送信機は、第１サービスのビットブロックストリームを受信デバイスに送信するように構成される。
【００９５】
マルチプレクサは、第１サービスから第２サービスに切り替えてサービス送信するかどうかを判定するように構成される。
【００９６】
送信機はさらに、マルチプレクサが第１サービスから第２サービスに切り替えてサービス送信すると判定した場合、少なくとも１つのサービス切り替え指示ビットブロックを受信デバイスに送信するように構成され、少なくとも１つのサービス切り替え指示ビットブロックは、第１サービスを第２サービスに切り替えてサービス送信することを示すのに用いられ、送信機はさらに、第２サービスのビットブロックストリームを受信デバイスに送信するように構成される。
【００９７】
本態様の送信デバイスは、本願の第１態様におけるサービス多重化方法を実行するように構成される。サービス多重化方法を実行するための具体的な処理については、本願の第１態様を参照されたい。詳細は、再度説明しない。
【００９８】
本態様において提供される送信デバイスの有益な効果とは、送信デバイスがリアルタイムのサービス切り替えを任意のビットブロックで要求に基づいて実施できるという点にある。さらに、サービス切り替え指示ビットブロックが、サービス切り替えを行うために、サービス切り替えを必要とするビットブロックストリーム間に挿入されるので、サービス切り替え処理の遅延及びジッタが減少し、サービス切り替え時の低遅延が保証される。
【００９９】
本実施形態では、送信デバイスは、優先順位の低いサービスよりも先に優先順位の高いサービスを送信するように切り替えを行ってよいので、優先順位の高いサービスの早期送信が実施され、優先順位の高いサービスの非常に低い遅延及び非常に低いジッタが保証される。本実施形態では、サービス多重化がバッファを用いて実装されることで、多重化が専用帯域幅を用いて行われるために生じる帯域幅の浪費及び伝送遅延を効果的に回避することができる。
【０１００】
これらの実施形態の第３態様の任意選択の実装例では、第１サービスのビットブロックストリームに含まれる任意のビットブロックと、第２サービスのビットブロックストリームに含まれる任意のビットブロックと、少なくとも１つのサービス切り替え指示ビットブロックのうちのいずれか１つとが、Ｍ１／Ｍ２ビットブロックである。ここで、Ｍ１は各ビットブロック内のペイロードビットの数を表し、Ｍ２は各ビットブロック内のビットの合計数を表し、Ｍ１及びＭ２は正の整数であり、Ｍ２＞Ｍ１である。
【０１０１】
これらの実施形態の第３態様の任意選択の実装例では、送信機はさらに、第１サービスの第１サービスデータを取得し、第１サービスデータを符号化して第１サービスのビットブロックストリームを生成し、第２サービスの第２サービスデータを取得し、第２サービスデータを符号化して第２サービスのビットブロックストリームを生成するように構成される。
【０１０２】
本態様では、送信デバイスは異なるタイプのネットワークのデータを多重化するので、送信デバイスは異なるタイプのサービスを多重化することができ、本実施形態の送信デバイスは異なるネットワーク環境に適用することができる。
【０１０３】
これらの実施形態の第３態様の任意選択の実装例では、Ｍ１／Ｍ２ビットブロックが６４Ｂ／６６Ｂビットブロックである場合、Ｍ２−Ｍ１、すなわち６６−６４は、各ビットブロック内のヘッダ同期ヘッダのビット数を表す。
【０１０４】
本態様では、１つ又は複数のサービス切り替え指示ビットブロックが、第１サービスのビットブロックストリームが第２サービスのビットブロックストリームに切り替えられることを示すのに用いられてよい。
【０１０５】
サービス切り替え指示ビットブロックは、パラメータＯ０、Ｄ１、Ｄ２、Ｄ３、Ｃ４、Ｃ５、Ｃ６、及びＣ７を含んでよく、パラメータＤ１、Ｄ２、及びＤ３は８ビットのビットデータであり、パラメータＣ４、Ｃ５、Ｃ６、及びＣ７は７ビットのビットデータであり、パラメータＯ０は４ビットの制御コードである。
【０１０６】
これらの実施形態の第３態様の任意選択の実装例では、Ｍ１／Ｍ２ビットブロックが８Ｂ／１０Ｂビットブロックである場合、複数のサービス切り替え指示ビットブロックが存在し、複数のサービス切り替え指示ビットブロックは少なくとも１つの特殊ビットブロックと少なくとも１つのデータビットブロックとを含む。
【０１０７】
８Ｂ／１０Ｂ符号化では、特殊ビットブロック及びデータビットブロックは、サービス切り替えを示すのに一緒に用いられる必要があることが分かる。
【０１０８】
本態様の受信デバイスによれば、サービス切り替え指示ビットブロックがサービス切り替えを示すのに用いられるので、リアルタイムのサービス切り替えが少なくとも１つのサービス切り替え指示ビットブロックを用いて実施され得ることにより、サービス切り替え処理における遅延及びジッタが減少し、サービス切り替え時の低遅延が保証されることが分かる。
【０１０９】
これらの実施形態の第３態様の任意選択の実装例では、少なくとも１つのサービス切り替え指示ビットブロックはさらに指示情報を含み、指示情報は、第２サービスの、受信デバイスに送信される、ビットブロックストリームに含まれるビットブロックの数を示すのに用いられる。
【０１１０】
具体的には、サービス切り替え指示ビットブロックが６４Ｂ／６６Ｂビットブロックである場合、指示情報は、サービス切り替え指示ビットブロックストリームに含まれるパラメータＤ１、Ｄ２、Ｄ３、Ｃ４、Ｃ５、Ｃ６、及びＣ７のうちのいずれか１つを用いて伝達されてよく、又は指示情報は、複数のサービス切り替え指示ビットブロックを用いて伝達されてもよい。
【０１１１】
本態様では、送信デバイスのサービス多重化処理において、第２サービスのビットブロックストリームに含まれるビットブロックの数が、少なくとも１つのサービス切り替え指示ビットブロックを用いてリアルタイムに通知され得るので、第２サービスのビットブロックストリームに含まれるビットブロックの数を受信デバイスに通知することができ、低遅延が保証される。
【０１１２】
これらの実施形態の第３態様の任意選択の実装例では、マルチプレクサはさらに、ターゲット識別子を判定することであって、ターゲット識別子は第２サービスに対応する識別子である、判定することと、少なくとも１つのサービス切り替え指示ビットブロックを生成することであって、少なくとも１つのサービス切り替え指示ビットブロックはターゲット識別子を含み、ターゲット識別子は、第２サービスのビットブロックストリームをターゲットバッファに保存するよう受信デバイスに命令するのに用いられ、ターゲットバッファは、受信デバイスによりターゲット識別子に割り当てられるバッファである、生成することとを行うように構成される。
【０１１３】
本態様では、ターゲット識別子を含む少なくとも１つのサービス切り替え指示ビットブロックを送信デバイスが受信デバイスに送信すると、受信デバイスは、少なくとも１つのサービス切り替え指示ビットブロックに基づいて、サービスが切り替えられると判定してよく、またターゲット識別子に基づいて、サービスが第２サービスのビットブロックストリームに切り替えられると判定してよいことにより、受信デバイスのサービス処理効率が向上する。
【０１１４】
これらの実施形態の第３態様の任意選択の実装例では、マルチプレクサはさらに、第１サービスのビットブロックストリーム及び／又は第２サービスのビットブロックストリームにアイドルビットブロックが存在すると判定された場合、アイドルビットブロックを削除するように構成される。
【０１１５】
送信デバイスが複数のサービスのビットブロックストリームを、対応するバッファｔｘ＿ｂｕｆに入力する前に、送信デバイスは、複数のサービスのビットブロックストリームにアイドルビットブロックが存在するかどうかを判定してよい。本実施形態では、アイドルビットブロックは、イーサネット（登録商標）規格のレートマッチングに用いられる専用制御ビットブロックであり、アイドルビットブロックは、有効なデータ伝送が現在何もない場合に送信されてよい。送信デバイスがアイドルビットブロックを削除した場合、送信デバイスがサービスを送信するのに用いる帯域幅の利用率が向上し得ることが分かる。
【０１１６】
本発明の実施形態の第４態様が受信デバイスを提供し、本デバイスは、送信デバイスにより送信される少なくとも１つのサービス切り替え指示ビットブロックが受信されたかどうかを判定するように構成された受信機であって、少なくとも１つのサービス切り替え指示ビットブロックは、送信デバイスが第１サービスから第２サービスに切り替えてサービス送信することを示すのに用いられ、第１サービスのビットブロックストリームが、少なくとも１つのサービス切り替え指示ビットブロックが受信される前に受信されるビットブロックストリームである、受信機と、少なくとも１つのサービス切り替え指示ビットブロックが受信されたと判定された場合、少なくとも１つのサービス切り替え指示ビットブロックが受信された後に受信されるビットブロックストリームが第２サービスのビットブロックストリームであると判定するように構成されたデマルチプレクサとを含む。
【０１１７】
受信機はデマルチプレクサに接続される。
【０１１８】
本態様は、本願の第２態様におけるサービス多重分離方法を実行するのに用いられる。サービス多重分離方法を実行するための具体的な処理については、本願の第２態様を参照されたい。詳細は、再度説明しない。
【０１１９】
これらの実施形態の第４態様の任意選択の実装例では、第１サービスのビットブロックストリームに含まれる任意のビットブロックと、第２サービスのビットブロックストリームに含まれる任意のビットブロックと、少なくとも１つのサービス切り替え指示ビットブロックのうちのいずれか１つとが、Ｍ１／Ｍ２ビットブロックである。ここで、Ｍ１は各ビットブロック内のペイロードビットの数を表し、Ｍ２は各ビットブロック内のビットの合計数を表し、Ｍ１及びＭ２は正の整数であり、Ｍ２＞Ｍ１である。
【０１２０】
これらの実施形態の第４態様の任意選択の実装例では、受信機はさらに、第１サービスの、送信デバイスにより送信される、ビットブロックストリームを受信するように構成され、デマルチプレクサはさらに、第１サービスのビットブロックストリームを復号して第１サービスの第１サービスデータを取得するように構成され、受信機はさらに、第２サービスの、送信デバイスにより送信される、ビットブロックストリームを受信するように構成され、デマルチプレクサはさらに、第２サービスのビットブロックストリームを復号して第２サービスの第１サービスデータを取得するように構成される。
【０１２１】
本態様では、受信デバイスは異なるタイプのサービスを多重分離できるので、本実施形態におけるサービス多重分離方法は異なるネットワーク環境に適用することができる。
【０１２２】
これらの実施形態の第４態様の任意選択の実装例では、Ｍ１／Ｍ２ビットブロックが６４Ｂ／６６Ｂビットブロックである場合、Ｍ２−Ｍ１、すなわち６６−６４は、各ビットブロック内のヘッダ同期ヘッダのビット数を表す。
【０１２３】
本態様では、１つ又は複数のサービス切り替え指示ビットブロックが、第１サービスのビットブロックストリームが第２サービスのビットブロックストリームに切り替えられることを示すのに用いられてよい。
【０１２４】
サービス切り替え指示ビットブロックは、パラメータＯ０、Ｄ１、Ｄ２、Ｄ３、Ｃ４、Ｃ５、Ｃ６、及びＣ７を含んでよく、パラメータＤ１、Ｄ２、及びＤ３は８ビットのビットデータであり、パラメータＣ４、Ｃ５、Ｃ６、及びＣ７は７ビットのビットデータであり、パラメータＯ０は４ビットの制御コードである。
【０１２５】
これらの実施形態の第４態様の任意選択の実装例では、Ｍ１／Ｍ２ビットブロックが８Ｂ／１０Ｂビットブロックである場合、複数のサービス切り替え指示ビットブロックが存在し、複数のサービス切り替え指示ビットブロックは少なくとも１つの特殊ビットブロックと少なくとも１つのデータビットブロックとを含む。
【０１２６】
８Ｂ／１０Ｂ符号化では、特殊ビットブロック及びデータビットブロックは、サービス切り替えを示すのに一緒に用いられる必要があることが分かる。
【０１２７】
これらの実施形態の第４態様の任意選択の実装例では、デマルチプレクサはさらに、少なくとも１つのサービス切り替え指示ビットブロックに含まれる指示情報を取得することであって、指示情報は、第２サービスのビットブロックストリームに含まれるビットブロックの数を示すのに用いられる、取得することと、指示情報に従って、第２サービスのビットブロックストリームに含まれるビットブロックの数を判定することとを行うように構成される。
【０１２８】
本態様では、サービス多重分離処理において、受信デバイスは、少なくとも１つのサービス切り替え指示ビットブロックを用いて、第２サービスのビットブロックストリームに含まれるビットブロックの数を判定してよく、これにより、サービス多重分離処理において低遅延が保証される。
【０１２９】
これらの実施形態の第４態様の任意選択の実装例では、デマルチプレクサはさらに、少なくとも１つのサービス切り替え指示ビットブロックに含まれるターゲット識別子を取得することであって、ターゲット識別子は第２サービスに対応する識別子である、取得することと、第２サービスのビットブロックストリームをターゲットバッファに保存することであって、ターゲットバッファは受信デバイスによりターゲット識別子に割り当てられるバッファである、保存することとを行うように構成される。
【０１３０】
本態様では、受信デバイスが、ターゲット識別子を含む少なくとも１つのサービス切り替え指示ビットブロックを受信すると、受信デバイスは、少なくとも１つのサービス切り替え指示ビットブロックに基づいて、サービスが切り替えられると判定してよく、またターゲット識別子に基づいて、サービスが第２サービスのビットブロックストリームに切り替えられると判定してよいことにより、受信デバイスのサービス処理効率が向上する。
【０１３１】
これらの実施形態の第４態様の任意選択の実装例では、デマルチプレクサはさらに、第１サービスのビットブロックストリーム及び／又は第２サービスのビットブロックストリームにアイドルビットブロックが存在すると判定された場合、アイドルビットブロックを削除するように構成される。
【０１３２】
受信デバイスが複数のサービスのビットブロックストリームを、対応するバッファｔｘ＿ｂｕｆにバッファリングする前に、受信デバイスは、複数のサービスのビットブロックストリームにアイドルビットブロックが存在するかどうかを判定してよい。本実施形態では、アイドルビットブロックは、イーサネット（登録商標）規格のレートマッチングに用いられる専用制御ビットブロックであり、アイドルビットブロックは、有効なデータ伝送が現在何もない場合に送信されてよい。受信デバイスがアイドルビットブロックを削除した場合、受信デバイスのサービス処理効率が向上し得ることが分かる。
【０１３３】
本願において提供されるサービス多重化方法、サービス多重分離方法、及び関連デバイスの有益な効果とは、送信デバイスが第１サービスから第２サービスに切り替えてサービス送信すると判定した場合、送信デバイスは、第１サービスのビットブロックストリームと第２サービスのビットブロックストリームとの間に少なくとも１つのサービス切り替え指示ビットブロックを挿入してよいので、送信デバイスは、第１サービスのビットブロックストリームと、少なくとも１つのサービス切り替え指示ビットブロックと、第２サービスのビットブロックストリームとを受信デバイスに連続的に送信することができるという点にある。送信デバイスは少なくとも１つのサービス切り替え指示ビットブロックを用いてリアルタイムのサービス切り替えを実施できることにより、サービス切り替え処理における遅延及びジッタが減少し、サービス切り替え時の低遅延が保証されることが分かる。
【図面の簡単な説明】
【０１３４】
【図１】先行技術におけるネットワークデバイスの概略構造図である。
【０１３５】
【図２】先行技術における、ネットワークデバイスにより出力されるサービスデータストリームの概略構造図である。
【０１３６】
【図３】本願における通信ネットワークの一実施形態の概略構造図である。
【０１３７】
【図４】本願のネットワークデバイスの一実施形態におけるハードウェア構造の概略図である。
【０１３８】
【図５】本願のネットワークデバイスの別の実施形態におけるハードウェア構造の概略図である。
【０１３９】
【図６】本願におけるサービス多重化方法の一実施形態の各段階のフローチャートである。
【０１４０】
【図７】本願におけるネットワークデバイスのネットワーク通信の基本フレームワークの一実施形態の概略構造図である。
【０１４１】
【図８】本願において複数のサービスのビットブロックストリームをマルチプレクサが多重化する処理の概略図である。
【０１４２】
【図９】本願におけるサービス多重分離方法の一実施形態の各段階のフローチャートである。
【０１４３】
【図１０】本願においてビットブロックストリームをデマルチプレクサが多重分離する一実施形態の処理の概略図である。
【０１４４】
【図１１】本願においてネットワークデバイスがサービスを多重化又は多重分離する処理の概略図である。
【０１４５】
【図１２】本願におけるサービス多重化方法の別の実施形態の各段階のフローチャートである。
【０１４６】
【図１３】本願におけるマルチプレクサの一実施形態の概略構造図である。
【０１４７】
【図１４】本願におけるサービス多重分離方法の別の実施形態の各段階のフローチャートである。
【０１４８】
【図１５】本願におけるデマルチプレクサの一実施形態の概略構造図である。
【０１４９】
【図１６】本願においてネットワークデバイスがサービスを多重化又は多重分離する別の実施形態の処理の概略図である。
【０１５０】
【図１７】本願におけるサービス多重分離方法の別の実施形態の各段階のフローチャートである。
【０１５１】
【図１８】本願におけるマルチプレクサの一実施形態の概略構造図である。
【０１５２】
【図１９】本願におけるサービス多重分離方法の別の実施形態の各段階のフローチャートである。
【０１５３】
【図２０】本願におけるデマルチプレクサの一実施形態の概略構造図である。
【０１５４】
【図２１】本願においてネットワークデバイスがサービスを多重化又は多重分離する別の実施形態の処理の概略図である。
【０１５５】
【図２２】本願のサービス切り替え指示ビットブロックストリームの一実施形態におけるコードワードの概略構造図である。
【０１５６】
【図２３】本願における送信デバイスの一実施形態の概略構造図である。
【０１５７】
【図２４】本願における受信デバイスの一実施形態の概略構造図である。
【発明を実施するための形態】
【０１５８】
本願は通信ネットワークを提供する。通信ネットワークは、本願におけるサービス多重化方法及びサービス多重分離方法を実施することができる。本願において提供される通信ネットワークの構造が、例として、図３を参照して以下に説明される。
【０１５９】
通信ネットワークは、接続された少なくとも２つのネットワークデバイス３００を含む。通信ネットワークに含まれるネットワークデバイス３００の具体的な数が本実施形態において限定されることはなく、また任意のネットワークデバイス３００に接続されるネットワークデバイス３００の具体的な数が本実施形態において限定されることはない。
【０１６０】
本実施形態におけるネットワークデバイスは、ネットワークアダプタ、スイッチ、又はルータなどのデバイスであってよい。
【０１６１】
ネットワークデバイスは、イーサネット（登録商標）、無線アクセスネットワーク（ｒａｄｉｏ  ａｃｃｅｓｓ  ｎｅｔｗｏｒｋ、ＲＡＮ）、又は無線ローカルエリアネットワーク（ｗｉｒｅｌｅｓｓ  ｌｏｃａｌ  ａｒｅａ  ｎｅｔｗｏｒｋｓ、ＷＬＡＮ）などのネットワーク環境に適用されてよい。
【０１６２】
ネットワークデバイスのハードウェア構造が、図４に示す一実施形態を参照して以下に説明される。
【０１６３】
本実施形態は、ネットワークデバイスが送信デバイスとして用いられる一例を用いて説明されている。送信デバイスとして用いられるネットワークデバイスは、受信されたサービスデータを多重化し、多重化されたビットブロックストリームを受信デバイスに送信するように構成される。
【０１６４】
本実施形態は、ネットワークデバイス４００が第１ネットワークデバイス４０１、第２ネットワークデバイス４０２、第３ネットワークデバイス４０３、及び第Ｎネットワークデバイス４０４により送信されるサービスデータを受信するように構成される一例を用いて説明される。
【０１６５】
ネットワークデバイス４００が受信できるサービスデータの量が、本実施形態において限定されることはない。
【０１６６】
具体的には、ネットワークデバイス４００に含まれる受信インタフェースが、異なるネットワークデバイスにより送信されるサービスデータを受信するように構成される。
【０１６７】
図４は一例として用いられ、受信インタフェース４０６は第１ネットワークデバイス４０１により送信されるサービスデータを受信するように構成され、受信インタフェース４０７は第２ネットワークデバイス４０２により送信されるサービスデータを受信するように構成され、受信インタフェース４０８は第３ネットワークデバイス４０３により送信されるサービスデータを受信するように構成され、受信インタフェース４０９は第Ｎネットワークデバイス４０４により送信されるサービスデータを受信するように構成される。
【０１６８】
ネットワークデバイス４００に含まれる受信インタフェースの数が、本実施形態において限定されることはない。
【０１６９】
ネットワークデバイスの送信インタフェース４０５が、受信インタフェースにより送信されるサービスデータを受信し、本願におけるサービス多重化方法を用いてサービス多重化を行ってビットブロックストリームを形成するように構成される。
【０１７０】
ネットワークデバイスに含まれる送信インタフェース４０５の具体的な数が、本実施形態において限定されることはない。
【０１７１】
図４に示す実施形態は、ネットワークデバイスが通信ネットワークにおける送信デバイスとして用いられる場合の、ネットワークデバイスのハードウェア構造を説明している。ネットワークデバイスが受信デバイスとして用いられる場合のネットワークデバイスのハードウェア構造が、図５に示す一実施形態を参照して以下に説明される。
【０１７２】
本実施形態では、受信デバイスとして用いられるネットワークデバイスは、多重化されたビットブロックストリームを受信するように構成され、ネットワークデバイスはさらに、多重化されたビットブロックストリームを多重分離するように構成される。
【０１７３】
本実施形態では、ネットワークデバイス５００の受信インタフェース５０１が、多重化されたビットブロックストリームを受信するように構成される。
【０１７４】
ネットワークデバイスに含まれる受信インタフェース５０１の具体的な数が、本実施形態において限定されることはない。
【０１７５】
受信インタフェース５０１は、本願におけるサービス多重分離方法を用いてビットブロックストリームを多重分離し、複数のサービスに別々に対応するビットブロックストリームを形成するように構成される。受信インタフェース５０１は、複数のサービスに対応するビットブロックストリームを、対応する送信インタフェースに送信する。例えば、受信インタフェース５０１は第１サービスのビットブロックストリームを送信インタフェース５０２に送信し、受信インタフェース５０１は第２サービスのビットブロックストリームを送信インタフェース５０３に送信し、受信インタフェース５０１は第３サービスのビットブロックストリームを送信インタフェース５０４に送信し、受信インタフェース５０１は第Ｎサービスのビットブロックストリームを送信インタフェース５０５に送信する。
【０１７６】
ネットワークデバイス５００に含まれる送信インタフェースの数が、本実施形態において限定されることはない。
【０１７７】
前述の実施形態に基づいて、送信デバイスとして用いられるネットワークデバイスが、受信されたサービスデータに対してどのようにサービス多重化を行うかについての具体的な処理が、図６を参照して以下に詳細に説明される。
【０１７８】
本実施形態は、本実施形態がイーサネット（登録商標）に適用される一例を用いて説明される。
【０１７９】
段階６０１：複数のサービスのビットブロックストリームを、対応するバッファｔｘ＿ｂｕｆに入力する。
【０１８０】
具体的には、本実施形態における送信デバイスの受信インタフェースが、複数のサービスのビットブロックストリームを受信するように構成され、受信インタフェースは、複数のサービスのビットブロックストリームに別々に対応するバッファｔｘ＿ｂｕｆを判定してよく、さらに、複数のサービスのビットブロックストリームを、対応するバッファｔｘ＿ｂｕｆに入力してよい。
【０１８１】
任意選択で、送信デバイスの受信インタフェースが複数のサービスのビットブロックストリームを、対応するバッファｔｘ＿ｂｕｆに入力する前に、送信デバイスは、複数のサービスのビットブロックストリームにアイドルビットブロックが存在するかどうかを判定してよい。本実施形態では、アイドルビットブロックは、イーサネット（登録商標）規格のレートマッチングに用いられる専用制御ビットブロックであり、アイドルビットブロックは、有効なデータ伝送が現在何もない場合に送信されてよい。
【０１８２】
送信デバイスの受信インタフェースが複数のサービスのビットブロックストリームにアイドルビットブロックが存在すると判定した場合、送信デバイスの受信インタフェースは、アイドルビットブロックを直接的に処分してよい。
【０１８３】
段階６０２：バッファｔｘ＿ｂｕｆに対して調停を行い、調停結果情報を生成する。
【０１８４】
本実施形態では、送信デバイスの送信インタフェースにあるマルチプレクサが、バッファｔｘ＿ｂｕｆに対して調停を行って、サービス多重化に用いられる調停結果情報を生成するように構成されてよい。
【０１８５】
本実施形態においてマルチプレクサを配置する方式が、以下に説明される。
【０１８６】
図７に示すように、本実施形態では、送信デバイスのネットワーク通信の基本フレームワークが開放型システム間相互接続（ｏｐｅｎ  ｓｙｓｔｅｍ  ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ、ＯＳＩ）である。ＯＳＩモデルは、送信デバイスのネットワーク通信作業を、物理層、データリンク層、ネットワーク層、トランスポート層、セッション層、プレゼンテーション層、及びアプリケーション層という７つの層に分割する。
【０１８７】
具体的には、物理層は、物理符号化副層（ｐｈｙｓｉｃａｌ  ｃｏｄｉｎｇ  ｓｕｂｌａｙｅｒ、ＰＣＳ）、前方誤り訂正部（ｆｏｒｗａｒｄ  ｅｒｒｏｒ  ｃｏｒｒｅｃｔｉｏｎ、ＦＥＣ）、物理媒体接続部（ｐｈｙｓｉｃａｌ  ｍｅｄｉｕｍ  ａｔｔａｃｈｍｅｎｔ、ＰＭＡ）、及び物理媒体依存部（ｐｈｙｓｉｃａｌ  ｍｅｄｉｕｍ  ｄｅｐｅｎｄｅｎｔ、ＰＭＤ）を含む。
【０１８８】
より具体的には、７１に示すように、送信デバイスの物理符号化副層ＰＣＳは、サービスデータを符号化するように構成された複数の符号化モジュール７１２を含み、符号化モジュール７１２は受信インタフェースに配置され、符号化モジュール７１２は、受信されたサービスデータを符号化してビットブロックストリームを生成し、当該ビットブロックストリームをマルチプレクサ７１３に入力してよい。
【０１８９】
本実施形態では、符号化モジュール７１２がサービスデータを符号化することで生成したビットブロックストリーム内の任意のビットブロックがＭ１／Ｍ２ビットブロックである。Ｍ１は各ビットブロック内のペイロードビットの数を表し、Ｍ２は各ビットブロック内のビットの合計数を表し、Ｍ１及びＭ２は正の整数であり、Ｍ２＞Ｍ１である。
【０１９０】
本実施形態では、物理符号化副層ＰＣＳは、複数のサービスの符号化されたビットブロックストリームを多重化するように構成されたマルチプレクサ７１３を含み、マルチプレクサ７１３は送信インタフェースに配置される。
【０１９１】
物理符号化副層ＰＣＳはさらに、送信インタフェースに配置されたスクランブルモジュール７１４及び処理モジュール７１５を含む。スクランブルモジュール７１４は、多重化されたビットブロックストリームに対してスクランブル処理を行うように構成される。
【０１９２】
処理モジュール７１５は、多重化されたビットブロックストリームに対して対応する処理を行う、例えば、多重化されたビットブロックストリームを複数の物理リンクに分配し、アライメント識別子を周期的に挿入するように構成される。本実施形態における処理モジュール７１５により行われる処理の説明は任意選択の例であって、限定されることはないことが明らかなはずである。
【０１９３】
マルチプレクサがどのようにして、バッファｔｘ＿ｂｕｆに対して調停を行い、サービス多重化に用いられる調停結果情報を生成するかについての具体的な処理が、以下に説明される。
【０１９４】
マルチプレクサは、複数のサービスのビットブロックストリームを別々にバッファリングするバッファｔｘ＿ｂｕｆがターゲット条件を満たしているかどうかを判定し、マルチプレクサは、バッファｔｘ＿ｂｕｆに対して調停を行い、バッファｔｘ＿ｂｕｆがターゲット条件を満たしている場合にだけ、調停結果情報を生成する。
【０１９５】
本実施形態では、ターゲット条件とは、バッファｔｘ＿ｂｕｆに送信対象データが存在するということであり、ターゲット条件はさらに、複数のサービスの、バッファｔｘ＿ｂｕｆにバッファリングされる、ビットブロックストリームのフロー制御の下で、データ送信が可能であるということである。
【０１９６】
マルチプレクサは、ターゲット条件を満たす複数のバッファｔｘ＿ｂｕｆから、調停結果情報を判定する。本実施形態では、調停結果情報は、ターゲット条件を満たす複数のバッファｔｘ＿ｂｕｆにバッファリングされたビットブロックストリームを受信デバイスに送信する優先順位を示すのに用いられ得るので、送信デバイスは、調停結果情報に示される優先順位に基づいて、複数のサービスのビットブロックストリームを優先順位の降順で受信デバイスに送信する。
【０１９７】
任意選択で、本実施形態では、ターゲット条件を満たす複数のバッファｔｘ＿ｂｕｆに別々にバッファリングされたビットブロックストリームが、バッファｔｘ＿ｂｕｆにバッファリングされたビットブロックストリームの送信待ち時間の降順でソートされることを、調停結果情報は示す。
【０１９８】
任意選択で、本実施形態では、ターゲット条件を満たす複数のバッファｔｘ＿ｂｕｆに別々にバッファリングされたビットブロックストリームが、バッファｔｘ＿ｂｕｆにバッファリングされたビットブロックストリームの送信データトラフィックの昇順でソートされることを、調停結果情報は示す。
【０１９９】
調停結果情報に示される、ターゲット条件を満たす複数のバッファｔｘ＿ｂｕｆに別々にバッファリングされたビットブロックストリームを受信デバイスに送信する優先順位の説明は、任意選択の例であって、限定されることはないことが明らかなはずである。
【０２００】
段階６０３：第１サービスのビットブロックストリームを受信デバイスに送信する。
【０２０１】
本実施形態では、受信デバイスは、ターゲット条件を満たす複数のバッファｔｘ＿ｂｕｆに別々にバッファリングされたビットブロックストリームから調停結果情報に基づいて、第１サービスの、受信デバイスに現在送信される必要がある、ビットブロックストリームを判定する。
【０２０２】
段階６０４：第１サービスから第２サービスに切り替えてサービス送信するかどうかを判定し、第１サービスから第２サービスに切り替えると判定された場合、段階６０５を行う。
【０２０３】
本実施形態では、マルチプレクサは、調停結果情報に基づいて、第１サービスを第２サービスに切り替えてサービス送信するかどうかを判定してよい。
【０２０４】
任意選択で、調停結果情報に示される優先順序が以下のとおりであってよい。つまり、送信デバイスは、第１サービスのビットブロックストリームを送信した後に、第２サービスのビットブロックストリームを送信する。
【０２０５】
任意選択で、調停結果情報に示される優先順序が、代替的に以下のとおりであってもよい。つまり、送信デバイスは、第１サービスのビットブロックストリームのうち事前設定データトラフィックを送信した後に、第２サービスのビットブロックストリームを送信する。事前設定データトラフィックは、調停結果情報に示されるデータトラフィックである。具体的には、本実施形態では、送信デバイスが第１サービスのビットブロックストリーム全体を送信する前に、且つ送信デバイスが第１サービスのビットブロックストリームのうち事前設定データトラフィックを送信した後に、送信デバイスは第２サービスのビットブロックストリームに切り替えてサービス送信してよい。
【０２０６】
段階６０５：第１サービスのビットブロックストリームと第２ビットブロックストリームとの間に、少なくとも１つのサービス切り替え指示ビットブロックを挿入する。
【０２０７】
図８は一例として用いられる。マルチプレクサが、調停結果情報に示される優先順序に基づいて、第１サービスのビットブロックストリームと第２サービスのビットブロックストリームとが受信デバイスに連続的に送信されると判定してよい場合、マルチプレクサは、第１サービスのビットブロックストリームと第１サービスのビットブロックストリームとの間に少なくとも１つのサービス切り替え指示ビットブロック８０１を挿入する。
【０２０８】
少なくとも１つのサービス切り替え指示ビットブロックは、第１サービスを第２サービスに切り替えてサービス送信することを示すのに用いられる。
【０２０９】
本実施形態では、少なくとも１つのサービス切り替え指示ビットブロックはさらにターゲット識別子を含み、ターゲット識別子は第２サービスのビットブロックストリームに対応する識別子である。
【０２１０】
本実施形態では、送信デバイスが第２サービスのビットブロックストリームに対応するターゲット識別子を判定できるならば、送信デバイスがターゲット識別子を取得する具体的な処理が本実施形態において限定されることはない。
【０２１１】
例えば、送信デバイスは、複数のサービスのうちのいずれか１つに対応する識別子を事前に受信してよく、送信デバイスは、第２サービスに対応するターゲット識別子を判定してよい。
【０２１２】
別の例では、複数のサービスを受信した後に、送信デバイスは、対応する識別子を複数のサービスのうちのいずれか１つに設定してよく、送信デバイスは、設定された識別子から第２サービスに対応するターゲット識別子を判定してよい。
【０２１３】
ターゲット識別子を含む少なくとも１つのサービス切り替え指示ビットブロックを送信デバイスが受信デバイスに送信すると、受信デバイスは、少なくとも１つのサービス切り替え指示ビットブロックに基づいて、サービスが切り替えられると判定してよく、またターゲット識別子に基づいて、サービスが第２サービスのビットブロックストリームに切り替えられると判定してよいことにより、受信デバイスのサービス処理効率が向上することが分かる。
【０２１４】
サービス切り替え指示ビットブロックの数が、本実施形態において限定されることはない。
【０２１５】
段階６０６：少なくとも１つのサービス切り替え指示ビットブロックを受信デバイスに送信する。
【０２１６】
本実施形態では、送信デバイスが第１サービスのビットブロックストリームを受信デバイスに送信した後に、送信デバイスは、第１サービスのビットブロックストリームと第２サービスのビットブロックストリームとの間に挿入される少なくとも１つのサービス切り替え指示ビットブロックを送信してよい。
【０２１７】
段階６０７：第２サービスのビットブロックストリームを受信デバイスに送信する。
【０２１８】
本実施形態では、送信デバイスは、少なくとも１つのサービス切り替え指示ビットブロックを送信した後に、第２サービスのビットブロックストリームを送信してよい。
【０２１９】
送信デバイスは、第１サービスのビットブロックストリームと、少なくとも１つのサービス切り替え指示ビットブロックと、第２サービスのビットブロックストリームとを送信時間に基づいて時系列的に送信することが分かる。
【０２２０】
送信デバイスがサービス切り替えを行うたびにバッファｔｘ＿ｂｕｆのステータスが変わるため、本実施形態の送信デバイスは、バッファｔｘ＿ｂｕｆにあるターゲット条件を満たす全ての送信対象ビットブロックストリームが受信デバイスに送信されるまで、本実施形態の段階６０２から段階６０７までを周期的に実行してよい。
【０２２１】
段階６０８：どのバッファｔｘ＿ｂｕｆにも送信対象ビットブロックストリームがないことが検出された場合、アイドルビットブロックを受信デバイスに送信する。
【０２２２】
本実施形態では、ターゲット条件を満たすバッファｔｘ＿ｂｕｆの全てのビットブロックストリームが送信されたことをマルチプレクサが検出した場合、送信デバイスはアイドルビットブロックを受信デバイスに送信する。
【０２２３】
本実施形態において提供されるサービス多重化方法の有益な効果とは、送信デバイスのサービス切り替えが、現在伝達されているサービスによって影響を受けず、サービス切り替えを任意のビットブロックで要求に基づいてリアルタイムに実施できるという点にある。さらに、サービス切り替え指示ビットブロックが、サービス切り替えを行うために、サービス切り替えを必要とするビットブロックストリーム間に挿入されるので、サービス切り替え処理の遅延及びジッタが減少し、サービス切り替え時の低遅延が保証される。
【０２２４】
本実施形態では、送信デバイスは、優先順位の低いサービスよりも先に優先順位の高いサービスを送信するように切り替えを行ってよいので、優先順位の高いサービスの早期送信が実施され、優先順位の高いサービスの非常に低い遅延及び非常に低いジッタが保証される。
【０２２５】
本実施形態では、サービス多重化がバッファを用いて実装されることで、多重化が専用帯域幅を用いて行われるために生じる帯域幅の浪費及び伝送遅延を効果的に回避することができる。
【０２２６】
サービス多重化をどのように行うかについての具体的な処理が、図６に示す実施形態における送信デバイスの観点から説明されている。サービス多重分離を行う具体的な処理が、図９を参照して受信デバイスの観点から以下に説明される。
【０２２７】
段階９０１：送信デバイスにより送信されるビットブロックストリームを受信する。
【０２２８】
任意選択で、本実施形態では、受信デバイスの受信インタフェースが、送信デバイスにより送信されるビットブロックストリームにアイドルビットブロックが存在するかどうかを判定してよい。ビットブロックストリームにアイドルビットブロックが存在すると受信デバイスが判定した場合、受信デバイスの受信インタフェースは、アイドルビットブロックを直接的に処分してよい。
【０２２９】
段階９０２：少なくとも１つのサービス切り替え指示ビットブロックがビットブロックストリームに存在するかどうかを検出し、少なくとも１つのサービス切り替え指示ビットブロックがビットブロックストリームに存在した場合、段階９０３を行う。
【０２３０】
本実施形態では、受信デバイスのデマルチプレクサが、受信された各ビットブロックがサービス切り替え指示ビットブロックであるかどうかを検出する。
【０２３１】
デマルチプレクサが１つのサービス切り替え指示ビットブロック又は複数の連続したサービス切り替え指示ビットブロックを受信した場合、段階９０３が行われる。
【０２３２】
デマルチプレクサは、受信デバイスの受信インタフェースに配置される。
【０２３３】
本実施形態においてデマルチプレクサを配置する方式が、以下に説明される。
【０２３４】
図７に示すように、本実施形態における受信デバイスのネットワーク通信の基本フレームワークについては、送信デバイスのネットワーク通信の基本フレームワークを参照されたい。詳細は、本実施形態において再度説明しない。
【０２３５】
具体的には、７２に示すように、受信デバイスの物理符号化副層ＰＣＳは複数の処理モジュール７２４を含む。処理モジュール７２４は、複数の物理リンクからデータストリームを受信し、当該データストリームをアライメント識別子に基づいてアライメントしてソートするように構成される。本実施形態における処理モジュール７２４により行われる処理の説明は任意選択の例であって、限定されることはないことが明らかなはずである。
【０２３６】
物理符号化副層ＰＣＳはさらに、デスクランブルモジュール７２３を含み、デスクランブルモジュール７２３は、多重分離されたサービスデータに対してデスクランブル処理を行うように構成される。
【０２３７】
物理符号化副層ＰＣＳはさらにデマルチプレクサ７２２を含み、デマルチプレクサ７２２は、ビットブロックストリームを当該ビットブロックストリームに対応するバッファに保存するように構成される。
【０２３８】
物理符号化副層ＰＣＳはさらに復号モジュール７２１を含み、復号モジュール７２１は、多重分離されたビットブロックストリームを復号してサービスデータを生成するように構成される。
【０２３９】
本実施形態では、ビットブロックストリーム内の任意のビットブロックがＭ１／Ｍ２ビットブロックである。Ｍ１は各ビットブロック内のペイロードビットの数を表し、Ｍ２は各ビットブロック内のビットの合計数を表し、Ｍ１及びＭ２は正の整数であり、Ｍ２＞Ｍ１である。
【０２４０】
任意選択で、本実施形態では、送信デバイスにより送信される完全なビットブロックストリームを受信した後に、受信デバイスは、ビットブロックストリームに含まれるビットブロックを１つ１つ検出して、ビットブロックストリームに含まれる全てのサービス切り替え指示ビットブロックを判定してよい。
【０２４１】
任意選択で、本実施形態では、送信デバイスにより送信される１つのビットブロックを受信した後に、受信デバイスは現在受信されているビットブロックを検出して、現在受信されているビットブロックがサービス切り替え指示ビットブロックであるかどうかを判定してよい。
【０２４２】
段階９０３：少なくとも１つのサービス切り替え指示ビットブロックが受信された後に受信されるビットブロックストリームが、第２サービスのビットブロックストリームであると判定する。
【０２４３】
少なくとも１つのサービス切り替え指示ビットブロックが受信された後に受信されるビットブロックストリームが第２サービスのビットブロックストリームであると、デマルチプレクサがどのように判定するかが、以下に説明される。
【０２４４】
本実施形態では、受信デバイス及び送信デバイスが、少なくとも１つのサービス切り替え指示ビットブロックがサービス切り替えを示すのに用いられることに合意してよく、デマルチプレクサが少なくとも１つのサービス切り替え指示ビットブロックを受信した場合、デマルチプレクサは、第１サービスのビットブロックストリームと第２サービスのビットブロックストリームとの間でサービス切り替えが行われると判定してよい。
【０２４５】
第１サービスのビットブロックストリームは、受信デバイスが少なくとも１つのサービス切り替え指示ビットブロックを受信する前に受信デバイスにより受信されるビットブロックストリームであり、第２サービスのビットブロックストリームは、受信デバイスが少なくとも１つのサービス切り替え指示ビットブロックを受信した後に受信デバイスにより受信されるビットブロックストリームである。
【０２４６】
具体的には、本実施形態では、少なくとも１つのサービス切り替え指示ビットブロックはターゲット識別子を含み、ターゲット識別子は第２サービスのビットブロックストリームに対応する識別子である。
【０２４７】
受信デバイスは、第２サービスの対応するビットブロックストリームをターゲット識別子に基づいて判定してよく、受信デバイスは、少なくとも１つのサービス切り替え指示ビットブロックが受信された後に、第２サービスのビットブロックストリームが受信されると判定してよい。
【０２４８】
任意選択で、本実施形態では、受信デバイスは複数のサービスのうちのいずれか１つに対応する識別子を事前に受信してよく、送信デバイスにより送信されるターゲット識別子を受信した後に、受信デバイスは、ターゲット識別子に対応する第２サービスを判定してよい。
【０２４９】
任意選択で、受信デバイスは送信デバイスにより送信される識別子セットを事前に受信してよく、当該識別子セットは複数のサービスのうちのいずれか１つに対応する識別子を含む。この場合、送信デバイスにより送信されるターゲット識別子を受信した後に、受信デバイスは、ターゲット識別子に対応する第２サービスを判定してよい。
【０２５０】
ターゲット識別子を含む少なくとも１つのサービス切り替え指示ビットブロックを送信デバイスが受信デバイスに送信すると、受信デバイスは、少なくとも１つのサービス切り替え指示ビットブロックに基づいて、サービスが切り替えられると判定してよく、またターゲット識別子に基づいて、サービスが第２サービスのビットブロックストリームに切り替えられると判定してよいことにより、受信デバイスのサービス処理効率が向上することが分かる。
【０２５１】
段階９０４：第２サービスのビットブロックストリームをターゲットバッファに保存する。
【０２５２】
本実施形態では、複数のサービスのうちのいずれか１つに対応する識別子をデマルチプレクサが受信した後に、デマルチプレクサは、各識別子にバッファを割り当てて、サービスとバッファとの間の対応関係を確立してよい。
【０２５３】
図１０に示すように、例えば、デマルチプレクサは、第１サービスのビットブロックストリームと第２サービスのビットブロックストリームとを受信する。
【０２５４】
デマルチプレクサは、第１バッファｔｘ＿ｂｕｆを第１サービスに、第２バッファｔｘ＿ｂｕｆを第２サービスに予め割り当ててよい。
【０２５５】
デマルチプレクサが少なくとも１つのサービス切り替え指示ビットブロックに含まれるターゲット識別子を取得した場合、デマルチプレクサは、ターゲット識別子に対応する予め割り当てられたターゲットバッファを判定してよく、デマルチプレクサは第２サービスのビットブロックストリームをターゲットバッファに保存してよい。
【０２５６】
任意のサービスの、受信デバイスにより受信される、ビットブロックストリームが、対応するバッファに保存されるまで、本実施形態における段階９０２から段階９０４までが周期的に行われる。
【０２５７】
本実施形態において提供されるサービス多重分離方法の有益な効果とは、受信デバイスが、サービス切り替え指示ビットブロックを検出する方式で、サービスが切り替えられることを判定することにより、サービス切り替えが任意のビットブロックでリアルタイムに実施され得るので、サービス切り替え処理における遅延及びジッタが減少し、サービス切り替え時の低遅延が保証されるという点にある。
【０２５８】
本実施形態では、サービス多重分離がバッファを用いて実装されることで、多重分離が専用帯域幅を用いて行われるために生じる帯域幅の浪費及び伝送遅延を効果的に回避することができる。
【０２５９】
送信デバイスが本願におけるサービス多重化を行う具体的な処理をより十分に理解するために、送信デバイスがサービス多重化を行う具体的な処理が、例として、特定のサービスタイプを参照して以下に説明される。
【０２６０】
送信デバイスがイーサネット（登録商標）の全二重モードでサービス多重化をどのように実装するかが、本実施形態において例として説明される。
【０２６１】
図１１に示すように、本実施形態では、例えば、送信デバイスにより受信される全てのサービスがイーサネット（登録商標）パケットサービスである。
【０２６２】
イーサネット（登録商標）パケットサービスは具体的には、遅延に敏感なパケットサービス（ｅｘｐｒｅｓｓ  ｍｅｄｉａ  ａｃｃｅｓｓ  ｃｏｎｔｒｏｌ、ｅＭＡＣ）、及び優先順位が低いパケットサービス（ｐｒｅｅｍｐｔａｂｌｅ  ｍｅｄｉａ  ａｃｃｅｓｓ  ｃｏｎｔｒｏｌ、ｐＭＡＣ）である。
【０２６３】
ｅＭＡＣサービスの遅延感度は、ｐＭＡＣサービスの遅延感度より高い。
【０２６４】
本実施形態におけるサービス多重化処理が、図１２に示す各段階のフローチャートを参照して以下に詳細に説明される。
【０２６５】
段階１２０１：ＰＣＳ上部分により出力される、ｅＭＡＣの６４Ｂ／６６Ｂビットブロックストリームを、第１バッファｔｘ＿ｂｕｆがバッファリングする。
【０２６６】
送信デバイスのＰＣＳ上部分（Ｔｈｅ  ６４Ｂ／６６Ｂ  ｅｎｃｏｄｅｒ  ａｎｄ  ｄｅｃｏｄｅｒ  ｐａｒｔ  ｏｆ  ａ  ＰＣＳ，ＰＣＳ  ｕｐ−ｐａｒｔ）が、図７の符号化に用いられる符号化モジュール７１２である。
【０２６７】
本実施形態では、送信デバイスの第１ｔｘ＿ｂｕｆは、ｅＭＡＣサービスをバッファリングするように構成される。ｅＭＡＣサービスを受信した後に、送信デバイスは、ｅＭＡＣサービスをｅＭＡＣサービスに対応する第１ｔｘ＿ｂｕｆにバッファリングしてよい。
【０２６８】
イーサネット（登録商標）では、ｅＭＡＣサービスのデータストリームが６４Ｂ／６６Ｂビットブロックストリームである。
【０２６９】
段階１２０２：ＰＣＳ上部分により出力される、ｐＭＡＣの６４Ｂ／６６Ｂビットブロックストリームを、第２ｔｘ＿ｂｕｆがバッファリングする。
【０２７０】
本実施形態では、送信デバイスの第２ｔｘ＿ｂｕｆは、ｐＭＡＣサービスをバッファリングするように構成される。ｐＭＡＣサービスを受信した後に、送信デバイスは、ｐＭＡＣサービスをｐＭＡＣサービスに対応する第２ｔｘ＿ｂｕｆにバッファリングしてよい。
【０２７１】
イーサネット（登録商標）では、ｐＭＡＣサービスのデータストリームが６４Ｂ／６６Ｂビットブロックストリームである。
【０２７２】
本実施形態では、帯域幅利用率を向上させるために、マルチプレクサが、第１ｔｘ＿ｂｕｆ及び第２ｔｘ＿ｂｕｆにアイドルビットブロックが存在するかどうかを検出してよい。
【０２７３】
具体的には、マルチプレクサは、ＰＣＳ上部分により出力される６４Ｂ／６６Ｂビットブロックストリームのパケット間ギャップ（ｉｎｔｅｒ−ｐａｃｋｅｔ−ｇａｐ、ＩＰＧ）にアイドルビットブロックが存在するかどうかを検出してよく、アイドルビットブロックが存在する場合、マルチプレクサはＩＰＧ内のアイドルビットブロックを削除してよい。
【０２７４】
マルチプレクサの具体的な説明については、前述の実施形態を参照されたい。詳細は、本実施形態において再度説明しない。
【０２７５】
任意選択で、マルチプレクサは、バッファ内のビットブロックストリームに対してフロー制御を行ってよく、具体的な処理は以下のとおりである。
【０２７６】
マルチプレクサは、バッファ内のビットブロックストリームを周期的に又はリアルタイムに検出してよく、バッファ内のビットブロックストリームのデータ量が事前設定閾値より多い又はそれと等しいことをマルチプレクサが検出した場合、マルチプレクサは、データ送信を中断するよう命令するのに用いられる指示情報を送信デバイスに送信してよく、送信デバイスは、サービスのビットブロックストリームをＰＣＳ上部分に入力するのを中断してよい。次に、バッファ内のビットブロックストリームのデータ量が事前設定閾値より少ないことをマルチプレクサが検出した場合、マルチプレクサは、データを送信するよう命令するのに用いられる指示情報を送信デバイスに送信してよく、送信デバイスは、サービスのビットブロックストリームをＰＣＳ上部分に入力してよい。
【０２７７】
段階１２０３：第１ｔｘ＿ｂｕｆ及び第２ｔｘ＿ｂｕｆの両方がターゲット条件を満たしているかどうかを検出し、第１ｔｘ＿ｂｕｆ及び第２ｔｘ＿ｂｕｆの両方がターゲット条件を満たしていない場合は段階１２０４を行う、又は第１ｔｘ＿ｂｕｆ及び第２ｔｘ＿ｂｕｆの両方がターゲット条件を満たしている場合には段階１２０５を行う。
【０２７８】
具体的には、マルチプレクサは、第１ｔｘ＿ｂｕｆ及び第２ｔｘ＿ｂｕｆの両方がターゲット条件を満たしているかどうかを検出するように構成され、本実施形態は、マルチプレクサの具体的な構造を参照して以下に詳細に説明される。
【０２７９】
図１３に示すように、バッファｔｘ＿ｂｕｆと通信接続している、マルチプレクサ内の調停モジュール１３０２が、第１ｔｘ＿ｂｕｆ及び第２ｔｘ＿ｂｕｆの両方がターゲット条件を満たしているかどうかを検出するように構成される。
【０２８０】
本実施形態では、ターゲット条件とは、第１ｔｘ＿ｂｕｆ及び第２ｔｘ＿ｂｕｆに送信対象データが存在するということであり、ターゲット条件はさらに、複数のサービスの、第１ｔｘ＿ｂｕｆ及び第２ｔｘ＿ｂｕｆにバッファリングされた、ビットブロックストリームのフロー制御の下でデータ送信が可能であるということである。ターゲット条件の具体的な説明については、前述の実施形態を参照されたい。詳細は、本実施形態において再度説明しない。
【０２８１】
段階１２０４：アイドルビットブロックを受信デバイスに送信する。
【０２８２】
具体的には、送信デバイスのマルチプレクサは、アイドルビットブロックを受信デバイスに送信するように構成される。
【０２８３】
本実施形態では、マルチプレクサ内の多重化モジュール１３０１が、第１ｔｘ＿ｂｕｆも第２ｔｘ＿ｂｕｆもターゲット条件を満たしていないと判定した場合、多重化モジュール１３０１は、アイドルビットブロックを受信デバイスに送信するように構成される。
【０２８４】
段階１２０５：ｅＭＡＣサービスの、第１ｔｘ＿ｂｕｆにバッファリングされている、ビットブロックストリームを受信デバイスに送信する。
【０２８５】
具体的には、多重化モジュール１３０１と通信接続している、マルチプレクサ内の調停モジュール１３０２は、ｔｘ＿ｂｕｆ内のビットブロックストリームに対して調停を行い、受信デバイスに送信されるｔｘ＿ｂｕｆ内の第１ビットブロックストリームを判定してよい。
【０２８６】
本実施形態では、ｅＭＡＣサービスの遅延感度がｐＭＡＣサービスの遅延感度より高いと調停モジュール１３０２が判定した場合、調停モジュール１３０２は、ｅＭＡＣサービスをバッファリングする第１ｔｘ＿ｂｕｆがｐＭＡＣサービスをバッファリングするバッファより高い優先順位を有すると判定してよく、調停モジュール１３０２は、第１ｔｘ＿ｂｕｆにバッファリングされたビットブロックストリームが受信デバイスに送信されると判定してよい。
【０２８７】
本実施形態は、受信デバイスに送信されるビットブロックストリームの優先順位がサービスの遅延感度に基づいて判定される一例を用いて説明される。
【０２８８】
段階１２０６：サービス切り替えを行うかどうかを判定し、サービス切り替えを行う場合は段階１２０７を行う。
【０２８９】
本実施形態では、マルチプレクサ内の多重化モジュール１３０１は、サービス切り替えを行うかどうかを判定するように構成される。具体的には、多重化モジュール１３０１は、ｅＭＡＣサービスをｐＭＡＣサービスに切り替えてサービス送信するかどうかを判定する。
【０２９０】
具体的には、調停モジュール１３０２は、バッファ内のビットブロックストリームに対して調停を行った場合、調停結果情報を生成してよく、調停モジュール１３０２は調停結果情報を多重化モジュール１３０１に送信してよく、多重化モジュール１３０１は、調停結果情報に基づいて、サービス切り替えを行うかどうかを判定してよい。
【０２９１】
調停結果情報の具体的な説明については、前述の実施形態を参照されたい。詳細は、本実施形態において再度説明しない。
【０２９２】
段階１２０７：ｅＭＡＣサービスのビットブロックストリームとｐＭＡＣのビットブロックストリームとの間にサービス切り替え指示ビットブロックを挿入する。
【０２９３】
多重化モジュール１３０１が、調停結果情報に基づいて、サービス切り替え指示ビットブロックを挿入する必要があると判定した場合、多重化モジュール１３０１と通信接続している挿入モジュール１３０３が、ｅＭＡＣサービスのビットブロックストリームとｐＭＡＣサービスのビットブロックストリームとの間にサービス切り替え指示ビットブロックを挿入してよい。
【０２９４】
本実施形態では、サービス切り替え指示ビットブロックはタグＴＡＧビットブロックであり、少なくとも１つのＴＡＧビットブロックが存在する。
【０２９５】
サービス切り替え指示ビットブロックは、以下に詳細に説明される。
【０２９６】
本実施形態では、イーサネット（登録商標）において、サービス切り替え指示ビットブロックは６４Ｂ／６６Ｂビットブロックである。Ｍ２−Ｍ１、すなわち、６６−６４は、各ビットブロック内のヘッダ同期ヘッダのビット数を表す。
【０２９７】
本実施形態は、１つのサービス切り替え指示ビットブロックが存在する一例を用いて説明される。６４Ｂ／６６Ｂビットブロックのコードワードの構造については、図２２を参照されたい。
【０２９８】
本実施形態では、サービス切り替え指示ビットブロックは、サービス切り替え指示ビットブロックがパラメータＯ０、Ｄ１、Ｄ２、Ｄ３、Ｃ４、Ｃ５、Ｃ６、及びＣ７を含む一例を用いて説明される。
【０２９９】
パラメータＤ１、Ｄ２、及びＤ３は８ビットのビットデータであり、パラメータＣ４、Ｃ５、Ｃ６、及びＣ７は７ビットのビットデータであり、パラメータＯ０は、パラメータＯ０を含むビットブロックのカテゴリを示すのに用いられる４ビットの制御コードである。本実施形態では、パラメータＯ０は、サービス切り替えが行われることを示すのにパラメータＯ０を含むビットブロックが用いられるというような定義を作成するのに用いられる。
【０３００】
具体的には、本実施形態では、送信デバイスはＯ０の値を０ｘ４に設定して、パラメータＯ０を含むビットブロックをサービス切り替え指示ビットブロックとして識別する。
【０３０１】
本実施形態では、Ｏ０の値を０ｘ４に設定することは任意選択の例であって、Ｏ０の値は代替的に、既存の規格に定義されていない別の値に設定されてもよい。
【０３０２】
サービス切り替え指示ビットブロックに含まれるパラメータＤ１、Ｄ２、及びＤ３は、３バイトのパラメータを搬送する。Ｄ１、Ｄ２、及びＤ３で搬送される３バイトのパラメータは、ターゲット識別子を伝達するのに用いられてよい。ターゲット識別子は、ｐＭＡＣサービスのビットブロックストリームに対応する識別子である。
【０３０３】
本実施形態では、ターゲット識別子がＤ１、Ｄ２、及びＤ３を用いて伝達されるという説明は、任意選択の例であって、限定されることはない。特定の応用において、ターゲット識別子は、パラメータＤ１、Ｄ２、Ｄ３、Ｃ４、Ｃ５、Ｃ６、及びＣ７のうちのいずれか１つを用いて伝達されてもよく、又はターゲット識別子は複数のサービス切り替え指示ビットブロックを用いて伝達されてもよい。
【０３０４】
ターゲット識別子の説明については、前述の実施形態を参照されたい。詳細は、本実施形態において再度説明しない。
【０３０５】
任意選択で、サービス切り替え指示ビットブロックはさらに指示情報を含み、指示情報は、ｐＭＡＣサービスの、受信デバイスに送信される、ビットブロックストリームに含まれるビットブロックの数を示すのに用いられる。
【０３０６】
本実施形態では、指示情報は、サービス切り替え指示ビットブロックストリームに含まれるパラメータＤ１、Ｄ２、Ｄ３、Ｃ４、Ｃ５、Ｃ６、及びＣ７のうちのいずれか１つを用いて伝達されてよく、又は指示情報は、複数のサービス切り替え指示ビットブロックを用いて伝達されてもよい。
【０３０７】
任意選択で、調停モジュール１３０２がｐＭＡＣサービスに対して調停を行う処理において、調停モジュール１３０２は、ｐＭＡＣサービスに含まれる全てのビットブロックが受信デバイスに送信されると判定してよく、挿入モジュール１３０３が挿入するサービス切り替え指示ビットブロックに含まれる指示情報は、ｐＭＡＣサービスの全てのビットブロックの数を示してよい。
【０３０８】
任意選択で、調停モジュール１３０２がｐＭＡＣサービスに対して調停を行う処理において、調停モジュール１３０２は、ｐＭＡＣサービスに含まれる全てのビットブロックが受信デバイスに送信されるのではなく、換言すれば、ｐＭＡＣサービスに含まれる一部のビットブロックが送信されると判定してよい。この場合、挿入モジュール１３０３が挿入するサービス切り替え指示ビットブロックに含まれる指示情報は、受信デバイスに送信する必要があるｐＭＡＣサービスのビットブロックの数を含んでよい。
【０３０９】
段階１２０８：サービス切り替え指示ビットブロックを受信デバイスに送信する。
【０３１０】
段階１２０９：ｐＭＡＣサービスのビットブロックストリームを受信デバイスに送信する。
【０３１１】
本実施形態では、送信デバイスは、サービス切り替え指示ビットブロックを送信した後に、ｐＭＡＣサービスのビットブロックストリームを送信してよい。
【０３１２】
送信デバイスは、ｅＭＡＣサービスのビットブロックストリームと、サービス切り替え指示ビットブロックと、ｐＭＡＣサービスのビットブロックストリームとを送信時間に基づいて時系列的に送信することが分かる。
【０３１３】
段階１２１０：どのバッファｔｘ＿ｂｕｆにも送信対象ビットブロックストリームがないことが検出された場合、アイドルビットブロックを受信デバイスに送信する。
【０３１４】
本実施形態では、ターゲット条件を満たす第１ｔｘ＿ｂｕｆ及び第２ｔｘ＿ｂｕｆの両方のビットブロックストリームが送信されたことをマルチプレクサが検出した場合、送信デバイスはアイドルビットブロックを受信デバイスに送信する。
【０３１５】
本実施形態のマルチプレクサに含まれる各モジュールの説明は任意選択の例であって、マルチプレクサが本実施形態のサービス多重化処理を行うことができるならば、限定されることはないことが明らかなはずである。
【０３１６】
本実施形態は、本実施形態がイーサネット（登録商標）パケットサービスに適用される一例を用いて説明される。本願におけるサービス多重化が代替的に、低速ネットワークに適用されてもよい。
【０３１７】
この応用方式では、複数のサービス切り替え指示ビットブロックが存在し、これらのサービス切り替え指示ビットブロックは８Ｂ／１０Ｂビットブロックである。
【０３１８】
任意選択で、本実施形態は、４つのサービス切り替え指示ビットブロックが存在する一例を用いて説明される。
【０３１９】
サービス切り替え指示ビットブロックの構造については、表１を参照されたい。
【表１】
2020530959.tif 000003
【０３２０】
８Ｂ／１０Ｂ符号化では、サービス切り替え指示ビットブロックの構造は、Ｋ２８．５／Ｄ１８．６／ＤＸ，Ｙ／ＤＸ，Ｙであってもよく、ビットブロックの構造は、Ｋ２８．５／Ｄ１．２／ＤＸ，Ｙ／ＤＸ，Ｙであってもよい。
【０３２１】
例えば、６４Ｂ／６６Ｂ符号化では、サービス切り替えが１つのビットブロックを用いて示されてよく、８Ｂ／１０Ｂ符号化では、サービス切り替えのために複数のビットブロックを一緒に結合する必要がある。
【０３２２】
具体的には、本実施形態では、例えば、サービス切り替え指示ビットブロックの構造は、Ｋ２８．５／Ｄ１８．６／ＤＸ，Ｙ／ＤＸ，Ｙである。ビットブロックＫ２８．５は特殊ビットブロックであり、特殊ビットブロックに続くビットブロック（Ｄｘ，ｙ）はデータビットブロックである。８Ｂ／１０Ｂ符号化では、特殊ビットブロック及びデータビットブロックは、サービス切り替えを示すのに一緒に用いられる。
【０３２３】
受信デバイスがサービス多重分離を行う具体的な処理が、例として、図１１及び図１４を参照して以下に説明される。
【０３２４】
図１１に示すように、本実施形態では、例えば、送信デバイスにより送信され且つ受信デバイスにより受信される全てのサービスが、イーサネット（登録商標）パケットサービスである。
【０３２５】
イーサネット（登録商標）パケットサービスは具体的には、遅延に敏感なパケットサービス（ｅｘｐｒｅｓｓ  ｍｅｄｉａ  ａｃｃｅｓｓ  ｃｏｎｔｒｏｌ、ｅＭＡＣ）、及び優先順位が低いパケットサービス（ｐｒｅｅｍｐｔａｂｌｅ  ｍｅｄｉａ  ａｃｃｅｓｓ  ｃｏｎｔｒｏｌ、ｐＭＡＣ）である。
【０３２６】
ｅＭＡＣサービスの遅延感度は、ｐＭＡＣサービスの遅延感度より高い。
【０３２７】
段階１４０１：送信デバイスにより送信されるビットブロックストリームを受信する。
【０３２８】
図１１に示すように、受信デバイスのＰＣＳ下部分（ｔｈｅ  ６４Ｂ／６６Ｂ  ｅｎｃｏｄｅｒ  ａｎｄ  ｄｅｃｏｄｅｒ  ｐａｒｔ  ｏｆ  ａ  ＰＣＳ，ＰＣＳ  ｌｏｗ−ｐａｒｔ）が、送信デバイスにより送信されるビットブロックストリームを受信するように構成される。
【０３２９】
受信デバイスのＰＣＳ下部分は、図７に示すＰＣＳ内のデスクランブルモジュール７２３及び処理モジュール７２４である。
【０３３０】
本実施形態では、ビットブロックストリームがアイドルビットブロックを含むことを受信デバイスが検出した場合、受信デバイスはアイドルビットブロックを直接的に削除してよい。
【０３３１】
具体的には、図１５に示すように、受信デバイスのデマルチプレクサに含まれる検出モジュール１５０１が、アイドルビットブロックを検出するように構成され、検出モジュール１５０１がアイドルビットブロックを検出した場合、検出モジュール１５０１はアイドルビットブロックを直接的に削除してよい。
【０３３２】
段階１４０２：少なくとも１つのサービス切り替え指示ビットブロックがビットブロックストリームに存在するかどうかを検出し、少なくとも１つのサービス切り替え指示ビットブロックがビットブロックストリームに存在する場合は段階１４０３を行う。
【０３３３】
本実施形態では、デマルチプレクサにより受信されるビットブロックストリーム内の各ビットブロックがサービス切り替え指示ビットブロックであるかどうかが検出される。デマルチプレクサが１つのサービス切り替え指示ビットブロック又は複数の連続したサービス切り替え指示ビットブロックを受信した場合、段階１４０５が行われる。
【０３３４】
デマルチプレクサの具体的な説明については、前述の実施形態を参照されたい。詳細は、再度説明しない。
【０３３５】
サービス切り替え指示ビットブロックは、６４Ｂ／６６Ｂビットブロックである。６４Ｂ／６６Ｂビットブロックの具体的な説明については、前述の説明を参照されたい。詳細は、再度説明しない。
【０３３６】
段階１４０３：サービス切り替え指示ビットブロックが受信された後に受信されるビットブロックストリームが、ｐＭＡＣサービスのビットブロックストリームであると判定する。
【０３３７】
本実施形態では、サービス切り替え指示ビットブロックは、サービス切り替えを示すのに用いられ、サービス切り替え指示ビットブロックに含まれるターゲット識別子が、サービスをｐＭＡＣサービスに切り替えることを示すのに用いられる。
【０３３８】
段階１４０４：ｐＭＡＣサービスのビットブロックストリームを、対応するバッファに入力する。
【０３３９】
本実施形態では、検出モジュール１５０１がサービス切り替え指示ビットブロックを検出した後に、検出モジュール１５０１と通信接続している抽出モジュール１５０３が、サービス切り替え指示ビットブロックに含まれるターゲット識別子を抽出してよい。
【０３４０】
ターゲット識別子の具体的な説明については、前述の説明を参照されたい。詳細は、本実施形態において再度説明しない。
【０３４１】
抽出モジュール１５０３と通信接続している多重分離モジュール１５０２が、ターゲット識別子に基づいて、対応するバッファを判定する。
【０３４２】
本実施形態は、受信デバイスがサービス切り替え指示ビットブロックを受信する前に受信デバイスにより受信されるビットブロックストリームがｅＭＡＣサービスのビットブロックストリームであり、受信デバイスがサービス切り替え指示ビットブロックを受信した後に受信デバイスにより受信されるビットブロックストリームがｐＭＡＣサービスのビットブロックストリームである一例を用いて説明される。ｅＭＡＣサービス及びｐＭＡＣサービスの具体的な説明については、前述の説明を参照されたい。詳細は、再度説明しない。
【０３４３】
受信デバイスがサービス切り替え指示ビットブロックを受信する前に、多重分離モジュール１５０２は、ｅＭＡＣサービス用に予め設定された第１ｔｘ＿ｂｕｆにｅＭＡＣサービスのビットブロックストリームを保存する。ターゲット識別子を判定した後に、多重分離モジュール１５０２は、ターゲット識別子に対応するターゲットバッファが第２ｔｘ＿ｂｕｆであると判定してよく、また次に受信されるｐＭＡＣサービスのビットブロックストリームを第２ｔｘ＿ｂｕｆに入力してよい。
【０３４４】
段階１４０５：各バッファが出力条件を満たしているかどうかを判定し、各バッファが出力条件を満たしている場合に段階１４０６を行う。
【０３４５】
デマルチプレクサ内の出力制御モジュール１５０４が、各バッファが出力条件を満たしているかどうかを検出するように構成されてよい。出力条件は、各バッファが完全なイーサネット（登録商標）媒体アクセス制御（ｍｅｄｉａ  ａｃｃｅｓｓ  ｃｏｎｔｒｏｌ、ＭＡＣ）フレームを格納しているかどうかということである。
【０３４６】
具体的には、イーサネット（登録商標）では、受信デバイスに出力されるＭＡＣ層データが、完全なＭＡＣフレームに基づいている。
【０３４７】
バッファに格納されたビットブロックストリームが完全なＭＡＣフレームではないと制御モジュール１５０４が判定した場合、制御モジュール１５０４は、ビットブロックストリームをバッファリングし、完全なＭＡＣフレームがフレーム接合によって取得されるまで、バッファを用いてビットブロックストリームに対してフレーム接合を行ってよい。
【０３４８】
段階１４０６：完全なＭＡＣフレームをＭＡＣ層に出力する。
【０３４９】
具体的には、バッファに格納されたビットブロックストリームが完全なＭＡＣフレームであると制御モジュール１５０４が判定した場合、制御モジュール１５０４は、完全なＭＡＣフレームを格納するバッファを制御して、完全なＭＡＣフレームをＭＡＣ層に出力してよい。
【０３５０】
本実施形態のデマルチプレクサに含まれる各モジュールの説明は任意選択の例であって、デマルチプレクサが本実施形態のサービス多重分離処理を行うことができるならば、限定されることはないことが明らかなはずである。
【０３５１】
前述の実施形態は、イーサネット（登録商標）パケットサービスを一例として用いて説明されており、送信デバイスが非イーサネットパケットサービス及びイーサネット（登録商標）パケットサービスに対してどのようにサービス多重化を行うかについての具体的な処理が以下の実施形態において詳細に説明される。
【０３５２】
図１６に示すように、イーサネット（登録商標）パケットサービスはｐＭＡＣサービスである。ｐＭＡＣサービスの具体的な説明については、前述の説明を参照されたい。詳細は、再度説明しない。
【０３５３】
例えば、非イーサネットパケットサービスは、ストリーミングサービスである。ストリーミングサービスは、固定ビットレート（ｃｏｎｓｔａｎｔ  ｂｉｔ  ｒａｔｅ、ＣＢＲ）サービス、又は可変ビットレート（ｖａｒｉａｂｌｅ  ｂｉｔ  ｒａｔｅ、ＶＢＲ）サービスである。
【０３５４】
本実施形態は、ストリーミングサービスがＶＢＲサービスである一例を用いて説明される。
【０３５５】
本実施形態におけるサービス多重化処理が、図１７に示す各段階のフローチャートを参照して以下に詳細に説明される。
【０３５６】
段階１７０１：ＰＣＳ上部分により出力される、ｐＭＡＣの６４Ｂ／６６Ｂビットブロックストリームを、第１ｔｘ＿ｂｕｆがバッファリングする。
【０３５７】
ＰＣＳ上部分の具体的な説明については、前述の説明を参照されたい。詳細は、再度説明しない。
【０３５８】
本実施形態では、送信デバイスの第１ｔｘ＿ｂｕｆは、ｐＭＡＣサービスをバッファリングするように構成される。ｐＭＡＣサービスを受信した後に、送信デバイスは、ｅＭＡＣサービスをｐＭＡＣサービスに対応する第１ｔｘ＿ｂｕｆにバッファリングしてよい。
【０３５９】
段階１７０２：ＶＢＲサービスを符号化する。
【０３６０】
本実施形態では、ストリーミングサービスがＰＣＳ層関連のロジックを含まないため、受信デバイスの符号化モジュールがＶＢＲサービスに対して６４Ｂ／６６Ｂ符号化を行い、ビットブロックストリームを生成する必要がある。
【０３６１】
符号化モジュールの具体的な説明については、前述の説明を参照されたい。詳細は、再度説明しない。
【０３６２】
段階１７０３：符号化モジュールにより出力される６４Ｂ／６６Ｂビットブロックストリームを、第２ｔｘ＿ｂｕｆがバッファリングする。
【０３６３】
本実施形態では、帯域幅利用率を向上させるために、第１ｔｘ＿ｂｕｆ及び第２ｔｘ＿ｂｕｆにアイドルビットブロックが存在するかどうかをマルチプレクサが検出してよく、アイドルビットブロックが存在する場合、マルチプレクサはＩＰＧ内のアイドルビットブロックを削除してよい。
【０３６４】
マルチプレクサの具体的な説明については、前述の実施形態を参照されたい。詳細は、本実施形態において再度説明しない。
【０３６５】
マルチプレクサは、バッファ内のビットブロックストリームに対してフロー制御を行ってよい。具体的な処理については、前述の説明を参照されたい。詳細は、再度説明しない。
【０３６６】
段階１７０４：第１ｔｘ＿ｂｕｆ及び第２ｔｘ＿ｂｕｆの両方がターゲット条件を満たしているかどうかを検出し、第１ｔｘ＿ｂｕｆ及び第２ｔｘ＿ｂｕｆの両方がターゲット条件を満たしていない場合は段階１７０５を行う、又は第１ｔｘ＿ｂｕｆ及び第２ｔｘ＿ｂｕｆの両方がターゲット条件を満たしている場合には段階１７０６を行う。
【０３６７】
具体的には、マルチプレクサは、第１ｔｘ＿ｂｕｆ及び第２ｔｘ＿ｂｕｆの両方がターゲット条件を満たしているかどうかを検出するように構成される。マルチプレクサの具体的な構造については、図１８を参照されたい。図１８に示すマルチプレクサに含まれる多重化モジュール１８０１、調停モジュール１８０２、及び挿入モジュール１８０３の具体的な説明については、図１３に示すマルチプレクサに含まれる多重化モジュール１３０１、調停モジュール１３０２、及び挿入モジュール１３０３の説明を参照されたい。詳細は、再度説明しない。
【０３６８】
より具体的には、本実施形態では、調停モジュール１８０２は、第１ｔｘ＿ｂｕｆ及び第２ｔｘ＿ｂｕｆの両方がターゲット条件を満たしているかどうかを検出するように構成される。ターゲット条件の具体的な説明については、前述の説明を参照されたい。詳細は、再度説明しない。
【０３６９】
段階１７０５：アイドルビットブロックを受信デバイスに送信する。
【０３７０】
具体的には、多重化モジュール１８０１が第１ｔｘ＿ｂｕｆも第２ｔｘ＿ｂｕｆもターゲット条件を満たしていないと判定した場合、多重化モジュール１８０１は、アイドルビットブロックを受信デバイスに送信するように構成される。
【０３７１】
段階１７０６：ｐＭＡＣサービスの、第１ｔｘ＿ｂｕｆにバッファリングされている、ビットブロックストリームを受信デバイスに送信する。
【０３７２】
具体的には、調停モジュール１８０２は、ｔｘ＿ｂｕｆ内のビットブロックストリームに対して調停を行い、受信デバイスのｔｘ＿ｂｕｆに送信されるｔｘ＿ｂｕｆ内の第１ビットブロックストリームを判定してよい。
【０３７３】
本実施形態では、ｐＭＡＣサービスをバッファリングする第１ｔｘ＿ｂｕｆがＶＢＲサービスをバッファリングするバッファより高い優先順位を有すると調停モジュール１８０２が判定した場合、調停モジュール１８０２は、第１ｔｘ＿ｂｕｆにバッファリングされたビットブロックストリームを受信デバイスに送信してよい。
【０３７４】
段階１７０７：サービス切り替えを行うかどうかを判定し、サービス切り替えを行う場合には段階１７０８を行う。
【０３７５】
本実施形態では、多重化モジュール１８０１は、サービス切り替えを行うかどうかを判定するように構成される。具体的には、多重化モジュール１８０１は、ｐＭＡＣサービスとＶＢＲサービスとの切り替えを行うかどうかを判定するように構成される。
【０３７６】
具体的には、調停モジュール１８０２は、バッファ内のビットブロックストリームに対して調停を行った場合、調停結果情報を生成してよく、調停モジュール１８０２は調停結果情報を多重化モジュール１８０１に送信してよく、多重化モジュール１８０１は、調停結果情報に基づいて、サービス切り替えを行うかどうかを判定してよい。
【０３７７】
調停結果情報の具体的な説明については、前述の実施形態を参照されたい。詳細は、本実施形態において再度説明しない。
【０３７８】
段階１７０８：ｐＭＡＣサービスのビットブロックストリームとＶＢＲサービスのビットブロックストリームとの間にサービス切り替え指示ビットブロックを挿入する。
【０３７９】
多重化モジュール１８０１が、サービス切り替え指示ビットブロックＴＡＧを挿入する要求があると判定した場合、挿入モジュール１８０３は、ｐＭＡＣサービスのビットブロックストリームとＶＢＲサービスのビットブロックストリームとの間にサービス切り替え指示ビットブロックを挿入してよい。
【０３８０】
本実施形態におけるサービス切り替え指示ビットブロックの具体的な説明については、前述の実施形態を参照されたい。詳細は、本実施形態において再度説明しない。
【０３８１】
段階１７０９：サービス切り替え指示ビットブロックとＶＢＲサービスのビットブロックストリームとを受信デバイスに連続的に送信する。
【０３８２】
ｐＭＡＣサービスのビットブロックストリームとＶＢＲサービスのビットブロックストリームとの間にサービス切り替え指示ビットブロックが挿入された後に、送信デバイスは、サービス切り替え指示ビットブロックとＶＢＲサービスのビットブロックストリームとを受信デバイスに連続的に送信してよい。
【０３８３】
本実施形態のマルチプレクサに含まれる各モジュールの説明は任意選択の例であって、マルチプレクサが本実施形態のサービス多重化処理を行うことができるならば、限定されることはないことが明らかなはずである。
【０３８４】
図１６〜図１８に示すように、非イーサネットパケットサービス及びイーサネット（登録商標）パケットサービスに対してサービス多重化を行う具体的な処理は、送信デバイスの観点から説明される。非イーサネットパケットサービス及びイーサネット（登録商標）パケットサービスを多重分離する具体的な処理が、受信デバイスの観点から以下に詳細に説明される。
【０３８５】
図１６をさらに参照すると、本実施形態は、イーサネット（登録商標）パケットサービスがｐＭＡＣサービスであり、非イーサネットパケットサービスがＶＢＲサービスである一例を用いて説明される。
【０３８６】
本実施形態におけるサービス多重分離処理が、図１９に示す各段階のフローチャートを参照して以下に詳細に説明される。
【０３８７】
段階１９０１：送信デバイスにより送信されるビットブロックストリームを受信する。
【０３８８】
図１６に示すように、受信デバイスのＰＣＳ下部分が、送信デバイスにより送信されるビットブロックを受信する。
【０３８９】
本実施形態では、ビットブロックストリームがアイドルビットブロックを含むことを受信デバイスが検出した場合、受信デバイスはアイドルビットブロックを直接的に削除してよい。
【０３９０】
具体的には、図２０に示すように、受信デバイスのデマルチプレクサに含まれる検出モジュール２００１が、アイドルビットブロックを検出するように構成され、検出モジュール２００１がアイドルビットブロックを検出した場合、検出モジュール２００１はアイドルビットブロックを直接的に削除してよい。
【０３９１】
段階１９０２：サービス切り替え指示ビットブロックがビットブロックストリームに存在するかどうかを検出し、サービス切り替え指示ビットブロックがビットブロックストリームに存在した場合、段階１９０３を行う。
【０３９２】
本実施形態では、デマルチプレクサは、ビットブロックがサービス切り替え指示ビットブロックであるかどうかを検出するように構成される。デマルチプレクサの具体的な説明については、前述の実施形態を参照されたい。詳細は、再度説明しない。
【０３９３】
サービス切り替え指示ビットブロックは、６４Ｂ／６６Ｂビットブロックである。６４Ｂ／６６Ｂビットブロックの具体的な説明については、前述の説明を参照されたい。詳細は、再度説明しない。
【０３９４】
段階１９０３：サービス切り替え指示ビットブロックが受信された後に受信されるビットブロックストリームが、ＶＢＲサービスのビットブロックストリームであると判定する。
【０３９５】
本実施形態では、サービス切り替え指示ビットブロックは、サービス切り替えを示すのに用いられ、サービス切り替え指示ビットブロックに含まれるターゲット識別子が、サービスをＶＢＲサービスに切り替えることを示すのに用いられる。
【０３９６】
段階１９０４：ＶＢＲサービスのビットブロックストリームを対応するバッファに入力する。
【０３９７】
本実施形態では、検出モジュール２００１がサービス切り替え指示ビットブロックを検出した後に、検出モジュール２００１と通信接続している抽出モジュール２００３が、サービス切り替え指示ビットブロックに含まれるターゲット識別子を抽出してよい。
【０３９８】
ターゲット識別子の具体的な説明については、前述の説明を参照されたい。詳細は、本実施形態において再度説明しない。
【０３９９】
抽出モジュール２００３と通信接続している多重分離モジュール２００２が、ターゲット識別子に基づいて、対応するバッファを判定する。
【０４００】
本実施形態は、受信デバイスがサービス切り替え指示ビットブロックを受信する前に受信デバイスにより受信されるビットブロックストリームがｐＭＡＣサービスのビットブロックストリームであり、受信デバイスがサービス切り替え指示ビットブロックを受信した後に受信デバイスにより受信されるビットブロックストリームがＶＢＲサービスのビットブロックストリームである一例を用いて説明される。ＶＢＲサービス及びｐＭＡＣサービスの具体的な説明については、前述の説明を参照されたい。詳細は、再度説明しない。
【０４０１】
受信デバイスがサービス切り替え指示ビットブロックを受信する前に、多重分離モジュール２００２は、ｐＭＡＣサービス用に予め設定された第１ｔｘ＿ｂｕｆにｐＭＡＣサービスのビットブロックストリームを保存する。ターゲット識別子を判定した後に、多重分離モジュール２００２は、ターゲット識別子に対応するターゲットバッファが第２ｔｘ＿ｂｕｆであると判定してよく、また次に受信されるＶＢＲサービスのビットブロックストリームを第２ｔｘ＿ｂｕｆに入力してよい。
【０４０２】
段階１９０５：ＶＢＲサービスのビットブロックストリームを復号モジュールに入力する。
【０４０３】
本実施形態では、ストリーミングサービスＶＢＲの場合、出力制御モジュール２００４がフレーム接合を行う必要がなく、受信デバイスは、ＶＢＲサービスのビットブロックストリームを復号のために復号モジュールに直接的に入力してよい。
【０４０４】
復号モジュールの具体的な説明については、前述の説明を参照されたい。詳細は、本実施形態において再度説明しない。
【０４０５】
復号モジュールは、ＶＢＲサービスのビットブロックストリームを復号し、ＶＢＲサービスデータを出力するように構成される。
【０４０６】
段階１９０６：ＶＢＲサービスデータを出力する。
【０４０７】
本実施形態では、復号モジュールは、復号されたＶＢＲサービスデータを出力してよい。
【０４０８】
本実施形態では、例えば、受信デバイスは、復号モジュールにより出力されるＶＢＲサービスデータを共通公衆無線インタフェース（ｃｏｍｍｏｎ  ｐｕｂｌｉｃ  ｒａｄｉｏ  ｉｎｔｅｒｆａｃｅ、ＣＰＲＩ）に出力してよい。
【０４０９】
本願におけるサービス多重化方法及びサービス多重分離方法が適用されるネットワークの説明は、任意選択の例であって、限定されることはない。例えば、本願におけるサービス多重化方法及びサービス多重分離方法は、フレキシブルイーサネット（ｆｌｅｘ  Ｅｔｈｅｒｎｅｔ（登録商標）、ＦｌｅｘＥ）にも適用されてよい。
【０４１０】
図２１に示すように、ネットワークデバイスは、サービスｆｌｅｘＥ  ｃｌｉｅｎｔ  ａ１からサービスｆｌｅｘＥ  ｃｌｉｅｎｔ  ａｎに対してサービス多重化を実施することができる。
【０４１１】
具体的には、マルチプレクサは、サービスｆｌｅｘＥ  ｃｌｉｅｎｔ  ａ１からサービスｆｌｅｘＥ  ｃｌｉｅｎｔ  ａｎに対して、レベル１のサービス多重化を行う。具体的な多重化処理については、前述の実施形態を参照されたい。詳細は、再度説明しない。
【０４１２】
サービスｆｌｅｘＥ  ｃｌｉｅｎｔ  ａ１からサービスｆｌｅｘＥ  ｃｌｉｅｎｔ  ａｎの、マルチプレクサがサービスｆｌｅｘＥ  ｃｌｉｅｎｔ  ａ１からサービスｆｌｅｘＥ  ｃｌｉｅｎｔ  ａｎを処理した後にマルチプレクサにより出力される、ビットブロックストリームが、ｆｌｅｘＥカレンダモジュールｃａｌｅｎｄａｒに入力され、ｆｌｅｘＥ  ｃａｌｅｎｄａｒは、サービスｆｌｅｘＥ  ｃｌｉｅｎｔ  ａ１からサービスｆｌｅｘＥ  ｃｌｉｅｎｔ  ａｎのビットブロックストリームに対して、ｆｌｅｘＥ規格の方法を用いてレベル２の多重化を行うように構成される。
【０４１３】
本実施形態では、サービスｆｌｅｘＥ  ｃｌｉｅｎｔ  ｂが、ｆｌｅｘＥ多重化に基づくサービスである。アイドルビットブロック挿入／削除モジュールがサービスｆｌｅｘＥ  ｃｌｉｅｎｔ  ｂのビットブロックストリームに対してアイドルビットブロック挿入／削除を行った後に、ビットブロックストリームはｆｌｅｘＥ  ｃａｌｅｎｄａｒに入力される。
【０４１４】
アイドル挿入／削除モジュールは、サービスｆｌｅｘＥ  ｃｌｉｅｎｔ  ｂのビットブロックストリームに対してレートアダプテーションを行うように構成される。
【０４１５】
ｆｌｅｘＥ  ｃａｌｅｎｄａｒは、サービスｆｌｅｘＥ  ｃｌｉｅｎｔ  ｂのビットブロックストリームに対して、ｆｌｅｘＥ規格の方法を用いてタイムスロットマッピングを行い、サービス送信を行うように構成される。
【０４１６】
図２１に示すように、ネットワークデバイスが多重分離を実施する処理が、以下のとおりであってよい。
【０４１７】
ビットブロックストリームを受信した後に、ｆｌｅｘＥ  ｃａｌｅｎｄａｒは、ビットブロックストリームを多重分離して、サービスｆｌｅｘＥ  ｃｌｉｅｎｔ  ａ１からサービスｆｌｅｘＥ  ｃｌｉｅｎｔ  ａｎのビットブロックストリームとｆｌｅｘＥ  ｃｌｉｅｎｔ  ｂのビットブロックストリームとを取得する。
【０４１８】
ｆｌｅｘＥ  ｃａｌｅｎｄａｒはサービスｆｌｅｘＥ  ｃｌｉｅｎｔ  ａ１からサービスｆｌｅｘＥ  ｃｌｉｅｎｔ  ａｎのビットブロックストリームを多重分離のためにデマルチプレクサに入力して、サービスｆｌｅｘＥ  ｃｌｉｅｎｔ  ａ１からサービスｆｌｅｘＥ  ｃｌｉｅｎｔ  ａｎのビットブロックストリームを別々に取得し、これらのビットブロックストリームをサービスｆｌｅｘＥ  ｃｌｉｅｎｔ  ａ１からサービスｆｌｅｘＥ  ｃｌｉｅｎｔ  ａｎに対応するバッファに入力する。具体的な多重分離処理については、前述の実施形態を参照されたい。詳細は、本実施形態において再度説明しない。
【０４１９】
ｆｌｅｘＥ  ｃａｌｅｎｄａｒはｆｌｅｘＥ  ｃｌｉｅｎｔ  ｂの多重分離されたビットブロックストリームをアイドル挿入／削除モジュールに入力し、アイドル挿入／削除モジュールは、ｆｌｅｘＥ  ｃｌｉｅｎｔ  ｂのビットブロックストリームに対してレートアダプテーションを行うように構成される。
【０４２０】
本願において提供される送信デバイスの具体的構造が、例として図２３を参照して以下に説明される。本実施形態の送信デバイスは、本願のサービス多重化方法を実行するように構成される。サービス多重化方法を実行する具体的な処理については、前述の実施形態を参照されたい。詳細は、本実施形態において再度説明しない。
【０４２１】
本実施形態における送信デバイスは、第１サービスのビットブロックストリームを受信デバイスに送信するように構成された送信機２３０１と、第１サービスから第２サービスに切り替えてサービス送信するかどうかを判定するように構成されたマルチプレクサ２３０２とを含む。
【０４２２】
送信機２３０１はさらに、マルチプレクサが第１サービスから第２サービスに切り替えてサービス送信すると判定した場合、少なくとも１つのサービス切り替え指示ビットブロックを受信デバイスに送信するように構成され、少なくとも１つのサービス切り替え指示ビットブロックは、第１サービスを第２サービスに切り替えてサービス送信することを示すのに用いられる。
【０４２３】
送信機２３０１はさらに、第２サービスのビットブロックストリームを受信デバイスに送信するように構成される。
【０４２４】
本実施形態では、送信機２３０１及びマルチプレクサ２３０２は、前述の実施形態の送信インタフェースに配置される。特に、マルチプレクサ２３０２の具体的な説明については、前述の実施形態を参照されたい。
【０４２５】
本願において提供されるサービス多重化を本実施形態の送信デバイスが行う処理の有益な効果については、前述の実施形態を参照されたい。詳細は、本実施形態において再度説明しない。
【０４２６】
任意選択で、本実施形態では、第１サービスのビットブロックストリームに含まれる任意のビットブロックと、第２サービスのビットブロックストリームに含まれる任意のビットブロックと、少なくとも１つのサービス切り替え指示ビットブロックのうちのいずれか１つとが、Ｍ１／Ｍ２ビットブロックである。ここで、Ｍ１は各ビットブロック内のペイロードビットの数を表し、Ｍ２は各ビットブロック内のビットの合計数を表し、Ｍ１及びＭ２は正の整数であり、Ｍ２＞Ｍ１である。
【０４２７】
第１サービスのビットブロックストリームに含まれる任意のビットブロックと、第２サービスのビットブロックストリームに含まれる任意のビットブロックと、少なくとも１つのサービス切り替え指示ビットブロックのうちのいずれか１つとに関する具体的な説明については、前述の実施形態を参照されたい。詳細は、本実施形態において再度説明しない。
【０４２８】
任意選択で、送信機２３０１は具体的には、第１サービスの第１サービスデータを取得し、第１サービスデータを符号化して第１サービスのビットブロックストリームを生成し、第２サービスの第２サービスデータを取得し、第２サービスデータを符号化して第２サービスのビットブロックストリームを生成するように構成される。
【０４２９】
任意選択で、Ｍ１／Ｍ２ビットブロックが６４Ｂ／６６Ｂビットブロックである場合、少なくとも１つのサービス切り替え指示ビットブロックが存在する。
【０４３０】
本実施形態における６４Ｂ／６６Ｂビットブロックの具体的な説明については、前述の実施形態を参照されたい。詳細は、本実施形態において再度説明しない。
【０４３１】
任意選択で、Ｍ１／Ｍ２ビットブロックが８Ｂ／１０Ｂビットブロックである場合、複数のサービス切り替え指示ビットブロックが存在し、複数のサービス切り替え指示ビットブロックは少なくとも１つの特殊ビットブロックと少なくとも１つのデータビットブロックとを含む。
【０４３２】
本実施形態における８Ｂ／１０Ｂビットブロックの具体的な説明については、前述の実施形態を参照されたい。詳細は、本実施形態において再度説明しない。
【０４３３】
任意選択で、少なくとも１つのサービス切り替え指示ビットブロックはさらに指示情報を含み、指示情報は、第２サービスの、受信デバイスに送信される、ビットブロックストリームに含まれるビットブロックの数を示すのに用いられる。
【０４３４】
本実施形態における指示情報の具体的な説明については、前述の実施形態を参照されたい。詳細は、本実施形態において再度説明しない。
【０４３５】
任意選択で、マルチプレクサ２３０２はさらに、ターゲット識別子を判定することであって、ターゲット識別子は第２サービスに対応する識別子である、判定することと、少なくとも１つのサービス切り替え指示ビットブロックを生成することであって、少なくとも１つのサービス切り替え指示ビットブロックはターゲット識別子を含み、ターゲット識別子は、第２サービスのビットブロックストリームをターゲットバッファに保存するよう受信デバイスに命令するのに用いられ、ターゲットバッファは、受信デバイスによりターゲット識別子に割り当てられるバッファである、生成することとを行うように構成される。
【０４３６】
本実施形態におけるターゲット識別子の具体的な説明については、前述の実施形態を参照されたい。詳細は、本実施形態において再度説明しない。
【０４３７】
任意選択で、マルチプレクサ２３０２はさらに、第１サービスのビットブロックストリーム及び／又は第２サービスのビットブロックストリームにアイドルビットブロックが存在すると判定された場合、アイドルビットブロックを削除するように構成される。
【０４３８】
アイドルビットブロック削除処理については、前述の実施形態を参照されたい。詳細は、本実施形態において説明しない。
【０４３９】
本願において提供される受信デバイスの具体的構造が、例として図２４を参照して以下に説明される。本実施形態の受信デバイスは、本願におけるサービス多重分離方法を実行するように構成される。サービス多重分離方法を実行する具体的な処理については、前述の実施形態を参照されたい。詳細は、本実施形態において再度説明しない。
【０４４０】
本実施形態の受信デバイスは、送信デバイスにより送信される少なくとも１つのサービス切り替え指示ビットブロックが受信されたかどうかを判定するように構成された受信機２４０１であって、少なくとも１つのサービス切り替え指示ビットブロックは、送信デバイスが第１サービスから第２サービスに切り替えてサービス送信することを示すのに用いられ、第１サービスのビットブロックストリームが、少なくとも１つのサービス切り替え指示ビットブロックが受信される前に受信されるビットブロックストリームである、受信機２４０１と、少なくとも１つのサービス切り替え指示ビットブロックが受信されたと判定された場合、少なくとも１つのサービス切り替え指示ビットブロックが受信された後に受信されるビットブロックストリームが第２サービスのビットブロックストリームであると判定するように構成されたデマルチプレクサ２４０２とを含む。
【０４４１】
本願において提供されるサービス多重分離を本実施形態の受信デバイスが行う処理の有益な効果については、前述の実施形態を参照されたい。詳細は、本実施形態において再度説明しない。
【０４４２】
本実施形態では、受信機２４０１及びデマルチプレクサ２４０２は、前述の実施形態の受信インタフェースに配置される。特に、デマルチプレクサ２４０２の具体的な説明については、前述の実施形態を参照されたい。
【０４４３】
任意選択で、第１サービスのビットブロックストリームに含まれる任意のビットブロックと、第２サービスのビットブロックストリームに含まれる任意のビットブロックと、少なくとも１つのサービス切り替え指示ビットブロックのうちのいずれか１つとが、Ｍ１／Ｍ２ビットブロックである。ここで、Ｍ１は各ビットブロック内のペイロードビットの数を表し、Ｍ２は各ビットブロック内のビットの合計数を表し、Ｍ１及びＭ２は正の整数であり、Ｍ２＞Ｍ１である。
【０４４４】
本実施形態における、第１サービスのビットブロックストリームに含まれる任意のビットブロックと、第２サービスのビットブロックストリームに含まれる任意のビットブロックと、少なくとも１つのサービス切り替え指示ビットブロックのうちのいずれか１つとに関する具体的な説明については、前述の実施形態を参照されたい。詳細は、本実施形態において再度説明しない。
【０４４５】
任意選択で、受信機２４０１はさらに、第１サービスの、送信デバイスにより送信される、ビットブロックストリームを受信するように構成される。
【０４４６】
デマルチプレクサ２４０２はさらに、第１サービスのビットブロックストリームを復号して、第１サービスの第１サービスデータを取得するように構成される。
【０４４７】
受信機２４０１はさらに、第２サービスの、送信デバイスにより送信される、ビットブロックストリームを受信するように構成される。
【０４４８】
デマルチプレクサ２４０２はさらに、第２サービスのビットブロックストリームを復号して、第２サービスの第１サービスデータを取得するように構成される。
【０４４９】
任意選択で、Ｍ１／Ｍ２ビットブロックが６４Ｂ／６６Ｂビットブロックである場合、少なくとも１つのサービス切り替え指示ビットブロックが存在する。
【０４５０】
本実施形態における６４Ｂ／６６Ｂビットブロックの具体的な説明については、前述の実施形態を参照されたい。詳細は、本実施形態において再度説明しない。
【０４５１】
任意選択で、Ｍ１／Ｍ２ビットブロックが８Ｂ／１０Ｂビットブロックである場合、複数のサービス切り替え指示ビットブロックが存在し、複数のサービス切り替え指示ビットブロックは少なくとも１つの特殊ビットブロックと少なくとも１つのデータビットブロックとを含む。
【０４５２】
本実施形態における８Ｂ／１０Ｂビットブロックの具体的な説明については、前述の実施形態を参照されたい。詳細は、本実施形態において再度説明しない。
【０４５３】
任意選択で、デマルチプレクサ２４０２はさらに、少なくとも１つのサービス切り替え指示ビットブロックに含まれる指示情報を取得することであって、指示情報は、第２サービスのビットブロックストリームに含まれるビットブロックの数を示すのに用いられる、取得することと、指示情報に従って、第２サービスのビットブロックストリームに含まれるビットブロックの数を判定することとを行うように構成される。
【０４５４】
本実施形態における指示情報ビットブロックの具体的な説明については、前述の実施形態を参照されたい。詳細は、本実施形態において再度説明しない。
【０４５５】
任意選択で、デマルチプレクサ２４０２はさらに、少なくとも１つのサービス切り替え指示ビットブロックに含まれるターゲット識別子を取得することであって、ターゲット識別子は第２サービスに対応する識別子である、取得することと、第２サービスのビットブロックストリームをターゲットバッファに保存することであって、ターゲットバッファは受信デバイスによりターゲット識別子に割り当てられるバッファである、保存することとを行うように構成される。
【０４５６】
本実施形態におけるターゲット識別子の具体的な説明については、前述の実施形態を参照されたい。詳細は、本実施形態において再度説明しない。
【０４５７】
任意選択で、デマルチプレクサ２４０２はさらに、第１サービスのビットブロックストリーム及び／又は第２サービスのビットブロックストリームにアイドルビットブロックが存在すると判定された場合、アイドルビットブロックを削除するように構成される。
【０４５８】
本実施形態におけるアイドルビットブロック削除処理については、前述の実施形態を参照されたい。詳細は、本実施形態において再度説明しない。
【０４５９】
簡便且つ簡潔な説明のために、前述のシステム、装置、及びユニットの詳細な動作プロセスについては、前述の方法の実施形態における対応する処理を参照できることは、当業者が明確に理解するであろう。詳細は、ここで再度説明しない。
【０４６０】
本願において提供された、いくつかの実施形態では、開示されたシステム、装置、及び方法が他の方式で実装されてよいことを理解されたい。例えば、説明された装置の実施形態は、単なる一例にすぎない。例えば、ユニットの分割は単なる論理的機能の分割にすぎず、実際の実装では他の分割であってもよい。例えば、複数のユニット又は構成要素が組み合わされても、別のシステムに統合されてもよく、又はいくつかの特徴が無視されても実行されなくてもよい。さらに、表示又は論じられた相互連結又は直接的連結又は通信接続は、一部のインタフェースを用いて実装されてよい。装置間又はユニット間の間接的連結又は通信接続は、電気的形態、機械的形態、又は他の形態で実装されてよい。
【０４６１】
別個の部分として説明されたユニットは、物理的に離れていてもいなくてもよく、またユニットとして示された部分が物理的ユニットであってもなくてもよく、１か所に位置してもよく、又は複数のネットワークユニットに分散されてもよい。これらのユニットの一部又は全てが、各実施形態の解決手段の目的を達成するために、実際の必要性に基づいて選択されてよい。
【０４６２】
さらに、本発明の実施形態の複数の機能ユニットが、１つの処理ユニットに統合されてもよく、又はこれらのユニットのそれぞれが物理的に単独で存在してもよく、又は２つ若しくはそれより多くのユニットが１つのユニットに統合される。統合されたユニットは、ハードウェアの形態で実装されてもよく、ソフトウェア機能ユニットの形態で実装されてもよい。
【０４６３】
統合されたユニットがソフトウェア機能ユニットの形態で実装され、独立した製品として販売又は用いられる場合、統合されたユニットは、コンピュータ可読記憶媒体に格納されてよい。そのような理解に基づいて、本質的には本発明の技術的解決手段、又は先行技術に寄与する部分、又は技術的解決手段の全て若しくは一部が、ソフトウェア製品の形態で実装されてよい。ソフトウェア製品は記憶媒体に格納され、コンピュータデバイス（これは、パーソナルコンピュータ、サーバ、又はネットワークデバイスなどであってよい）に、本発明の実施形態において説明される方法の段階の全て又は一部を行うよう命令するいくつかの命令を含む。前述の記憶媒体には、プログラムコードを格納できるあらゆる媒体が含まれ、例えば、ＵＳＢフラッシュドライブ、着脱可能なハードディスク、リードオンリメモリ（ｒｅａｄ−ｏｎｌｙ  Ｍｅｍｏｒｙ、ＲＯＭ）、ランダムアクセスメモリ（ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ、ＲＡＭ）、磁気ディスク、又は光ディスクなどである。
【０４６４】
前述の実施形態は、本発明の技術的解決手段を説明することだけを意図しており、本発明を限定する意図はない。本発明は前述の実施形態を参照して詳細に説明されているが、当業者であれば、本発明の実施形態の技術的解決手段の意図及び範囲から逸脱することなく、依然として、前述の実施形態において説明された技術的解決手段に対して修正を施しても、又は本発明の一部の技術的特徴に対して均等物による置き換えを行ってもよいことを理解するはずである。
【図１】
2020530959.tif 000004
【図２】
2020530959.tif 000005
【図３】
2020530959.tif 000006
【図４】
2020530959.tif 000007
【図５】
2020530959.tif 000008
【図６】
2020530959.tif 000009
【図７】
2020530959.tif 000010
【図８】
2020530959.tif 000011
【図９】
2020530959.tif 000012
【図１０】
2020530959.tif 000013
【図１１】
2020530959.tif 000014
【図１２】
2020530959.tif 000015
【図１３】
2020530959.tif 000016
【図１４】
2020530959.tif 000017
【図１５】
2020530959.tif 000018
【図１６】
2020530959.tif 000019
【図１７】
2020530959.tif 000020
【図１８】
2020530959.tif 000021
【図１９】
2020530959.tif 000022
【図２０】
2020530959.tif 000023
【図２１】
2020530959.tif 000024
【図２２】
2020530959.tif 000025
【図２３】
2020530959.tif 000026
【図２４】
2020530959.tif 000027
【手続補正書】
【提出日】令和2年3月4日(2020.3.4)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
サービス多重化方法であって、
送信デバイスが第１サービスのビットブロックストリームを受信デバイスに送信する段階と、
前記送信デバイスが前記第１サービスから第２サービスに切り替えてサービス送信するかどうかを判定する段階と、
前記送信デバイスが前記第１サービスから前記第２サービスに切り替えてサービス送信すると判定した場合、前記送信デバイスが少なくとも１つのサービス切り替え指示ビットブロックを前記受信デバイスに送信する段階であって、前記少なくとも１つのサービス切り替え指示ビットブロックは、前記第１サービスを前記第２サービスに切り替えてサービス送信することを示すのに用いられる、段階と、
前記送信デバイスが前記第２サービスのビットブロックストリームを前記受信デバイスに送信する段階と
を備える方法。
【請求項２】
前記第１サービスの前記ビットブロックストリームに含まれる任意のビットブロックと、前記第２サービスの前記ビットブロックストリームに含まれる任意のビットブロックと、前記少なくとも１つのサービス切り替え指示ビットブロックのうちのいずれか１つとがＭ１／Ｍ２ビットブロックであり、Ｍ１は各ビットブロック内のペイロードビットの数を表し、Ｍ２は各ビットブロック内のビットの合計数を表し、Ｍ１及びＭ２は正の整数であり、Ｍ２＞Ｍ１である、請求項１に記載の方法。
【請求項３】
送信デバイスが第１サービスのビットブロックストリームを受信デバイスに送信する前記段階の前に、前記方法はさらに、
前記送信デバイスが前記第１サービスの第１サービスデータを取得する段階と、
前記送信デバイスが前記第１サービスデータを符号化して前記第１サービスの前記ビットブロックストリームを生成する段階と
を備え、
前記送信デバイスが前記第２サービスのビットブロックストリームを前記受信デバイスに送信する前記段階の前に、前記方法はさらに、
前記送信デバイスが前記第２サービスの第２サービスデータを取得する段階と、
前記送信デバイスが前記第２サービスデータを符号化して前記第２サービスの前記ビットブロックストリームを生成する段階と
を備える、請求項２に記載の方法。
【請求項４】
前記Ｍ１／Ｍ２ビットブロックが６４Ｂ／６６Ｂビットブロックである場合、少なくとも１つのサービス切り替え指示ビットブロックが存在する、請求項２又は３に記載の方法。
【請求項５】
前記Ｍ１／Ｍ２ビットブロックが８Ｂ／１０Ｂビットブロックである場合、複数のサービス切り替え指示ビットブロックが存在し、前記複数のサービス切り替え指示ビットブロックは、少なくとも１つの特殊ビットブロックと少なくとも１つのデータビットブロックとを含む、請求項２又は３に記載の方法。
【請求項６】
前記少なくとも１つのサービス切り替え指示ビットブロックはさらに指示情報を含み、前記指示情報は、前記第２サービスの、前記受信デバイスに送信される、前記ビットブロックストリームに含まれるビットブロックの数を示すのに用いられる、請求項１から５のいずれか一項に記載の方法。
【請求項７】
前記送信デバイスが少なくとも１つのサービス切り替え指示ビットブロックを前記受信デバイスに送信する前記段階の前に、前記方法はさらに、
前記送信デバイスがターゲット識別子を判定する段階であって、前記ターゲット識別子は前記第２サービスに対応する識別子である、段階と、
前記送信デバイスが前記少なくとも１つのサービス切り替え指示ビットブロックを生成する段階であって、前記少なくとも１つのサービス切り替え指示ビットブロックは前記ターゲット識別子を含み、前記ターゲット識別子は、前記第２サービスの前記ビットブロックストリームをターゲットバッファに保存するよう前記受信デバイスに命令するのに用いられ、前記ターゲットバッファは、前記受信デバイスにより前記ターゲット識別子に割り当てられるバッファである、段階と
を備える、請求項１から６のいずれか一項に記載の方法。
【請求項８】
前記方法はさらに、
前記第１サービスの前記ビットブロックストリーム及び／又は前記第２サービスの前記ビットブロックストリームにアイドルビットブロックが存在すると前記送信デバイスが判定した場合、前記送信デバイスが前記アイドルビットブロックを削除する段階を備える、請求項１から７のいずれか一項に記載の方法。
【請求項９】
サービス多重分離方法であって、
送信デバイスにより送信される少なくとも１つのサービス切り替え指示ビットブロックが受信されたかどうかを受信デバイスが判定する段階であって、前記少なくとも１つのサービス切り替え指示ビットブロックは、前記送信デバイスが第１サービスから第２サービスに切り替えてサービス送信することを示すのに用いられ、前記第１サービスのビットブロックストリームが、前記受信デバイスが前記少なくとも１つのサービス切り替え指示ビットブロックを受信する前に前記受信デバイスにより受信されるビットブロックストリームである、段階と、
前記受信デバイスが前記少なくとも１つのサービス切り替え指示ビットブロックが受信されたと判定した場合、前記受信デバイスが前記少なくとも１つのサービス切り替え指示ビットブロックを受信した後に前記受信デバイスにより受信されるビットブロックストリームが前記第２サービスのビットブロックストリームであると前記受信デバイスが判定する段階と
を備える方法。
【請求項１０】
前記第１サービスの前記ビットブロックストリームに含まれる任意のビットブロックと、前記第２サービスの前記ビットブロックストリームに含まれる任意のビットブロックと、前記少なくとも１つのサービス切り替え指示ビットブロックのうちのいずれか１つとがＭ１／Ｍ２ビットブロックであり、Ｍ１は各ビットブロック内のペイロードビットの数を表し、Ｍ２は各ビットブロック内のビットの合計数を表し、Ｍ１及びＭ２は正の整数であり、Ｍ２＞Ｍ１である、請求項９に記載の方法。
【請求項１１】
前記少なくとも１つのサービス切り替え指示ビットブロックが受信されたと前記受信デバイスが判定する前に、前記方法はさらに、
前記受信デバイスが、前記第１サービスの、前記送信デバイスにより送信される、前記ビットブロックストリームを受信する段階と、
前記受信デバイスが、前記第１サービスの前記ビットブロックストリームを復号して前記第１サービスの第１サービスデータを取得する段階と
を備え、
前記少なくとも１つのサービス切り替え指示ビットブロックが受信されたと前記受信デバイスが判定した後に、前記方法はさらに、
前記受信デバイスが、前記第２サービスの、前記送信デバイスにより送信される、前記ビットブロックストリームを受信する段階と、
前記受信デバイスが、前記第２サービスの前記ビットブロックストリームを復号して前記第２サービスの第２サービスデータを取得する段階と
を備える、請求項１０に記載の方法。
【請求項１２】
前記Ｍ１／Ｍ２ビットブロックが６４Ｂ／６６Ｂビットブロックである場合、少なくとも１つのサービス切り替え指示ビットブロックが存在する、請求項１０又は１１に記載の方法。
【請求項１３】
前記Ｍ１／Ｍ２ビットブロックが８Ｂ／１０Ｂビットブロックである場合、複数のサービス切り替え指示ビットブロックが存在し、前記複数のサービス切り替え指示ビットブロックは、少なくとも１つの特殊ビットブロックと少なくとも１つのデータビットブロックとを含む、請求項１０又は１１に記載の方法。
【請求項１４】
前記少なくとも１つのサービス切り替え指示ビットブロックが受信されたと前記受信デバイスが判定した後に、前記方法はさらに、
前記受信デバイスが前記少なくとも１つのサービス切り替え指示ビットブロックに含まれる指示情報を取得する段階であって、前記指示情報は、前記第２サービスの前記ビットブロックストリームに含まれるビットブロックの数を示すのに用いられる、段階と、
前記受信デバイスが前記指示情報に従って、前記第２サービスの前記ビットブロックストリームに含まれる前記ビットブロックの数を判定する段階と
を備える、請求項１１から１３のいずれか一項に記載の方法。
【請求項１５】
前記少なくとも１つのサービス切り替え指示ビットブロックが受信されたと前記受信デバイスが判定した後に、前記方法はさらに、
前記受信デバイスが、前記少なくとも１つのサービス切り替え指示ビットブロックに含まれるターゲット識別子を取得する段階であって、前記ターゲット識別子は前記第２サービスに対応する識別子である、段階と、
前記受信デバイスが前記第２サービスの前記ビットブロックストリームをターゲットバッファに保存する段階であって、前記ターゲットバッファは、前記受信デバイスにより前記ターゲット識別子に割り当てられるバッファである、段階と
を備える、請求項９から１４のいずれか一項に記載の方法。
【請求項１６】
前記方法はさらに、
前記第１サービスの前記ビットブロックストリーム及び／又は前記第２サービスの前記ビットブロックストリームにアイドルビットブロックが存在すると前記受信デバイスが判定した場合、前記受信デバイスが前記アイドルビットブロックを削除する段階を備える、請求項９から１５のいずれか一項に記載の方法。
【請求項１７】
送信機と前記送信機に接続されたマルチプレクサとを備える送信デバイスであって、
前記送信機は、第１サービスのビットブロックストリームを受信デバイスに送信するように構成され、
前記マルチプレクサは、前記第１サービスから第２サービスに切り替えてサービス送信するかどうかを判定するように構成され、
前記送信機はさらに、前記マルチプレクサが前記第１サービスから前記第２サービスに切り替えてサービス送信すると判定した場合、少なくとも１つのサービス切り替え指示ビットブロックを前記受信デバイスに送信するように構成され、前記少なくとも１つのサービス切り替え指示ビットブロックは、前記第１サービスを前記第２サービスに切り替えてサービス送信することを示すのに用いられ、前記送信機はさらに、前記第２サービスのビットブロックストリームを前記受信デバイスに送信するように構成される、送信デバイス。
【請求項１８】
前記第１サービスの前記ビットブロックストリームに含まれる任意のビットブロックと、前記第２サービスの前記ビットブロックストリームに含まれる任意のビットブロックと、前記少なくとも１つのサービス切り替え指示ビットブロックのうちのいずれか１つとがＭ１／Ｍ２ビットブロックであり、Ｍ１は各ビットブロック内のペイロードビットの数を表し、Ｍ２は各ビットブロック内のビットの合計数を表し、Ｍ１及びＭ２は正の整数であり、Ｍ２＞Ｍ１である、請求項１７に記載の送信デバイス。
【請求項１９】
前記送信機はさらに、前記第１サービスの第１サービスデータを取得し、前記第１サービスデータを符号化して前記第１サービスの前記ビットブロックストリームを生成し、前記第２サービスの第２サービスデータを取得し、前記第２サービスデータを符号化して前記第２サービスの前記ビットブロックストリームを生成するように構成される、請求項１８に記載の送信デバイス。
【請求項２０】
前記Ｍ１／Ｍ２ビットブロックが６４Ｂ／６６Ｂビットブロックである場合、少なくとも１つのサービス切り替え指示ビットブロックが存在する、請求項１８又は１９に記載の送信デバイス。
【請求項２１】
前記Ｍ１／Ｍ２ビットブロックが８Ｂ／１０Ｂビットブロックである場合、複数のサービス切り替え指示ビットブロックが存在し、前記複数のサービス切り替え指示ビットブロックは、少なくとも１つの特殊ビットブロックと少なくとも１つのデータビットブロックとを含む、請求項１８又は１９に記載の送信デバイス。
【請求項２２】
前記少なくとも１つのサービス切り替え指示ビットブロックはさらに指示情報を含み、前記指示情報は、前記第２サービスの、前記受信デバイスに送信される、前記ビットブロックストリームに含まれるビットブロックの数を示すのに用いられる、請求項１７から２１のいずれか一項に記載の送信デバイス。
【請求項２３】
前記マルチプレクサはさらに、ターゲット識別子を判定することであって、前記ターゲット識別子が前記第２サービスに対応する識別子である、判定することと、前記少なくとも１つのサービス切り替え指示ビットブロックを生成することであって、前記少なくとも１つのサービス切り替え指示ビットブロックは前記ターゲット識別子を含み、前記ターゲット識別子は、前記第２サービスの前記ビットブロックストリームをターゲットバッファに保存するよう前記受信デバイスに命令するのに用いられ、前記ターゲットバッファは、前記受信デバイスにより前記ターゲット識別子に割り当てられるバッファである、生成することとを行うように構成される、請求項１７から２２のいずれか一項に記載の送信デバイス。
【請求項２４】
前記マルチプレクサはさらに、前記第１サービスの前記ビットブロックストリーム及び／又は前記第２サービスの前記ビットブロックストリームにアイドルビットブロックが存在する場合、前記アイドルビットブロックを削除するように構成される、請求項１７から２３のいずれか一項に記載の送信デバイス。
【請求項２５】
受信機と前記受信機に接続されたデマルチプレクサとを備える受信デバイスであって、
前記受信機は、送信デバイスにより送信される少なくとも１つのサービス切り替え指示ビットブロックが受信されたかどうかを判定するように構成され、前記少なくとも１つのサービス切り替え指示ビットブロックは、前記送信デバイスが第１サービスから第２サービスに切り替えてサービス送信することを示すのに用いられ、前記第１サービスのビットブロックストリームが、前記少なくとも１つのサービス切り替え指示ビットブロックが受信される前に受信されるビットブロックストリームであり、
前記デマルチプレクサは、前記少なくとも１つのサービス切り替え指示ビットブロックが受信されたと判定された場合、前記少なくとも１つのサービス切り替え指示ビットブロックが受信された後に受信されるビットブロックストリームが前記第２サービスのビットブロックストリームであると判定するように構成される、受信デバイス。
【請求項２６】
前記第１サービスの前記ビットブロックストリームに含まれる任意のビットブロックと、前記第２サービスの前記ビットブロックストリームに含まれる任意のビットブロックと、前記少なくとも１つのサービス切り替え指示ビットブロックのうちのいずれか１つとがＭ１／Ｍ２ビットブロックであり、Ｍ１は各ビットブロック内のペイロードビットの数を表し、Ｍ２は各ビットブロック内のビットの合計数を表し、Ｍ１及びＭ２は正の整数であり、Ｍ２＞Ｍ１である、請求項２５に記載の受信デバイス。
【請求項２７】
前記受信機はさらに、前記第１サービスの、前記送信デバイスにより送信される、前記ビットブロックストリームを受信するように構成され、
前記デマルチプレクサはさらに、前記第１サービスの前記ビットブロックストリームを復号して前記第１サービスの第１サービスデータを取得するように構成され、
前記受信機はさらに、前記第２サービスの、前記送信デバイスにより送信される、前記ビットブロックストリームを受信するように構成され、
前記デマルチプレクサはさらに、前記第２サービスの前記ビットブロックストリームを復号して前記第２サービスの第１サービスデータを取得するように構成される、請求項２６に記載の受信デバイス。
【請求項２８】
前記Ｍ１／Ｍ２ビットブロックが６４Ｂ／６６Ｂビットブロックである場合、少なくとも１つのサービス切り替え指示ビットブロックが存在する、請求項２６又は２７に記載の受信デバイス。
【請求項２９】
前記Ｍ１／Ｍ２ビットブロックが８Ｂ／１０Ｂビットブロックである場合、複数のサービス切り替え指示ビットブロックが存在し、前記複数のサービス切り替え指示ビットブロックは、少なくとも１つの特殊ビットブロックと少なくとも１つのデータビットブロックとを含む、請求項２６又は２７に記載の受信デバイス。
【請求項３０】
前記デマルチプレクサはさらに、前記少なくとも１つのサービス切り替え指示ビットブロックに含まれる指示情報を取得することであって、前記指示情報は、前記第２サービスの前記ビットブロックストリームに含まれるビットブロックの数を示すのに用いられる、取得することと、前記指示情報に従って、前記第２サービスの前記ビットブロックストリームに含まれる前記ビットブロックの数を判定することとを行うように構成される、請求項２７から２９のいずれか一項に記載の受信デバイス。
【請求項３１】
前記デマルチプレクサはさらに、前記少なくとも１つのサービス切り替え指示ビットブロックに含まれるターゲット識別子を取得することであって、前記ターゲット識別子は前記第２サービスに対応する識別子である、取得することと、前記第２サービスの前記ビットブロックストリームをターゲットバッファに保存することであって、前記ターゲットバッファは、前記受信デバイスにより前記ターゲット識別子に割り当てられるバッファである、保存することとを行うように構成される、請求項２５から３０のいずれか一項に記載の受信デバイス。
【請求項３２】
前記デマルチプレクサはさらに、前記第１サービスの前記ビットブロックストリーム及び／又は前記第２サービスの前記ビットブロックストリームにアイドルビットブロックが存在すると判定された場合、前記アイドルビットブロックを削除するように構成される、請求項２５から３１のいずれか一項に記載の受信デバイス。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００４０
【補正方法】変更
【補正の内容】
【００４０】
サービス切り替え指示ビットブロックは、パラメータＯ０、Ｄ１、Ｄ２、Ｄ３、Ｃ４、Ｃ５、Ｃ６、及びＣ７を含んでよく、パラメータＤ１、Ｄ２、及びＤ３は８ビットのデータであり、パラメータＣ４、Ｃ５、Ｃ６、及びＣ７は７ビットのデータであり、パラメータＯ０は４ビットの制御コードである。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００６５
【補正方法】変更
【補正の内容】
【００６５】
本態様において提供されるサービス多重分離方法の有益な効果とは、受信デバイスが任意のビットブロックでサービス切り替えを判定できるため、サービス切り替え処理における遅延及びジッタが減少しサービス切り替え時の低遅延が保証されるという点にある。本実施形態では、サービス多重分離がバッファを用いて実装されることで、多重分離が専用帯域幅を用いて行われるために生じる帯域幅の浪費及び伝送遅延を効果的に回避することができる。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００７６
【補正方法】変更
【補正の内容】
【００７６】
サービス切り替え指示ビットブロックは、パラメータＯ０、Ｄ１、Ｄ２、Ｄ３、Ｃ４、Ｃ５、Ｃ６、及びＣ７を含んでよく、パラメータＤ１、Ｄ２、及びＤ３は８ビットのデータであり、パラメータＣ４、Ｃ５、Ｃ６、及びＣ７は７ビットのデータであり、パラメータＯ０は４ビットの制御コードである。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】０１０５
【補正方法】変更
【補正の内容】
【０１０５】
サービス切り替え指示ビットブロックは、パラメータＯ０、Ｄ１、Ｄ２、Ｄ３、Ｃ４、Ｃ５、Ｃ６、及びＣ７を含んでよく、パラメータＤ１、Ｄ２、及びＤ３は８ビットのデータであり、パラメータＣ４、Ｃ５、Ｃ６、及びＣ７は７ビットのデータであり、パラメータＯ０は４ビットの制御コードである。
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】０１２４
【補正方法】変更
【補正の内容】
【０１２４】
サービス切り替え指示ビットブロックは、パラメータＯ０、Ｄ１、Ｄ２、Ｄ３、Ｃ４、Ｃ５、Ｃ６、及びＣ７を含んでよく、パラメータＤ１、Ｄ２、及びＤ３は８ビットのデータであり、パラメータＣ４、Ｃ５、Ｃ６、及びＣ７は７ビットのデータであり、パラメータＯ０は４ビットの制御コードである。
【手続補正７】
【補正対象書類名】明細書
【補正対象項目名】０２０７
【補正方法】変更
【補正の内容】
【０２０７】
図８は一例として用いられる。マルチプレクサが、調停結果情報に示される優先順序に基づいて、第１サービスのビットブロックストリームと第２サービスのビットブロックストリームとが受信デバイスに連続的に送信されると判定してよい場合、マルチプレクサは、第１サービスのビットブロックストリームと第２サービスのビットブロックストリームとの間に少なくとも１つのサービス切り替え指示ビットブロック８０１を挿入する。
【手続補正８】
【補正対象書類名】明細書
【補正対象項目名】０２９４
【補正方法】変更
【補正の内容】
【０２９４】
本実施形態では、サービス切り替え指示ビットブロックはタグビットブロックであり、少なくとも１つのＴＡＧビットブロックが存在する。
【手続補正９】
【補正対象書類名】明細書
【補正対象項目名】０２９９
【補正方法】変更
【補正の内容】
【０２９９】
パラメータＤ１、Ｄ２、及びＤ３は８ビットのデータであり、パラメータＣ４、Ｃ５、Ｃ６、及びＣ７は７ビットのデータであり、パラメータＯ０は、パラメータＯ０を含むビットブロックのカテゴリを示すのに用いられる４ビットの制御コードである。本実施形態では、パラメータＯ０は、サービス切り替えが行われることを示すのにパラメータＯ０を含むビットブロックが用いられるというような定義を作成するのに用いられる。
【手続補正１０】
【補正対象書類名】明細書
【補正対象項目名】０３３３
【補正方法】変更
【補正の内容】
【０３３３】
本実施形態では、デマルチプレクサにより受信されるビットブロックストリーム内の各ビットブロックがサービス切り替え指示ビットブロックであるかどうかが検出される。デマルチプレクサが１つのサービス切り替え指示ビットブロック又は複数の連続したサービス切り替え指示ビットブロックを受信した場合、段階１４０３が行われる。
【手続補正１１】
【補正対象書類名】明細書
【補正対象項目名】０３５８
【補正方法】変更
【補正の内容】
【０３５８】
本実施形態では、送信デバイスの第１ｔｘ＿ｂｕｆは、ｐＭＡＣサービスをバッファリングするように構成される。ｐＭＡＣサービスを受信した後に、送信デバイスは、ｐＭＡＣサービスをｐＭＡＣサービスに対応する第１ｔｘ＿ｂｕｆにバッファリングしてよい。
【手続補正１２】
【補正対象書類名】明細書
【補正対象項目名】０４１４
【補正方法】変更
【補正の内容】
【０４１４】
アイドルビットブロック挿入／削除モジュールは、サービスｆｌｅｘＥ  ｃｌｉｅｎｔ  ｂのビットブロックストリームに対してレートアダプテーションを行うように構成される。
【手続補正１３】
【補正対象書類名】明細書
【補正対象項目名】０４１９
【補正方法】変更
【補正の内容】
【０４１９】
ｆｌｅｘＥ  ｃａｌｅｎｄａｒはｆｌｅｘＥ  ｃｌｉｅｎｔ  ｂの多重分離されたビットブロックストリームをアイドルビットブロック挿入／削除モジュールに入力し、アイドルビットブロック挿入／削除モジュールは、ｆｌｅｘＥ  ｃｌｉｅｎｔ  ｂのビットブロックストリームに対してレートアダプテーションを行うように構成される。
【国際調査報告】
2020530959.tif 000028
2020530959.tif 000029
2020530959.tif 000030
2020530959.tif 000031