WO2021171481A1 - Ｎｎｉ故障検出システム、ｎｎｉ故障検出方法、及びプログラム - Google Patents

Ｎｎｉ故障検出システム、ｎｎｉ故障検出方法、及びプログラム Download PDF

Info

Publication number
WO2021171481A1
WO2021171481A1 PCT/JP2020/008027 JP2020008027W WO2021171481A1 WO 2021171481 A1 WO2021171481 A1 WO 2021171481A1 JP 2020008027 W JP2020008027 W JP 2020008027W WO 2021171481 A1 WO2021171481 A1 WO 2021171481A1
Authority
WO
WIPO (PCT)
Prior art keywords
call
nni
rtp
failure detection
network
Prior art date
Application number
PCT/JP2020/008027
Other languages
English (en)
French (fr)
Inventor
広樹 金成
広嗣 撰
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to PCT/JP2020/008027 priority Critical patent/WO2021171481A1/ja
Publication of WO2021171481A1 publication Critical patent/WO2021171481A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks

Definitions

  • the present invention relates to an NNI failure detection system, an NNI failure detection method, and a program for detecting a failure between a network interface (Network to Network Interface) and a network facing the network.
  • a network interface Network to Network Interface
  • the opposite network cannot be monitored because the opposite network is another operator.
  • Non-Patent Document 1 The regulation regarding the monitoring of the inter-network interface is only the detection of RTP (Realtime Transfer Protocol) interruption for 30 seconds in the interconnection specification of TTC (Telecommunication Technology Committee) (Non-Patent Document 1).
  • the present invention has been made in view of this problem, and an object of the present invention is to provide an NNI failure detection system, an NNI failure detection method, and a program capable of detecting a failure with an opposing network in a network interface. do.
  • the NNI failure detection system calls a pseudo call to the called party network, receives the transferred call to which the pseudo call is transferred by the called party network, and receives the pseudo call.
  • An NNI failure detection device that measures the delay time by associating each packet string of the transfer call with a sequence number and detects a failure with the calling side network based on the delay time, and a calling side.
  • the gist is to include an RTP conversion device that transfers the number to the RTP data of the transfer call that is transmitted to the called party network.
  • the NNI failure detection method is an NNI failure detection method for detecting a failure between the calling side network and a SIP message from the calling side and the calling side, respectively, by the RTP conversion device.
  • the RTP data of the pseudo call on the calling side is encoded according to the coding method of the called side
  • the NNI failure detection device The pseudo call encoded according to the coding method of the called side is called, the transfer call to which the pseudo call is transferred by the call side network is received, and each of the pseudo call and the transfer call is received.
  • the gist includes a process of associating a packet sequence with a sequence number, measuring a delay time, and detecting a failure with the calling network based on the delay time.
  • the program according to one aspect of the present invention is a program for operating a computer as the above-mentioned NNI failure detection system.
  • FIG. 1 It is a block diagram which shows the structural example of the NNI failure detection system which concerns on embodiment of this invention. It is a figure which shows the operation sequence of the NNI failure detection system shown in FIG. It is a figure which shows the specific example of the SIP message. It is a block diagram which shows the functional structure example of the RTP conversion apparatus shown in FIG. It is a flowchart which shows the processing procedure of the coding part and RTP regeneration part shown in FIG. It is a figure which shows typically the RTP packet sequence of a pseudo call, and the pseudo call RTP packet sequence (forwarding call) regenerated by the RTP regeneration unit shown in FIG. It is a block diagram which shows the functional configuration example of the NNI failure detection apparatus shown in FIG. It is a figure which shows the format of the RTP packet. It is a block diagram which shows the configuration example of a general-purpose computer system.
  • FIG. 1 is a block diagram showing a configuration example of an IP telephone network using the NNI failure detection system according to the embodiment of the present invention.
  • the IP telephone network 200 shown in FIG. 1 is a network that provides a telephone service using VoIP (Voice over Internet Protocol) technology.
  • the IP telephone network 200 is a network that uses SIP (Session Initiation Protocol) as a path control protocol, and main information (data) that is communicated between terminals connected to the network is transmitted using RTP (Realtime Transfer Protocol).
  • SIP Session Initiation Protocol
  • RTP Realtime Transfer Protocol
  • the NNI failure detection system 100 is composed of a packet transfer network 2, an RTP conversion device 10, a SIP server 3, and an NNI failure detection device 20.
  • the configurations other than the RTP conversion device 10 and the NNI failure detection device 20 are general.
  • An example is shown in which the telecommunications carriers are different, for example, the packet transfer network 2 is company A, and the packet transfer network 5 is company B, for example.
  • the SIP servers 3 and 4 are servers that manage and control the IP telephone service using SIP, and are provided in each of the packet transfer networks 2 and 5.
  • the RTP conversion devices 10 and 20 are devices that enable RTP packets of main information to be communicated between adjacent networks.
  • the RTP converters 10 and 20 are generally referred to as SBCs (Session Border Controllers).
  • SBCs Session Border Controllers
  • the RTP converters 10 and 20 may have the functions of the SIP servers 3 and 4.
  • the RTP conversion device 10 has a sequence number of the calling side RTP data when encoding the calling side RTP data according to the calling side coding method in addition to the general SBC function. Has a function of transferring to RTP data on the called side.
  • FIG. 2 is an operation sequence diagram schematically showing the operation procedure of the NNI failure detection system 100.
  • SIP servers 3 and 4 for convenience of drawing. Further, hereinafter, the description will be abbreviated as SIP server 3.
  • the NNI failure detection device 30 includes two numbers, a calling number for issuing a pseudo call, which is a forwarding call, and a forwarding number for receiving the forwarding call.
  • a calling number for issuing a pseudo call which is a forwarding call
  • a forwarding number for receiving the forwarding call.
  • each of the calling number and the forwarding number is represented by two vertical lines.
  • the NNI failure detection device 30 issues a pseudo call from the oscillation number to the called destination number when detecting whether or not the connection with the incoming network (RTP conversion device 20) is functioning normally.
  • the pseudo call is a transfer call.
  • a SIP INVITE message is transmitted from the NNI failure detection device 30 to the RTP conversion device 20 via the RTP conversion device 10 and the SIP server 3 (INVITE).
  • the RTP conversion devices 10 and 20 acquire the calling number of the NNI failure detection device 30 from the INVITE message (step S1). Further, the RTP conversion device 10 detects the coding method of the calling side and the calling side.
  • the destination number is a number contracted by the administrator of the NNI failure detection system 100 with company B, a telecommunications carrier that operates the packet transfer network 5. It is predetermined that the incoming call to the number is a transfer call. In FIG. 2, this is represented by a transfer instruction arrow extending from the incoming call terminal 6 to the RTP conversion device 20.
  • FIG. 3 shows a specific example of the SIP INVITE message. For example, it can be seen from the information in the header of History-Info on the 18th line from the top that it is a transfer call.
  • sip: +81322222222 represents the destination number (03-2222-2222)
  • sip: +81333333333 represents the forwarding number (03-3333-3333).
  • the RTP conversion device 20 transmits an INVITE message to the transfer destination number (03-3333-3333) of the NNI failure detection device 30 via the SIP server 3 and the RTP conversion device 10.
  • the NNI failure detection device 30 that has received the INVITE message traces back the route that received the INVITE message and returns a provisional response of 180 Ringing to its own calling number.
  • the NNI failure detection device 30 transmits a success response of 200 OK via the route of the RTP conversion device 10 ⁇ SIP server 3 ⁇ RTP conversion device 20 ⁇ NNI failure detection device 30 (transmission number) (step S2). At this time, each of the RTP converters 10 and 20 acquires the transfer destination number included in the 200 OK message.
  • the NNI failure detection device 30 Upon receiving the 200OK message, the NNI failure detection device 30 (transmission number) transmits the ACK message via the route of the RTP conversion device 10 ⁇ SIP server 3 ⁇ RTP conversion device 20 ⁇ NNI failure detection device 30 (transfer destination number).
  • the transmission of the ACK message means that a line has been established (session establishment) between the outgoing number of the NNI failure detection device 30 and the transfer destination number via the RTP conversion device 20 of the called party network.
  • the voice packet which is the main information, is transmitted between the NNI failure detection device 30 and the RTP conversion device 20 using the RTP.
  • the RTP conversion device 10 encodes the calling side received RTP data received from the calling side according to the coding method of the called side (step S3).
  • the coding method on the called side has already been acquired in step S1.
  • the RTP conversion device 10 includes data in which the sequence number of the pseudo call RTP data received from the NNI failure detection device 30 and the sequence number of the transfer call RTP data transmitted to the called party are associated with each other. Regenerate the packet (step S4). The regenerated RTP packet is transferred (forwarded) to the transfer destination number of the NNI failure detection device 30 by the RTP conversion device 20.
  • the pseudo call RTP data is, for example, voice data representing a signal sound. Alternatively, it may be a signal having a predetermined fixed arrangement.
  • the NNI failure detection device 30 receives the transfer call transferred by the RTP conversion device 20, and associates the packet sequences of the pseudo call transmitted to the RTP conversion device 20 and the received transfer call with a sequence number to determine the delay time. taking measurement. Then, a failure with the called party network is detected based on the delay time (step S5).
  • the codec conversion is performed by the RTP conversion device. Do at 10. Next, the operation of the RTP conversion device 10 for converting the codec will be described.
  • FIG. 4 is a block diagram showing a functional configuration example of the RTP conversion device 10.
  • notations such as a communication interface unit and a control unit, which are general configurations, are omitted.
  • the RTP conversion device 10 includes an IP header analysis unit 11, a coding unit 12, and an RTP regeneration unit 13.
  • Each functional component of the RTP converter 10 is realized by, for example, a computer including a ROM, a RAM, a CPU, and the like.
  • the processing content of the function that each functional component should have is described by a program.
  • FIG. 5 is a flowchart showing a processing procedure of the coding unit 12 and the RTP regeneration unit 13.
  • the IP header analysis unit 11 starts an operation of acquiring information on the calling side and the called side (step S10).
  • the coding unit 12 first initializes the variables i and j (step S11).
  • the variable i represents the sequence number of the data of the calling party RTP.
  • the variable j represents the sequence number of the data of the incoming RTP.
  • step S15 After encoding the read data by the calling side coding method, the variable i is incremented (step S15) until the code length encoded by the calling side coding method reaches a predetermined code length, and the step is performed. The processing of S12 and S13 is repeated (NO loop in step S14).
  • one AMR RTP packet corresponds to a plurality of PCMU RTP packets.
  • the RTP regeneration unit 13 regenerates the RTP packet by associating the variables i and j.
  • FIG. 6 is a diagram schematically showing an example of an RTP packet sequence of a pseudo call on the calling side and an RTP packet sequence regenerated by the RTP regenerating unit 13.
  • the first column from the top of FIG. 56 shows the RTP packet sequence of the pseudo call received from the NNI failure detection device 30.
  • the second column shows the RTP packet sequence regenerated by the RTP regenerating unit 13.
  • the sequence number of the pseudo call RTP data received from the NNI failure detection device 30 and the sequence number of the transfer call RTP data transmitted to the called party by the action of the coding unit 12 and the RTP regeneration unit 13. Regenerates an RTP packet containing data associated with. This makes it possible to associate packets even when the calling side and the incoming call side have different codecs.
  • FIG. 7 is a block diagram showing a functional configuration example of the NNI failure detection device 30.
  • the NNI failure detection device 30 includes a packet sequence division unit 31, a delay time measurement unit 32, and a failure detection unit 33.
  • the NNI failure detection device 30 shown in FIG. 7 is different from the RTP conversion device 20 in that it is realized by a computer including, for example, a ROM, a RAM, a CPU, and the like, and that a general configuration such as a communication interface unit is omitted. It is the same.
  • the packet string dividing unit 31 divides the packet sequence of the transferred call transferred by the called party network for each sequence number.
  • the packet string dividing unit 31 divides the packet sequence of the transfer call shown in FIG. 6 into "1-3: A1", “4-5: A2", “6-8: A3", “9-10: A4", Divide into packets for each sequence number as in ...
  • the delay time measurement unit 32 measures the difference between the time stamp information given to the divided packet and the reception time information for receiving the transfer call.
  • the time stamp information is included in each of the RTP packets. Specific examples will be described later.
  • the time stamp information is the time possessed by the NNI failure detection device 30 when the RTP data of the pseudo call on the calling side is encoded according to the coding method on the calling side. For example, for each RTP packet with a resolution of ms. Granted.
  • the delay time measuring unit 32 measures the difference between the time stamp information and the reception time, which is the time held by the NNI failure detection device 30 when the transfer call is received. This difference is the difference between the time when the RTP data of the pseudo call on the calling side is encoded according to the coding method on the called side and the reception time when the transfer call is received, and is the difference between the RTP conversion device 10 and the RTP conversion. This is the delay time during which the packet reciprocates between the devices 20.
  • the failure detection unit 33 detects a failure with the incoming network when the difference (delay time) measured by the delay time measurement unit 32 exceeds the threshold value.
  • the threshold value may be a predetermined delay time or the magnitude of fluctuation (jitter) of the delay time.
  • FIG. 8 is a diagram showing a general format of RTP packets.
  • the numbers 0 to 3 in the first line from the top shown in FIG. 8 indicate the tens digit of the number of bits.
  • the second line shows the ones digit of the number of bits.
  • V 2 on the 3rd line indicates that the RTP version is 2.
  • P is the area indicated when there is padding at the end.
  • FIG. 8 schematically shows how an RTP packet of "1-3: A1" is written in the extension header. In this way, one RTP packet is described in the extension header and transmitted.
  • NNI failure detection method This is an NNI failure detection method for detecting a failure between the calling side network and the calling side network performed by the NNI failure detecting system 100, wherein the RTP conversion device 10 receives a SIP message from the calling side and the called side, respectively, to make a call.
  • a pseudo call encoded according to the coding method is called, a transfer call to which the pseudo call is transferred by the called party network is received, and each packet sequence of the pseudo call and the transfer call is associated with a sequence number. It includes the process of measuring the delay time and detecting a failure with the calling network based on the delay time. As a result, in the inter-network interface, it is possible to detect a failure with the opposite network.
  • the coding method of the calling side is, for example, PCMU
  • the coding method of the calling side is, for example, AMR.
  • the present invention is not limited to this example. It is possible to apply the present invention even if the coding method of the calling side and the calling side is the same.
  • the RTP conversion device 10 may regenerate (transfer call) the same RTP data as the received pseudo call.
  • the description has been given with an example in which the NNI failure detection system 100 of the present invention is applied to the IP telephone network, the description is not limited to this example.
  • the present invention can be widely applied to networks other than IP telephone networks.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)

Abstract

着呼側ネットワーク５に対して疑似呼を発呼し、着呼側ネットワーク５によって疑似呼が転送された転送呼を受信し、疑似呼と転送呼のそれぞれのパケット列をシーケンス番号で対応付けて遅延時間を測定し、該遅延時間に基づいて着呼側ネットワーク５との間の故障を検出するＮＮＩ故障検出装置３０と、発呼側と着呼側の符号化方式を検出し、疑似呼のＲＴＰデータを着呼側の符号化方式に合わせて符号化する際に、ＮＮＩ故障検出装置３０から受信する疑似呼のＲＴＰデータのシーケンス番号を着呼側ネットワークに送信する転送呼のＲＴＰデータに転写するＲＴＰ変換装置１０とを備える。

Description

ＮＮＩ故障検出システム、ＮＮＩ故障検出方法、及びプログラム
　本発明は、網間インターフェース（Network to Network Interface）において対向するネットワークとの間の故障を検出するＮＮＩ故障検出システム、ＮＮＩ故障検出方法、及びプログラムに関する。
　事業者が異なるネットワーク（網）と接続される網間インターフェースにおいては、対向するネットワークが他事業者のため、対向する装置を監視対象にすることができない。
　網間インターフェースの監視に関する規定は、ＴＴＣ（Telecommunication Technology Committee）の相互接続仕様において30秒間のＲＴＰ（Realtime Transfer Protocol）断検出のみである（非特許文献１）。
　したがって、30秒未満の通信断、ジッタ、及び遅延等から、対向するネットワークとの間の故障を検出することは出来ないという課題がある。また、符号化方式（コーデック）が変換された場合は、パケット数も変化するので、発呼側と着呼側のパケットの対応付けが困難であり、遅延、及びパケット損失率などの解析が不可能である。
　このように網間インターフェースにおいて、対向するネットワークとの間の故障を検出する好適なシステム及び方法が存在しないという課題がある。また、ＲＴＰの再生成を伴う場合は、故障を検出することが更に困難になる。
　本発明は、この課題に鑑みてなされたものであり、網間インターフェースにおいて、対向するネットワークとの間の故障を検出できるＮＮＩ故障検出システム、ＮＮＩ故障検出方法、及びプログラムを提供することを目的とする。
　本発明の一態様に係るＮＮＩ故障検出システムは、着呼側ネットワークに対して疑似呼を発呼し、前記着呼側ネットワークによって前記疑似呼が転送された転送呼を受信し、前記疑似呼と前記転送呼のそれぞれのパケット列をシーケンス番号で対応付けて遅延時間を測定し、該遅延時間に基づいて前記着呼側ネットワークとの間の故障を検出するＮＮＩ故障検出装置と、発呼側と着呼側の符号化方式を検出し、前記疑似呼のＲＴＰデータを着呼側の符号化方式に合わせて符号化する際に、前記ＮＮＩ故障検出装置から受信する前記疑似呼のＲＴＰデータのシーケンス番号を前記着呼側ネットワークに送信する前記転送呼のＲＴＰデータに転写するＲＴＰ変換装置とを備えることを要旨とする。
　また、本発明の一態様に係るＮＮＩ故障検出方法は、着呼側ネットワークとの間の故障を検出するＮＮＩ故障検出方法であって、ＲＴＰ変換装置が発呼側と着呼側からそれぞれＳＩＰメッセージを受信して発呼側と着呼側の符号化方式を検出し、発呼側の疑似呼のＲＴＰデータを着呼側の符号化方式に合わせて符号化する過程と、ＮＮＩ故障検出装置が着呼側の符号化方式に合わせて符号化した前記疑似呼を発呼し、前記着呼側ネットワークによって前記疑似呼が転送された転送呼を受信し、前記疑似呼と前記転送呼のそれぞれのパケット列をシーケンス番号で対応付けて遅延時間を測定し、該遅延時間に基づいて前記着呼側ネットワークとの間の故障を検出する過程とを含むことを要旨とする。
　また、本発明の一態様に係るプログラムは、上記のＮＮＩ故障検出システムとしてコンピュータを機能させるためのプログラムであることを要旨とする。
　本発明によれば、網間インターフェースにおいて、対向するネットワークとの間の故障を検出することができる。
本発明の実施形態に係るＮＮＩ故障検出システムの構成例を示すブロック図である。 図１に示すＮＮＩ故障検出システムの動作シーケンスを示す図である。 ＳＩＰメッセージの具体例を示す図である。 図１に示すＲＴＰ変換装置の機能構成例を示すブロック図である。 図４に示す符号化部とＲＴＰ再生成部の処理手順を示すフローチャートである。 疑似呼のＲＴＰパケット列と、図４に示すＲＴＰ再生成部で再生成された疑似呼ＲＴＰパケット列（転送呼）を模式的に示す図である。 図１に示すＮＮＩ故障検出装置の機能構成例を示すブロック図である。 ＲＴＰパケットのフォーマットを示す図である。 汎用的なコンピュータシステムの構成例を示すブロック図である。
　以下、本発明の実施形態について図面を用いて説明する。複数の図面中同一のものには同じ参照符号を付し、説明は繰り返さない。
　（ＩＰ電話網）
　図１は、本発明の実施形態に係るＮＮＩ故障検出システムを用いたＩＰ電話網の構成例を示すブロック図である。図１に示すＩＰ電話網２００は、ＶｏＩＰ（Voice over Internet Protocol）技術を利用した電話サービスを提供するネットワークである。ＩＰ電話網２００は、パス制御プロトコルとしてＳＩＰ（Session Initiation Protocol）を利用したネットワークであり、ネットワークに接続する端末間で疎通する主情報（データ）は、ＲＴＰ（Realtime Transfer Protocol）を用いて伝送される。
　本実施形態に係るＮＮＩ故障検出システム１００は、パケット転送網２、ＲＴＰ変換装置１０、ＳＩＰサーバ３、及びＮＮＩ故障検出装置２０で構成される。なお、ＲＴＰ変換装置１０とＮＮＩ故障検出装置２０以外の構成は一般的なものである。パケット転送網２は例えばＡ社、パケット転送網５は例えばＢ社といった様に通信事業者が異なる例を示す。
　ＳＩＰサーバ３，４は、ＳＩＰを利用したＩＰ電話サービスの管理制御を行うサーバであり、パケット転送網２，５のそれぞれに設けられる。
　ＲＴＰ変換装置１０，２０は、隣接するネットワーク間で主情報のＲＴＰパケットを疎通できるようにする装置である。ＲＴＰ変換装置１０，２０は、一般的にＳＢＣ（Session Border Controller）と称される。なお、ＲＴＰ変換装置１０，２０は、ＳＩＰサーバ３，４の機能を備えてもよい。
　本実施形態に係るＲＴＰ変換装置１０は、一般的なＳＢＣの機能に加えて発呼側ＲＴＰデータを着呼側の符号化方式に合わせて符号化する際に、発呼側ＲＴＰデータのシーケンス番号を着呼側のＲＴＰデータに転写する機能を備える。
　図２は、ＮＮＩ故障検出システム１００の動作手順を模式的に示す動作シーケンス図である。図２では、作図の都合により2台のＳＩＰサーバをＳＩＰサーバ３，４と表記する。また、以降ではＳＩＰサーバ３と省略して説明する。
　ＮＮＩ故障検出装置３０は、転送呼である疑似呼を発呼する発信番号と、転送呼を受信する転送先番号の2つを備える。図２において発信番号と転送先番号のそれぞれを2つの縦線で表す。
　ＮＮＩ故障検出装置３０は、着呼側ネットワークとの間（ＲＴＰ変換装置２０）が正常に機能しているか否を検出する場合に、発振番号から着信先番号に疑似呼を発呼する。疑似呼は転送呼である。
　この時、ＮＮＩ故障検出装置３０からＲＴＰ変換装置１０とＳＩＰサーバ３を介してＲＴＰ変換装置２０に、ＳＩＰのINVITEメッセージが送信される（INVITE）。ＲＴＰ変換装置１０と２０は、INVITEメッセージからＮＮＩ故障検出装置３０の発信番号を取得する（ステップＳ１）。また、ＲＴＰ変換装置１０は、発呼側と着呼側の符号化方式を検出する。
　着信先番号は、ＮＮＩ故障検出システム１００の管理者が、パケット転送網５を運営する通信事業者のＢ社と契約した番号である。当該番号に対する着信は転送呼であることが予め定められている。そのことを図２では、着呼端末６からＲＴＰ変換装置２０に延びる転送指示の矢印で表している。
　図３は、ＳＩＰのINVITEメッセージの具体例を示す。例えば、上から18行目のHistory-Infoのヘッダの情報から転送呼であることが分かる。この例では、sip:+81322222222が着信先番号（03-2222-2222）を表し、sip:+81333333333が転送先番号（03-3333-3333）を表す。
　ＲＴＰ変換装置２０は、ＳＩＰサーバ３とＲＴＰ変換装置１０を介してＮＮＩ故障検出装置３０の転送先番号（03-3333-3333）にINVITEメッセージを送信する。INVITEメッセージを受信したＮＮＩ故障検出装置３０は、INVITEメッセージを受信した経路を遡って自らの発信番号に180Ringingの暫定応答を返信する。
　その後、ＮＮＩ故障検出装置３０は、200OKの成功応答をＲＴＰ変換装置１０→ＳＩＰサーバ３→ＲＴＰ変換装置２０→ＮＮＩ故障検出装置３０（発信番号）の経路で発信する（ステップＳ２）。この時、ＲＴＰ変換装置１０，２０のそれぞれは、200OKメッセージに含まれる転送先番号を取得する。
　200OKメッセージを受信したＮＮＩ故障検出装置３０（発信番号）は、ACKメッセージをＲＴＰ変換装置１０→ＳＩＰサーバ３→ＲＴＰ変換装置２０→ＮＮＩ故障検出装置３０（転送先番号）の経路で送信する。ACKメッセージの送信は、ＮＮＩ故障検出装置３０の発信番号と転送先番号の間で、着信側ネットワークのＲＴＰ変換装置２０を介した回線が確立（セッション確立）されたことを意味する。
　以降は、ＮＮＩ故障検出装置３０とＲＴＰ変換装置２０の間で、主情報である音声パケットがＲＴＰを用いて伝送される。回線が確立した後、ＲＴＰ変換装置１０は、発呼側から受信する発呼側受信ＲＴＰデータを着信側の符号化方式に合わせて符号化する（ステップＳ３）。着呼側の符号化方式は、ステップＳ１で取得済みである。
　次に、ＲＴＰ変換装置１０は、ＮＮＩ故障検出装置３０から受信する疑似呼のＲＴＰデータのシーケンス番号と、着呼側に送信する転送呼のＲＴＰデータのシーケンス番号とを対応付けたデータを含むＲＴＰパケットを再生成する（ステップＳ４）。再生成されたＲＴＰパケットは、ＲＴＰ変換装置２０によって、ＮＮＩ故障検出装置３０の転送先番号に転送（転送呼）される。
　疑似呼のＲＴＰデータは、例えば信号音を表す音声データである。又は、所定の固定された配列の信号で有ってもよい。
　ＮＮＩ故障検出装置３０は、ＲＴＰ変換装置２０によって転送された転送呼を受信し、ＲＴＰ変換装置２０に送信した疑似呼と受信した転送呼のそれぞれのパケット列をシーケンス番号で対応付けて遅延時間を測定する。そして、その遅延時間に基づいて着呼側ネットワークとの間の故障を検出する（ステップＳ５）。
　パケット転送網２の符号化方式を例えばＰＣＭＵ（G.711 μ-low）、パケット転送網５の符号化方式を例えばＡＭＲ（Adaptive Multi-Rate）と仮定した場合のコーデックの変換は、ＲＴＰ変換装置１０で行う。次に、ＲＴＰ変換装置１０がコーデックの変換を行う動作を説明する。
　（ＲＴＰ変換装置）
　図４は、ＲＴＰ変換装置１０の機能構成例を示すブロック図である。図４において、一般的な構成である例えば通信インターフェース部及び制御部等の表記は省略している。
　図４に示すようにＲＴＰ変換装置１０は、ＩＰヘッダ解析部１１、符号化部１２、及びＲＴＰ再生成部１３を備える。ＲＴＰ変換装置１０の各機能構成部は、例えば、ＲＯＭ、ＲＡＭ、ＣＰＵ等からなるコンピュータで実現される。各機能構成部をコンピュータによって実現する場合、各機能構成部が有すべき機能の処理内容はプログラムによって記述される。
　図５は、符号化部１２とＲＴＰ再生成部１３の処理手順を示すフローチャートである。
　ＩＰヘッダ解析部１１は、発呼側と着呼側の情報を取得する動作を開始する（ステップＳ１０）。符号化部１２は、動作を開始すると先ず変数ｉとｊを初期化する（ステップＳ１１）。変数ｉは発呼側ＲＴＰのデータのシーケンス番号を表す。変数ｊは着呼側ＲＴＰのデータのシーケンス番号を表す。
　次に符号化部１２は、変数ｉ＝１のシーケンス番号のＮＮＩ故障検出装置３０から受信するＲＴＰパケトのデータを読み込む（ステップＳ１２）。そして、読み込んだデータを着呼側の符号化方式であるＡＭＲで符号化する（ステップＳ１３）。
　読み込んだデータを着呼側の符号化方式で符号化した後、着呼側の符号化方式で符号化した符号長が所定の符号長になるまで、変数ｉをインクリメント（ステップＳ１５）してステップＳ１２とＳ１３の処理を繰り返す（ステップＳ１４のＮＯのループ）。
　この例では、ＰＣＭＵよりもＡＭＲのデータ圧縮率が高いので、複数のＰＣＭＵのＲＴＰパケットに対して1つのＡＭＲのＲＴＰパケットが対応する関係になる。
　ＲＴＰ再生成部１３は、着呼側の符号化方式で符号化した符号長が所定の符号長になる（ステップＳ１４のＹＥＳ）と、変数ｉとｊを対応付けてＲＴＰパケットを再生成する。
　図６は、発呼側の疑似呼のＲＴＰパケット列と、ＲＴＰ再生成部１３で再生成されたＲＴＰパケット列の例を模式的に示す図である。図５６上から1列目は、ＮＮＩ故障検出装置３０から受信した疑似呼のＲＴＰパケット列を示す。2列目は、ＲＴＰ再生成部１３で再生成されたＲＴＰパケット列を示す。
　図６に示すように、例えば、3つの発呼側ＲＴＰパケットＡＡ１～ＡＡ３が、1つのＲＴＰパケットＡ１に変換されている。ＲＴＰパケットＡ１の頭に添付されている1-3は、この対応関係を示す情報である。変換処理は、データが終了するまで繰り返される（ステップＳ１８のＮＯ）。
　以上述べたように符号化部１２とＲＴＰ再生成部１３の作用によって、ＮＮＩ故障検出装置３０から受信する疑似呼のＲＴＰデータのシーケンス番号と着呼側に送信する転送呼のＲＴＰデータのシーケンス番号を対応付けたデータを含むＲＴＰパケットを再生成する。これにより、発呼側と着呼側でコーデックが異なる場合でもパケットの対応付けが可能になる。
　（ＮＮＩ故障検出装置）
　図７は、ＮＮＩ故障検出装置３０の機能構成例を示すブロック図である。図７に示すようにＮＮＩ故障検出装置３０は、パケット列分割部３１、遅延時間計測部３２、及び故障検出部３３を備える。
　図７に示すＮＮＩ故障検出装置３０は、例えば、ＲＯＭ、ＲＡＭ、ＣＰＵ等からなるコンピュータで実現される点、及び通信インターフェース部等の一般的な構成を省略している点でＲＴＰ変換装置２０と同じである。
　パケット列分割部３１は、着呼側ネットワークによって転送された転送呼のパケット列をシーケンス番号ごとに分割する。パケット列分割部３１は、図６に示す転送呼のパケット列を、「1-3：Ａ１」、「4-5：Ａ２」、「6-8：Ａ３」、「9-10：Ａ4」、…のようにシーケンス番号ごとのパケットに分割する。
　遅延時間計測部３２は、分割されたパケットに付与されたタイムスタンプ情報と転送呼を受信した受信時刻情報の差分を計測する。タイムスタンプ情報は、ＲＴＰパケットのそれぞれに含まれている。具体例は後述する。
　タイムスタンプ情報は、発呼側の疑似呼のＲＴＰデータを着呼側の符号化方式に合わせて符号化した時のＮＮＩ故障検出装置３０が持つ時刻であり、例えばmsの分解能でＲＴＰパケットごとに付与される。
　遅延時間計測部３２は、そのタイムスタンプ情報と、転送呼を受信した時のＮＮＩ故障検出装置３０が持つ時刻である受信時刻との差分を計測する。この差分は、発呼側の疑似呼のＲＴＰデータを着呼側の符号化方式に合わせて符号化した時刻と、転送呼を受信した受信時刻との差であり、ＲＴＰ変換装置１０とＲＴＰ変換装置２０の間をパケットが往復する間の遅延時間である。
　故障検出部３３は、遅延時間計測部３２で計測した差分（遅延時間）が閾値を越えた場合に着呼側ネットワークとの間の故障を検出する。閾値は、所定の遅延時間であってもよいし、遅延時間の揺らぎ（ジッタ）の大きさであってもよい。
　（ＲＴＰパケットフォーマット）
　図８は、ＲＴＰパケットの一般的なフォーマットを示す図である。図８に示す上から1行目の数字0～3はビット数の10の位を示す。2行目はビット数の1の位を示す。
　3行目のV=2は、ＲＴＰのバージョンが２であることを示している。Pは、最後にパディングがある場合に示す領域である。Xは、拡張ヘッダ（header extension）を利用する場合に示す領域である。本実施形態では、拡張ヘッダに変換したＲＴＰパケットを書き込むので、ここに１（X=1）を設定する。X以降の領域の説明は省略する。
　図８において、拡張ヘッダに「1-3:A1」のＲＴＰパケットが書かれている様子を模式的に示す。このように、1つのＲＴＰパケットが拡張ヘッダに記述されて送信される。
　（ＮＮＩ故障検出方法）
　上記のＮＮＩ故障検出システム１００が行う着呼側ネットワークとの間の故障を検出するＮＮＩ故障検出方法であって、ＲＴＰ変換装置１０が発呼側と着呼側からそれぞれＳＩＰメッセージを受信して発呼側と着呼側の符号化方式を検出し、発呼側の疑似呼のＲＴＰデータを着呼側の符号化方式に合わせて符号化する過程と、ＮＮＩ故障検出装置３０が着呼側の符号化方式に合わせて符号化した疑似呼を発呼し、着呼側ネットワークによって疑似呼が転送された転送呼を受信し、疑似呼と転送呼のそれぞれのパケット列をシーケンス番号で対応付けて遅延時間を測定し、該遅延時間に基づいて着呼側ネットワークとの間の故障を検出する過程とを含む。これにより、網間インターフェースにおいて、対向するネットワークとの間の故障を検出することができる。
　以上説明したように本実施形態に係るＮＮＩ故障検出システム１００は、発呼側（パケット転送網２）の符号化方式を例えばＰＣＭＵ、着呼側（パケット転送網５）の符号化方式を例えばＡＭＲの例で説明したが、本発明はこの例に限定されない。発呼側と着呼側の符号化方式が同じであっても本発明を適用することが可能である。発呼側と着呼側の符号化方式が同じ場合、ＲＴＰ変換装置１０は受信した疑似呼と同じＲＴＰデータを再生成（転送呼）すればよい。
　また、ＩＰ電話網に本発明のＮＮＩ故障検出システム１００を適用した例で説明を行ったが、この例に限定されない。本発明は、ＩＰ電話網以外のネットワークに広く適用することが可能である。
　このように、本発明はここでは記載していない様々な実施形態等を含むことは勿論である。したがって、本発明の技術的範囲は上記の説明から妥当な特許請求の範囲に係る発明特定事項によってのみ定められるものである。
１：発呼側端末
２、５：パケット転送網
３、４：ＳＩＰサーバ
６：着呼側端末
１０、２０：ＲＴＰ変換装置
３０：ＮＮＩ故障検出装置
１１：ＩＰヘッダ解析部
１２：符号化部
１３：ＲＴＰ再生成部
３１：パケット列分割部
３２：遅延時間計測部
３３：故障検出部

Claims (5)

  1. 　着呼側ネットワークに対して疑似呼を発呼し、前記着呼側ネットワークによって前記疑似呼が転送された転送呼を受信し、前記疑似呼と前記転送呼のそれぞれのパケット列をシーケンス番号で対応付けて遅延時間を測定し、該遅延時間に基づいて前記着呼側ネットワークとの間の故障を検出するＮＮＩ故障検出装置と、
    　発呼側と着呼側の符号化方式を検出し、前記疑似呼のＲＴＰデータを着呼側の符号化方式に合わせて符号化する際に、前記ＮＮＩ故障検出装置から受信する前記疑似呼のＲＴＰデータのシーケンス番号を前記着呼側ネットワークに送信する前記転送呼のＲＴＰデータに転写するＲＴＰ変換装置と
    　を備えるＮＮＩ故障検出システム。
  2. 　前記ＮＮＩ故障検出装置は、
    　前記転送呼のパケット列をシーケンス番号ごとに分割するパケット列分割部と、
    　前記分割されたパケットに付与されたタイムスタンプ情報と前記転送呼を受信した受信時刻情報の差分を計測する遅延時間計測部と、
    　前記差分が閾値を越えた場合に前記着呼側ネットワークとの間の故障を検出する故障検出部と
    　を備える請求項１に記載のＮＮＩ故障検出システム。
  3. 　前記ＲＴＰ変換装置は、
    　発呼側と着呼側からそれぞれＳＩＰメッセージを受信し、発呼側と着呼側の符号化方式を検出するＩＰヘッダ解析部と、
    　発呼側の前記疑似呼のＲＴＰデータを着呼側の符号化方式に合わせて符号化する符号化部と、
    　発呼側の前記疑似呼のＲＴＰデータのシーケンス番号と、着呼側の符号化方式に合わせて符号化された前記転送呼のＲＴＰデータのシーケンス番号とを対応付けたデータを含むＲＴＰパケットを再生成するＲＴＰ再生成部と
    　を備える請求項１又は２に記載のＮＮＩ故障検出システム。
  4. 　着呼側ネットワークとの間の故障を検出するＮＮＩ故障検出方法であって、
    　ＲＴＰ変換装置が発呼側と着呼側からそれぞれＳＩＰメッセージを受信して発呼側と着呼側の符号化方式を検出し、発呼側の疑似呼のＲＴＰデータを着呼側の符号化方式に合わせて符号化する過程と、
    　ＮＮＩ故障検出装置が着呼側の符号化方式に合わせて符号化した前記疑似呼を発呼し、前記着呼側ネットワークによって前記疑似呼が転送された転送呼を受信し、前記疑似呼と前記転送呼のそれぞれのパケット列をシーケンス番号で対応付けて遅延時間を測定し、該遅延時間に基づいて前記着呼側ネットワークとの間の故障を検出する過程と
    　を含むＮＮＩ故障検出方法。
  5. 　請求項１に記載のＮＮＩ故障検出システムとしてコンピュータを機能させるためのプログラム。
PCT/JP2020/008027 2020-02-27 2020-02-27 Ｎｎｉ故障検出システム、ｎｎｉ故障検出方法、及びプログラム WO2021171481A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2020/008027 WO2021171481A1 (ja) 2020-02-27 2020-02-27 Ｎｎｉ故障検出システム、ｎｎｉ故障検出方法、及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2020/008027 WO2021171481A1 (ja) 2020-02-27 2020-02-27 Ｎｎｉ故障検出システム、ｎｎｉ故障検出方法、及びプログラム

Publications (1)

Publication Number Publication Date
WO2021171481A1 true WO2021171481A1 (ja) 2021-09-02

Family

ID=77491100

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/008027 WO2021171481A1 (ja) 2020-02-27 2020-02-27 Ｎｎｉ故障検出システム、ｎｎｉ故障検出方法、及びプログラム

Country Status (1)

Country Link
WO (1) WO2021171481A1 (ja)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004297287A (ja) * 2003-03-26 2004-10-21 Agilent Technologies Japan Ltd 通話品質評価システム、および、該通話品質評価のための装置
JP2008167318A (ja) * 2006-12-28 2008-07-17 Fujitsu Ltd パケット測定システム、パケット測定プログラム、プローブおよびパケット測定方法
JP2009219075A (ja) * 2008-03-13 2009-09-24 Hitachi Ltd 通信品質監視システム
WO2010032370A1 (ja) * 2008-09-19 2010-03-25 パナソニック株式会社 伝送レート制御装置及び伝送レート制御方法
JP2019161342A (ja) * 2018-03-09 2019-09-19 日本電信電話株式会社 Ｒｔｐ変換装置及びｒｔｐ変換方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004297287A (ja) * 2003-03-26 2004-10-21 Agilent Technologies Japan Ltd 通話品質評価システム、および、該通話品質評価のための装置
JP2008167318A (ja) * 2006-12-28 2008-07-17 Fujitsu Ltd パケット測定システム、パケット測定プログラム、プローブおよびパケット測定方法
JP2009219075A (ja) * 2008-03-13 2009-09-24 Hitachi Ltd 通信品質監視システム
WO2010032370A1 (ja) * 2008-09-19 2010-03-25 パナソニック株式会社 伝送レート制御装置及び伝送レート制御方法
JP2019161342A (ja) * 2018-03-09 2019-09-19 日本電信電話株式会社 Ｒｔｐ変換装置及びｒｔｐ変換方法

Similar Documents

Publication Publication Date Title
US8711857B2 (en) Dynamic facsimile transcoding in a unified messaging platform
CN100566310C (zh) 网络通信设备
US7746845B2 (en) Support for fax and modem in SIP/SIP-T networks and the interworking of these networks with ISUP+/BICC
US9071684B2 (en) Media forking
JP2004088772A (ja) 通話によるｒｔｐデータストリームの監視
US7486665B2 (en) Transport of DTMF tones over VOATM/VOIP networks
KR20060055066A (ko) 브이오아이피 서비스 시스템의 서비스 등급별 시그널링방법 및 그 장치
US20060203801A1 (en) System and method for determining network quality for volP calls
CN110430102B (zh) 基于ims的电话录音方法
WO2012063888A1 (ja) コアネットワークおよび通信システム
JP5242683B2 (ja) インターネットプロトコル（ｉｐ）ドメインでの監視における又はこれに関連する改良
US8031708B2 (en) Methods and apparatus for dual-tone multi-frequency signal analysis within a media over internet protocol network
WO2021171481A1 (ja) Ｎｎｉ故障検出システム、ｎｎｉ故障検出方法、及びプログラム
US8787363B2 (en) Fault isolation constructs for POTS emulation service on an FTTx platform
WO2019172449A1 (ja) Ｒｔｐ変換装置及びｒｔｐ変換方法
WO2012063890A1 (ja) コアネットワークおよび通信システム
US8130662B1 (en) Method and apparatus for providing transcoding in a network
US8102989B1 (en) Apparatus and method for switching from overlap signaling to en bloc signaling in a data network
US7881294B1 (en) Method and apparatus for enabling network based media manipulation
Cisco G.Clear, GSMFR, and G.726 Codecs and Modem and Fax Passthrough for Cisco Universal Gateways
Cisco Interactive Voice Response Version 2.0 on VoIP
US9160842B2 (en) Method for measuring processing delays of voice-over IP devices
US8737575B1 (en) Method and apparatus for transparently recording media communications between endpoint devices
JP2009212908A (ja) 多チャンネル通話録音システム
TWM393936U (en) System for detecting disability on packets

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20921573

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20921573

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP