WO2011052079A1 - ゲートウェイ装置、通信システムおよび通信方法 - Google Patents

ゲートウェイ装置、通信システムおよび通信方法 Download PDF

Info

Publication number
WO2011052079A1
WO2011052079A1 PCT/JP2009/068710 JP2009068710W WO2011052079A1 WO 2011052079 A1 WO2011052079 A1 WO 2011052079A1 JP 2009068710 W JP2009068710 W JP 2009068710W WO 2011052079 A1 WO2011052079 A1 WO 2011052079A1
Authority
WO
WIPO (PCT)
Prior art keywords
call control
communication
bandwidth
packet
gateway device
Prior art date
Application number
PCT/JP2009/068710
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 US13/505,138 priority Critical patent/US8737387B2/en
Priority to PCT/JP2009/068710 priority patent/WO2011052079A1/ja
Priority to EP09850858.3A priority patent/EP2495916A4/en
Priority to JP2011538177A priority patent/JP5214035B2/ja
Publication of WO2011052079A1 publication Critical patent/WO2011052079A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1033—Signalling gateways
    • H04L65/1036—Signalling gateways at the edge
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/59—Providing operational support to end devices by off-loading in the network or by emulation, e.g. when they are unavailable
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]

Definitions

  • the present invention relates to a gateway in a communication system comprising: a terminal that does not have a session control function; a network that performs session control; and a gateway device that is connected to the terminal and performs the session control processing of the terminal.
  • the present invention relates to an apparatus and a communication method.
  • a network (hereinafter referred to as a session control network) that guarantees QoS (Quality of Service) such as communication bandwidth by introducing the concept of a session on an IP (Internet Protocol) network based on best effort has been established.
  • QoS Quality of Service
  • IP Internet Protocol
  • Each terminal needs to support a protocol for session control in order to connect to such a session control network and benefit from session control.
  • existing terminals may not support the session control protocol.
  • the gateway device when the gateway device performs the session control process, it is necessary for the gateway device to determine bandwidth information to be reported to the session control network for target communication during session control. Therefore, for example, in the technique described in Patent Document 1 below, the gateway device identifies flow information identified based on a source address, a destination address, a protocol, a source port number, a destination port number, and the like in communication between existing terminals.
  • a correspondence table with bandwidth information to be declared in session control is stored in advance.
  • the gateway device detects communication targeted for session control proxy processing, the gateway device refers to the correspondence table and searches for bandwidth information corresponding to the flow information of the communication, thereby declaring the bandwidth to be reported to the session control network. Information is determined.
  • the gateway device determines the bandwidth information to be reported to the session control network with reference to the held correspondence table when detecting the communication subject to the session control proxy process. ing.
  • the bandwidth required for communication differs for each application, and even for the same application, the required bandwidth is not necessarily the same. For this reason, there is a problem that it is difficult to report the optimum necessary bandwidth in the method of determining the bandwidth based on the flow information shown in the prior art.
  • the present invention has been made in view of the above, and in the event of performing session control processing for an existing terminal, appropriately assigns a bandwidth value necessary for communication between existing terminals subject to session control to the call control network. It is an object of the present invention to obtain a gateway device, a communication system, and a communication method that can be declared.
  • the present invention connects a call control network that performs call control and a terminal that does not have a call control function, and communicates between the call control network and the terminal.
  • a gateway device that relays the call, proxying call control processing in call control communication, which is communication performed by the terminal via the call control network, and declaring a bandwidth required for the call control communication to the call control network Call control means; and bandwidth adjustment means for obtaining an updated value of the bandwidth of the call control communication based on the communication packet of the call control communication received from the terminal, wherein the call control means obtains the updated value. Declaring to the call control network as a bandwidth required for the call control communication.
  • the gateway device has an effect that a bandwidth value necessary for communication between existing terminals that are subject to session control can be appropriately reported to the call control network.
  • FIG. 1 is a diagram illustrating a configuration example of a communication system according to the first embodiment.
  • FIG. 2 is a diagram illustrating a functional configuration example of the gateway device according to the first embodiment.
  • FIG. 3 is a diagram illustrating an example of the session information table.
  • FIG. 4 is a sequence diagram illustrating an example of a communication procedure according to the first embodiment.
  • FIG. 5 is a diagram illustrating an example of the format of an RTCP Receiver Report packet.
  • FIG. 6 is a diagram illustrating an example of a SIP UPDATE message.
  • FIG. 7 is a flowchart illustrating an example of a method for updating a report band according to the first embodiment.
  • FIG. 8 is a sequence diagram illustrating an example of a communication procedure according to the second embodiment.
  • FIG. 1 is a diagram illustrating a configuration example of a communication system according to the first embodiment.
  • FIG. 2 is a diagram illustrating a functional configuration example of the gateway device according to the first embodiment.
  • FIG. 9 is a diagram illustrating an example of the “RTSP DESCRIBE” message.
  • FIG. 10 is a diagram illustrating an example of an “RTSP 200 OK” response.
  • FIG. 11 is a diagram illustrating a functional configuration example of the gateway device according to the third embodiment.
  • FIG. 12 is a sequence diagram illustrating an example of a communication procedure according to the third embodiment.
  • FIG. 13 is a diagram illustrating an example of a header format of a TCP packet.
  • FIG. 14 is a flowchart illustrating an example of a method for updating a report band according to the third embodiment.
  • FIG. 15 is a diagram illustrating a functional configuration example of the gateway device according to the fourth embodiment.
  • FIG. 16 is a sequence diagram illustrating an example of a communication procedure according to the fourth embodiment.
  • FIG. 1 is a diagram showing a configuration example of a first embodiment of a communication system according to the present invention.
  • the communication system according to the present embodiment is a network that performs call control (session control) and call management (session management) using a plurality of priority classes, as shown in FIG. A control network 4, user networks 5-1 and 5-2 that are existing IP networks that do not perform call control, a gateway device 2-1 that exists between the user network 5-1 and the call control network 4, and a user And a gateway device 2-2 existing between the network 5-2 and the call control network 4.
  • a SIP (Session Initiation Protocol) server 1 that performs call control and call management is connected to the call control network.
  • a terminal 3-1 that is a terminal that does not have a call control function is connected to the user network 5-1
  • a terminal 3-2 that is a terminal that does not have a call control function is connected to the user network 5-2. is doing.
  • the configuration in FIG. 1 is an example, and the number of user networks is not limited to this, and any number may be used, and the number of terminals connected to each user network is not limited to this, and any number may be used.
  • the gateway device is provided between the user network and the call control network 4 for each user network.
  • FIG. 2 is a diagram illustrating a functional configuration example of the gateway device 2 (the gateway device 2-1 or the gateway device 2-2) according to the present embodiment. Note that the gateway device 2-1 and the gateway device 2-2 shown in FIG. 1 have the same configuration, and when these gateway devices are represented representatively without being individually identified, write.
  • the gateway device 2 includes a packet relay unit 21, a session control (call control) unit 22, a packet analysis unit 24, and a bandwidth adjustment unit 25. Further, the gateway device 2 holds a session information table 23 which is a table for holding communication flow conditions (flow information) to be subjected to session control, parameters for session control, and the like.
  • the holding (storing) means for holding the session information table 23 may be provided in the session control unit 22 or may be held separately from the session control unit 22.
  • the packet relay unit 21 performs predetermined reception processing on packets received from the call control network 4 and user networks (user network 5-1, user network 5-2, etc.) to which the packet relay network 21 is connected. A packet is transmitted between the call control network 4 and the user network to which the call control network 4 is connected by performing predetermined transmission processing on the packet transmitted to the user network to which the call is connected. The packet relay unit 21 monitors traffic between the call control network 4 and a user network to which the packet relay unit 21 is connected.
  • the session control unit 22 performs a session control process with the call control network 4 instead of the terminal in the user network to which the session control unit 22 is connected. Any method may be used for the session control, but here, control using SIP (Session Initiation Protocol) is performed as an example.
  • SIP Session Initiation Protocol
  • FIG. 3 is a diagram illustrating an example of the session information table 23.
  • the session information table includes flow conditions and session control parameters. * In the figure indicates that the item may have any value (no constraint).
  • the flow condition includes a source and destination IP address, a protocol, and a source and destination port number.
  • the session control parameters include a destination SIP-URI (Uniform Resource Identifier) indicating a destination on SIP, a media type such as “audio”, “video”, “applicaiton”, a transport protocol, a media format, and a media.
  • the direction and the band initial value are included.
  • the media format indicates the payload number in the case of RTP (Real-time Transport Protocol) / AVP (Audio Video Profile), the MIME subtype in the case of TCP, and the like.
  • the media direction indicates the direction of communication, such as “sendrecv (transmission / reception)”, “sendonly (transmission only)”, “recvonly (reception only)”.
  • the configuration of FIG. 3 is an example, and the configuration of the session information table 23 is not necessarily limited to the configuration of FIG. As long as the flow conditions of the session information table 23 include conditions for specifying the flow to be identified, the session control parameters include control parameters necessary for setting in session control. do it.
  • the packet analysis unit 24 refers to the header of the packet subject to session control, analyzes the communication content, extracts the packet loss rate as information for obtaining the bandwidth value necessary for the communication, and the bandwidth adjustment unit To 25.
  • the bandwidth adjustment unit 25 obtains a report bandwidth to be reported to the call control network 4 based on the packet loss rate, and outputs the obtained report bandwidth to the session control unit 22.
  • FIG. 4 is a sequence diagram illustrating an example of a communication procedure according to the present embodiment.
  • the operation of the present embodiment will be described with reference to FIG. 4 taking as an example the case where terminal 3-1 performs RTP communication addressed to terminal 3-2.
  • the terminal 3-1 transmits the first packet (communication start packet) of RTP communication to the terminal 3-2 (step S11).
  • RTP communication packets are transmitted as UDP (User Datagram Protocol) packets.
  • the gateway device 2-1 when the packet relay unit 21 receives a communication start packet from the terminal 3-1, the relay of the packet is suspended, and the packet is held and transferred to the session control unit 22.
  • the session control unit 22 extracts information corresponding to the flow conditions such as the transmission source IP address, the destination IP address, the protocol, the transmission source port number, and the destination port number from the received communication start packet, and extracts based on the session information table 23
  • the flow condition that matches the acquired information is searched, and a session control parameter corresponding to the flow condition obtained by the search is acquired (step S12).
  • the session control unit 22 of the gateway device 2-1 generates an INVITE message that is a call connection request (session establishment request) based on the acquired session control parameter, and transmits it to the SIP server 1 (step S13).
  • SDP Session Description Protocol
  • the SIP server 1 Upon receiving the INVITE message, the SIP server 1 returns a temporary response “100 Trying” indicating that the process for establishing the session is being performed to the gateway device 2-1 (step S14), and the received INVITE message is transmitted. The data is transferred to the gateway device 2-2 connected to the destination terminal 3-2 (step S15). The gateway device 2-2 returns “100 Trying” to the SIP server 1 (step S16).
  • the gateway device 2-2 sends a “200 OK” response to the SIP server 1 (step S17), and the SIP server 1 sends a “200 OK” response from the gateway device 2-2.
  • a “200 OK” response is transmitted to the gateway device 2-1 (step S18).
  • the session control unit 22 of the gateway device 2-1 detects that the communication path has been established by receiving the “200 OK” response transmitted in step S18 from the SIP server 1, the session control unit 22 resumes packet relay processing.
  • the packet relay unit 21 instructs the packet relay unit 21 to transfer the held packet (the packet transmitted in step S11) to the terminal 3-2 (step S19).
  • RTP and RTCP RTP Control Protocol communications are performed between the terminal 3-1 and the terminal 3-2 via the gateway device 2-1, the SIP server 1, and the gateway device 2-2 (step S20).
  • the packet relay unit 21 relays the RTP / RTCP communication packet transmitted from the terminal 3-1, but the packet relay unit 21
  • the RTP / RTCP communication packet to be relayed received from -1 is passed to the packet analysis unit 24.
  • the packet analysis unit 24 analyzes the packet, and when the received packet is an RTCP Sender Report packet or Receiver Report packet, extracts the packet loss rate from the corresponding report block of the packet and adjusts the bandwidth.
  • the bandwidth adjustment unit 25 obtains a bandwidth to be reported based on the packet loss rate as shown in a report bandwidth update method described later (step S21).
  • FIG. 5 is a diagram showing an example of the format of an RTCP Receiver Report packet.
  • the Receiver Report packet zero or more report blocks are stored after the RTCP header part.
  • the RTCP header part includes a protocol version V (Version number), a padding presence / absence P (Padding), and a report block count RC (Reception Report Count).
  • a packet type (PT) indicating the packet type, a packet length, and a sender SSRC (synchronization source identifier).
  • PT packet type
  • 201 indicating RR (Receiver Report) is stored in PT.
  • report block #i (i is an integer of 1 or more indicating the number of the report block) includes SSRC_i (report target SSRC corresponding to the i-th report block), packet loss rate, cumulative number of lost packets, It consists of the latest received RTP sequence number, packet reception interval jitter, LSR (Last SR (Sender Report) timestamp), and DLSR (Delay since Last SR).
  • SSRC_i report target SSRC corresponding to the i-th report block
  • packet loss rate packet loss rate
  • cumulative number of lost packets It consists of the latest received RTP sequence number, packet reception interval jitter, LSR (Last SR (Sender Report) timestamp), and DLSR (Delay since Last SR).
  • the RTCP Sender Report packet includes zero or more report blocks as in the Receiver Report packet, and the report block format is the same as the report block format of the Receiver Report packet.
  • FIG. 6 is a diagram illustrating an example of a SIP UPDATE message.
  • the report bandwidth for the call control network 4 is dynamically changed based on the packet loss rate. Therefore, even if the packet loss rate increases, the bandwidth of the communication path reserved for the RTP communication can be expanded, so that discarding of the packet of the RTP communication within the call control network 4 can be avoided. it can.
  • the SIP server 1 When the SIP server 1 receives the UPDATE message, it secures the requested bandwidth based on the UPDATE message and transfers the UPDATE message to the gateway device 2-2 (step S23). The gateway device 2-2 secures the requested bandwidth based on the UPDATE message, and transmits a “200 OK” response to the SIP server 1 (step S24). When the SIP server 1 receives the “200 OK” response from the gateway device 2-2, the SIP server 1 transmits a “200 OK” response to the gateway device 2-1 (step S25).
  • RTP and RTCP RTP Control Protocol
  • the gateway device 2-1 obtains the bandwidth to be declared based on the packet loss rate included in the relayed packet in the same manner as in step S21, and changes to the obtained bandwidth using the UPDATE message as in step S22. Request. Note that the report bandwidth may not be changed depending on the value of the packet loss rate.
  • FIG. 7 is a flowchart showing an example of a method for updating a report band according to this embodiment.
  • the packet analysis unit 24 waits for reception of an RTCP Sender Report packet or Receiver Report packet (step S31). Then, when the RTCP Sender Report packet or Receiver Report packet is used, the packet analysis unit 24 extracts the packet loss rate from the received RTCP packet (step S32), and outputs the extracted packet loss rate to the bandwidth adjustment unit 25.
  • the bandwidth adjustment unit 25 determines whether or not the packet loss rate is greater than a certain value A (step S33). If the bandwidth adjustment unit 25 determines that the packet loss rate is greater than A (Yes in step S33), the bandwidth adjustment unit 25 increases the reporting bandwidth (step S34) and returns to step S31. Specifically, the bandwidth adjustment unit 25 obtains the bandwidth increased from the currently declared bandwidth as the bandwidth after the change, notifies the determined bandwidth to the session control unit 22, and the session control unit 22 is notified. Based on the bandwidth, an UPDATE message is generated and transmitted to the SIP server 1. Any method may be used to increase the reporting bandwidth. For example, a method of increasing the bandwidth at a predetermined ratio with respect to the value of the bandwidth currently being declared or a bandwidth where the bandwidth is currently being declared. There is a method of increasing by adding to the above.
  • the bandwidth adjustment unit 25 determines whether or not the packet loss rate is smaller than a certain value B for a certain time (step S35). When it is determined that the packet loss rate is smaller than the constant value B for a certain time (step S35, Yes), the bandwidth adjustment unit 25 decreases the declared bandwidth (step S36) and returns to step S31. Specifically, the bandwidth adjustment unit 25 obtains a bandwidth that has been reduced from the currently declared bandwidth as the bandwidth after the change, notifies the determined bandwidth to the session control unit 22, and the session control unit 22 is notified. Based on the bandwidth, an UPDATE message is generated and transmitted to the SIP server 1. Any method may be used to decrease the reporting bandwidth. For example, a method of decreasing the bandwidth at a predetermined ratio with respect to the value of the bandwidth currently being declared or a bandwidth at which the bandwidth is currently being declared. There is a method of decreasing by subtracting from.
  • step S35 When it is determined that the packet loss rate is not smaller than the constant value B for a certain period of time (the period when the packet loss rate is smaller than the certain value B is smaller than the certain time) (No in step S35), the reporting bandwidth is not changed and step S31 Return to.
  • the packet loss rate is extracted every time an RTCP Receiver Report packet or Sender Report packet is received, and the processing after Step S32 is performed.
  • the Receiver Report packet or Sender Report is used.
  • the processing after step S31 may be performed every predetermined time.
  • the packet analysis unit 24 receives the packet loss every time it receives the Receiver Report packet or the Sender Report packet.
  • the rate is extracted and held, and when the number of held packet loss rates reaches a predetermined number, statistical processing such as averaging processing is performed using the held packet loss rate, and the processed packets
  • the loss rate may be output to the band adjustment unit 25.
  • the bandwidth to be reported is reduced. If it is not desirable to reduce the bandwidth, the processing for reducing the declared bandwidth may not be performed.
  • the bandwidth value to be reported to the call control network 4 is increased when the packet loss rate in the RTCP Sender Report packet and Receiver Report packet is a certain value or more.
  • a decrease in the packet loss rate may not be observed within a certain time due to the influence of packet loss or the like outside the call control network 4. For this reason, if the decrease in the packet loss rate cannot be observed within a certain time after the declared bandwidth is increased in this way, it is determined that the packet loss is outside the call control network 4, and the call control network 4 You may make it report again to the value before increasing the zone value to report.
  • the packet loss rate stored in the RTCP Sender Report packet and Receiver Report packet is used to detect excess or deficiency in the bandwidth value of RTP communication.
  • the present invention is not limited to this. You may make it obtain
  • a necessary bandwidth value is determined by calculating the number of octets transmitted within a predetermined unit time using a plurality of Sender Report packets, and the value is reported to the call control network 4 by an UPDATE message. Also good.
  • the gateway device 2 stores information related to excess or deficiency of the bandwidth value of the communication flow subject to session control proxy, such as statistical information of the communication flow subject to session control proxy notified by NetFlow (registered trademark). If the communication can be obtained by analyzing the contents of the relay packet, the gateway device 2 can obtain the bandwidth to be changed based on the obtained information, and can change the reporting bandwidth as in the present embodiment.
  • the present invention is not limited to this.
  • a control protocol such as H.323 or MEGACO (MEdia GAteway Control) can be used as long as it can perform session control and session management on the IP network in the same manner as SIP.
  • MEGACO MEdia GAteway Control
  • the bandwidth to be changed is obtained as in the present embodiment, and the reporting bandwidth may be changed by updating the reporting bandwidth corresponding to the control protocol to be used.
  • the gateway device 2-1 acting as a proxy for session control of the terminal 3-1 that does not support session control relays a packet subject to session control as a proxy
  • the packet loss rate extracted from the packet relayed by the analysis unit 24 is extracted, and the bandwidth update unit 25 obtains the updated bandwidth value to be reported based on the packet loss rate. Therefore, it is possible to appropriately report to the call control network 4 a bandwidth value necessary for communication between existing terminals that are subject to session control.
  • FIG. FIG. 8 is a sequence diagram showing an example of a communication procedure of the second embodiment of the communication system according to the present invention.
  • the configuration of the communication system of the present embodiment is the same as the configuration of the communication system of the first embodiment, and the configuration of the gateway device of the present embodiment is also the same as that of the gateway device of the first embodiment.
  • elements having the same functions as those in the first embodiment are denoted by the same reference numerals as those in the first embodiment.
  • the session information table 23 of the present embodiment is partially different from the session information table 23 of the first embodiment.
  • the session information table 23 of the present embodiment will be described later.
  • RTP and RTCP communication are performed between the terminal 3-1 and the terminal 3-2.
  • RTSP Real Time Streaming Protocol
  • RTP and RTCP communication may be performed after a communication path is established by RTSP communication.
  • RTSP communication a case will be described in which RTP and RTCP communication is performed after a communication path is established by RTSP communication.
  • a TCP-SYN packet (communication start packet) indicating the start of RTSP communication (RTSP communication) is transmitted from the terminal 3-1 to the terminal 3-2 (step S41).
  • the packet relay unit 21 of the gateway device 2-1 suspends the relay of the packet and passes the packet to the session control unit 22.
  • the session control unit 22 extracts flow information such as a transmission source IP address, a destination IP address, a protocol, a transmission source port number, and a destination port number from the communication start packet, and refers to the session information table 23 to extract the extracted flow information.
  • the session control parameter corresponding to is acquired (step S42).
  • the session control unit 22 generates an INVITE message that is a call connection request based on the acquired session control parameter, and transmits the generated INVITE message to the SIP server 1 (step S43).
  • the SIP server 1 When the SIP server 1 receives the INVITE message, it returns a provisional response “100 Trying” indicating that the process for establishing the session is being performed to the gateway device 2-1 (step S44). The data is transferred to the gateway device 2-2 connected to the destination terminal 3-2 (step S45). The gateway device 2-2 returns “100 Trying” to the SIP server 1 (step S46).
  • the gateway device 2-2 sends a “200 OK” response to the SIP server 1 (step S47), and the SIP server 1 sends a “200 OK” response from the gateway device 2-2.
  • a “200 OK” response is transmitted to the gateway device 2-1 (step S48).
  • the session control unit 22 of the gateway device 2-1 detects that the communication path has been established by receiving the “200 OK” response transmitted in step S47 from the SIP server 1, the session control unit 22 resumes the packet relay processing.
  • the packet relay unit 21 forwards the suspended TCP-SYN packet to the terminal 3-2 (step S49).
  • the terminal 3-2 When the terminal 3-2 receives the TCP-SYN packet, it returns a response TCP-SYN / ACK to the terminal 3-1 (step S50). When the terminal 3-1 receives the TCP-SYN / ACK, it returns a TCP-ACK (step S51). With the above procedure, a TCP connection for the RTSP control channel is established between the terminal 3-1 and the terminal 3-2.
  • the terminal 3-1 transmits an “RTSP DESCRIBE” message requesting acquisition of information such as the media type and bandwidth for the data transmitted by the terminal 3-2 ( Step S52).
  • the terminal 3-2 Upon receiving the “RTSP DESCRIBE” message, the terminal 3-2 transmits an “RTSP 200 OK” response including information such as the media type and bandwidth described in SDP (step S53).
  • step S53 the packet relay unit 21 of the gateway device 2-1 relays the “RTSP 200 OK” response.
  • the packet relay unit 21 passes the packet of the “RTSP 200 OK” response to be relayed to the packet analysis unit 24.
  • the packet analysis unit 24 extracts and holds the QoS parameters necessary for session control from the information described in SDP included in the “RTSP 200 OK” response packet (step S54).
  • the QoS parameters necessary for session control are, for example, band information, media type, attribute, and the like.
  • FIG. 9 is a diagram showing an example of an “RTSP DESCRIBE” message
  • FIG. 10 is a diagram showing an example of an “RTSP 200 OK” response as a response.
  • the terminal 3-1 Upon receiving the “RTSP 200 OK” response, the terminal 3-1 transmits an “RTSP SETUP” message (step S55). Upon receiving the “RTSP SETUP” message, the terminal 3-2 transmits an “RTSP 200 OK” response including information described in SDP to the terminal 3-1 (step S56).
  • the packet relay unit 21 of the gateway device 2-1 suspends the relay, and passes the RTSP 200 OK response to the packet analysis unit 24.
  • the packet analysis unit 24 “RTSP 200 OK”. “From the SDP description part of the response, out of the held QoS parameters, the QoS parameters corresponding to the communication requested to be set by the“ RTSP SETUP ”message in step S41 are extracted, and the extracted QoS parameters are stored in the session control unit 23.
  • the session control unit 23 generates an UPDATE message based on the QoS parameter received from the packet analysis unit 24, and transmits the generated UPDATE message to the SIP server 1 (step S57).
  • the SIP server 1 When the SIP server 1 receives the UPDATE message, it secures the requested bandwidth based on the UPDATE message and transfers the UPDATE message to the gateway device 2-2 (step S58). The gateway device 2-2 secures the requested bandwidth based on the UPDATE message, and transmits a “200 OK” response to the SIP server 1 (step S59). When the SIP server 1 receives the “200 OK” response from the gateway device 2-2, the SIP server 1 transmits a “200 OK” response to the gateway device 2-1 (step S60).
  • the packet relay unit 21 of the gateway device 2-1 When the packet relay unit 21 of the gateway device 2-1 receives the 200 OK response, it transmits the “RTSP 200 OK” response that has been suspended to the terminal 3-1 (step S61). 1 transmits an “RTSP PLAY” message as the start of the communication requesting SETUP in step S55 (step S62), and the terminal 3-2 returns “RTSP 200 OK” (step S63). 1 and the terminal 3-2 can perform communication by streaming.
  • Step S63 the streaming communication between the terminal 3-1 and the terminal 3-2 is performed by RTP / RTCP, and the streaming communication is performed after step S63.
  • the operation of this embodiment at the time of streaming communication is the same as Step S20 to Step S26 of Embodiment 1.
  • the operations of the present embodiment other than those described above are the same as those of the first embodiment.
  • the gateway device 2-1 needs to hold an initial value of bandwidth information related to RTP / RTCP communication as a session control parameter of the session information table.
  • the session information table 23 since the UPDATE message is transmitted based on the bandwidth information included in the “RTSP 200 OK” response using the RTSP control channel before the start of RTP / RTCP communication, the session information table 23 Therefore, it is not necessary to hold the initial value of the band information regarding RTP / RTCP communication.
  • the gateway device 2-1 retains the initial value of the band information related to the control channel for RTSP communication.
  • the gateway device 2-1 that performs the session control processing of the terminal 3-1 that does not support session control performs the “RTSP 200 OK” response in response to the “RTSP DESCRIBE” message.
  • the UPDATE message is generated based on the band information included in the message to secure a band for RTSP communication. Therefore, the same effects as those of the first embodiment can be obtained, and the amount of information that the gateway device 2-1 holds as the session control parameter for RTP / RTCP communication can be reduced.
  • FIG. 11 is a diagram illustrating a functional configuration example of the third embodiment of the gateway device 2a according to the present invention.
  • the gateway device 2a of the present embodiment is the same as that of the first embodiment except that it includes a TCP observation unit 26 and a bandwidth adjustment unit 27 instead of the packet analysis unit 24 and the bandwidth adjustment unit 25 of the first embodiment. Same as 2.
  • the configuration of the communication system of the present embodiment is the same as that of the embodiment except that the gateway device 2-1 and the gateway device 2-2 are replaced with the gateway device 2a-1 and the gateway device 2a-2 having the configuration shown in FIG. It is the same as that of the communication system (refer FIG. 1) of the form 1.
  • the TCP observation unit 26 observes TCP communication that is subject to session control, extracts the reception window size from the TCP packet, and measures RTT (Round Trip Time). Based on the reception window size and the RTT, the bandwidth adjustment unit 27 obtains a bandwidth necessary for TCP communication that is subject to session control.
  • FIG. 12 is a sequence diagram illustrating an example of a communication procedure of the communication system according to the present embodiment.
  • the terminal 3-1 performs TCP communication with the terminal 3-2 will be described.
  • the terminal 3-1 transmits a TCP-SYN packet (step S71).
  • the packet relay unit 21 of the gateway device 2a-1 suspends relaying of the received TCP-SYN packet and passes the TCP-SYN packet to the session control unit 22.
  • the session control unit 22 extracts flow information such as a transmission source IP address, a destination IP address, a protocol, a transmission source port number, and a destination port number from the TCP-SYN packet, and refers to the session information table 23 to extract the extracted flow.
  • a session control parameter corresponding to the information is acquired (step S72).
  • the session control unit 22 generates an INVITE message that is a call connection request based on the acquired session control parameters, and transmits the generated INVITE message to the SIP server 1 (step S73).
  • steps S74 to S80 are the same as steps S44 to S50 in the second embodiment.
  • the packet relay unit 21 of the gateway device 2a-1 relays the TCP-SYN / ACK packet and passes the TCP-SYN / ACK packet to the TCP observation unit 26 in step S80.
  • the TCP observation unit 26 extracts and holds the TCP reception window size and window scale option from the TCP-SYN / ACK packet (step S81).
  • FIG. 13 is a diagram illustrating an example of a header format of a TCP packet.
  • RFC Request For Comments
  • IETF Internet Engineering Task Force
  • the maximum window size can be expressed up to 65535 bytes, so in RFC 1323, the maximum window size can be set to a value larger than 65535 bytes by bit-shifting the window size value as a window scale option. I am doing so. Therefore, the actual window size can be obtained using the window size (TCP reception window size) included in the standard header portion and this shift count.
  • the TCP reception window size may be obtained based on the window size value included in the TCP packet header.
  • the terminal 3-1 When the terminal 3-1 receives the TCP-SYN / ACK packet, it transmits the TCP-ACK packet to the terminal 3-2 (step S82). Thus, the TCP 3-way handshake between the terminal 3-1 and the terminal 3-2 is completed, and data transmission / reception is performed between the terminal 3-1 and the terminal 3-2 (step S83).
  • the packet relay unit 21 transmits the received data, but simultaneously passes the received data to the TCP observation unit 26, and the TCP observation unit 26 transmits the TCP traffic.
  • Observation is performed (step S84). Specifically, the TCP observation unit 26 extracts the TCP reception window size on the terminal 3-2 side from the TCP-ACK packet transmitted from the terminal 3-2 to the terminal 3-1 in the TCP traffic. Also, the TCP observation unit 26, among the TCP traffic, a TCP packet transmitted from the terminal 3-1 to the terminal 3-2 and a TCP ACK packet transmitted from the terminal 3-2 to the terminal 3-1 as a response thereto Based on the above, the RTT is measured. The TCP observation unit 26 passes the held window scale option, the extracted TCP reception window size, and the measured RTT to the bandwidth adjustment unit 27.
  • the bandwidth adjustment unit 27 obtains the maximum bandwidth based on the window scale option, the TCP reception window size, and the RTT, and when the maximum bandwidth is larger than the bandwidth declared in step S73, the changed The value obtained by increasing the declared bandwidth value is obtained as the bandwidth value.
  • the bandwidth adjustment unit 27 decreases the bandwidth value that has been declared as the bandwidth value after the change when the maximum bandwidth is smaller than the bandwidth that has been declared and the difference between the bandwidth that has been declared and the maximum bandwidth is greater than a predetermined value X. Find the value. Then, the bandwidth adjustment unit 27 passes the changed bandwidth value to the session control unit 22.
  • the session control unit 22 generates an UPDATE message reflecting the changed bandwidth value received from the bandwidth adjustment unit 27 as a bandwidth for reporting, and transmits the generated UPDATE message to the SIP server 1 (step S85).
  • the subsequent steps S86 to S88 are the same as steps S23 to S25 of the first embodiment.
  • step S88 data transmission / reception is continued (step S89), and the gateway device 2a-1 observes TCP traffic in the same manner as in step 84, and when the maximum bandwidth is larger than the declared bandwidth or When the maximum bandwidth is smaller than the bandwidth and the difference between the declared bandwidth and the maximum bandwidth is greater than the predetermined value X, the bandwidth to be declared is changed by performing the same processing as in steps S85 to S88.
  • the operations of the present embodiment other than those described above are the same as those of the first embodiment.
  • FIG. 14 is a flowchart showing an example of a method for updating a report band according to this embodiment.
  • the TCP observation unit 26 receives the TCP-SYN / ACK packet at the time of establishing the TCP connection between the terminal 3-1 and the terminal 3-2 from the packet relay unit 21, and extracts the value of the window scale option from the TCP-SYN / ACK packet. And held inside (step S91).
  • the TCP observation unit 26 then transmits a TCP packet transmitted from the terminal 3-1 to the terminal 3-2 over the TCP connection and a TCP ACK packet transmitted from the terminal 3-2 to the terminal 3-1 as a response to the TCP packet.
  • RTT is measured based on (step S92).
  • the window size value included in the TCP ACK packet transmitted from the terminal 3-2 is extracted (step S92).
  • the TCP observation unit 26 determines whether or not the maximum bandwidth is larger than the bandwidth already reported to the call control network 4 (step S94). It is assumed that the TCP observation unit 26 acquires and holds the bandwidth that has been reported to the call control network 4 from the session control unit 22. When the maximum bandwidth is larger than the declared bandwidth (Yes in step S94), the TCP observation unit 26 obtains a value obtained by increasing the declared bandwidth as the changed bandwidth, and passes the changed bandwidth to the session control unit 22. (Step S95). The session control unit 22 generates an UPDATE message based on the changed band, transmits the generated UPDATE message to the SIP server 1 (step S95), and returns to step S92.
  • the TCP observation unit 26 determines whether or not the difference between the reported bandwidth and the maximum bandwidth is greater than a predetermined value X (step S96). When the difference between the declared bandwidth and the maximum bandwidth is larger than the predetermined value X (step S96, Yes), the TCP observation unit 26 obtains a value obtained by reducing the declared bandwidth as the changed bandwidth, and the changed bandwidth. Is transferred to the session control unit 22 (step S97). The session control unit 22 generates an UPDATE message based on the changed band, transmits the generated UPDATE message to the SIP server 1 (step S97), and returns to step S92.
  • step S96 If the difference between the declared bandwidth and the maximum bandwidth is not greater than the predetermined value X (No in step S96), the bandwidth to be reported is not changed and the process returns to step S92.
  • any method may be used as a method of obtaining the changed bandwidth in step S95 and step S97.
  • the obtained maximum bandwidth is the changed bandwidth.
  • the changed band may be obtained by adding a fixed value (subtracting in the case of step S97) to the declared band that is increased at a constant rate (decreasing in the case of step S97).
  • the bandwidth to be reported is reduced.
  • the bandwidth is reduced depending on the application or system used. If it is not desirable to do so, the processing for reducing the bandwidth to be reported may not be performed.
  • the method of updating the bandwidth value on the TCP connection generation side has been described.
  • the opposite TCP node The bandwidth to be reported may be changed based on the TCP reception window size of the terminal 3-1) and the RTT.
  • the gateway device can reduce information on the bandwidth value of the session information table held.
  • the TCP observation unit 26 extracts the window scale option from the TCP-SYN / ACK packet at the time of establishing the TCP connection, and is included in the TCP ACK packet transmitted from the terminal 3-2.
  • the window size value is extracted, and the RTT is measured based on the packet transmitted between the terminal 3-1 and the terminal 3-2.
  • the TCP observation unit 26 calculates the changed bandwidth based on the maximum bandwidth obtained based on the window scale option, the window size value, and the RTT, and the session control unit 22 determines the changed bandwidth as the call control network. Declare to 4. Therefore, when performing communication using TCP, it is possible to appropriately declare to the call control network 4 a bandwidth value necessary for communication between existing terminals that are subject to session control.
  • FIG. FIG. 15 is a diagram illustrating a functional configuration example of the gateway device 2b according to the fourth embodiment of the present invention.
  • the gateway device 2b according to the present embodiment is the same as the gateway device 2 according to the first embodiment except that it includes a bandwidth measuring unit 28 instead of the packet analysis unit 24 and the bandwidth adjusting unit 25 according to the first embodiment.
  • the configuration of the communication system of the present embodiment is the same as that of the embodiment except that the gateway device 2-1 and the gateway device 2-2 are replaced with the gateway device 2b-1 and the gateway device 2b-2 having the configuration shown in FIG. It is the same as that of the communication system (refer FIG. 1) of the form 1.
  • the bandwidth measuring unit 28 measures the communication bandwidth (transmission bandwidth) of communication that is subject to session control. Any method may be used for measuring the transmission band. For example, the band measuring unit 28 accumulates and accumulates the data amount of the target communication of the session control proxy process relayed by the relay packet 21 within a predetermined unit time. There is a method of measuring the transmission band by dividing the data amount by unit time. Since the bandwidth measuring unit 28 obtains the transmission bandwidth measured in this way as an updated value of the bandwidth to be reported to the call control network 4, the bandwidth measuring unit 28 functions as a bandwidth adjusting unit in the same manner as the bandwidth adjusting unit 25 in the first embodiment. Have.
  • FIG. 16 is a sequence diagram illustrating an example of a communication procedure of the communication system according to the present embodiment.
  • this communication may be any type of communication as long as it is a communication that transmits a packet including the following flow information, and may be, for example, TCP communication or UDP communication.
  • the terminal 3-1 transmits a communication start packet, which is the first packet of communication with the terminal 3-2 (step S101).
  • the gateway device 2b-1 when the packet relay unit 21 receives the communication start packet from the terminal 3-1, the relay of the packet is suspended, and the packet is held and transferred to the session control unit 22.
  • the session control unit 22 extracts information corresponding to the flow conditions such as the transmission source IP address, the destination IP address, the protocol, the transmission source port number, and the destination port number from the received communication start packet, and extracts based on the session information table 23
  • the flow condition that matches the acquired information is searched, and a session control parameter corresponding to the flow condition obtained by the search is acquired (step S102).
  • steps S103 to S108 are performed.
  • the session control unit 22 of the gateway device 2b-1 detects that the communication path has been established by receiving the “200 OK” response transmitted in step S108 from the SIP server 1, the session control unit 22 resumes the packet relay process.
  • the packet relay unit 21 instructs the packet relay unit 21 to transfer the suspended packet (the packet transmitted in step S101) to the terminal 3-2 (step S109).
  • step S110 communication is performed between the terminal 3-1 and the terminal 3-2 (step S110).
  • the packet relay unit 21 relays the communication packet between the terminal 3-1 and the terminal 3-2, and the band measuring unit 28 transmits (terminal) based on the communication packet.
  • the bandwidth is measured and notified to the session control unit 22 (step S111).
  • the session control unit 22 of the gateway device 2b-1 generates an UPDATE message using the transmission band notified from the band measurement unit 28 as a band for declaring, and transmits the generated UPDATE message to the SIP server 1 (step S112). . Thereafter, Steps S113 to S115 are performed in the same manner as Steps S23 to S25 of the first embodiment. As a result, a communication path in which a bandwidth corresponding to the communication is secured is established on the call control network 4.
  • the terminals 3-1 and 3-2 continue to communicate (step S116), and during that time, the band measuring unit 28 measures the transmission band based on the communication packet in the same manner as described above, and the session control unit 22 The UPDATE message is transmitted based on the transmission band.
  • the operations of the present embodiment other than those described above are the same as those of the first embodiment.
  • the measured transmission band is not different from the declared band, or if the difference between the measured transmission band and the declared band is within a predetermined range, transmission of an UPDATE message based on the transmission band is performed. It may not be implemented.
  • the band measuring unit 28 may measure the transmission band at every predetermined time interval.
  • the band measuring unit 28 may perform statistical processing such as averaging processing using a plurality of measured transmission bands, and pass the processed transmission band to the session control unit 22.
  • the communication start side (gateway device 2b-1) measures the transmission bandwidth and updates the bandwidth
  • the communication reception side (gateway device 2b-2) similarly
  • the transmission (transmission from the terminal 3-2) band may be measured, and the reported band may be updated based on the transmission band.
  • the gateway device can reduce information on the bandwidth value of the session information table held.
  • the bandwidth measuring unit 28 of the gateway device 2b-1 measures the transmission bandwidth based on the relayed communication packet, and the session control unit 22 determines the call control network 4 based on the transmission bandwidth.
  • An UPDATE message for updating the bandwidth to be declared is sent. Therefore, the same effect as in the first embodiment can be obtained without analyzing the contents of the communication packet.
  • the gateway device, the communication system, and the communication method according to the present invention are useful for a communication system including a gateway device that performs session control processing for a terminal, and in particular, a communication system that handles communication under various flow conditions. Suitable for
  • SIP server 2 2-1, 2-2, 2a, 2a-1, 2a-2, 2b-1, 2b-2 Gateway device 3-1, 3-2 terminal 4 Call control network 5-1, 5- 2 User network 21 Packet relay unit 22 Session control unit 23 Session information table 24 Packet analysis unit 25, 27 Band adjustment unit 26 TCP observation unit 28 Band measurement unit

Landscapes

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

Abstract

　呼制御ネットワークと呼制御機能を備えない端末間の通信を中継するゲートウェイ装置であって、端末が呼制御ネットワーク経由で行なう呼制御通信の呼制御処理を代行し、呼制御通信が必要とする帯域を呼制御ネットワークへ申告するセッション制御部２２と、端末から受信した呼制御通信の通信パケットに基づいて、呼制御通信の帯域の更新値を求める帯域調整部２５と、を備え、セッション制御部２２は、前記更新値を呼制御通信が必要とする帯域として呼制御ネットワークへ申告する。

Description

ゲートウェイ装置、通信システムおよび通信方法
　本発明は、セッション制御機能を備えない端末と、セッション制御を実施するネットワークと、前記端末および前記ネットワークに接続し、前記端末のセッション制御処理を代行するゲートウェイ装置と、を備える通信システムにおけるそのゲートウェイ装置および通信方法に関する。
　近年、ベストエフォートを基本とするＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ：インターネットプロトコル）ネットワーク上で、セッションの概念を導入し通信帯域等のＱｏＳ（Ｑｕａｌｉｔｙ　ｏｆ　Ｓｅｒｖｉｃｅ）を保証するネットワーク（以下、セッション制御ネットワークという）が構築されている。各端末は、このようなセッション制御ネットワークに接続してセッション制御による恩恵を受けるためには、セッション制御のためのプロトコルをサポートする必要がある。しかし、既存の端末は、セッション制御プロトコルに対応していない場合がある。
　このため、セッション制御プロトコルに対応していない既存端末とセッション制御ネットワークとの間に存在するゲートウェイ装置が、既存端末とセッション制御ネットワークの間のセッション制御処理を代行する方法が提案されている（たとえば、下記特許文献１参照）。
　また、ゲートウェイ装置がセッション制御処理を代行する場合、ゲートウェイ装置が、セッション制御時に対象の通信用にセッション制御ネットワークに申告する帯域情報を決定する必要がある。したがって、たとえば、下記特許文献１に記載の技術では、ゲートウェイ装置が、既存端末間の通信における送信元アドレス、宛先アドレス、プロトコル、送信元ポート番号、宛先ポート番号等に基づいて識別するフロー情報とセッション制御で申告する帯域情報との対応表を内に予め保持する。そして、ゲートウェイ装置は、セッション制御代行処理の対象となる通信を検出した際に、対応表を参照し、その通信のフロー情報に対応する帯域情報を検索することで、セッション制御ネットワークに申告する帯域情報を決定している。
国際公開第２００６／０５１５９４号
　しかしながら、上記従来の技術によれば、ゲートウェイ装置は、セッション制御代行処理の対象となる通信を検出した際に、保持している対応表を参照してセッション制御ネットワークに申告する帯域情報を決定している。一方、通信に必要な帯域はアプリケーション毎に異なり、さらに同一のアプリケーションであっても必要な帯域は必ずしも同一とは限らない。そのため、従来の技術で示されているフロー情報に基づいて帯域を決定する方法では、最適な必要帯域の申告を行うことが困難である、という問題があった。
　本発明は、上記に鑑みてなされたものであって、既存端末のセッション制御処理を代行する場合に、セッション制御の対象となる既存端末間の通信に必要な帯域値を呼制御ネットワークへ適切に申告することができるゲートウェイ装置、通信システムおよび通信方法を得ることを目的とする。
　上述した課題を解決し、目的を達成するために、本発明は、呼制御を実施する呼制御ネットワークと、呼制御機能を備えない端末と、接続し、前記呼制御ネットワークと前記端末間の通信を中継するゲートウェイ装置であって、前記端末が前記呼制御ネットワーク経由で行なう通信である呼制御通信における呼制御処理を代行し、前記呼制御通信が必要とする帯域を前記呼制御ネットワークへ申告する呼制御手段と、前記端末から受信した前記呼制御通信の通信パケットに基づいて、前記呼制御通信の帯域の更新値を求める帯域調整手段と、を備え、前記呼制御手段は、前記更新値を前記呼制御通信が必要とする帯域として前記呼制御ネットワークへ申告する、ことを特徴とする。
　本発明にかかるゲートウェイ装置は、セッション制御の対象となる既存端末間の通信に必要な帯域値を適切に呼制御ネットワークへ申告することができる、という効果を奏する。
図１は、実施の形態１の通信システムの構成例を示す図である。 図２は、実施の形態１のゲートウェイ装置の機能構成例を示す図である。 図３は、セッション情報テーブルの一例を示す図である。 図４は、実施の形態１の通信手順の一例を示すシーケンス図である。 図５は、ＲＴＣＰのReceiver　Reportパケットのフォーマットの一例を示す図である。 図６は、ＳＩＰのＵＰＤＡＴＥメッセージの一例を示す図である。 図７は、実施の形態１の申告帯域の更新方法の一例を示すフローチャートである。 図８は、実施の形態２の通信手順の一例を示すシーケンス図である。 図９は、“ＲＴＳＰ　ＤＥＳＣＲＩＢＥ”メッセージの一例を示す図である。 図１０は、“ＲＴＳＰ　２００　ＯＫ”レスポンスの一例を示す図である。 図１１は、実施の形態３のゲートウェイ装置の機能構成例を示す図である。 図１２は、実施の形態３の通信手順の一例を示すシーケンス図である。 図１３は、ＴＣＰパケットのヘッダフォーマットの一例を示す図である。 図１４は、実施の形態３の申告帯域の更新方法の一例を示すフローチャートである。 図１５は、実施の形態４のゲートウェイ装置の機能構成例を示す図である。 図１６は、実施の形態４の通信手順の一例を示すシーケンス図である。
　以下に、本発明にかかるゲートウェイ装置、通信システムおよび通信方法の実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態によりこの発明が限定されるものではない。
実施の形態１．
　図１は、本発明にかかる通信システムの実施の形態１の構成例を示す図である。図１に示すように、本実施の形態の通信システムは、図１に示すように、複数の優先クラスを用いた呼制御（セッション制御）および呼管理（セッション管理）を実施するネットワークである呼制御ネットワーク４と、呼制御を実施しない既存のＩＰネットワークであるユーザネットワーク５－１，５－２と、ユーザネットワーク５－１と呼制御ネットワーク４の間に存在するゲートーェイ装置２－１と、ユーザネットワーク５－２と呼制御ネットワーク４の間に存在するゲートーェイ装置２－２と、で構成される。
　呼制御ネットワークには、呼制御および呼管理を行なうＳＩＰ（Session　Initiation　Protocol）サーバ１が接続している。また、ユーザネットワーク５－１には、呼制御機能を有しない端末である端末３－１が接続し、ユーザネットワーク５－２には、呼制御機能を有しない端末である端末３－２が接続している。なお、図１の構成は例示であり、ユーザネットワークの個数はこれに限らず、いくつでもよく、また各ユーザネットワークに接続する端末の台数もこれに限らず、何台でもよい。なお、ゲートウェイ装置は、ユーザネットワークごとにユーザネットワークと呼制御ネットワーク４間に備えることとする。
　図２は、本実施の形態のゲートウェイ装置２（ゲートウェイ装置２－１またはゲートウェイ装置２－２）の機能構成例を示す図である。なお、図１に示したゲートウェイ装置２－１とゲートウェイ装置２－２は、同様の構成を有することとし、これらのゲートウェイ装置を、個別を識別せず代表して表記する場合はゲートウェイ装置２と表記する。
　ゲートウェイ装置２は、パケット中継部２１と、セッション制御（呼制御）部２２と、パケット解析部２４と、帯域調整部２５と、を備えている。また、ゲートウェイ装置２は、セッション制御を行う対象となる通信フローの条件（フロー情報）とセッション制御のためのパラメータと保持するテーブルであるセッション情報テーブル２３を保持している。セッション情報テーブル２３を保持するための保持（記憶）手段は、セッション制御部２２が備えることとしてもよいし、セッション制御部２２とは別に記憶手段を保持するようにしてもよい。
　パケット中継部２１は、呼制御ネットワーク４および自身が接続するユーザネットワーク（ユーザネットワーク５－１、ユーザネットワーク５－２等）から受信したパケットに対する所定の受信処理を行い、また呼制御ネットワーク４および自身が接続するユーザネットワークへ送信するパケットに対して所定の送信処理を行うことにより、呼制御ネットワーク４と自身が接続するユーザネットワークとの間のパケットを中継する。また、パケット中継部２１は、呼制御ネットワーク４と自身が接続するユーザネットワークとの間のトラフィックの監視を行う。
　セッション制御部２２は、自身が接続するユーザネットワーク内の端末に代わり呼制御ネットワーク４との間のセッション制御処理を行う。セッション制御の方法はどのような方法を用いてもよいが、ここでは一例としてＳＩＰ（Session　Initiation　Protocol）を用いた制御を実施する。
　図３は、セッション情報テーブル２３の一例を示す図である。図３に示すように、セッション情報テーブルは、フロー条件とセッション制御パラメータとで構成される。図中の＊は、その項目についてはどのような値でもよい（制約が無い）ことを示す。フロー条件は、送信元および宛先のＩＰアドレスと、プロトコルと、送信元および宛先のポート番号と、を含む。セッション制御パラメータは、ＳＩＰ上での宛先を示す宛先ＳＩＰ－ＵＲＩ（Uniform　Resource　Identifier）と、“ａｕｄｉｏ”，“ｖｉｄｅｏ”，“ａｐｐｌｉｃａｉｔｏｎ”等のメディアタイプと、トランスポートプロトコルと、メディアフォーマットと、メディア方向と、帯域初期値と、を含む。メディアフォーマットは、ＲＴＰ（Real-time　Transport　Protocol）／ＡＶＰ（Audio　Video　Profile）の場合のペイロード番号，ＴＣＰの場合のＭＩＭＥサブタイプなどをあらわす。メディア方向は、“ｓｅｎｄｒｅｃｖ（送受信）”，“ｓｅｎｄｏｎｌｙ（送信のみ）”，“ｒｅｃｖｏｎｌｙ（受信のみ）”等、通信の方向を示す。
　なお、図３の構成は一例であり、セッション情報テーブル２３の構成は図３の構成に限定する必要はない。セッション情報テーブル２３のフロー条件としては、識別対象のフローを特定するための条件が含まれていればよく、また、セッション制御パラメータは、セッション制御で設定するために必要な制御パラメータを含むようにすればよい。
　パケット解析部２４は、セッション制御の対象となるパケットのヘッダ等を参照して通信内容を解析し、その通信に必要な帯域値を求めるための情報として、パケット損失率を抽出し、帯域調整部２５へ出力する。帯域調整部２５は、パケット損失率に基づいて呼制御ネットワーク４へ申告する申告帯域を求め、求めた申告帯域をセッション制御部２２へ出力する。
　つぎに、本実施の形態の動作を説明する。図４は、本実施の形態の通信手順の一例を示すシーケンス図である。図４を用いて、端末３－１が端末３－２宛のＲＴＰ通信を行う場合を例に本実施の形態の動作を説明する。
　まず端末３－１は、端末３－２宛に、ＲＴＰ通信の最初のパケット（通信開始パケット）を送信する（ステップＳ１１）。なお、ＲＴＰ通信のパケットはＵＤＰ（User　Datagram　Protocol）パケットとして送信される。
　ゲートウェイ装置２－１では、パケット中継部２１が端末３－１から通信開始パケットを受信すると、当該パケットの中継を保留し、そのパケットを保持するとともにセッション制御部２２に渡す。セッション制御部２２は、受信した通信開始パケットから送信元ＩＰアドレス、宛先ＩＰアドレス、プロトコル、送信元ポート番号、宛先ポート番号等フロー条件に対応する情報を抽出し、セッション情報テーブル２３に基づいて抽出した情報と一致するフロー条件を検索し、検索して得られたフロー条件に対応するセッション制御パラメータを取得する（ステップＳ１２）。
　そして、ゲートウェイ装置２－１のセッション制御部２２は、取得したセッション制御パラメータに基づいて呼接続要求（セッション確立要求）であるＩＮＶＩＴＥメッセージを生成し、ＳＩＰサーバ１へ送信する（ステップＳ１３）。具体的には、呼制御ネットワーク４へ申告するＱｏＳパラメータとして、取得したセッション制御パラメータの値をＳＤＰ（Session　Description　Protocol）で記述したＳＤＰ情報を生成し、生成したＳＤＰ情報をＩＮＶＩＴＥメッセージに含めて送信する。
　ＳＩＰサーバ１は、ＩＮＶＩＴＥメッセージを受信すると、セッション確立ための処理を実施中であること示す暫定応答“１００　Ｔｒｙｉｎｇ”をゲートウェイ装置２－１へ返信し（ステップＳ１４）、受信したＩＮＶＩＴＥメッセージを通信の宛先の端末３－２に接続するゲートウェイ装置２－２へ転送する（ステップＳ１５）。ゲートウェイ装置２－２は、“１００　Ｔｒｙｉｎｇ”をＳＩＰサーバ１へ返信する（ステップＳ１６）。
　ゲートウェイ装置２－２は、セッション確立の処理が正常に終了すると“２００　ＯＫ”レスポンスをＳＩＰサーバ１に送信し（ステップＳ１７）、ＳＩＰサーバ１は、ゲートウェイ装置２－２から“２００　ＯＫ”レスポンスを受信すると“２００　ＯＫ”レスポンスをゲートウェイ装置２－１へ送信する（ステップＳ１８）。
　ゲートウェイ装置２－１のセッション制御部２２は、ステップＳ１８で送信された“２００　ＯＫ”レスポンスをＳＩＰサーバ１から受信することにより通信路が確立されたことを検知すると、パケットの中継処理を再開するようパケット中継部２１に指示し、パケット中継部２１は、保留していたパケット（ステップＳ１１で送信されたパケット）を端末３－２に転送する（ステップＳ１９）。
　その後、端末３－１と端末３－２の間で、ゲートウェイ装置２－１、ＳＩＰサーバ１およびゲートウェイ装置２－２を経由したＲＴＰおよびＲＴＣＰ（ＲＴＰ　Control　Protocol）通信が行われる（ステップＳ２０）。
　ステップＳ２０の通信が行われている間、ゲートウェイ装置２－１では、パケット中継部２１が端末３－１から送信されたＲＴＰ／ＲＴＣＰの通信パケットを中継するが、パケット中継部２１は、端末３－１から受信した中継対象のＲＴＰ／ＲＴＣＰの通信パケットをパケット解析部２４に渡す。そして、パケット解析部２４は、そのパケットの解析を行い、受信したパケットがＲＴＣＰのSender　ReportパケットまたはReceiver　Reportパケットである場合に、そのパケットの対応するレポートブロックからパケット損失率を抽出して帯域調整部２５に渡し、帯域調整部２５が、後述の申告帯域の更新方法で示すようにパケット損失率に基づいて申告する帯域を求める（ステップＳ２１）。
　図５は、ＲＴＣＰのReceiver　Reportパケットのフォーマットの一例を示す図である。Receiver　Reportパケットには、ＲＴＣＰヘッダ部の後に、０個以上のレポートブロックが格納される。図５に示すように、ＲＴＣＰヘッダ部は、プロトコルバージョンを表すＶ（Version　number）と、パディングの有無を示すＰ（Padding）と、そのパケットに含まれるレポートブロック数を示すＲＣ（Reception　Report　Count）と、パケットの種別を示すＰＴ（Packet　Type）と、パケット長と、送信者ＳＳＲＣ（synchronization　source　identifier）と、で構成される。Receiver　Reportパケットの場合、ＰＴには、ＲＲ（Receiver　Report）を示す２０１が格納される。
　また、レポートブロック＃ｉ（ｉはレポートブロックの番号を示す１以上の整数）は、ＳＳＲＣ＿ｉ（ｉ番目のレポートブロックに対応するレポート対象のＳＳＲＣ）と、パケット損失率と、累積損失パケット数と、最新受信ＲＴＰシーケンス番号と、パケット受信間隔ジッタと、ＬＳＲ（Last　ＳＲ（Sender　Report）　timestamp）と、ＤＬＳＲ（Delay　since　Last　ＳＲ）と、で構成される。
　ＲＴＣＰのSender　Reportパケットは、Receiver　Reportパケットと同様に０個以上のレポートブロックを含み、レポートブロックのフォーマットはReceiver　Reportパケットのレポートブロックのフォーマットと同様である。
　帯域調整部２５は、ステップＳ２１で求めた帯域をセッション制御部２２へ渡し、セッション制御部２２は、申告する帯域を帯域調整部２５が求めた帯域に変更するためのＵＰＤＡＴＥメッセージをＳＩＰサーバ１へ送信する（ステップＳ２２）。図６は、ＳＩＰのＵＰＤＡＴＥメッセージの一例を示す図である。図６に示したＵＰＤＡＴＥメッセージでは、最下段の“ｂ＝ＡＳ：２００”が変更後の申告帯域を示しており、この例では２００ｋｂｐｓへの変更を要求している。
　このように本実施の形態ではパケット損失率に基づいて、動的に呼制御ネットワーク４に対する申告帯域を変更する。したがって、パケット損失率が上昇しても、当該ＲＴＰ通信用に確保された通信路の帯域を拡大することができるため、呼制御ネットワーク４内での当該ＲＴＰ通信のパケットの廃棄を回避することができる。
　ＳＩＰサーバ１は、ＵＰＤＡＴＥメッセージを受信すると、ＵＰＤＡＴＥメッセージに基づいて要求された帯域を確保し、ＵＰＤＡＴＥメッセージをゲートウェイ装置２－２へ転送する（ステップＳ２３）。ゲートウェイ装置２－２は、ＵＰＤＡＴＥメッセージに基づいて要求された帯域を確保し、“２００　ＯＫ”レスポンスをＳＩＰサーバ１に送信する（ステップＳ２４）。ＳＩＰサーバ１は、ゲートウェイ装置２－２から“２００　ＯＫ”レスポンスを受信すると、“２００　ＯＫ”レスポンスをゲートウェイ装置２－１へ送信する（ステップＳ２５）。
　その後、端末３－１と端末３－２の間で、ゲートウェイ装置２－１、ＳＩＰサーバ１およびゲートウェイ装置２－２を経由したＲＴＰおよびＲＴＣＰ（ＲＴＰ　Control　Protocol）通信が再び行われる（ステップＳ２６）。その際、ゲートウェイ装置２－１は、ステップＳ２１と同様に中継するパケットに含まれるパケット損失率に基づいて申告する帯域を求め、ステップＳ２２と同様にＵＰＤＡＴＥメッセージを用いて、求めた帯域への変更を要求する。なお、パケット損失率の値によっては、申告帯域を変更しない場合もある。
　図７は、本実施の形態の申告帯域の更新方法の一例を示すフローチャートである。まず、パケット解析部２４は、ＲＴＣＰのSender　ReportパケットまたはReceiver　Reportパケットの受信を待機する（ステップＳ３１）。そして、パケット解析部２４は、ＲＴＣＰのSender　ReportパケットまたはReceiver　Reportパケットをすると、受信したＲＴＣＰパケットからパケット損失率を抽出し（ステップＳ３２）、抽出したパケット損失率を帯域調整部２５へ出力する。
　帯域調整部２５は、パケット損失率が、一定値Ａより大きいな否かを判断する（ステップＳ３３）。帯域調整部２５は、パケット損失率がＡより大きいと判断した場合（ステップＳ３３　Ｙｅｓ）は、申告帯域を増加させ（ステップＳ３４）、ステップＳ３１へ戻る。具体的には、帯域調整部２５は、現在申告している帯域より増加させた帯域を変更後の帯域として求め、求めた帯域をセッション制御部２２へ通知し、セッション制御部２２は通知された帯域に基づいてＵＰＤＡＴＥメッセージを生成してＳＩＰサーバ１へ送信する。なお、申告帯域を増加させる方法は、どのような方法でもよいが、たとえば、現在申告している帯域の値に対して所定の比率で増加させる方法や、所定の値を現在申告している帯域に加えることにより増加させる方法等がある。
　パケット損失率がＡ以下であると判断した場合（ステップＳ３４　Ｎｏ）、帯域調整部２５は、一定時間の間パケット損失率が一定値Ｂより小さいか否かを判断する（ステップＳ３５）。一定時間の間パケット損失率が一定値Ｂより小さいと判断した場合（ステップＳ３５　Ｙｅｓ）、帯域調整部２５は申告帯域を減少させ（ステップＳ３６）ステップＳ３１へ戻る。具体的には、帯域調整部２５は、現在申告している帯域より減少させた帯域を変更後の帯域として求め、求めた帯域をセッション制御部２２へ通知し、セッション制御部２２は通知された帯域に基づいてＵＰＤＡＴＥメッセージを生成してＳＩＰサーバ１へ送信する。なお、申告帯域を減少させる方法は、どのような方法でもよいが、たとえば、現在申告している帯域の値に対して所定の比率で減少させる方法や、所定の値を現在申告している帯域から減ずることにより減少させる方法等がある。
　一定時間の間パケット損失率が一定値Ｂより小さくない（パケット損失率が一定値Ｂより小さい期間が一定時間より小さい）と判断した場合（ステップＳ３５　Ｎｏ）、申告帯域は変更せずにステップＳ３１へ戻る。
　なお、図７に示した例では、ＲＴＣＰのReceiver　ReportパケットまたはSender　Reportパケットを受信するたびにパケット損失率を抽出して、ステップＳ３２以降の処理を行うようにしたが、Receiver　ReportパケットまたはSender　Reportパケットの送信頻度が高い場合等には、所定の時間ごとにステップＳ３１以降の処理を行ってもよい。
　また、パケット損失率の短期的な変動が大きい場合や頻繁に帯域の変更を行うことが好ましくない場合等には、パケット解析部２４は、Receiver　ReportパケットまたはSender　Reportパケットを受信するたびにパケット損失率を抽出して保持し、保持しているパケット損失率が所定の個数になった場合に、保持しているパケット損失率を用いて平均化処理等の統計処理を行って、処理後のパケット損失率を帯域調整部２５に出力するようにしてもよい。
　また、本実施の形態では、一定時間の間パケット損失率が一定値Ｂより小さいと判断した場合に、申告する帯域を減少させるようにしているが、使用するアプリケーションやシステムの要求により、帯域を減少させることが望ましくない場合には、申告する帯域を減少させる処理を実施しないようにしてもよい。
　なお、本実施の形態では、ＲＴＣＰのSender　ReportパケットおよびReceiver　Reportパケットにおけるパケット損失率が一定値以上の場合に、呼制御ネットワーク４に申告する帯域値を増加させるようにした。しかし、呼制御ネットワーク４外でのパケット損失等の影響により、一定時間内にパケット損失率の減少が観測できない場合がある。そのため、このように、申告帯域を増加させた後、一定時間内にパケット損失率の減少が観測できない場合には、呼制御ネットワーク４外でのパケット損失であると判定し、呼制御ネットワーク４に申告する帯域値を増加させる前の値に再申告するようにしてもよい。
　なお、本実施の形態では、ＲＴＰ通信の帯域値の過不足を検出するためにＲＴＣＰのSender　ReportパケットおよびReceiver　Reportパケットに格納されているパケット損失率を用いる例を示したが、これに限らずＲＴＣＰのSender　Reportパケットに格納されている送信オクテット数を用いて申告する帯域を求めるようにしてもよい。たとえば、複数のSender　Reportパケットを用いて、所定の単位時間内の送信オクテット数を算出することにより必要となる帯域値を決定し、その値をＵＰＤＡＴＥメッセージにより呼制御ネットワーク４へ申告するようにしてもよい。
　また、本実施の形態では、端末３－１と端末３－２間の通信が、ＲＴＰおよびＲＴＣＰ通信である場合を例に説明したが、本実施の形態を適用する通信はＲＴＰおよびＲＴＣＰ通信に限らない。たとえば、NetFlow（登録商標）により通知されるセッション制御代行の対象となる通信フローの統計情報等のセッション制御代行の対象となる通信フローの帯域値の過不足に関連した情報を、ゲートウェイ装置２が中継パケットの内容を解析することで取得できる通信であれば、ゲートウェイ装置２は、その取得した情報に基づいて変更する帯域を求め、本実施の形態と同様に申告帯域を変更することができる。
　また、本実施の形態では、セッション制御プロトコルとしてＳＩＰを用いた場合を示したが、これに限らず、たとえばＨ．３２３やＭＥＧＡＣＯ（MEdia　GAteway　COntrol）等のように、ＳＩＰと同様にＩＰネットワーク上でセッション制御およびセッション管理ができる制御プロトコルであればよい。ＳＩＰ以外の制御プロトコルを用いる場合、本実施の形態と同様に、変更する帯域を求め、用いる制御プロトコルに対応した申告帯域の更新処理により、申告帯域を変更すればよい。
　以上のように、本実施の形態では、セッション制御に対応していない端末３－１のセッション制御処理を代行するゲートウェイ装置２－１が、セッション制御の代行対象のパケットを中継する際に、パケット解析部２４が中継するパケットから抽出したパケット損失率を抽出し、帯域調整部２５がパケット損失率に基づいて申告する帯域の更新値を求めるようにした。そのため、セッション制御の対象となる既存端末間の通信に必要な帯域値を適切に呼制御ネットワーク４へ申告することができる。
実施の形態２．
　図８は、本発明にかかる通信システムの実施の形態２の通信手順の一例を示すシーケンス図である。本実施の形態の通信システムの構成は、実施の形態１の通信システムの構成と同様であり、本実施の形態のゲートウェイ装置の構成も実施の形態１のゲートウェイ装置と同様である。以下の説明では、実施の形態１と同様の機能を有する要素は、実施の形態１と同一の符号を付すこととする。ただし、本実施の形態のセッション情報テーブル２３は、実施の形態１のセッション情報テーブル２３と一部異なる。本実施の形態のセッション情報テーブル２３については後述する。
　実施の形態１では、端末３－１と端末３－２の間で、ＲＴＰおよびＲＴＣＰ通信を行う場合について説明した。一方、ＲＴＰおよびＲＴＣＰ通信に先立ってＲＴＳＰ（Real　Time　Streaming　Protocol）通信が行われ、ＲＴＳＰ通信によって通信路が確立された後に、ＲＴＰおよびＲＴＣＰ通信が行われる場合がある。本実施の形態では、このようにＲＴＳＰ通信によって通信路が確立された後にＲＴＰおよびＲＴＣＰ通信が行われる場合について説明する。
　まず、端末３－１から端末３－２に宛ててＲＴＳＰによる通信（ＲＴＳＰ通信）の開始を表すＴＣＰ－ＳＹＮパケット（通信開始パケット）を送信する（ステップＳ４１）。ゲートウェイ装置２－１のパケット中継部２１は、端末３－１からＴＣＰ－ＳＹＮパケット（通信開始パケット）を受信すると、そのパケットの中継を保留し、そのパケットをセッション制御部２２に渡す。セッション制御部２２は、通信開始パケットから送信元ＩＰアドレス、宛先ＩＰアドレス、プロトコル、送信元ポート番号、宛先ポート番号等のフロー情報を抽出し、セッション情報テーブル２３を参照して、抽出したフロー情報に対応するセッション制御パラメータを取得する（ステップＳ４２）。セッション制御部２２は、取得したセッション制御パラメータに基づいて、呼接続要求であるＩＮＶＩＴＥメッセージを生成し、生成したＩＮＶＩＴＥメッセージをＳＩＰサーバ１に送信する（ステップＳ４３）。
　ＳＩＰサーバ１は、ＩＮＶＩＴＥメッセージを受信すると、セッション確立ための処理を実施中であること示す暫定応答“１００　Ｔｒｙｉｎｇ”をゲートウェイ装置２－１へ返信し（ステップＳ４４）、受信したＩＮＶＩＴＥメッセージを通信の宛先の端末３－２に接続するゲートウェイ装置２－２へ転送する（ステップＳ４５）。ゲートウェイ装置２－２は、“１００　Ｔｒｙｉｎｇ”をＳＩＰサーバ１へ返信する（ステップＳ４６）。
　ゲートウェイ装置２－２は、セッション確立の処理が正常に終了すると“２００　ＯＫ”レスポンスをＳＩＰサーバ１に送信し（ステップＳ４７）、ＳＩＰサーバ１は、ゲートウェイ装置２－２から“２００　ＯＫ”レスポンスを受信すると“２００　ＯＫ”レスポンスをゲートウェイ装置２－１へ送信する（ステップＳ４８）。
　ゲートウェイ装置２－１のセッション制御部２２は、ステップＳ４７で送信された“２００　ＯＫ”レスポンスをＳＩＰサーバ１から受信することにより通信路が確立されたことを検知すると、パケットの中継処理を再開するようパケット中継部２１に指示し、パケット中継部２１は、保留していたＴＣＰ－ＳＹＮパケットを端末３－２に転送する（ステップＳ４９）。
　端末３－２は、ＴＣＰ－ＳＹＮパケットを受信すると、その応答であるＴＣＰ－ＳＹＮ／ＡＣＫを端末３－１へ返信する（ステップＳ５０）。端末３－１は、ＴＣＰ－ＳＹＮ／ＡＣＫを受信するとＴＣＰ－ＡＣＫを返信する（ステップＳ５１）。以上の手順により、端末３－１と端末３－２の間で、ＲＴＳＰ制御チャネルのためのＴＣＰコネクションが確立される。
　ＲＴＳＰ制御チャネルのためのＴＣＰコネクションが確立されると、端末３－１は、端末３－２が送信するデータについてのメディア種別や帯域等の情報取得を要求する“ＲＴＳＰ　ＤＥＳＣＲＩＢＥ”メッセージを送信する（ステップＳ５２）。端末３－２は、“ＲＴＳＰ　ＤＥＳＣＲＩＢＥ”メッセージを受信すると、ＳＤＰにより記述されたメディア種別や帯域等の情報を含む“ＲＴＳＰ　２００　ＯＫ”レスポンスを送信する（ステップＳ５３）。
　ステップＳ５３では、ゲートウェイ装置２－１のパケット中継部２１が“ＲＴＳＰ　２００　ＯＫ”レスポンスを中継する。この際、パケット中継部２１は中継する“ＲＴＳＰ　２００　ＯＫ”レスポンスのパケットをパケット解析部２４へ渡す。パケット解析部２４は、“ＲＴＳＰ　２００　ＯＫ”レスポンスのパケットに含まれるＳＤＰにより記載された情報から、セッション制御で必要となるＱｏＳパラメータを抽出し、保持する（ステップＳ５４）。セッション制御で必要となるＱｏＳパラメータは、たとえば、帯域情報、メディア種別、属性等である。
　図９は、“ＲＴＳＰ　ＤＥＳＣＲＩＢＥ”メッセージの一例を示す図であり、図１０は、その応答である“ＲＴＳＰ　２００　ＯＫ”レスポンスの一例を示す図である。図１０に示した“ｂ＝”を含む行は帯域を示し、“ｍ＝”を含む行はメディア種別を示し、“ａ＝”を含む行は属性を示している。
　端末３－１は、“ＲＴＳＰ　２００　ＯＫ”レスポンスを受信すると、“ＲＴＳＰ　ＳＥＴＵＰ”メッセージを送信する（ステップＳ５５）。端末３－２は、“ＲＴＳＰ　ＳＥＴＵＰ”メッセージを受信すると、ＳＤＰで記述された情報を含む“ＲＴＳＰ　２００　ＯＫ”レスポンスを端末３－１に宛てて送信する（ステップＳ５６）。
　ゲートウェイ装置２－１のパケット中継部２１は、“ＲＴＳＰ　２００　ＯＫ”レスポンスを受信すると中継を保留し、そのＲＴＳＰ　２００　ＯＫ”レスポンスをパケット解析部２４へ渡す。パケット解析部２４は、“ＲＴＳＰ　２００　ＯＫ”レスポンスのＳＤＰ記述部分から、保持しているＱｏＳパラメータのうち、ステップＳ４１の“ＲＴＳＰ　ＳＥＴＵＰ”メッセージで設定が要求された通信に対応するＱｏＳパラメータを抽出し、抽出したＱｏＳパラメータをセッション制御部２３へ渡す。セッション制御部２３は、パケット解析部２４から受け取ったＱｏＳパラメータに基づいてＵＰＤＡＴＥメッセージを生成し、生成したＵＰＤＡＴＥメッセージをＳＩＰサーバ１へ送信する（ステップＳ５７）。
　ＳＩＰサーバ１は、ＵＰＤＡＴＥメッセージを受信すると、ＵＰＤＡＴＥメッセージに基づいて要求された帯域を確保し、ＵＰＤＡＴＥメッセージをゲートウェイ装置２－２へ転送する（ステップＳ５８）。ゲートウェイ装置２－２は、ＵＰＤＡＴＥメッセージに基づいて要求された帯域を確保し、“２００　ＯＫ”レスポンスをＳＩＰサーバ１に送信する（ステップＳ５９）。ＳＩＰサーバ１は、ゲートウェイ装置２－２から“２００　ＯＫ”レスポンスを受信すると、“２００　ＯＫ”レスポンスをゲートウェイ装置２－１へ送信する（ステップＳ６０）。
　ゲートウェイ装置２－１のパケット中継部２１は、２００　ＯＫ”レスポンスを受信すると、中継を保留していた“ＲＴＳＰ　２００　ＯＫ”レスポンスを端末３－１へ送信する（ステップＳ６１）。そして、端末３－１は、ステップＳ５５でＳＥＴＵＰを要求した通信の開始として“ＲＴＳＰ　ＰＬＡＹ”メッセージを送信し（ステップＳ６２）、端末３－２は“ＲＴＳＰ　２００　ＯＫ”を返信する（ステップＳ６３）。以降、端末３－１と端末３－２の間でストリーミングによる通信を行うことができるようになる。
　ここでは、端末３－１と端末３－２の間のストリーミング通信がＲＴＰ／ＲＴＣＰにより行われることとし、ステップＳ６３の後に、ストリーミング通信が行われる。ストリーミング通信の際の本実施の形態の動作は、実施の形態１のステップＳ２０～ステップＳ２６と同様である。以上述べた以外の本実施の形態の動作は実施の形態１と同様である。
　実施の形態１では、ゲートウェイ装置２－１は、セッション情報テーブルのセッション制御パラメータとしてＲＴＰ／ＲＴＣＰ通信に関する帯域情報の初期値を保持する必要があった。これに対し本実施の形態では、ＲＴＰ／ＲＴＣＰ通信の開始前に、ＲＴＳＰ制御チャネルを用いた“ＲＴＳＰ　２００　ＯＫ”レスポンスに含まれる帯域情報に基づいてＵＰＤＡＴＥメッセージが送信されるため、セッション情報テーブル２３ではＲＴＰ／ＲＴＣＰ通信に関する帯域情報の初期値を保持する必要がない。ただし、ゲートウェイ装置２－１は、ＲＴＳＰ通信の制御チャネルに関する帯域情報の初期値は保持する。
　以上のように、本実施の形態では、セッション制御に対応していない端末３－１のセッション制御処理を代行するゲートウェイ装置２－１が、“ＲＴＳＰ　ＤＥＳＣＲＩＢＥ”メッセージの応答の“ＲＴＳＰ　２００　ＯＫ”レスポンスに含まれる帯域情報に基づいて、ＵＰＤＡＴＥメッセージを生成し、ＲＴＳＰ通信用の用の帯域を確保するようにした。そのため、実施の形態１と同様の効果が得られるとともに、ゲートウェイ装置２－１がＲＴＰ／ＲＴＣＰ通信が、従来に比べセッション制御パラメータとして保持する情報量を削減することができる。
実施の形態３．
　図１１は、本発明にかかるゲートウェイ装置２ａの実施の形態３の機能構成例を示す図である。本実施の形態のゲートウェイ装置２ａは、実施の形態１のパケット解析部２４おおよび帯域調整部２５の代わりに、ＴＣＰ観測部２６および帯域調整部２７を備える以外は、実施の形態１のゲートウェイ装置２と同様である。本実施の形態の通信システムの構成は、ゲートウェイ装置２－１，ゲートウェイ装置２－２を、それぞれ図１１に示した構成を有するゲートウェイ装置２ａ－１，ゲートウェイ装置２ａ－２に換える以外は、実施の形態１の通信システム（図１参照）と同様である。
　ＴＣＰ観測部２６は、セッション制御の対象となるＴＣＰ通信を観測し、ＴＣＰパケットから受信ウィンドウサイズの抽出を行うとともに、ＲＴＴ（Round　Trip　Time）の測定を行う。帯域調整部２７は、受信ウィンドウサイズとＲＴＴに基づいて、セッション制御の対象となるＴＣＰ通信に必要な帯域を求める。
　つぎに、本実施の形態の動作を説明する。図１２は、本実施の形態の通信システムの通信手順の一例を示すシーケンス図である。ここでは、端末３－１が端末３－２との間で、ＴＣＰ通信を行う場合について説明する。
　端末３－１は、ＴＣＰ－ＳＹＮパケットを送信する（ステップＳ７１）。ゲートウェイ装置２ａ－１のパケット中継部２１は、受信したＴＣＰ－ＳＹＮパケットの中継を保留し、ＴＣＰ－ＳＹＮパケットをセッション制御部２２へ渡す。セッション制御部２２は、ＴＣＰ－ＳＹＮパケットから送信元ＩＰアドレス、宛先ＩＰアドレス、プロトコル、送信元ポート番号、宛先ポート番号等のフロー情報を抽出し、セッション情報テーブル２３を参照して、抽出したフロー情報に対応するセッション制御パラメータを取得する（ステップＳ７２）。セッション制御部２２は、取得したセッション制御パラメータに基づいて、呼接続要求であるＩＮＶＩＴＥメッセージを生成し、生成したＩＮＶＩＴＥメッセージをＳＩＰサーバ１に送信する（ステップＳ７３）。
　以降のステップＳ７４～ステップＳ８０は、実施の形態２のステップＳ４４～ステップＳ５０と同様である。ゲートウェイ装置２ａ－１のパケット中継部２１は、ステップＳ８０でＴＣＰ－ＳＹＮ／ＡＣＫパケットを中継するとともに、ＴＣＰ－ＳＹＮ／ＡＣＫパケットをＴＣＰ観測部２６へ渡す。ＴＣＰ観測部２６は、ＴＣＰ－ＳＹＮ／ＡＣＫパケットからＴＣＰ受信ウィンドウサイズおよびウィンドウスケールオプションを抽出して保持する（ステップＳ８１）。
　図１３は、ＴＣＰパケットのヘッダフォーマットの一例を示す図である。図１３の例は、ＩＥＴＦ（Internet　Engineering　Task　Force）のＲＦＣ（Request　For　Comments）１３２３で規定されているウィンドウスケールオプションを用いる場合を示している。図１３の先頭から、緊急ポインタまでは標準のヘッダであり、“Ｋｉｎｄ＝２”以降はオプションのフィールドを示している。図１３の最後から３番目の“Ｋｉｎｄ＝３”以降の部分が、ウィンドウスケールオプションを示し、“Ｌｅｎｇｔｈ＝３”はそのオプションフィールド長さを示し、“シフトカウント”がウィンドウサイズの値をビットシフトする値を示している。
　標準のＴＣＰパケットヘッダでは、ウィンドウサイズは最大で６５５３５バイトまでしか表現できないため、ＲＦＣ１３２３ではウィンドウスケールオプションとしてウィンドウサイズの値をビットシフトさせることにより、最大のウィンドウサイズを６５５３５バイトより大きい値に設定できるようにしている。したがって、標準のヘッダ部分に含まれるウィンドウサイズ（ＴＣＰ受信ウィンドウサイズ）と、このシフトカウントと、を用いて実際のウィンドウサイズを求めることができる。なお、ウィンドウスケールオプションを用いない場合には、ＴＣＰパケットのヘッダに含まれるウィンドウサイズの値に基づいてＴＣＰ受信ウィンドウサイズを求めればよい。
　図１２を用いた説明に戻る。端末３－１は、ＴＣＰ－ＳＹＮ／ＡＣＫパケットを受信するとＴＣＰ－ＡＣＫパケットを端末３－２へ送信する（ステップＳ８２）。以上により、端末３－１と端末３－２の間のＴＣＰ　３ｗａｙハンドシェイクが終了し、端末３－１と端末３－２の間でデータの送受信が行なわれる（ステップＳ８３）。
　ステップＳ８３のデータの送受信の間、ゲートウェイ装置２ａ－１では、パケット中継部２１は受信したデータを伝送するが、同時に受信したデータをＴＣＰ観測部２６に渡し、ＴＣＰ観測部２６が当該ＴＣＰトラフィックの観測を行なう（ステップＳ８４）。具体的には、ＴＣＰ観測部２６は、当該ＴＣＰトラフィックのうち、端末３－２から端末３－１へ送信されるＴＣＰ－ＡＣＫパケットから端末３－２側のＴＣＰ受信ウィンドウサイズを抽出する。また、ＴＣＰ観測部２６は、当該ＴＣＰトラフィックのうち、端末３－１から端末３－２へ送信されるＴＣＰパケットとそれに対する応答として端末３－２から端末３－１へ送信されるＴＣＰ　ＡＣＫパケットとに基づいて、ＲＴＴの測定を行なう。ＴＣＰ観測部２６は、保持しているウィンドウスケールオプションと抽出したＴＣＰ受信ウィンドウサイズと測定したＲＴＴとを帯域調整部２７へ渡す。
　そして、ゲートウェイ装置２ａ－１では、帯域調整部２７が、ウィンドウスケールオプションとＴＣＰ受信ウィンドウサイズおよびＲＴＴに基づいて最大帯域を求め、最大帯域がステップＳ７３で申告済みの帯域より大きい場合に、変更後の帯域値として申告済みの帯域値を増加させた値を求める。また帯域調整部２７は、申告済みの帯域より最大帯域が小さくかつ申告済みの帯域と最大帯域の差が所定の値Ｘより大きい場合に、変更後の帯域値として申告済みの帯域値を減少させた値を求める。そして、帯域調整部２７は、変更後の帯域値をセッション制御部２２へ渡す。セッション制御部２２は、帯域調整部２７から受け取った変更後の帯域値を申告する帯域として反映させたＵＰＤＡＴＥメッセージを生成し、生成したＵＰＤＡＴＥメッセージをＳＩＰサーバ１へ送信する（ステップＳ８５）。以降のステップＳ８６～ステップＳ８８の処理は、実施の形態１のステップＳ２３～ステップＳ２５と同様である。
　ステップＳ８８の後、データの送受信を継続し（ステップＳ８９）、ゲートウェイ装置２ａ－１では、ステップ８４と同様にＴＣＰトラフィックを観測し、最大帯域が申告済みの帯域より大きい場合に、または申告済みの帯域より最大帯域が小さく申告済みの帯域と最大帯域の差が所定の値Ｘより大きい場合に、ステップＳ８５～ステップＳ８８と同様の処理を行い申告する帯域を変更する。以上述べた以外の本実施の形態の動作は実施の形態１と同様である。
　つぎに、ゲートウェイ装置２ａ－１の申告帯域の更新方法について詳細に説明する。図１４は、本実施の形態の申告帯域の更新方法の一例を示すフローチャートである。ＴＣＰ観測部２６は、端末３－１と端末３－２間のＴＣＰコネクション確立時のＴＣＰ－ＳＹＮ／ＡＣＫパケットをパケット中継部２１から受け取り、ＴＣＰ－ＳＹＮ／ＡＣＫパケットからウィンドウスケールオプションの値を抽出し、内部に保持する（ステップＳ９１）。
　そして、ＴＣＰ観測部２６は、当該ＴＣＰコネクションで端末３－１から端末３－２へ送信されるＴＣＰパケットとそのＴＣＰパケットに対する応答として端末３－２から端末３－１へ送信されるＴＣＰ　ＡＣＫパケットに基づいてＲＴＴを測定する（ステップＳ９２）。また、その際、端末３－２から送信されるＴＣＰ　ＡＣＫパケットに含まれるウィンドウサイズ値を抽出する（ステップＳ９２）。
　ＴＣＰ観測部２６は、保持しているウィンドウスケールオプションの値と抽出したウィンドウサイズ値と測定したＲＴＴとに基づいて、最大帯域を算出する（ステップＳ９３）。具体的には、ウィンドウスケールオプションの値とウィンドウサイズ値に基づいてを求め、最大帯域＝ＴＣＰ受信ウィンドウサイズ／ＲＴＴとして最大帯域を求める。
　ＴＣＰ観測部２６は、最大帯域が、呼制御ネットワーク４へ申告済みの帯域より大きいか否かを判断する（ステップＳ９４）。なお、ＴＣＰ観測部２６は、呼制御ネットワーク４へ申告済みの帯域をセッション制御部２２から取得して保持していることとする。最大帯域が申告済みの帯域より大きい場合（ステップＳ９４　Ｙｅｓ）、ＴＣＰ観測部２６は、変更後の帯域として申告済みの帯域を増加させた値を求め、変更後の帯域をセッション制御部２２へ渡す（ステップＳ９５）。セッション制御部２２は変更後の帯域に基づいてＵＰＤＡＴＥメッセージを生成し、生成したＵＰＤＡＴＥメッセージをＳＩＰサーバ１へ送信し（ステップＳ９５）、ステップＳ９２に戻る。
　最大帯域が申告済みの帯域以下の場合（ステップＳ９４　Ｎｏ）、ＴＣＰ観測部２６は、申告済みの帯域と最大帯域の差が所定の値Ｘより大きいか否かを判断する（ステップＳ９６）。申告済みの帯域と最大帯域の差が所定の値Ｘより大きい場合（ステップＳ９６　Ｙｅｓ）、ＴＣＰ観測部２６は、変更後の帯域として申告済みの帯域を減少させた値を求め、変更後の帯域をセッション制御部２２へ渡す（ステップＳ９７）。セッション制御部２２は変更後の帯域に基づいてＵＰＤＡＴＥメッセージを生成し、生成したＵＰＤＡＴＥメッセージをＳＩＰサーバ１へ送信し（ステップＳ９７）、ステップＳ９２に戻る。
　また、申告済みの帯域と最大帯域の差が所定の値Ｘより大きくない場合（ステップＳ９６　Ｎｏ）、申告する帯域は変更せず、ステップＳ９２に戻る。
　ステップＳ９５およびステップＳ９７での変更後の帯域の求め方としては、どのような方法を用いてもよいが、たとえば、求めた最大帯域を変更後の帯域とする方法がある。これに限らず、一定割合で増加（ステップＳ９７の場合は減少）させる、申告済みの帯域に一定値を加算する（ステップＳ９７の場合は減算）ことにより変更後の帯域を求めてもよい。
　なお、本実施の形態では申告済みの帯域と最大帯域の差が所定の値Ｘより大きい場合に、申告する帯域を減少させるようにしているが、使用するアプリケーションやシステムの要求により、帯域を減少させることが望ましくない場合には、申告する帯域を減少させる処理を実施しないようにしてもよい。
　なお、上記の例では、ＴＣＰコネクション生成側（ゲートウェイ装置２ａ－１）での帯域値の更新方法を示したが、ＴＣＰコネクションの受信側（ゲートウェイ装置２ａ－２）でも同様に、対向ＴＣＰノード（端末３－１）のＴＣＰ受信ウィンドウサイズおよびＲＴＴに基づいて、申告する帯域を変更するようにしてもよい。ＴＣＰコネクションの受信側でも同様の処理を行うことにより、双方向でそれぞれ適切な最大帯域に応じた帯域が確保された通信路を確立することができる。
　また、さらに最初に呼制御ネットワーク４に申告する帯域値をフロー情報によらず固定値とすると、ゲートウェイ装置が、保持するセッション情報テーブルの帯域値に関する情報を削減することができる。
　以上のように、本実施の形態では、ＴＣＰ観測部２６が、ＴＣＰコネクション確立時のＴＣＰ－ＳＹＮ／ＡＣＫパケットからウィンドウスケールオプションを抽出し、端末３－２から送信されたＴＣＰ　ＡＣＫパケットに含まれるウィンドウサイズ値を抽出し、また、端末３－１と端末３－２の間で送信されるパケットに基づいてＲＴＴを測定する。そして、ＴＣＰ観測部２６は、ウィンドウスケールオプションとウィンドウサイズ値とＲＴＴとに基づいて求めた最大帯域に基づいて変更後の帯域を算出し、セッション制御部２２が、変更後の帯域を呼制御ネットワーク４へ申告するようにした。そのため、ＴＣＰを用いた通信を行なう場合に、セッション制御の対象となる既存端末間の通信に必要な帯域値を適切に呼制御ネットワーク４へ申告することができる。
実施の形態４．
　図１５は、本発明にかかるゲートウェイ装置２ｂの実施の形態４の機能構成例を示す図である。本実施の形態のゲートウェイ装置２ｂは、実施の形態１のパケット解析部２４おおよび帯域調整部２５の代わりに、帯域測定部２８を備える以外は、実施の形態１のゲートウェイ装置２と同様である。本実施の形態の通信システムの構成は、ゲートウェイ装置２－１，ゲートウェイ装置２－２を、それぞれ図１５に示した構成を有するゲートウェイ装置２ｂ－１，ゲートウェイ装置２ｂ－２に換える以外は、実施の形態１の通信システム（図１参照）と同様である。
　帯域測定部２８は、セッション制御の対象となる通信の通信帯域（送信帯域）を測定する。送信帯域の測定方法はどのような方法でもよいが、たとえば、帯域測定部２８は、所定の単位時間内に中継パケット２１が中継したセッション制御代行処理の対象通信のデータ量を積算し、積算したデータ量を単位時間で割ることにより送信帯域を測定する方法等がある。帯域測定部２８は、このように測定した送信帯域を、呼制御ネットワーク４に申告する帯域の更新値として求めるため、実施の形態１の帯域調整部２５等と同様に帯域調整手段としての機能を有する。
　つぎに、本実施の形態の動作を説明する。図１６は、本実施の形態の通信システムの通信手順の一例を示すシーケンス図である。ここでは、端末３－１が通信を開始し、端末３－２との間で通信を行なう場合を例に説明する。なお、この通信は、以下のフロー情報などを含むパケットを送信する通信であればどのような種類の通信でもよく、たとえばＴＣＰの通信であってもよく、またＵＤＰの通信であってもよい。
　まず、端末３－１は、端末３－２との間の通信の最初のパケットである通信開始パケットを送信する（ステップＳ１０１）。ゲートウェイ装置２ｂ－１では、パケット中継部２１が端末３－１から通信開始パケットを受信すると、当該パケットの中継を保留し、そのパケットを保持するとともにセッション制御部２２に渡す。セッション制御部２２は、受信した通信開始パケットから送信元ＩＰアドレス、宛先ＩＰアドレス、プロトコル、送信元ポート番号、宛先ポート番号等フロー条件に対応する情報を抽出し、セッション情報テーブル２３に基づいて抽出した情報と一致するフロー条件を検索し、検索して得られたフロー条件に対応するセッション制御パラメータを取得する（ステップＳ１０２）。
　以降、実施の形態１のステップＳ１３～ステップＳ１８と同様に、ステップＳ１０３～ステップＳ１０８の処理を行う。ゲートウェイ装置２ｂ－１のセッション制御部２２は、ステップＳ１０８で送信された“２００　ＯＫ”レスポンスをＳＩＰサーバ１から受信することにより通信路が確立されたことを検知すると、パケットの中継処理を再開するようパケット中継部２１に指示し、パケット中継部２１は、保留していたパケット（ステップＳ１０１で送信されたパケット）を端末３－２に転送する（ステップＳ１０９）。
　その後、端末３－１と端末３－２の間で通信が行なわれる（ステップＳ１１０）。その際、ゲートウェイ装置２ｂ－１では、パケット中継部２１が、端末３－１と端末３－２の間で通信パケットを中継するとともに、帯域測定部２８が、通信パケットに基づいて、送信（端末３－１からの送信）帯域の測定を行い、セッション制御部２２へ通知する（ステップＳ１１１）。
　ゲートウェイ装置２ｂ－１のセッション制御部２２は、帯域測定部２８から通知された送信帯域を申告する帯域として用いたＵＰＤＡＴＥメッセージを生成し、生成したＵＰＤＡＴＥメッセージをＳＩＰサーバ１に送信する（ステップＳ１１２）。以降、実施の形態１のステップＳ２３～ステップＳ２５と同様に、ステップＳ１１３～ステップＳ１１５を実施する。これにより、呼制御ネットワーク４上に当該通信に応じた帯域が確保された通信路を確立する。端末３－１と端末３－２は、通信を継続し（ステップＳ１１６）、その間、帯域測定部２８は上記と同様に、通信パケットに基づいて、送信帯域の測定を行い、セッション制御部２２が、送信帯域に基づいてＵＰＤＡＴＥメッセージを送信する。以上述べた以外の本実施の形態の動作は実施の形態１と同様である。
　なお、測定した送信帯域が申告済みの帯域と変わらない場合、または、測定した送信帯域と申告済みの帯域との差が所定の範囲内である場合には、送信帯域に基づくＵＰＤＡＴＥメッセージの送信を実施しないようにしてもよい。
　また、帯域測定部２８は、所定の時間間隔ごとに送信帯域を測定するようにしてもよい。また、帯域測定部２８は、複数の測定した送信帯域を用いて平均化処理等の統計処理等を行い、処理後の送信帯域をセッション制御部２２へ渡すようにしてもよい。
　また、上記の例では、通信開始側（ゲートウェイ装置２ｂ－１）が送信帯域を測定し、帯域を更新する方法を示したが、当該通信の受信側（ゲートウェイ装置２ｂ－２）でも、同様に送信（端末３－２からの送信）帯域の測定を行い、送信帯域に基づいて申告する帯域を更新するようにしてもよい。受信側でも同様の処理を行うことにより、双方向でそれぞれ適切な最大帯域に応じた帯域が確保された通信路を確立することができる。
　また、さらに最初に呼制御ネットワーク４に申告する帯域値をフロー情報によらず固定値とすると、ゲートウェイ装置が、保持するセッション情報テーブルの帯域値に関する情報を削減することができる。
　以上のように、本実施の形態では、ゲートウェイ装置２ｂ－１の帯域測定部２８が、中継する通信パケットに基づいて送信帯域を測定し、セッション制御部２２が送信帯域に基づいて呼制御ネットワーク４へ申告する帯域を更新するためのＵＰＤＡＴＥメッセージを送信するようにした。そのため、通信パケットの内容を解析することなく、実施の形態１と同様の効果を得ることができる。
　以上のように、本発明にかかるゲートウェイ装置、通信システムおよび通信方法は、端末のセッション制御処理を代行するゲートウェイ装置を備える通信システムに有用であり、特に、多様なフロー条件の通信を扱う通信システムに適している。
　１　ＳＩＰサーバ
　２，２－１，２－２，２ａ，２ａ－１，２ａ－２，２ｂ－１，２ｂ－２　ゲートウェイ装置
　３－１，３－２　端末
　４　呼制御ネットワーク
　５－１，５－２　ユーザネットワーク
　２１　パケット中継部
　２２　セッション制御部
　２３　セッション情報テーブル
　２４　パケット解析部
　２５，２７　帯域調整部
　２６　ＴＣＰ観測部
　２８　帯域測定部

Claims (11)

  1. 　呼制御を実施する呼制御ネットワークと、呼制御機能を備えない端末と、接続し、前記呼制御ネットワークと前記端末間の通信を中継するゲートウェイ装置であって、
    　前記端末が前記呼制御ネットワーク経由で行なう通信である呼制御通信における呼制御処理を代行し、前記呼制御通信が必要とする帯域を前記呼制御ネットワークへ申告する呼制御手段と、
    　前記端末から受信した前記呼制御通信の通信パケットに基づいて、前記呼制御通信の帯域の更新値を求める帯域調整手段と、
    　を備え、
    　前記呼制御手段は、前記更新値を前記呼制御通信が必要とする帯域として前記呼制御ネットワークへ申告する、
    　ことを特徴とするゲートウェイ装置。
  2. 　前記通信パケットに含まれる所定の情報を抽出するパケット解析手段、
    　をさらに備え、
    　前記帯域調整手段は、前記情報に基づいて前記更新値を求める、
    　ことを特徴とする請求項１に記載のゲートウェイ装置。
  3. 　前記呼制御通信をＲＴＰおよびＲＴＣＰを用いた通信とし、
    　前記パケット解析手段は、Ｒｅｃｅｉｖｅｒ　ＲｅｐｏｒｔパケットまたはＳｅｎｄｅｒ　Ｒｅｐｏｒｔパケットに含まれるパケット損失率を前記情報として抽出し、
    　前記帯域調整手段は、前記パケット損失率が所定の上限しきい値より大きい場合、前記更新値を申告済みの帯域より大きい値となるよう求める、
    　ことを特徴とする請求項２に記載のゲートウェイ装置。
  4. 　前記帯域調整手段は、一定期間の間前記パケット損失率が所定の下限しきい値より小さい場合、前記更新値を申告済みの帯域より小さい値となるよう求める、
    　ことを特徴とする請求項３に記載のゲートウェイ装置。
  5. 　前記呼制御通信としてさらにＲＴＳＰを用いた通信を含み、ＲＴＰおよびＲＴＣＰを用いた通信の前にＲＴＳＰを用いてＲＴＰおよびＲＴＳＰの通信路を確立することとし、
    　前記パケット解析手段は、さらに、ＲＴＳＰの通信パケットに含まれる帯域情報を抽出し、
    　前記帯域調整手段は、さらに前記帯域情報を前記更新値とする、
    　ことを特徴とする請求項４に記載のゲートウェイ装置。
  6. 　前記呼制御通信を、ＴＣＰを用いた通信とし、
    　前記呼制御通信のＴＣＰパケットとそのＴＣＰパケットに対する応答パケットとに基づいて、往復遅延時間を測定し、また、前記応答パケットから受信側ウィンドウサイズを抽出するＴＣＰ観測手段、
    　をさらに備え、
    　前記帯域調整手段は、前記往復遅延時間および前記受信側ウィンドウサイズに基づいて最大帯域を求め、前記最大帯域に基づいて前記更新値を求める、
    　ことを特徴とする請求項１に記載のゲートウェイ装置。
  7. 　前記ＴＣＰ観測手段は、前記呼制御通信のＴＣＰコネクション確立の際に送信されるＴＣＰパケットからウィンドウスケールオプション情報を抽出し、
    　さらに前記ウィンドウスケールオプション情報に基づいて前記最大値を求める、
    　ことを特徴とする請求項６に記載のゲートウェイ装置。
  8. 　前記帯域調整手段は、前記呼制御通信の通信パケットに基づいて通信帯域を測定し、前記通信帯域を前記更新値とする、
    　ことを特徴とする請求項１に記載のゲートウェイ装置。
  9. 　前記呼制御処理を、ＳＩＰを用いた処理とし、
    　前記呼制御手段は、ＵＰＤＡＴＥメッセージを用いて前記更新値を前記呼制御通信が必要とする帯域として前記呼制御ネットワークへ申告する、
    　ことを特徴とする請求項１～８のいずれか１つに記載のゲートウェイ装置。
  10. 　呼制御を実施する呼制御ネットワークと、呼制御機能を備えない端末と、前記呼制御ネットワークと前記端末間の通信を中継するゲートウェイ装置と、を備える通信システムであって、
    　ゲートウェイ装置は、
    　前記端末が前記呼制御ネットワーク経由で行なう通信である呼制御通信における呼制御処理を代行し、前記呼制御通信が必要とする帯域を前記呼制御ネットワークへ申告する呼制御手段と、
    　前記端末から受信した前記呼制御通信の通信パケットに基づいて、前記呼制御通信の帯域の更新値を求める帯域調整手段と、
    　を備え、
    　前記呼制御手段は、前記更新値を前記呼制御通信が必要とする帯域として前記呼制御ネットワークへ申告する、
    　ことを特徴とする通信システム。
  11. 　呼制御を実施する呼制御ネットワークと、呼制御機能を備えない端末と、接続し、前記呼制御ネットワークと前記端末間の通信を中継するゲートウェイ装置における通信方法であって、
    　前記端末が前記呼制御ネットワーク経由で行なう通信である呼制御通信における呼制御処理を代行し、前記呼制御通信が必要とする帯域を前記呼制御ネットワークへ申告する呼制御ステップと、
    　前記端末から受信した前記呼制御通信の通信パケットに基づいて、前記呼制御通信の帯域の更新値を求める帯域調整ステップと、
    　前記更新値を前記呼制御通信が必要とする帯域として前記呼制御ネットワークへ申告する帯域更新ステップと、
    　を含むことを特徴とする通信方法。
PCT/JP2009/068710 2009-10-30 2009-10-30 ゲートウェイ装置、通信システムおよび通信方法 WO2011052079A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US13/505,138 US8737387B2 (en) 2009-10-30 2009-10-30 Gateway unit, communication system and communication method
PCT/JP2009/068710 WO2011052079A1 (ja) 2009-10-30 2009-10-30 ゲートウェイ装置、通信システムおよび通信方法
EP09850858.3A EP2495916A4 (en) 2009-10-30 2009-10-30 GATEWAY DEVICE, COMMUNICATION SYSTEM AND COMMUNICATION PROCESS
JP2011538177A JP5214035B2 (ja) 2009-10-30 2009-10-30 ゲートウェイ装置、通信システムおよび通信方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2009/068710 WO2011052079A1 (ja) 2009-10-30 2009-10-30 ゲートウェイ装置、通信システムおよび通信方法

Publications (1)

Publication Number Publication Date
WO2011052079A1 true WO2011052079A1 (ja) 2011-05-05

Family

ID=43921520

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2009/068710 WO2011052079A1 (ja) 2009-10-30 2009-10-30 ゲートウェイ装置、通信システムおよび通信方法

Country Status (4)

Country Link
US (1) US8737387B2 (ja)
EP (1) EP2495916A4 (ja)
JP (1) JP5214035B2 (ja)
WO (1) WO2011052079A1 (ja)

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103685200B (zh) * 2012-09-24 2018-01-30 中兴通讯股份有限公司 接入协商、释放中服务质量承载资源控制的方法及系统
US10374904B2 (en) 2015-05-15 2019-08-06 Cisco Technology, Inc. Diagnostic network visualization
US10536357B2 (en) 2015-06-05 2020-01-14 Cisco Technology, Inc. Late data detection in data center
US9967158B2 (en) 2015-06-05 2018-05-08 Cisco Technology, Inc. Interactive hierarchical network chord diagram for application dependency mapping
US10142353B2 (en) 2015-06-05 2018-11-27 Cisco Technology, Inc. System for monitoring and managing datacenters
US10708183B2 (en) 2016-07-21 2020-07-07 Cisco Technology, Inc. System and method of providing segment routing as a service
US10972388B2 (en) 2016-11-22 2021-04-06 Cisco Technology, Inc. Federated microburst detection
CN108234184B (zh) * 2016-12-22 2021-01-15 上海诺基亚贝尔股份有限公司 用于管理用户信息的方法和设备
US10708152B2 (en) 2017-03-23 2020-07-07 Cisco Technology, Inc. Predicting application and network performance
US10523512B2 (en) 2017-03-24 2019-12-31 Cisco Technology, Inc. Network agent for generating platform specific network policies
US10764141B2 (en) 2017-03-27 2020-09-01 Cisco Technology, Inc. Network agent for reporting to a network policy system
US10594560B2 (en) 2017-03-27 2020-03-17 Cisco Technology, Inc. Intent driven network policy platform
US10250446B2 (en) 2017-03-27 2019-04-02 Cisco Technology, Inc. Distributed policy store
US10873794B2 (en) 2017-03-28 2020-12-22 Cisco Technology, Inc. Flowlet resolution for application performance monitoring and management
US10680887B2 (en) 2017-07-21 2020-06-09 Cisco Technology, Inc. Remote device status audit and recovery
US10554501B2 (en) 2017-10-23 2020-02-04 Cisco Technology, Inc. Network migration assistant
US10523541B2 (en) 2017-10-25 2019-12-31 Cisco Technology, Inc. Federated network and application data analytics platform
US10594542B2 (en) 2017-10-27 2020-03-17 Cisco Technology, Inc. System and method for network root cause analysis
US11233821B2 (en) 2018-01-04 2022-01-25 Cisco Technology, Inc. Network intrusion counter-intelligence
US10999149B2 (en) 2018-01-25 2021-05-04 Cisco Technology, Inc. Automatic configuration discovery based on traffic flow data
US10826803B2 (en) 2018-01-25 2020-11-03 Cisco Technology, Inc. Mechanism for facilitating efficient policy updates
US10574575B2 (en) 2018-01-25 2020-02-25 Cisco Technology, Inc. Network flow stitching using middle box flow stitching
US10798015B2 (en) 2018-01-25 2020-10-06 Cisco Technology, Inc. Discovery of middleboxes using traffic flow stitching
US11128700B2 (en) 2018-01-26 2021-09-21 Cisco Technology, Inc. Load balancing configuration based on traffic flow telemetry
US10856344B2 (en) * 2019-03-15 2020-12-01 Hong Kong Applied Science and Technology Research Institute Company Limited Method and an apparatus for reducing connection set-up time in a communications network

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006013618A1 (ja) * 2004-08-02 2006-02-09 Mitsubishi Denki Kabushiki Kaisha 伝送制御装置
JP2006080847A (ja) * 2004-09-09 2006-03-23 Matsushita Electric Ind Co Ltd 媒体の誤り状態に応じて媒体確保を調整する方法
WO2006051594A1 (ja) * 2004-11-11 2006-05-18 Mitsubishi Denki Kabushiki Kaisha 通信ネットワークにおけるｉｐパケット中継方法およびゲートウエイ装置
JP2009152973A (ja) * 2007-12-21 2009-07-09 Mitsubishi Electric Corp 中継通信システム

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4805081B2 (ja) * 2006-09-29 2011-11-02 富士通株式会社 無線中継装置、無線中継方法および無線中継プログラム
JP4613981B2 (ja) * 2008-06-12 2011-01-19 ソニー株式会社 通信制御装置と通信端末装置と通信システムおよび通信制御方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006013618A1 (ja) * 2004-08-02 2006-02-09 Mitsubishi Denki Kabushiki Kaisha 伝送制御装置
JP2006080847A (ja) * 2004-09-09 2006-03-23 Matsushita Electric Ind Co Ltd 媒体の誤り状態に応じて媒体確保を調整する方法
WO2006051594A1 (ja) * 2004-11-11 2006-05-18 Mitsubishi Denki Kabushiki Kaisha 通信ネットワークにおけるｉｐパケット中継方法およびゲートウエイ装置
JP2009152973A (ja) * 2007-12-21 2009-07-09 Mitsubishi Electric Corp 中継通信システム

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
KOJI SATO ET AL.: "SIP Adaptation o Tekiyo shita NGN ni Okeru QoS Seigyo no Jitsugen", DENSHI TSUSHIN GAKKAI GIJUTSU KENKYU HOKOKU (TECHNICAL REPORT OF IEICE), CS2005-46, 10 November 2005 (2005-11-10), XP008112806 *
See also references of EP2495916A4 *

Also Published As

Publication number Publication date
US20120218989A1 (en) 2012-08-30
JPWO2011052079A1 (ja) 2013-03-14
JP5214035B2 (ja) 2013-06-19
EP2495916A1 (en) 2012-09-05
EP2495916A4 (en) 2014-10-01
US8737387B2 (en) 2014-05-27

Similar Documents

Publication Publication Date Title
JP5214035B2 (ja) ゲートウェイ装置、通信システムおよび通信方法
US9154396B2 (en) Passive measurement of available link bandwidth
KR100759954B1 (ko) 멀티미디어 스트리밍에서 클라이언트 레이트 능력을시그널링하는 방법
JP4456115B2 (ja) サービス品質に関する埋込み情報の送信
US20050005020A1 (en) Server-based rate control in a multimedia streaming environment
JP4323432B2 (ja) ストリーミングメディアの伝送品質を高めるための方法
US20100274920A1 (en) Adjustment of Transmission Data Rate Based on Data Errors and/or Latency
EP2636191B1 (en) Real time protocol packet tunneling
US11271862B2 (en) Service delivery in a communication network
KR101871303B1 (ko) 멀티캐스트 클라이언트로부터 스트림을 구독하는 방법
US20150341705A1 (en) Network content delivery method using a delivery helper node
US9439100B2 (en) System and method for dynamic rate adaptation based on real-time call quality metrics
Zhao et al. Cross-layer adaptive rate control for video transport over wireless ad hoc networks
EP2127268B1 (en) Transmission of real-time user data frames in packets
KR101384125B1 (ko) 통신 시스템에서 맥 계층의 서비스 품질 파라미터 생성장치 및 방법
KR100486447B1 (ko) 인터넷 멀티미디어 통신에서 사용자 이동성 보장을 위한서비스 품질 제어 방법
US11533237B2 (en) Round-trip estimation
KR20050068433A (ko) 통신 시스템에서의 혼잡 제어 방법 및 장치

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: 09850858

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2011538177

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 13505138

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2009850858

Country of ref document: EP