WO2006132080A1 - 送受信方法およびプログラム並びに記録媒体 - Google Patents

送受信方法およびプログラム並びに記録媒体 Download PDF

Info

Publication number
WO2006132080A1
WO2006132080A1 PCT/JP2006/310205 JP2006310205W WO2006132080A1 WO 2006132080 A1 WO2006132080 A1 WO 2006132080A1 JP 2006310205 W JP2006310205 W JP 2006310205W WO 2006132080 A1 WO2006132080 A1 WO 2006132080A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
information
flow
communication
path
Prior art date
Application number
PCT/JP2006/310205
Other languages
English (en)
French (fr)
Inventor
Suguru Toyokawa
Tohru Sugayama
Hisao Kumai
Original Assignee
Sharp Kabushiki Kaisha
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 Sharp Kabushiki Kaisha filed Critical Sharp Kabushiki Kaisha
Priority to US11/915,714 priority Critical patent/US8165022B2/en
Publication of WO2006132080A1 publication Critical patent/WO2006132080A1/ja

Links

Classifications

    • 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/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/12—Shortest path evaluation
    • H04L45/125—Shortest path evaluation based on throughput or bandwidth
    • 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
    • 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/80—Responding to QoS
    • 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/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/14—Multichannel or multilink protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/02—Selection of wireless resources by user or terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]

Definitions

  • the present invention relates to a transmission / reception method having a communication path selection function in a third layer mobility management protocol such as MobilelP and allocating a band to an application.
  • a third layer mobility management protocol such as MobilelP
  • MobileIPv6 Mobility Support in IPv6, RFC3775
  • OSI Open Systems Inter connection
  • HA home agent
  • CN correspondent node
  • a mopile node always has an invariable address called a home address, and a node that manages the address is a home agent (HA).
  • HA home agent
  • the MN connects to a network other than the home link, which is a link of the HA, it obtains an address called a care-of address (CoA) by some means (RA, DHCPv6, etc.).
  • RA care-of address
  • DHCPv6 DHCPv6, etc.
  • the home address is the address of the link managed by the HA, and thus reaches the HA.
  • the HA forwards the home address to the associated CoA.
  • the MN can always communicate with the home address.
  • the application power that operates on the MN always communicates using the IP address called the home address.
  • CoA is used for the source address or destination address of an actual IPv6 (Internet Protocol Version 6) packet.
  • the home address is notified to the application using technologies such as IPv6 over IPv6 encapsulation and mobility header, and the actual IPv6 address (CoA) is hidden.
  • IPv6 Internet Protocol Version 6
  • CoA IPv6 address
  • the MobilelP compatible terminal can have a plurality of communication media (for example, NIC: Network Interface Card), and can perform handover across the plurality of communication media.
  • NIC Network Interface Card
  • a known problem with MobilelP is that when a MobilelP compatible terminal has multiple communication media, which communication media is used, that is, which address is used for CoA.
  • Patent Document 1 Special Table 2004 — No. 528764
  • Patent Document 1 the ability to route multiple packet flows to multiple communication media (wireless LAN, mobile phone, PHS, etc.) remains a method of selecting one's own communication media (bearer). ing. This method can control transmitted packets but not received packets.
  • the routing in Patent Document 1 is a method for selecting the bearer that it has, and is indifferent to the selection of the other bearer.
  • VoIP Voice over Internet Protocol
  • OSI layer 2 the communication speed of OSI layer 2 is about 120kbps.
  • preferences such as giving priority to delay over bandwidth if it is 120kbps or higher.
  • MobilelP basically does not stipulate the ability to handle handovers with multiple communication media, how to use them successfully, and how to handle them.
  • the preference regarding the flow basically exists for the "downstream flow”.
  • the preference of “I want to watch a large and beautiful video”, “I want to hear audio with little delay”, etc. is the one that the person receiving the data has.
  • the data transmission path is determined by the sender that generates the IP packet.
  • the present invention has been made in view of the above-described circumstances, and a plurality of flows on a communication terminal select a combination of communication media between the user and the other party reflecting the preference of the user or the application for each flow. It is possible to communicate with a plurality of terminals, and to provide a transmission / reception method that can be executed without the preference information being known to the other party.
  • the transmission / reception method is a transmission / reception method for selecting a combination of a flow and a path when transmitting / receiving one or more flows with one or more paths between a plurality of communication terminals.
  • the application passes flow information including at least address information and network preference information to the communication management unit.
  • the communication management unit of each communication terminal transmits the communication media information of the communication terminal based on the flow information to the communication terminal of the communication partner, and the communication management unit of the communication terminal of the communication partner transmits the communication media of the communication terminal that has transmitted
  • the path information is created from the information and the communication media information of the communication terminal of the communication partner, and sent to the communication terminal that sent the information.
  • the communication management unit of each communication terminal creates a combination that maps the flow to the path from the flow information and path information that it has, and sends a score for each combination.
  • Each communication management unit of a plurality of communication terminals selects a high score and combination including its own preference information and sets a path to be used for each data flow. Can be selected.
  • the application in the communication terminal A performs communication.
  • Flow information including at least address information and network preference information is passed to the management unit, and also in communication terminal B, the application passes flow information including at least address information to the communication management unit.
  • the communication management unit of communication terminal A transmits the communication media information possessed by communication terminal A to communication terminal B based on the flow information, and the communication management unit of communication terminal B communicates with the received communication media information possessed by communication terminal A. Create path information from the communication media information of communication terminal B and send it to communication terminal A.
  • the communication management unit of communication terminal A and communication terminal B creates combinations that map flows to paths from the flow information and path information that each has, and Calculate the preference information of each downstream flow and send it.
  • Each communication management unit of communication terminal A and communication terminal B selects a combination with a high score including the preference information of its own uplink, and uses a path for each data flow. A nose can be selected.
  • the preference information in the present invention includes at least one or more requested bandwidth information, delay difference information, billing information, packet loss rate information per unit time, wireless communication corresponding to content usable in an application. Includes media cell information.
  • the communication management unit notifies the application of flow information including at least the bandwidth allocated to the flow represented by the numerical value, and the application is based on the allocated bandwidth. Select content.
  • a path reflecting user or application preferences is selected for each data flow, that is, a combination of oneself and one or more partner communication media is selected. can do. These can be performed without the preference information being known to the other party.
  • the application can select content that matches the available transmission speed in the path to be used.
  • FIG. 1 is a schematic diagram of a system configuration example illustrating a first embodiment of the present invention.
  • FIG. 2 is a sequence diagram of FIG.
  • FIG. 3 (A) is an example of flow information, (B) and (D) are communication media information, and (C) is an example of path information.
  • FIG. 4 is a diagram showing an example of confirmed path information.
  • FIG. 5 is a diagram showing an example of allocated bandwidth.
  • FIG. 6 is a diagram showing an example of a combination table.
  • FIG. 7 is a diagram showing an example of MIP custom information.
  • FIG. 8 is a schematic diagram of a system configuration example for explaining a second embodiment of the present invention.
  • FIG. 9 is a sequence diagram of FIG.
  • FIG. 10 is a diagram showing an example of flow information.
  • FIG. 11 (A) and (C) are examples of communication media information, and (B) is an example of path information.
  • FIG. 12 is a diagram showing an example of confirmed path information.
  • FIG. 13 is a diagram showing an example of a combination table.
  • FIG. 14 is a diagram showing an example of an allocated bandwidth table.
  • FIG. 15 is a diagram showing an example of a score calculation table (flow 1).
  • FIG. 16 is a diagram showing an example of a score calculation table (flow 2).
  • FIG. 17 is a diagram showing an example of a score table.
  • FIG. 18 is a diagram showing an example of a bandwidth allocation table.
  • FIG. 19 is a diagram showing an example of a score calculation table (flow 11-1).
  • FIG. 20 is a diagram showing an example of a score calculation table (Flow 11-2).
  • FIG. 21 is a diagram showing an example of a score table.
  • FIG. 22 (A) shows the path priority, (B) shows the selected combination, and (C) shows an example of the network status.
  • FIG. 23 is a diagram showing an example of a MIP custom table.
  • FIG. 24 is a diagram showing a configuration example of an IP packet.
  • FIG. 25 (A) is a path priority order, (B) is a selected combination, and (C) is a diagram showing an example of a network state.
  • FIG. 26 is a diagram showing an example of a MIP custom table.
  • FIG. 27 is a schematic diagram of a system configuration example for explaining a third embodiment of the present invention.
  • FIG. 28 is a sequence diagram of FIG. 27.
  • FIG. 29 (A) shows flow information, (B) and (D) show communication media information, and (C) and (E) show examples of path information.
  • FIG. 30 is a diagram showing an example of a bandwidth allocated to a flow.
  • FIG. 31 is a diagram showing an example of a MIP custom table.
  • ⁇ 32 A schematic diagram of a system configuration example illustrating a fourth embodiment of the present invention.
  • FIG. 33 is a sequence diagram of FIG. 32.
  • FIG. 34 is a diagram showing an example of flow information.
  • Figure 3 is path information
  • (B) is communication media information
  • (C) and (D) are combinations of flow and path It is a figure which shows the example of matching.
  • FIG. 36 (A) shows path information, (B) shows communication media information, and (C) and (D) show examples of combinations of flows and paths.
  • FIG. 37 is a diagram showing an example of a combination table.
  • FIG. 38 is a diagram showing an example of a combination of flow and path.
  • FIG. 39 is a diagram showing an example of a table for packet generation rules.
  • ⁇ 40 It is a schematic diagram of a system configuration example for explaining a fifth embodiment of the present invention.
  • FIG. 41 is the sequence diagram of FIG. 40 (terminal 10 to terminal 11).
  • FIG. 42 is a sequence diagram of FIG. 40 (terminal 10 to terminal 12).
  • FIG. 43 is the sequence diagram of FIG. 40 (terminal 11—terminal 12).
  • ⁇ 44] is a diagram showing an example of flow information (terminal 10-terminal 12).
  • ⁇ 45] is a diagram showing an example of flow information (terminal 10-terminal 11).
  • FIG. 48 is a diagram showing an example of confirmed path information.
  • FIG. 49 is a diagram showing an example of determining the priority order of flows.
  • FIG. 50 is a diagram showing a flow (terminal 10).
  • FIG. 51 is a diagram showing an example of a score table.
  • FIG. 52 is a diagram showing an example of a selected path.
  • FIG. 53 is a diagram showing an example of a transmission packet rule.
  • FIG. 54 is a diagram showing an example of a network state.
  • FIG. 55 is a diagram showing an example of flow information.
  • FIG. 56 (A) illustrates communication media information, (B) illustrates path information, and (C) illustrates communication media information.
  • FIG. 57 shows a flow (terminal 11).
  • FIG. 58 is a diagram showing an example of a score table.
  • FIG. 59 is a diagram showing an example of a combination table.
  • FIG. 60 is a diagram showing an example of combination priorities.
  • FIG. 61 is a diagram showing an example of a network state.
  • FIG. 62 is a diagram showing an example of a network state.
  • the present invention provides preference (preference) information when transmitting or receiving one or a plurality of flows (data flows) between a plurality of communication terminals via one or a plurality of paths (communication paths).
  • preference preference information when transmitting or receiving one or a plurality of flows (data flows) between a plurality of communication terminals via one or a plurality of paths (communication paths).
  • a method for selecting a CoA combination (CoA of communication partner and own CoA) in mobility 'protocol such as MobilelP for each flow is presented. Specifically, the score is assigned to a path where the flow can be considered. At this time, considering an overlapping combination of a flow and a path, a score is calculated for the combination, transmitted to the partner terminal, and an optimal path is selected by obtaining an understanding. As a result, a CoA suitable for preference among multiple communication terminals is selected.
  • communication terminal A for example, a caller
  • communication partner B for example, a callee
  • the communication terminal B creates path information obtained by merging both communication media information, and returns it to the communication terminal A.
  • Communication terminal A and communication terminal B grasp the network status in each path between communication terminal A and communication terminal B, and communication terminal A scores and ranks the matching condition for the flow request in the path. The ranking and score are transmitted to communication terminal B.
  • communication terminal B assigns points to the path according to its own preference, and selects the optimum path by adding the rank and score transmitted from communication terminal A. The selected path is returned to communication terminal A, and communication terminal A and communication terminal B allocate the optimum bandwidth to the application based on the selected path information.
  • FIGS. A schematic diagram of the system configuration example is shown in Fig. 1, and a sequence diagram is shown in Fig. 2.
  • This first embodiment is a terminal 1 that communicates with each other. 0 and the terminal 11 exist, and the communication management units 14a and 14b and Vol P (Voice over Internet Protocol) applications 13a and 13b installed in the terminal 10 and the terminal 11 are configured. Also, one terminal 10 is connected to the Internet via a communication media NIC 100, and the other terminal 11 is connected to the Internet via a communication media NIC 110 and a communication media NIC 111! / ⁇ Let's do it.
  • the call control protocol used in VoIP is often SIP (Session Initiation Protocol).
  • SIP Session Initiation Protocol
  • the VoIP application 13a passes the flow information to the communication management unit 14a.
  • Flow information Figure 3 (A)) includes at least the destination address (Dst Addr), source address (Src Addr), destination port (Dst Port), and minimum required bandwidth BW (min) Including the bandwidth BW (max) required for highest quality!
  • the destination and source address here are the home addresses of MobileP for mobilel compatible terminals.
  • the address used as the terminal identifier in each protocol is used.
  • Lin6 mobile support layer 3 protocol proposed by Teraoka et al.
  • IPha mobility support layer 3 protocol proposed by NTT DoCoMo
  • the flow information (FIG. 3A) is also passed to the communication management unit 14b in the terminal 11. At this time, the communication management unit 14b notifies the application power of which power it should become.
  • the VoIP application 13a of the terminal 10 that is the calling terminal notifies the communication management unit 14a of the terminal 10 that it is the initiator together with the flow information.
  • the calling side (terminal 10 side) of the VoIP application is the initiator, but the called side (terminal 11 side) of the VoIP application may be the initiator.
  • the communication management unit 14a of the terminal 10 Based on this information, the communication management unit 14a of the terminal 10 generates its own communication media information (Fig. 3 (B)), that is, the communication media NIC10, in order to generate a path with the communication partner terminal.
  • the information of 0 is transmitted to the communication management unit 14b of the communication partner terminal 11.
  • the terminal 11 creates path information (FIG.
  • the nose information includes mutual communication media information (Fig. 3 (D)).
  • the network status is investigated in order to fill in missing data (for example, bandwidth BW in Fig. 3 (C)) in the path information.
  • missing data for example, bandwidth BW in Fig. 3 (C)
  • various network conditions may be stored in a database, and information on the database power network may be acquired, or network information may be acquired by measuring with END—END, There is no problem even if other methods are used.
  • measurement is performed with END—END.
  • the terminal 10 that has obtained the path information measures the network state with the terminal 11 in order to obtain network information. This fills the available bandwidth BW in the path information ( Figure 4).
  • the communication media NIC111 of the terminal 11 it is more convenient to use the communication media NIC111 of the terminal 11 in the flow of the terminal 11 ⁇ terminal 10, and the communication media NIC110 is used in the flow of the terminal 10 ⁇ terminal 11. It is more convenient. Since it is the user who receives the data that has the preference as described above, the user power of the terminal 10 regarding the flow 1 should be selectable depending on the preference of the user of the terminal 11 regarding the flow 2. This preference is, for example, information such as delay (less amount) priority or sound quality priority in VoIP, etc., and may be set in advance or selected on a selection screen each time. .
  • preference information is set in advance.
  • the preference information can be processed as a numerical value, and is calculated by weighting when scoring. This is below BW (min) and BW (max) in Fig. 3 (A) ( * 1) and (* 3) are two numerical values.
  • BW (min) and BW (max) in Fig. 3 (A) ( * 1) and (* 3) are two numerical values.
  • the bandwidth obtained by dividing the bandwidth of the path obtained by the measurement of END—END by the number of flows is allocated to the flow.
  • a method of allocating as a bandwidth can be considered.
  • the bandwidth of the path acquired by the END-END measurement can be halved in order of the priority of the flow. It is done. In other words, in the second method, a low priority flow has the right to obtain only half the bandwidth of a higher priority flow. This bandwidth is assigned as the bandwidth assigned to the flow.
  • Other methods may be used, but it is assumed that a bandwidth is allocated to each flow when the flow is mapped to the path.
  • the communication management unit 14a of the terminal 10 performs scoring based on the preference information of the VoIP application 13a. For example, assume that scoring is performed according to the following arrangement. If the bandwidth force conditions mapped to the flow are met, the score is 100 points, otherwise it is scored as 90 points. Then, the score of the entire nose is weighted, and the total is the combined score. In this embodiment, since there is only one downstream flow, it is difficult to say that it is a thread stitch. However, for the time being, a combination in which flow 1 is mapped to path 1 and a combination in which flow 1 is mapped to path 2 There are two ways of combination, and consider which is more suitable on the terminal 10 side. In addition, the combination in which flow 2 is mapped to path 3 and the combination in which flow 2 is mapped to path 4 are considered to be suitable on the terminal 11 side.
  • FIG. 6A is created on the terminal 10 side and transmitted to the terminal 11.
  • the scores are the same. In a sense, this can be said to indicate that the terminal 10 can use either combination.
  • the terminal 11 It becomes possible to select.
  • the combination that will be processed first programmatically (“Combination 1”) is selected.
  • terminal 11 selects “combination 1” and transmits the result to terminal 10.
  • terminal 11 creates FIG. 6B and sends it to terminal 10.
  • the terminal 10 since there is no preference information regarding uplink, “combination 1”, that is, path 3 is selected, and the terminal 11 is returned as the selected combination.
  • the terminal 10 and the terminal 11 return these information, as a packet generation rule, the terminal 10 has the information in FIG. 7 (A) and the terminal 11 has the information in FIG. 7 (B). .
  • the NI C information is associated with the IP address as shown in Fig. 3 (D).
  • CoAl 10 is used as the source address on the terminal 11 side
  • NIC 110 is used as the source IF
  • the destination address is used as the destination address.
  • the terminal 10 uses CoAlOO as the source address, NIC100 as the source IF, and CoAl 10 as the destination address.
  • the terminal that receives the data is notified of the usable bandwidth by determining the communication path.
  • the terminal that receives data makes a codec change request to the partner terminal as call control on the application, requests the codec change to the terminal on the transmission side, and changes the received content.
  • An example in which the network state is notified on the transmission side will be described in a second embodiment described later.
  • the preference information refers to a collection of preference levels for each value as the entire flow information.
  • FIGS. A schematic diagram of the system configuration example is shown in Fig. 8, and a sequence diagram is shown in Fig. 9.
  • This second embodiment is an example of a videophone, where there are two flows at the top and bottom, and the network state is notified on the transmission side. It is assumed that terminal 10 and terminal 11 exist, terminal 10 is connected to the Internet through communication media NIC 100 and NIC 101, and terminal 11 is connected to the Internet through communication media NIC 110 and communication media NIC 111. Further, this embodiment includes communication management units 14a and 14b, TV phone applications 15a and 15b, and Mobile P management units 16a and 16b installed in the terminal 10 and the terminal 11.
  • the call control protocol used in VoIP is mostly SIP.
  • SIP the flow information with the other terminal is not confirmed until the reception of SDP is completed.
  • the call control that is, SDP transmission / reception is completed with each other and the flow information is determined, the videophone application 15a passes the flow information to the communication management unit 14a.
  • the telephone power S starts with the lowest codec (no image) after the first SDP exchange.
  • FIG. An example of the flow information in this case (including preference information) is shown in FIG.
  • the bandwidth is linked to the codec that can be supported by the application.
  • the preference information for each codec is “* 4, Must” or the like. “Must”, as the name suggests, is the preference level used when this is the minimum requirement.
  • the preference information in this example includes bandwidth, delay difference, cost (up), cost (down), and stability * mobility.
  • the band BW is the same as described above, and is therefore omitted.
  • the delay difference can be measured precisely, there is no problem using the absolute delay time, but if that is not possible, the shortest delay of each path in the direction of oneself is set to ⁇ 0 '' and Take the difference and request for that time. This can be measured, for example, by performing the following test.
  • the flow information including the preference information passed from the TV phone application 15b to the communication management unit 14b has been described above.
  • terminal 10 includes preference information as shown in FIG. Flow information is used.
  • the flow 10-1 is a flow from the terminal 11 to the terminal 10 (that is, a downstream flow), and the destination port is 7080.
  • the minimum required bandwidth is 8kbps
  • the preference level for the 64kbps codec * 5 the delay difference is small
  • the preference preference level * 4 there is no value for cost (up), cost (down) Is a flow with a preference level of * 0, a high level of stability 'mobility, and a preference level of * 1.
  • the flow is from the terminal 11 to the terminal 10 (downstream flow), and the destination port is 9080.
  • the minimum required bandwidth is 0 kbps.
  • preference level * 0, preference level for 100 kbps codec * 3, preference level for 500 kbps * 2, preference level for delay difference * 0, cost (up)
  • preference level * 3 for low cost (down) and a high preference level for stability 'mobility and a preference level * 1.
  • the flow 11-1 is a flow from the terminal 10 to the terminal 11 (upstream flow), the destination port is 7080, only the cost (upstream) is preferred, and the smallest one is selected. Desired, preference level * 1.
  • Flow 11 2 is also a flow from terminal 10 to terminal 11 (upstream flow), the destination port is 9080, only the cost (upstream) is preferred, the minimum is desired, and the preference level * 5 .
  • the flow information (FIG. 10A) is passed to the communication management unit 14b at the terminal 11.
  • the terminal 10 passes the flow information (FIG. 10 (B)) to the communication management unit 14a.
  • the terminal 11 side since the terminal 11 side is more likely to receive the flow information first, it is notified that the terminal 11 side becomes an initiator at the same time when the flow information is passed. As a result, the terminal 11 transmits its own communication media information to the terminal 10.
  • This communication media information is shown in FIG.
  • the terminal 10 After receiving the communication media information, the terminal 10 creates path information by merging its own communication media information with a full mesh, and transmits it to the terminal 11 as path information.
  • this path information includes the direction.
  • Figure 11 (B) shows this path information
  • Figure 11 (C) shows the communication media information attached to the path information.
  • the path information data includes data (BW (measurement)) that is not embedded in the force figure 11 (B) shared by the terminals 10 and 11. These are obtained by a method such as the force obtained from the server, END-END measurement. In the present embodiment, an example of obtaining by measurement is shown.
  • the terminal 10 and the terminal 11 have different values.
  • the path information in which these data are buried is held as FIG. 12 (A) at the terminal 10 and as FIG. 12 (B) at the terminal 11.
  • the cost is a charge for the path and a charge for using the NIC, and is a price per unit.
  • the communication managers 14a and 14b first consider the combination of flow and path.
  • the bandwidth obtained by dividing the bandwidth of the path obtained by the measurement of END-END by the number of flows is allocated to the flow.
  • a method of allocating as a bandwidth is conceivable.
  • the bandwidth of the path acquired by END—END measurement is half the right from the highest priority of the flow. Conceivable. In other words, in the second method, a low priority flow has the right to obtain only half the bandwidth of a higher priority flow! /!
  • FIG. 14 shows data in which the allocated bandwidth is filled as described above. Once the bandwidth for each flow is obtained, it can be scored. A score is assigned for each flow, and the total is taken for each combination. For example, taking “combination 1” as an example, an example of scoring will be explained. For Flow 1, 64kbps or more is allocated for bandwidth. In the case of V, it will be 100 X 5 (64kbps preference level). If it is 8kbps or more and less than 64kbps, give it a score of 80 X 5.
  • the path of the reference differential delay force Oms is set to 100 points, and the slowest path is set to 70 points, and scored by proportional calculation.
  • the score for the delay difference is 85 ⁇ 4 (RTT (Round-Trip Time) delay difference preference level). Cost is a preference level * 0, so it is not considered.
  • RTT Random-Trip Time
  • FIG 15 shows the score for each combination for Flow 1. The score as a flow can be expressed as “ ⁇ ” as described in the first embodiment.
  • the RTT delay difference is not considered because it is a preference level * 0, and the cost is 100 points when the cost is 0, and after that, every time the cost increases by 1, 2 points will be deducted.
  • 100 X 4 (cost preference level), and cost 10 passes, 80 X 4 (cost preference level).
  • points are given in the form of 100 points for A, 90 points for B, and 80 points for C.
  • Figure 16 shows the score of this flow 10-2 for each combination. As a result, the total score for “Combination 1” in Figures 15 and 16 is 2020.
  • Figure 17 shows an example of a combination with a score. All or part of this Fig. 17 is transmitted to terminal 11, and terminal 11 considers its upstream preference (although only cost increase) for flows 10-1 and 10-2, and finally uses it Select a path.
  • the terminal 11 adds a score related to the score (up) to the transmitted combination. Since the flow information possessed by the terminal 11 is shown in FIG. 10A, the preference level of the cost (upstream) relating to the flow 10-1 is * 1, and the preference level of the cost (upstream) relating to the flow 10-2 is * 5. Force with path 1 and 3 having an upstream cost of 0 Since path 2 and 4 have an upstream cost of 10, the total cost is as shown in FIG. 22 (B), and “combination 1” is selected. The selected combination is transmitted from the terminal 11 to the terminal 10 (the selected combination in FIG. 22C).
  • flow 10-1 is transmitted on path 1
  • flow 10-2 is also transmitted on path 1.
  • These settings need to be set in the MobilelP management unit 16b, and these settings are shown in Figure 23.
  • the contents of the routing header type 2 and destination option header are the home address as in MobileIPv6.
  • the header for this flow 10-1 is simply represented as shown in Fig. 24 (A). Also 10 The header for 2 is also shown in Figure 24 (B). Terminal 11 transmits the selected combination information (Fig. 22 (C)), so for flow 10-1 (voice), change to a 64-kbps codec, and for flow 10-2 (image). Therefore, it is judged that the codec can be changed to a 500kbps codec.
  • the communication management unit 14b notifies the information on the network state to the TV phone application 15b.
  • the videophone application 15b of the terminal 11 determines that the codec can be changed, and notifies the videophone application 15a of the terminal 10 that is the receiving terminal of the codec change as SendOnly in SIPZSDP re-INVITE.
  • the communication medium of the other party is limited and transmitted. Restriction conditions are limited to only the path using NIC100, which does not care about the communication media of the other party, and limited to the path using NIC101.
  • FIG. 25A “Combination 3” and “Combination 8” are selected and transmitted to terminal 10 (path priority order notification in FIG. 9). Based on the priority information transmitted from the terminal 11, the terminal 10 selects a path to be used in consideration of the upstream cost based on its own flow information (FIG. 10B).
  • FIG. 25B is acquired.
  • “combination 1” is selected, and the selected combination of FIG. Since the selected combination is determined, the terminal 10 determines the flow path for the terminal 11 and transmits the parameters as shown in FIG. 26 to the MobilelP management unit 16a.
  • These packets can be illustrated simply as shown in FIGS. 24 (C) and 24 (D). The difference between these is the destination address and the port.
  • the videophone application 15a of terminal 10 can change the codec, and the videophone application 15b of terminal 11 that is the receiving terminal is changed to SendOnly in SIP / SDP re-I NVITE. Notice.
  • the codec change is permitted according to SIP / SDP 200 OK and ReceiveOnly accordingly.
  • the flow from the terminal 10 to the terminal 11 is such that the audio flows through the path 5, the image uses the path 7, and the band according to the transmission path is transmitted. It becomes possible.
  • a third embodiment will be described with reference to FIGS.
  • the video distribution server 18 (terminal 11) is connected to the Internet via the NIC 110, and the terminal 10 is connected to the Internet via the NIC 100 and the NIC 101.
  • there are only three types of data in the direction from the terminal 11 to the terminal 10 and are 2 Mbps, 3 Mbps, and 4 Mbps.
  • the terminal 10 acquires flow information (including preference information) using RTSP (Real Time Streaming Protocol), HTTP (Hyper Text Transfer Protocol), or the like.
  • RTSP Real Time Streaming Protocol
  • HTTP Hyper Text Transfer Protocol
  • the terminal 11 which is a moving image distribution server.
  • the obtained flow information (including preference information) is shown in Fig. 29 (A).
  • the description is simplified. Therefore, only band data was used.
  • the terminal 10 that has obtained the flow information transmits its own communication media information (FIG. 29B) to the terminal 11.
  • the terminal 11 adds its own NIC information and transmits path information (FIG. 29 (C)) including the NIC information (FIG. 29 (D)) to the terminal 10.
  • unnecessary data for one-way communication is a hyphen.
  • Terminal 10 obtains network information (bandwidth BW) by accessing the database in order to obtain insufficient network information by obtaining path information.
  • the path information filled with the results is shown in Fig. 29 (E).
  • the terminal 10 Since the terminal 10 has obtained the path information, it creates a table of overlapping combinations of flows and paths. Furthermore, if a bandwidth is allocated to the result, the result shown in FIG. 30 is obtained. In this example, any flow other than “Combination 2” is unusable. As a result, only “Combination 2” has the path priority and is transmitted to the terminal 11. The terminal 11 accepts the priority as it is and transmits it to the terminal 10 as a used path.
  • a fourth embodiment will be described with reference to FIGS.
  • This embodiment is an example in which transmission / reception between three or more communication terminals is performed with respect to transmission / reception between two terminals of the first embodiment.
  • Terminal 10 is connected to the Internet via communication media NIC100 and NIC101
  • terminal 11 is connected to the Internet via communication media NIC110!
  • the terminal 12 is connected by the communication media NIC 120.
  • the system is composed of communication terminals 10, 11, 12, and communication management units 14a, 14b, 14c and VoIP applications 13a, 13b, 13c installed in these communication terminals.
  • the call control protocol used in VoIP uses many SIPs.
  • SIP Session Initiation Protocol
  • the flow information with the partner terminal is not fixed until the reception of SDP is completed. Yes.
  • the call control that is, SDP transmission / reception is completed and the flow information is determined
  • the Vol P application passes the flow information to the communication management unit. Further, in this embodiment, it is assumed that communication is started (data transmission is started) with the minimum bandwidth (8 kbps) after reception of the SDP.
  • VoIP application can create flow information (including preference information). .
  • the VoIP application passes the flow information to the communication management unit.
  • Figure 34 (A) and Figure 34 (B) show the flow information passed by terminal 10
  • Figure 34 (C) shows the flow information passed by terminal 11
  • Figure 34 (D) shows the flow information passed by terminal 12. Show.
  • Each terminal identifies and manages the communication partner with DstAddr or SrcAddr. Therefore, if the communication partner is different, there is no problem even if the flow or path number is applied (see Fig. 35 (A) and Fig. 36 (A)).
  • flow information is separately obtained from the two VoIP applications 13al and 13a2. Since this information comes at different timings, the communication management unit 14a receives each information one by one. In the communication management unit 14a, the operation starts every time one flow information is received, and when the second or more flow information is obtained, the force path information that basically moves the first force is already created. In such a case, the nose information is not newly created and only correction is performed.
  • FIG. 35 (A) shows the nose information between terminal 10 and terminal 11, and FIG. 35 (B) shows the communication media information included in the path information.
  • FIG. 35 (B) shows the communication media information included in the path information.
  • Figure 35 (C) shows this combination on the terminal 10 side
  • Figure 35 (D) shows the combination on the terminal 11 side.
  • the path information is shown in FIG. 36 (A)
  • the communication media information included in the path information is shown in FIG. 36 (B).
  • Figure 36 (C) shows the combinations on the terminal 10 side
  • Figure 36 (D) shows the combinations on the terminal 12 side.
  • Terminal 10 has a combination related to communication with terminal 11 (FIG. 35C) and a combination related to communication with terminal 12 (FIG. 36C).
  • terminal 11 and terminal 12 are only communicating with terminal 10, respectively. Since the terminal 11 and the terminal 12 communicate with only the terminal 10, the same processing as in the first embodiment may be performed. In other words, a combination is created for the downstream flow, and one or more suitable ones are selected.
  • the terminal 10 since the terminal 10 communicates with the terminal 11 and the terminal 12, it is necessary to allocate the path used by the flow and the bandwidth in consideration of the bandwidth that can be used by the terminal itself. Create a combination of downstream flows (Fig. 37 (A)) and select the best one. As a result, the combination for each terminal is transmitted to the partner terminal. This is shown in FIG. 37 (B), where “combination 1” is selected for terminal 11 and “combination 2” is selected for terminal 12. By sending this combination to the other party and obtaining the consent of the other terminal, the node used in each flow is determined.
  • the communication management unit 14a can allocate a bandwidth to the flow, and notifies the applications 13al and 13a2 of the allocated bandwidth.
  • the abrasion determines whether or not the codec needs to be changed, and if it determines “Yes”, it notifies the partner applications 13b and 13c to that effect. More specifically, the terminal 10 transmits “combination 1” to the terminal 11 and “combination 2” to the terminal 12. Here, it is assumed that terminal 11 and terminal 12 responded OK, respectively.
  • the flow from terminal 11 to terminal 10 is “combination 1”, that is, path 1 (the path from NIC 110 of terminal 11 to NIC 100 of terminal 10). Will be used.
  • the flow in the direction from the terminal 12 to the terminal 10 uses “combination 2”, that is, path 2 (path reaching the NI C101 of the terminal 10 from the NIC 120 of the terminal 12).
  • the bandwidth allocated to the flow is determined.
  • the communication management unit 14a notifies this result to the VoIP applications 13al and 13a2.
  • the VoIP applications 13al and 13a2 request the other terminal to change the codec used. This is done by re-INVITE in SIP signaling.
  • the terminal 11 is equivalent to the first embodiment.
  • terminal 11 creates a flow and path combination (FIG. 38A) in communication with terminal 10, selects the one with the highest score (combination 2), and transmits it to terminal 10.
  • the terminal 10 notifies the terminal 11 as OK (in consideration of the uplink cost).
  • the path to be used for the flow from terminal 10 to terminal 11 (flow 2) is determined, and the usable bandwidth is also determined.
  • 64kbps is allocated and notified to the VoIP application 13b.
  • the VoIP application 13b of the terminal 11 determines that the codec needs to be changed, and instructs the VoIP application 13a of the terminal 10 to change the codec by re-INVITE.
  • the terminal 10 is the same as in the first embodiment. That is, a combination of a flow and a path in communication with the terminal 10 (FIG. 38 (B)) is created, the one with the highest score is selected (combination 1), and transmitted to the terminal 10.
  • the terminal 10 notifies the terminal 12 as OK (in consideration of the uplink cost).
  • the path to be used for the flow from terminal 10 to terminal 12 (flow 2) is determined, and the usable bandwidth is also determined.
  • 64kbps is allocated and notified to the VoIP application 13c.
  • the VoIP application 13c of the terminal 12 determines that the codec needs to be changed, and instructs the VoIP application 13a of the terminal 10 to change the codec by re-INVITE.
  • FIG. 39A shows a table created by the terminal 10
  • FIG. 39B shows a table created by the terminal 11
  • FIG. 39C shows a table created by the terminal 12.
  • an OK signal is sent as the selected combination.
  • the selected combination is not necessarily "combination" data.
  • FIG. 40 to FIG. 62 are diagrams for explaining a fifth embodiment in which video streaming is viewed while making a videophone call by transmission / reception between three or more terminals.
  • a grandson and his grandfather are watching football while making a videophone call.
  • the terminal 10 includes a TV phone application 15a, a video viewing application 17a, a communication management unit 14a, and a MobilelP management unit 16a.
  • the terminal 11 includes a TV phone application 15b, a video viewing application 17b, a communication management unit 14b, and a MobilelP management unit 16b.
  • the terminal 12 includes a moving image distribution server 18, a communication management unit 14c, and a MobilelP management unit 16c.
  • FIG. 41 shows a video phone sequence between terminal 10 and terminal 11
  • FIG. 42 shows a sequence related to the video distribution application between terminal 10 and terminal 12, and video distribution regarding video distribution between terminal 11 and terminal 12.
  • Figure 43 shows this sequence.
  • Each sequence shown in FIGS. 41 to 43 is the same as that of the second embodiment shown in FIG. Ie
  • the preference information regarding delay is small, and the preference level is “* 2” for things, and the preference level is “* 3” for cost reduction. With regard to mobility and stability, both of them prefer something high, but it has a preference level of * 1 and is not much important.
  • the fact that a videophone comes in from terminal 11 means that it receives a SIPZSDP INVITE message.
  • the videophone application 15a of the terminal 10 creates flow information from the SDP in the INVITE message and notifies the communication management unit 14a. This flow information is shown in FIG.
  • FIG. 45 shows information of four flows.
  • the flow 10-2 is a flow from the terminal 11 to the terminal 10, that is, the destination address is IP10 and the source address is IP11.
  • the destination port is 7080, which is the voice flow, but what the application does not make sense in the communication management unit 14a, and what is the preference for this flow is important. Also important is the power with which this flow 10-2 is associated with any application. In other words, it is important for this flow to be a videophone flow. This means that it is not important whether it is audio or video for a videophone.
  • the communication management unit stores that this flow 10-2 is a videophone flow.
  • This identifier can be a PID or port number.
  • the minimum required bandwidth is 8 kbps. This is a force that can be associated with the codec used by applications such as G72 9.1.
  • the codec used does not make sense, and how much bandwidth is required is important.
  • the preference for bandwidth is 64kbps, given as * 5. This is a force that can be associated with, for example, the G711 Mu-low codec. As described above, this does not make sense for the communication management unit 14a. It is important to have a preference level of * 5 for this band of 64 kb ps.
  • the request for delay should be considered at the preference level * 4, and the cost should be considered at the preference level * 0! It has become good.
  • the mobility 'stability is at a preference level * 1.
  • the next flow 10-3 is a flow from the terminal 11 to the terminal 10, that is, the destination address is IP10 and the source address is IP11 similarly to the flow 10-2.
  • the destination port is 9080, which is a videophone image flow, but what the application does not make sense in the communication management unit 14a, and what is the preference for this flow? is important.
  • the minimum bandwidth is 0kbps, which means that no image is allowed.
  • the preference level for 100kbps is * 3
  • the preference level for 500kbps is * 2.
  • Delay is not considered at preference level * 0, cost (down) is at preference level * 3, and mobility 'stability is at preference level * 1.
  • Also important is the power with which this flow 10-3 is associated with any application. In other words, it is important that this flow is a videophone flow. This means that it is not important whether it is a voice or video image of a videophone.
  • the communication management unit stores that this flow 10-3 is a videophone flow.
  • This identifier can be a PID or port
  • the next flow 112 is a flow from the terminal 10 to the terminal 11, in other words, an upstream flow, that is, the destination address is IP11 and the source address is IP10. Therefore, there is a preference only for the upstream cost, and the preference level is * 1.
  • the flow 11-3 is an upstream flow from the terminal 10 to the terminal 11, and the preference level of the upstream cost is set to * 0 and is not considered.
  • the communication management unit 14a Based on the flow information, the communication management unit 14a operates. A path (path 10-12-1 and path 10-12-2) has already been formed with the terminal 12. The path information and NIC information are shown in Figs. 46 (A) and 46 (B). Flow 10—1 is selected for these paths. It is assumed that the path 10-12-2 is currently used. Since new downstream flows (flow 10-2, flow 10-3) have been added, it is necessary for the communication management unit 14a to re-map the flow path.
  • the terminal 10 transmits NIC information to the terminal 11, and obtains path information (path 10-11-11 to path 10-11-8).
  • the path information and NIC information obtained here are shown in Fig. 47 (A) and Fig. 47 (B).
  • Fig. 47 (A) and Fig. 47 (B) Acquire the network status to complete the figure obtained here (details of acquisition method) The description is omitted).
  • the terminal 10 obtains FIG. 48 (A), and the terminal 11 obtains FIG. 48 (B).
  • the moving image streamer with the highest priority selects the path in order.
  • flow 10-1 selects a path.
  • flow 10-1 shall have the right to occupy half of the bandwidth (measurement) of the nose.
  • the reason for the half is that it becomes the sum (1Z2 + 1Z4 + 1 ⁇ 8 ⁇ ) power of the geometric series of 1Z2.
  • a large value of half of the bandwidth (measurement) and the bandwidth (Max) in the flow information is given as the bandwidth allocated to the flow.
  • the next flow 10-2 selects a path from the path 10-11-11 to the path 10-11-4.
  • flow 10-1 mapped to path 10-12-2 can affect the available bandwidth of paths 10-1 1-1 to 10-10-11-4. Possible force It is assumed that there is no influence in this embodiment. In some cases, it is assumed that there is a right to occupy half of the remaining bandwidth after calculating the available bandwidth after taking this into consideration.
  • Figure 51 (B) shows the score of each path considering the bandwidth allocated when flow 10-2 selects each path (path 10-11-11 to path 10-11-4). Shown in As a result, the flow 10 0-2 selects the path 10-11-2.
  • the communication management unit 14a notifies the terminal 11 and the terminal 12 of the path priority.
  • This path priority is a combination of flow and path as described above.
  • the flow 10-1 transmits the combination of selecting the path 10-12-2 out of the combination of two flows, that is, two paths. This is shown in Figure 52 (B).
  • the rule shown above in Figure 53 (A) shows that packets with a flow where the source HoA is IP11, the destination HoA is IP10, and the destination port is 7080 are NIC111 on the source communication media. Using IP, IP111 is used for the source CoA and IP100 is used for the destination CoA. Also, the rule shown below in Figure 53 (A) shows that the packet of the flow with the source HoA as IP11, the destination HoA as IP10, and the destination port as 9080 must have NIC110 as the source communication media. It is a rule that uses IP110 for the source CoA and IP100 for the destination CoA. This The MobilelP management unit 16b of the terminal 11 generates an appropriate packet according to the protocol.
  • terminal 12 determines a transmission packet generation rule. As shown in Figure 53 (B), this generation rule is for a knot with destination HoA of IP10, source HoA of IP12, and destination port power of 9200, using NIC 120 as the source communication media. Thus, the rule uses IP12 for the source CoA and IP101 for the destination CoA. According to this rule, the MobilelP management unit 16c of the terminal 12 generates an appropriate packet.
  • the terminal 10 is notified of the combination selected from the terminal 11. Based on the notification, the terminal 10 notifies the videophone application 15a of the network status (FIG. 54 (A)).
  • This network state shows that the bandwidth allocated to the flow with destination Ho A IP 10 and source Ho A IP11, destination port 7080 is 64k bps, stability is B, cost is 4, RTT delay difference is 0, the bandwidth allocated to the flow with destination Ho A as IP10, source HoA as IP11 and destination port as 9080 is 500kbps, stability is A, cost is 2, RTT delay difference is 50 It means that.
  • the communication management unit knows that the network status to be notified is flow 10-2 and flow 10-3 is a TV phone flow, it is notified to the TV phone application.
  • the TV phone application 15a transmits SIPZSDP re-I NVITE Receive Only in order to change the codec used for the TV phone application 15b of the terminal 11.
  • Terminal 11 transmits 200 OK as 200 OK.
  • the usage combination is notified from the terminal 12 separately from the communication of the terminal 11. Based on the notification, the terminal 10 notifies the video viewing application 17a of the network status.
  • This network status is shown in Fig. 54 (B). This means that the bandwidth allocated to the flow with destination HoA as IP10, source HoA as IP12 and destination port as 9200 is 6Mbps, stability is A, cost is 5, and RTT delay difference is 50. Means. These notifications are sent to the video application because the communication management unit knows that the flow 10-1 is the flow of the video application.
  • the video viewing application 17a of the terminal 10 notifies the video distribution server 18 of the terminal 12 which timing to change to which codec in RTSP SETUP.
  • the video distribution server 18 accepts the request and notifies the video viewing application of the communication terminal 10 of 200 OK. This completes the optimization of the downlink flow to the terminal 10.
  • the grandchild watched the soccer video viewing application 17a via the pass 10-12-2 with 6Mbps quality, and the videophone application 15a received the audio via the pass 10-11-2 with 64kbps quality. It is possible to view at 500kbps via path 10-11-11.
  • the grandfather makes a videophone call to the grandchild. This is realized by notifying the terminal 10 of the SIPZSDP INVITE, and receiving a call by the grandchild is returning a SIPZSDP 200 OK.
  • the video phone application 15b of terminal 11 receives SIPZSDP 200 OK and creates flow information based on this information.
  • the videophone is connected with the minimum conditions (8kbps audio, no image).
  • a video viewing request is made by the grandfather's hand.
  • flow information is obtained by exchanging RTSP between the video viewing application 17b of the terminal 11 and the video distribution server 18 of the terminal 12.
  • the communication management unit 14b of the terminal 11 receives the flow information related to the videophone (Fig. 55 (A)) from the videophone application 15b and the flow information related to the video viewing (Fig. 55 (B)) from the video viewing application 17b. It is.
  • the characteristics of the flow information are as follows. For the flow information of the videophone, all the costs are at the preference level * 0 and high quality is preferred. This is a preference for videophones with grandchildren who prefer cost-effective and high-quality ones. On the other hand, with regard to video viewing, high quality video is not so good, and cost is given priority.
  • the preference level of the lOOkbp s codec is * 1, the preference level of the codec of 500 kbps * 7, and the delay difference is small
  • the preference level is * 2
  • the cost is not considered
  • the stability is the preference level * 2
  • the mobility is the preference level * 1.
  • the minimum 64kbps is essential, the preference level of the 1Mbps codec * 1, the preference level of the 6Mbps codec * 1, and the preference level that prefers a small delay difference * 1, Cost preference level * 6, Preference level * 1 for stability, Preference level * 1 for mobility.
  • the communication management unit 14b of the terminal 11 obtains the flow information, it creates a path with the terminal 10 and the terminal 12. Since the path to terminal 10 is as described above, it is omitted here. Here, it is necessary to create a path with the terminal 12.
  • Terminal 11 transmits its own communication media information (FIG. 56 (A)) to terminal 12.
  • the terminal 12 creates a path, and transmits path information (FIG. 56 (B)) and communication media information (FIG. 56 (C)).
  • terminal 11 Since terminal 11 has acquired flow information and path information, an optimal combination is selected.
  • the flow is prioritized in the same manner as shown in FIG. This is a GUI as shown in Fig. 49 (B), where the first place is the video phone video, the second is the video phone voice, and the third is the video watch. Therefore, the video phone video, that is, flow 11-3, selects the path first.
  • Figure 57 shows the sequence of these flows.
  • the flow 11-3 selects a path from the paths 10-11-11-5 to 10-11-11. Similar to the above, scoring is performed including the bandwidth that can be used when the path is used. The result is shown in FIG. As a result, the video phone image selects path 10-11-5 and is allocated 500kbps. In this embodiment, the lower rank is also taken into consideration.
  • the path 10-11-5 is a path using the communication medium: NIC100 of the terminal 10 which is the communication partner. Because the other party may refuse due to cost preference, use NIC101 If it is, pass 10-11-6 or pass 10-11-8 is better! For this, the path 10-11-8 is selected from the score.
  • the flow 112 of the audio flow of the videophone selects a path.
  • Flow 11 2 selects a path from nose 10-11-5 to path 10-11-8.
  • scoring is performed including the bandwidth that can be used when the path is used.
  • the results are shown in Fig. 58 (B).
  • video phone images select path 10-11-8 and are allocated 64kbps. Also, as in the above case, the lower ranks are also taken into consideration.
  • the path 10-11-8 uses the NIC 101 of the terminal 10, the path 10-11-5 and the path 10-11-7 using the NIC 100 are selected. This will select paths 10–11–5.
  • the flow 11-1 of the video viewing flow selects a path.
  • Flow 11—1 selects a path from path 1 1-12-1 to node 11-12-2. Similar to the above, scoring is performed including the bandwidth that can be used when the path is used. The result is shown in Fig. 58 (C).
  • the video viewing flow selects path 11-12-1 and is allocated 1Mbps.
  • the path 11—12—2 was selected, the preference for the power cost that resulted in a 6 Mbps flow was high, so for the viewing of soccer, a low-cost path at 1 Mbps was selected.
  • terminal 11 creates a priority order (FIG. 59 (A)) for the combination of the flows related to the videophone for terminal 10.
  • “Combination 1” is selected without regard to the NIC of the other party (terminal 10).
  • a combination priority order (FIG. 59B) is created for terminal 12.
  • the terminal 10 adds the preference information of its own upstream cost with respect to the obtained priority order, and selects the use combination.
  • Figure 60 (A) shows the result of adding the up cost score.
  • “combination 1” is selected as the selected combination, and FIG. 60 (B) is transmitted from terminal 10 to terminal 11.
  • terminal 10 transmits a packet to terminal 11 Therefore, the MobilelP management unit 16a is notified of the information shown in FIG. 61 (A).
  • Fig. 61 (A) shows a flow where the source HoA is IP10, the destination HoA is IP11, and the destination port is 7080, using IP101 as the source CoA and NIC as the source communication media.
  • IP 111 is used for the destination Co A.
  • the flow with source HoA IP10, destination HoA IP11, destination port 9080 uses IP100 as the source CoA, from NIC100 as the source communication media, and IP110 as the destination CoA. It is set. As a result of these settings, it is possible to use the path 10 11 8 for the flow 11-2 and the path 10-11-5 for the flow 11-3.
  • the communication management unit 14b of the terminal 11 receives the use combination determined by the terminal 10.
  • the communication management unit 14b notifies the videophone application 15b of the network state (FIG. 61 (B)).
  • the upper part of Fig. 61 (B) shows a flow where the source IP address is IP10, the destination IP address is IP11, and the destination port is 7080. Means 1 and the RTT delay difference is 0. As in the case of the terminal 10, these are grasped by the communication management unit, and the network status is notified to the appropriate abrasion.
  • the flow with source IP address IP10, destination IP address IP11 and destination port 9080 is hit with 500kbps bandwidth force S ij and stability is A, This means that the cost is 3 and the RTT delay difference is 90.
  • the videophone application 15b of the terminal 11 that has obtained the information requests the videophone application 15a of the terminal 10 to change the codec using SIP / SDP Re-INVITE Receive Only.
  • the codec is changed when the TV phone application of the terminal 10 returns SIPZSDP 200 OK Send Only. This completes the setting for the TV phone.
  • the terminal 11 exchanges with the terminal 12 in parallel with the above exchange with the terminal 10.
  • the terminal 11 transmits the combination of FIG. 59 (B) to the terminal 12.
  • Terminal 12 communicates Since it has only one media, it does not list multiple candidates and is a single combination.
  • the terminal 12 receives the combination of FIG. 59 (B), accepts the combination as OK, and returns the combination of FIG. 59 (B) as the selected combination.
  • the information in FIG. 62 (A) is notified to the MobilelP management unit 16c. This is because the source HoA is IP12, the destination Ho A is IP11, the destination port is 9200, the source IP address is IP12, the source communication media is from NIC120, and the destination CoA is It is set to use IP110.
  • the communication management unit 14b of the terminal 11 that has received the usage combination from the terminal 12 notifies the video viewing application 17b of the network state (FIG. 62 (B)).
  • the video viewing application of terminal 11 that has received this network status requests codec change in RTSPZSDP Setup.
  • the video distribution server of terminal 12 responds with 200 OK.
  • the transmission / reception method according to the present invention described above is executed by a computer installed in a communication terminal. For this reason, a program is used that shows a procedure for executing data transmission / reception between various applications and the communication management unit, and transmission / reception between communication terminals via various communication media.
  • transmission / reception according to the present invention can be performed using a computer-readable recording medium in which the program for causing a computer to execute is recorded.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

　通信端末上における複数のフローは、フロー毎にユーザもしくはアプリケーションの嗜好を反映した自分と相手の通信メディアの組み合わせを選択することができ、しかも、嗜好情報を相手に知られることなく実行可能な送受信方法を提供する。通信端末間で、１以上のパス（通信路）で、１以上のフロー（データの流れ）を送受信する際に、アプリケーションの嗜好情報を参考にして、ＭｏｂｉｌｅＩＰにおけるＣｏＡの組み合わせ（通信相手のＣｏＡと自身のＣｏＡ）を選択する手段を提示する。フローとパスの組み合わせを考慮し、その組み合わせに対してスコアを計算し、相手端末に送信し、了解を取ることによって最適のパスを選択する。その結果、各フローごとに両者の嗜好に適したＣｏＡの選択が行われる。

Description

明 細 書
送受信方法およびプログラム並びに記録媒体
技術分野
[0001] 本発明は、 MobilelPなどの第三層移動管理プロトコルにおける通信路選択機能を 有し、アプリケーションに帯域を割り当てる送受信方法に関する。
背景技術
[0002] 近年、 MobileIPv6 (Mobility Support in IPv6、 RFC3775)等の IP層でのモ ピリティサポートの研究'開発が盛んである。 MobilelPは、 OSI (Open Systems Inter connection) 7階層モデルにおける第三層のプロトコルで、上位アプリケーションから クライアントの移動 (ネットワーク Z通信メディアの切り替えや、通信の瞬断など）を隠 蔽し、通信を継続させる技術である。この MobilelPは、モパイルノード（MN : Mobile Node) ·ホームエージェント（HA： Home Agent)、コレスポンデントノード（CN： C orrespondent Node)と呼ばれるノードから構成される。
[0003] モパイルノード（MN)は、ホームアドレスと呼ばれる常に不変なアドレスを有しており 、そのアドレスを管理するノードがホームエージェント（HA)である。 MNは HAのリン クであるホームリンク以外のネットワークに接続した際、ケアォブアドレス (CoA:Care-o f Address)と呼ばれるアドレスを何らかの手段 (RA、 DHCPv6など）で得る。ここで得 た CoAは、 HAに Binding Updateというメッセージで通知される。
[0004] この結果、 MNと通信した ソード（ = CN)がホームアドレス宛にパケットを送信する と、ホームアドレスは HAの管理するリンクのアドレスであるので、ー且、 HAに届く。そ の際に、 HAは、ホームアドレスを関連付けされた CoA宛に転送する。この結果、常 に MNは、ホームアドレスで通信可能となる。 MNにおいては、 MN上で動作するァ プリケーシヨン力 前記ホームアドレスと呼ばれる IPアドレスを常に使用し通信する。
[0005] 実際の IPv6 (Internet Protocol Version 6 )パケットのソースアドレスもしくはデイス ティネーシヨンアドレスには CoAを用いる。 IPv6 over IPv6カプセル化、 mobility headerなどの技術を用いてアプリケーションにはホームアドレスを通知し、実際に 用いる IPv6アドレス (CoA)を隠蔽している。その結果、前記アプリケーションは、以 下のような特性を持つ。
[0006] (1)ネットワークとの接続性がある際には、ホームアドレスで常に通信が可能である 。 （2)通信中に、複数の異なるネットワークへのハンドオーバーが出来るようになる。 すなわち、 MobilelP対応端末は、複数の通信メディア（例えば、 NIC : Network Inter face Card)を有することが可能で、前記複数の通信メディアに跨ったハンドオーバー が可能である。 MobilelPの既知の問題点として、 MobilelP対応端末が複数の通信 メディアを有する場合に、どの通信メディアを使用するカゝ、すなわち CoAにどのァドレ スを用いるかと ヽぅ問題がある。
[0007] また、 MobilelPは、複数の CoAを有する場合、複数の通信メディアを同時に使用 するマルチホームを実現できるといわれることが多い。し力しながら、実際の Mobilel Pの仕様では、マルチホームを実現することはできない。そこで、それを実現する一 手段として、全ての CoAを通信相手に対して通知するべきであるとの趣旨から、複数 の CoAを有する際の MobilelPの仕様である「draft— wakikawa— mobileip— mul tiplecoajが提案されている。また、複数の通信メディアを同時に使用する技術として 、特許文献 1が知られている。
特許文献 1：特表 2004— 528764号公報
発明の開示
発明が解決しょうとする課題
[0008] 前記特許文献 1では、複数の通信メディア（無線 LAN、携帯、 PHS等）に対して複 数のパケットフローをルーティングする技術である力 自分の通信メディア (ベアラ）を 選択する方法に留まっている。この方法は、送信パケットの制御は可能であるが受信 パケットの制御はできない。すなわち、特許文献 1におけるルーティングとは、自身の 有するベアラを選択するための手法であって、相手のベアラの選択に関しては無関 心である。
[0009] し力しながら、複数通信メディアを有する端末同士での通信においては、ネットヮー クの相性などから、お互いが勝手にべストを選んだ場合がベストな解になるとは限ら ない。前記特許文献 1においては、例えば、端末 Aが 2つの通信メディアを有し、端 末 Bが 3つの通信メディアを有している場合、前記発明では端末 Aが 2つの自由度、 端末 Bが 3つの自由度を持つだけであるが、実際には 2 X 3 = 6のうち最も適切なもの を選択する必要がある。また、アプリケーションによっては、帯域よりもその他のパラメ ータが重要なことも想定される。
[0010] 例えば、 VoIP (Voice over Internet Protocol)にお 、ては、最高レートのコーデック を用い、 MobileIPv6で接続したところで、たかだか OSIの第 2層の通信速度におい て 120kbps程度あれば十分である。その結果、 120kbps以上であれば、帯域よりも 遅延等を優先するべきなどのプリファレンス（嗜好）が存在する。また、 MobilelPでは 、基本的に複数の通信メディアでのハンドオーバーには対応している力 それらをど う上手く使うか、どう操るかは規定されていない。
[0011」 3;た、 「draft— wakikawa— mobileip— multiplecoaj【こお ヽても、マノレチホーム には対応している力 具体的にどのようにして、マルチホームを実現する力、また、最 適な通信メディアの組み合わせを選択することにつ 、ては規定されて 、な 、。例えば 、通信の品質と課金問題は密接に関係するが、一方が課金を気にせずに高品質な 通信を望み、他方では品質よりも課金を重要視することもある。
[0012] さらに、課金には様々な形態がありえるため、双方が自分にとって最適な通信メディ ァを選択するだけでは解決できない問題が起こりうる。そのため、これらを実現する際 に、例えば、通信端末同士がプリファレンスそのものをやり取りすることも考えられるが 、これはプライバシー上の問題ともなる。また、複数のアプリケーションが存在する場 合に、どのような手順が必要かは明らかにされていない。すなわち、 1つの通信路に アプリケーションがマップされた場合、その通信路の使用可能な帯域は減少してしま う。そのため、通信路にアプリケーションをマップする際には、通信路とアプリケーショ ンの重複組み合わせを考えなくてはならな 、が、この考慮は未だされて ヽな 、。
[0013] また、フロー（データの流れ）に関する嗜好は基本的には「下りフロー」に対して存在 することである。すなわち、「大きい'綺麗な動画が見たい」、「遅延の少ない音声が聞 きたい」等といった嗜好は、そのデータを受け取る人が持っているものである。しかし ながら、データの伝送路は、 IPパケットを生成する送信者によって決められる。また、 これらの課題は、 2つの端末間の通信だけでなぐ複数の端末間での通信での実現 も要望されている。 [0014] 本発明は、上述した実情に鑑みてなされたもので、通信端末上における複数のフロ 一は、フロー毎にユーザもしくはアプリケーションの嗜好を反映した自分と相手の通 信メディアの組み合わせを選択することができ、複数の端末との通信も可能で、しか も、嗜好情報を相手に知られることなく実行可能な送受信方法の提供を目的とする。 課題を解決するための手段
[0015] 本発明による送受信方法は、複数の通信端末間で、 1以上のパスで、 1以上のフロ 一を送受信する際に、フローとパスの組み合わせを選択する送受信方法である。複 数の各通信端末において、アプリケーションは、通信管理部に少なくともアドレス情報 及びネットワークに関する嗜好情報を含むフロー情報を渡す。各通信端末の通信管 理部は、フロー情報に基づき通信端末の有する通信メディア情報を通信相手の通信 端末に送信し、通信相手の通信端末の通信管理部は、発信した通信端末の有する 通信メディア情報と通信相手の通信端末の有する通信メディア情報から、パス情報を 作成して発信した通信端末に送信する。
各通信端末の通信管理部では、それぞれ有するフロー情報とパス情報から、パス にフローをマップする組み合わせを作成して、各組み合わせに関するスコアを送信し
、複数の通信端末の各々の通信管理部において、自身の上りの嗜好情報を含めて スコアの高 、組み合わせを選択し、各データフロー毎にパスを使用するように設定し 、各フロー毎にノ スを選択可能とする。
[0016] また、本発明による他の送受信方法は、通信端末 Aと通信端末 B間で、 1以上のパ スで、 1以上のフローを送受信する際に、通信端末 Aにおいて、アプリケーションは、 通信管理部に少なくともアドレス情報及びネットワークに関する嗜好情報を含むフロ 一情報を渡し、通信端末 Bにおいても、アプリケーションは通信管理部に少なくともァ ドレス情報を含むフロー情報を渡す。通信端末 Aの通信管理部は、前記フロー情報 に基づき通信端末 Aの有する通信メディア情報を通信端末 Bに送信し、通信端末 B の通信管理部は、受信した通信端末 Aの有する通信メディア情報と通信端末 Bの有 する通信メディア情報から、パス情報を作成して通信端末 Aに送信する。
通信端末 A及び通信端末 Bの通信管理部では、それぞれが有するフロー情報とパ ス情報から、パスにフローをマップする組み合わせを作成し、各組み合わせに関する スコアを各下りフローの嗜好情報力 計算し送信する。通信端末 A及び通信端末 B の各々の通信管理部において、自身の上りの嗜好情報を含めて前記のスコアの高 い組み合わせを選択し、データフロー毎にパスを使用するように設定し、フロー毎に ノ スを選択可能とする。
[0017] また、本発明における前記の嗜好情報は、少なくともアプリケーションで使用可能な コンテンツに対応した 1以上の要求帯域情報、遅延差情報、課金情報、単位時間当 たりのパケットロス率情報、無線通信メディアのセル情報等を含む。また、フローの使 用するパスが決定した後に、通信管理部はアプリケーションに少なくとも数値で表さ れるフローに割り当てられた帯域を含むフロー情報を通知し、アプリケーションは割り 当てられた帯域をもとにコンテンツを選択する。
発明の効果
[0018] 本発明によれば、通信端末上における 1以上のデータフローは、各データフロー毎 にユーザもしくはアプリケーションの嗜好を反映したパス、すなわち、自分と 1以上の 相手の通信メディアの組み合わせを選択することができる。これらは、嗜好情報を相 手に知られることなく実行可能である。また、アプリケーションは、使用するパスにお いて使用可能な伝送速度に見合ったコンテンツを選択することが可能となる。
図面の簡単な説明
[0019] [図 1]本発明の第 1の実施形態を説明するシステム構成例の模式図である。
[図 2]図 1のシーケンス図である。
[図 3] (A)はフロー情報、（B) , (D)は通信メディア情報、（C)はパス情報の例を示す 図である。
[図 4]確定したパス情報の例を示す図である。
[図 5]割り当てられた帯域の例を示す図である。
[図 6]組み合わせ表の例を示す図である。
[図 7]MIPカスタム情報の例を示す図である。
[図 8]本発明の第 2の実施形態を説明するシステム構成例の模式図である。
[図 9]図 8のシーケンス図である。
[図 10]フロー情報の例を示す図である。 [図 11] (A) , (C)は通信メディア情報、（B)はパス情報の例を示す図である。
[図 12]確定したパス情報の例を示す図である。
[図 13]組み合わせ表の例を示す図である。
圆 14]割り当てられた帯域表の例を示す図である。
[図 15]スコア計算表 (フロー 1)の例を示す図である。
[図 16]スコア計算表 (フロー 2)の例を示す図である。
[図 17]スコア表の例を示す図である。
圆 18]帯域割当表の例を示す図である。
[図 19]スコア計算表 (フロー 11— 1)の例を示す図である。
[図 20]スコア計算表（フロー 11 - 2)の例を示す図である。
[図 21]スコア表の例を示す図である。
[図 22] (A)はパスの優先順位、 (B)は選択された組み合わせ、（C)はネットワーク状 態の例を示す図である。
[図 23]MIPカスタム表の例を示す図である。
[図 24]IPパケットの構成例を示す図である。
[図 25] (A)はパスの優先順位、 (B)は選択された組み合わせ、（C)はネットワーク状 態の例を示す図である。
[図 26]MIPカスタム表の例を示す図である。
圆 27]本発明の第 3の実施形態を説明するシステム構成例の模式図である。
[図 28]図 27のシーケンス図である。
[図 29] (A)はフロー情報、（B) , (D)は通信メディア情報、（C) , (E)はパス情報の例 を示す図である。
[図 30]フローに割り当てられる帯域の例を示す図である。
[図 31]MIPカスタム表の例を示す図である。
圆 32]本発明の第 4の実施形態を説明するシステム構成例の模式図である。
[図 33]図 32のシーケンス図である。
[図 34]フロー情報の例を示す図である。
[図 3 (A)はパス情報、（B)は通信メディア情報、（C) , (D)はフローとパスの組み合 わせの例を示す図である。
[図 36] (A)はパス情報、（B)は通信メディア情報、（C) , (D)はフローとパスの組み合 わせの例を示す図である。
[図 37]組み合わせ表の例を示す図である。
[図 38]フローとパスの組み合わせの例を示す図である。
[図 39]パケット生成ルールのためのテーブル例を示す図である。
圆 40]本発明の第 5の実施形態を説明するシステム構成例の模式図である。
[図 41]図 40のシーケンス図（端末 10—端末 11)である。
[図 42]図 40のシーケンス図（端末 10—端末 12)である。
[図 43]図 40のシーケンス図（端末 11—端末 12)である。
圆 44]フロー情報 (端末 10—端末 12)の例を示す図である。
圆 45]フロー情報 (端末 10—端末 11)の例を示す図である。
圆 46]パス情報と通信メディア情報 (端末 10—端末 12)を示す図である。
圆 47]パス情報と通信メディア情報 (端末 10—端末 11)を示す図である。
[図 48]確定したパス情報の例を示す図である。
[図 49]フローの優先順位を決める例を示す図である。
[図 50]フロー (端末 10)の様子を示す図である。
[図 51]スコア表の例を示す図である。
[図 52]選択されたパスの例を示す図である。
[図 53]送信パケットのルールの例を示す図である。
[図 54]ネットワーク状態の例を示す図である。
[図 55]フロー情報の例を示す図である。
[図 56] (A)は通信メディア情報、（B)はパス情報、（C)は通信メディア情報の例を説 明する図である。
[図 57]フロー (端末 11)の様子を示す図である。
[図 58]スコア表の例を示す図である。
[図 59]組み合わせ表の例を示す図である。
[図 60]組み合わせの優先順位の例を示す図である。 [図 61]ネットワーク状態の例を示す図である。
[図 62]ネットワーク状態の例を示す図である。
符号の説明
[0020] 10, 11, 12· ··端末、 13a, 13b, 13c- "VoIPアプリケーション、 14a, 14b, 14c…通 信管理部、 15a, 15b- "TV電話アプリケーション、 16a, 16b, 16c- "MobileIP管理 部、 17a, 17b…動画視聴アプリケーション、 18· ··動画配信サーバ。
発明を実施するための最良の形態
[0021] 本発明は、複数の通信端末間で、 1つ又は複数のパス (通信路)で、 1つ又は複数 のフロー（データの流れ)を送受信する際に、嗜好 (プリファレンス)情報を参考にして 、各フローごとに MobilelP等のモビリティ'プロトコルにおける CoAの組み合わせ（通 信相手の CoAと自身の CoA)を選択する手段を提示するものである。具体的には、 フローを考えうるパスに当てはめてスコア付けをおこなう。これに際して、フローとパス の重複組み合わせを考慮し、その組み合わせに対してスコアを計算し、相手端末に 送信し、了解を取ることによって最適のパスを選択する。その結果、複数の通信端末 間でのプリファレンスに適した CoAの選択がおこなわれる。
[0022] 例えば、 2つの端末間での通信で、通信端末 A (例えば、発呼側とする）は、通信メ ディア情報を通信相手の通信端末 B (例えば、着呼側とする）に送信し、通信端末 B は、両者の通信メディア情報をマージしたパス情報を作成し、通信端末 Aに返信する 。通信端末 Aと通信端末 Bは、通信端末 Aと通信端末 B間の各パスにおけるネットヮ ーク状態を把握し、通信端末 Aはパスにフローの要求に対するマッチ具合をスコアリ ングして順位付けをし、順位およびスコアを通信端末 Bに送信する。同時に通信端末 Bは自身のプリファレンスによりパスに点数付けをおこない、通信端末 Aから送信され た順位およびスコアを加算し最適パスを選択する。選択したパスを通信端末 Aに返 信し、通信端末 Aおよび通信端末 Bは選択したパスの情報をもとにアプリケーション に最適な帯域幅を割り当てる。
[0023] (第 1の実施形態）
図 1〜図 7により、第 1の実施形態について説明する。そのシステム構成例の模式 図を図 1、シーケンス図を図 2に示す。この第 1の実施形態は、互いに通信する端末 1 0と端末 11が存在し、端末 10及び端末 11に実装された通信管理部 14a, 14bと Vol P (Voice over Internet Protocol)アプリケーション 13a, 13b力ら構成される。また、一 方の端末 10は、通信メディア NIC100でインターネットと接続しており、他方の端末 1 1は、通信メディア NIC 110及び通信メディア NIC 111でインターネットに接続して！/ヽ るちのとする。
[0024] 現在、 VoIPで使われる呼制御プロトコルは、 SIP (Session Initiation Protocol)が多 い。 SIPを用いる場合には、 SDP (Session Description Protocol)の受信が完了する まで相手端末とのフローの情報は確定しな 、。呼制御すなわち SDPの送受信がお 互いに完了しフローの情報が確定したら、 VoIPアプリケーション 13aは、フローの情 報を通信管理部 14aに渡す。また、本実施形態においては、例えば、 SDP中の最低 帯域幅 (8kbps)で通信を開始するものとする。フロー情報（図 3 (A) )は、少なくともデ イスティネーシヨンアドレス（Dst Addr)、ソースアドレス（Src Addr)、デイスティネーショ ンポート (Dst Port)、最低限必要な帯域幅 BW(min)、最高クオリティに必要な帯域 幅 BW (max)を含んで!/、る。
[0025] ここでのディスティネーション及びソースアドレスは、 MobilelP対応端末では Mobil elPでのホームアドレスとなっている。その他の第 3層の移動プロトコルを利用する場 合には、各プロトコルにおける端末識別子となるアドレスを用いる、例えば、移動透過 性を保証する Lin6 (寺岡らが提唱する移動サポート第 3層プロトコル）においては Lin 6汎用 ID、 IPIP (NTT DoCoMo社の提唱する移動サポート第 3層プロトコル）にお いては IPhaを用いる。また、同時に端末 11においてもフロー情報（図 3 (A) )は、通 信管理部 14bに渡される。このとき、通信管理部 14bにおいてどちら力 シエータと なるべきかを、アプリケーション力 通知される。
[0026] 本実施形態においては、発呼端末である端末 10の VoIPアプリケーション 13aが、 自身の通信管理部 14aに対してイニシエータである旨をフロー情報とともに通知する 。なお、本実施形態では、 VoIPアプリケーションの発呼側 (端末 10側）をィ-シエー タとしたが、 VoIPアプリケーションでの着呼側 (端末 11側）がイニシエータとなっても よい。これらの情報をもとに端末 10の通信管理部 14aは、通信相手端末とのパスを 生成するために自身の通信メディア情報（図 3 (B) )、すなわち、通信メディア NIC10 0の情報を通信相手の端末 11の通信管理部 14bに送信する。端末 11では受信した 通信メディア情報と自身の通信メディア情報からパス情報（図 3 (C) )を作成し、端末 1 0に送信する。ここで、パスは上りと下りを別なパスと認識するものとする。また、ノ ス 情報には、ぉ互 、の通信メディアの情報（図 3 (D) )も含まれて 、るものとする。
[0027] 次に、このパス情報中の足りないデータ（例えば、図 3 (C)の帯域幅 BW)を埋める ためにネットワーク状況を調査する。この調査は、例えば、データベースにおいて様 々なネットーク状況を蓄えて 、て、前記データベース力 ネットワークの情報を取得し ても良いし、 END— ENDで計測してネットワーク情報を取得しても良いし、その他の 手法を用いても問題ない。本実施形態では、 END— ENDで計測するものとする。パ ス情報を得た端末 10は、ネットワーク情報を得るために、端末 11との間でネットヮー ク状態を測定する。こうして、パス情報中の使用可能な帯域幅 BWが埋まる（図 4)。
[0028] その結果、フロー 1においてはパス 1、 2のどちらを利用したら良いか、フロー 2にお いては、パス 3、 4のどちらを利用したら良いかを判断する必要がある。また、本発明 においては、マルチホーム環境が前提となっており、上りと下りは別々のパスとして判 断する。同様に、フロー 1に関しては端末 10力 フロー 2に関しては端末 11が前記嗜 好情報に沿い、使用したいパスを選択する。すなわち、各フローごとに端末 11側の 通信メディア NIC 110を用いるのが良いか、通信メディア NIC 111を用いた方が良い か決定することが可能となる。
[0029] 本実施形態の場合、端末 11→端末 10のフローにおいては、端末 11の通信メディ ァ NIC111を用いた方が好都合で、端末 10→端末 11のフローにおいては、通信メ ディア NIC110を用いた方が好都合である。これらは、前記のように嗜好を有するの はデータを受け取るユーザであるので、フロー 1に関しては端末 10のユーザ力 フロ 一 2に関しては端末 11のユーザの嗜好により選択できるべきである。この嗜好は、例 えば、 VoIPにおいて、遅延 (量の少なさ)優先か音質優先か、等といった情報であり 、予め設定されていても良いし、その都度、選択画面等により選択しても良い。
[0030] また、本実施形態においては、予め嗜好情報が設定されているものとする。この場 合、嗜好情報は数値として処理できるようにされていて、スコア付けの際に重み付け して計算される。これは、図 3 (A)中の BW(min) , BW (max)の下方に付いている（ * 1)や（ * 3)と 、つた数値である。これら嗜好情報を含んだパスの選択には、先ず、 各パスを用いた場合のフローに割り当てられる帯域幅を知る必要がある。これには、 種々の方法が考えられる。
[0031] 例えば、第 1の方法としては、そのパスを利用した際は、 END— ENDの計測によつ て得られたパスの帯域をフローの数で割った帯域を、フローに割り当てられた帯域と して割り当てる方法が考えられる。また、第 2の方法としてはそのパスを利用した際は 、 END— ENDの計測によって取得されたパスの帯域を、フローの優先度の高いもの 力 順に半分の権利を持つようにする方法も考えられる。つまり、第 2の方法では、優 先度の低いフローは、より優先度の高いフローの半分の帯域しか得る権利を持って いないこととなる。この帯域をフローに割り当てられた帯域として割り当てる。その他の 方法を用いても良いが、前記パスにフローがマップされた際に各フローに帯域が割り 当てられるとする。
[0032] 本実施形態では、フロー毎に割り当てられた帯域は既知のものとする。フローがパ スに割り当てられた際に割り振られる帯域の 1例を図 5 (A) ,図 5 (B)に示す。なお、 図 5 (A)は端末 10側で、図 5 (B)は端末 11側で所有するものとする。
[0033] ここで、端末 10の通信管理部 14aでは VoIPアプリケーション 13aの嗜好情報に基 づきスコアリングをおこなう。例えば、以下のような取り決めで、スコアリングをおこなう ものとする。フローにマップされる帯域力 条件を満たしている場合は 100点、そうで ない場合は 90点としてスコア付けをおこなう。そして、ノ ス全体のスコアとしては、そ のスコアに重み付けをおこない、合計したものを組み合わせとしてのスコアとする。本 実施形態では、下りフローが 1つしかないため、糸且み合わせとは言い難いが、とりあえ ず、パス 1にフロー 1がマップされる組み合わせと、パス 2にフロー 1がマップされる組 み合わせの 2通りがあり、端末 10側でどちらが適しているか考慮する。また、パス 3に フロー 2がマップされる組み合わせ、パス 4にフロー 2がマップされる組み合わせの 2 通りを、端末 11側でどちらが適しているか考慮する。
[0034] 先ず、端末 10側で図 6 (A)を作成し、端末 11に送信する。この図 6 (A)においては 、スコアが同点となってしまっている。これは、ある意味で端末 10としては、どちらの組 み合わせでも構わないという意思表示とも言える。その結果、端末 11では好きな方を 選択することが可能となる。ここでは、プログラム的に先に処理される組み合わせ（「組 み合わせ 1」とする）を選択するものとする。同点になってしまう場合には、端末 11で は「組み合わせ 1」を選択し、その結果を端末 10に送信する。これとほぼ同時に、端 末 11では図 6 (B)を作成し端末 10に送信する。
[0035] 本実施形態においては、上りに関しては嗜好情報がないので、「組み合わせ 1」す なわちパス 3を選択し、端末 11に選択された組み合わせとして返信する。端末 10及 び端末 11では、これらの情報を返信する際に、パケット生成ルールとして、図 7 (A) の情報を端末 10で持ち、図 7 (B)の情報を端末 11で持つルールとなる。ここで、 NI C情報は、図 3 (D)により IPアドレスと関連付けられており、フロー 1に関しては、端末 11側でソースアドレスとして CoAl 10を用い、ソース IFとしては NIC110、デイスティ ネーシヨンアドレスとしては CoAlOOと!、うパケットを作成するルールとなって!/、る。フ ロー 2に関しては、端末 10側でソースアドレスとして CoAlOOを用い、ソース IFとして は NIC100、ディスティネーションアドレスとしては CoAl 10というパケットを作成する ルールとなっている。
[0036] これらの図に示すような情報が作成されることによって、各フローに関して、自身が どの IFから出し、相手のどの CoA宛のパケットを作成すればよいかを判断できるよう になる。また、これらフローが使用するパスが決定されることによって、フローは使用 可能なコンテンツの選択も可能となる。当初、 8kbpsのコーデックで通信を開始して いるが、パスが決定したことにより 64kbpsのコーデックの利用が可能となる。なお、コ ンテンッの必要な帯域にヘッダの帯域が加わるため、測定結果が 70kbpsの場合は 、 64kbpsをマップすることが出来ないような状況も起こりうる。これらを考慮に入れて コンテンツの選択をおこなっても良 ヽが、本発明にお ヽては詳述を省略する。
[0037] 通信パスが決定されると、データを受け取る端末にぉ 、て、通信パスが決定されて 使用可能な帯域が通知される。その結果、データを受け取る端末では、相手端末に 対してコーデック変更要求をアプリケーション上の呼制御としておこな 、、送信側の 端末にコーデック変更を要求して受け取りコンテンツの変更をおこなう。なお、送信側 でネットワーク状態を通知する例については、後述の第 2の実施形態で説明する。
[0038] 本発明におけるスコア方法の 1例として、例えば、以下のような方法を用いることが できる。フローのスコア =S、嗜好レベルの値 = α、パスの特性に関するスコア = と すると、「S =∑ α Χ」となる。ここで、嗜好レベルが上れば点数が上ることになるので、 「S = ΣΧα」又は、「S=∑ (log a ) ·Χ」等も考えられる。但し、嗜好レベルが低いもの を重要とみなして高 、点数が付くようにしたり、逆に点数が低 、ものが嗜好に合致し ているとしても良ぐ一貫性があり、ユーザの嗜好によりフィットしているかの判断が可 能であることが必要である。なお、本発明においては、「S=∑ α Χ」を用いてスコア付 けをする例で説明する。ここで、嗜好レベルとは、フロー情報での各項目に対する嗜 好の値（=数値)のことを指し、嗜好情報は、フロー情報全体としての各値に対する 嗜好レベルの集合体を指す。
[0039] (第 2の実施形態）
図 8〜図 26により第 2の実施形態について説明する。そのシステム構成例の模式 図を図 8、シーケンス図を図 9に示す。この第 2の実施形態は、 TV電話の例で、フロ 一が上下で二本ずつであり、また、送信側でネットワーク状態を通知するものとする。 端末 10と端末 11が存在し、端末 10は通信メディア NIC 100及び NIC 101でインタ 一ネットと接続しており、端末 11は通信メディア NIC110及び通信メディア NIC111 でインターネットに接続しているものとする。また、本実施形態は端末 10及び端末 11 に実装された通信管理部 14a, 14bと TV電話アプリケーション 15a, 15bと Mobilel P管理部 16a, 16bから構成される。
[0040] 現在 VoIP等で使われる呼制御プロトコルは SIPが多い。 SIPを用いる場合には SD Pの受信が完了するまで相手端末とのフローの情報は確定しな 、。呼制御すなわち SDPの送受信がお互いに完了しフローの情報が確定したら、 TV電話アプリケーショ ン 15aはフロー情報を通信管理部 14aに渡す。なお、本実施形態においても、最初 の SDP交換後、最低コーデック（画像なし)で電話力 Sスタートするものとする。
[0041] この電話のスタートとほぼ同時に、 TV電話アプリケーション 15a, 15bから通信管理 部 14a, 14bに対して、フロー情報が渡される。このとき、通信管理部 14aにィユシェ 一タカどうかの情報も渡される。本実施形態においては、着呼端末である端末 11側 力 Sイニシエータである旨が伝えられるものとする。これは、 SDPパケットを先に受け取 るのが端末 11になるため、効率上 SDPを受け取った側力もスタートした方が、都合が 良 、可能性があるためである。
[0042] この場合のフロー情報の 1例（嗜好情報を含む）を図 10 (A)に示す。帯域幅 BW1 〜BW3に関しては、アプリケーションで対応可能なコーデックとリンクした帯域幅とな つていて、各々のコーデックに関しての嗜好情報は、「* 4、 Must」等である。「Must 」は名前の通り、これだけは最低必要という場合に用いる嗜好レベルである。この例 における嗜好情報には、帯域、遅延差、コスト（上り）、コスト（下り）、安定性 *モビリテ ィが存在する。
[0043] 嗜好情報に関して簡単に説明すると、帯域 BWは先述の通りであるので省略する。
遅延差は、厳密に遅延が測れる場合は絶対遅延時間を用いて問題ないが、それが 出来ない場合に、自分方向に対する各パスの遅延の最短なものを「0」として、そのパ スとの差を取って、その時間に対する要求である。これは、例えば、以下のようなテス トをおこなうことによって計測することが可能である。
[0044] NIC100→NIC110→NIC100に力かる時間と、 NIC 101→NIC 110→NIC 100 に力かる時間との差を取ることによって、 NIC100→NIC110と NIC101→NIC110 にかかる時間の差が分かる。これを何回力繰り返すことによって、片方向に対する遅 延差を求めることが可能となる。もし、端末 10及び端末 11が GPS (Global Positioning System)等を装備している場合は、絶対的な遅延をかなりの精度で求めることも可能 で、この絶対的な遅延を情報として用いる方が望ま 、とも 、える。
[0045] しかし、この絶対遅延を用いる力、遅延差を用いるかは重要ではなぐこのようなパ ラメータを嗜好情報として用いることが重要であり、本実施形態では遅延差を使用す る例で示してある。次にコスト（上り）であるが、これは相手に対する送信データに関す る嗜好で、今までの嗜好情報とは異なり、相手に対して送信するデータに関する嗜好 となるが、詳細は後述する。
[0046] 次にコスト（下り）である力 これは下りデータに関する課金への嗜好である。当然、 安い方がユーザにはメリットとなるが、高くても品質の高いパスを使用したい場合など もありえるため、それらの嗜好を反映する。次に安定性であるが、これは通信路の安 定性で、例えば、揺らぎが少ない等の情報である。最後にモビリティであるが、これは セルの大きさに関する嗜好と考えてよい。例えば、高速で動いている場合などは、こ のモビリティに対する嗜好が高くなる。
[0047] 端末 11において、フロー 10— 1は上りフローになるので、コスト（上り）に関してのみ 嗜好情報が存在する。フロー 10— 1に関しては、力かるコストが小さいことを望み、そ の嗜好レベルは * 1である。同様にフロー 10— 2も上りフローであって、コスト（上り） に関しては、小さいことを望み嗜好レベルが * 5となっている。この嗜好レベルの値は 、後のスコアリングの際に用いる。
[0048] 次に、フロー 11— 1である力 これは端末 10から端末 11に対する方向のフロー（す なわち、下りフロー）であるので、ディスティネーションポートは 7080、アプリケーショ ンの使用可能なコーデック種別、ユーザの嗜好により、次のような設定となる。 8kbps のコーデックが使用可能なことは「Must」で、そのパスを使用した際に、フローに割り 当てられる帯域力 Sこれ以下の場合は、通信不可と判断される。 64kbps以上のコーデ ックに関しては、嗜好レベル * 4となっている。遅延差に関しては、小さいものを好み 、嗜好レベル * 5となっている。このフロー 11— 1は、下りフローなので上りのコストに 関する嗜好情報は存在しないため、ハイフンとなっている。また、コスト下りに関して は本例では嗜好レベル * 0、すなわち考慮しない嗜好となっている。安定性に関して は高いものを好み、嗜好レベル * 1、モビリティに関しても、高いものを好み嗜好レべ ル * 1となっている。
[0049] 次に、フロー 11— 2に関しても、簡単に説明すると、これはフロー 11—1と同様、端 末 10力も端末 11に対する方向のフロー（下りフロー）である。ディスティネーションポ ートは 9080、最低限必要な帯域は Okbps、すなわち、データ無しで、この場合に関 しては嗜好レベル * 0であって、使用可能なコーデックとしては、 100kbpsと 500kbp sのものがあり、それぞれ嗜好レベルは、 * 3、 * 2となっている。また、遅延差に関し ては嗜好レベル * 0、すなわち考慮しない嗜好となっている。コスト（上り）に関しては 考慮しない。コスト（下り）に関しては、安いことを好み、嗜好レベル * 5である。安定 性に関しては高いものを好み、嗜好レベル * 1、モビリティに関しても、高いものを好 み嗜好レベル * 1となっている。
[0050] 以上が、 TV電話アプリケーション 15bから通信管理部 14bに渡される嗜好情報を 含むフロー情報である。同様に端末 10では、図 10 (B)に示すような嗜好情報を含む フロー情報が利用される。簡単に説明すると、フロー 10— 1は、端末 11から端末 10 へのフロー（すなわち、下りフロー）であって、ディスティネーションポートは 7080であ る。また、最低限必要な帯域は 8kbpsであって、 64kbpsのコーデックに関する嗜好 レベル * 5、遅延差は小さいことを好み嗜好レベル * 4、コスト（上り）に関しては値は 存在せず、コスト（下り）は嗜好レベル * 0、安定性'モビリティに関しては高いものを 望み、嗜好レベル * 1というフローである。
[0051] 次に、フロー 10— 2では、端末 11から端末 10へのフロー（下りフロー）であって、デ イスティネーシヨンポートは 9080である。最低限必要な帯域は 0kbpsであってこれに 関しては嗜好レベル * 0、 100kbpsのコーデックに関する嗜好レベル * 3、 500kbps に関する嗜好レベル * 2、遅延差に関する嗜好レベルは * 0で、コスト（上り）に関し て値は存在せず、コスト（下り）は小さいことを望み嗜好レベル * 3、安定性'モビリティ に関しては高いものを望み、嗜好レベル * 1というフローである。
[0052] さらに、フロー 11— 1は、端末 10から端末 11へのフロー（上りフロー）であって、ディ スティネーシヨンポートは 7080で、コスト（上り）のみ嗜好があって、最小のものを望み 、嗜好レベル * 1である。フロー 11 2も端末 10から端末 11へのフロー（上りフロー） であって、ディスティネーションポートは 9080で、コスト（上り）のみ嗜好があって、最 小のものを望み、嗜好レベル * 5である。
[0053] 上述の送受信を図 9のシーケンスに従って説明する。端末 10の TV電話アプリケー シヨン 15aでの呼制御、すなわち、 SIPZSDP INVITE を受信した後、端末 11に おいて、そのフロー情報（図 10 (A) )が通信管理部 14bに渡される。次いで、端末 11 力 の SIPZSDP 200 OKを受信後、端末 10においてそのフロー情報（図 10 (B) )が通信管理部 14aに渡される。この際、端末 11側の方が先にフロー情報を渡される 可能性が高いので、端末 11側にてフロー情報が渡される際に同時にイニシエータに なる旨が通知される。その結果、端末 11において、自身の通信メディア情報を端末 1 0に対して送信する。
[0054] この通信メディア情報を図 11 (A)に示す。端末 10では、通信メディア情報を受信し た後、自身の通信メディア情報をマージしたパス情報をフルメッシュで作成し、パス情 報として端末 11に送信する。本実施形態においては、このパス情報は、方向まで含 めて 8通り存在する。このパス情報を図 11 (B)に、パス情報に付帯する通信メディア 情報を図 11 (C)に示す。ここで、パス情報データは、端末 10と端末 11で共有される 力 図 11 (B)に埋まらないデータ (BW (測定)）がある。これらは、サーバから取得す る力、 END— ENDで計測する等の方法で取得する。本実施形態においては、測定 により取得する例で示してある。
[0055] また、モビリティに関しては、パスにおいて両者の通信メディアの低いものが入るも のとする。また、ここで、コストは、端末 10と端末 11では異なる値を持つこととなる。こ れらのデータが埋まったパス情報を、端末 10では図 12 (A)として、端末 11では図 1 2 (B)として保持することとなる。ここで、コストはパスにかかる課金や NIC使用にかか る課金で、単位あたりの値段である。これらのパス情報が完成した結果、通信管理部 14a, 14bにおいては、先ず、フローとパスの組み合わせを考慮する。
[0056] また、先述したように下りフローに関して、端末がパスを選択したいとすると、全ての 下りフローは全ての下りパスを自由に選択する自由度があるので、この重複組み合わ せは、（下りパスの数)の（下りフローの数)乗となる。本実施形態においては、 42= 16 通りとなり、端末 10で持つ組み合わせを図 13に示す。次に、この図 13に対してスコ ァ付けをする。このとき、フローは、割り当てられた帯域をもとにスコアを付けるため、 組み合わせを選択した場合の各フローに割り当てられる帯域を知る必要がある。
[0057] 例えば、帯域を知る第 1の方法としては、そのパスを利用した際は、 END -END の計測によって得られたパスの帯域をフローの数で割った帯域を、フローに割り当て られた帯域として割り当てる方法が考えられる。また、第 2の方法としてはそのパスを 利用した際は、 END— ENDの計測によって取得されたパスの帯域を、フローの優 先度の高いものから順に半分の権利を持つようにする方法も考えられる。つまり、第 2 の方法では、優先度の低いフローは、より優先度の高いフローの半分の帯域しか得 る権利を持って!/、な!、こととなる。
[0058] 上述のようにして、割り当てられる帯域が埋まったデータを図 14に示す。各フロー の帯域が得られると、スコア付けすることが可能となる。スコアはフロー毎に付け、組 み合わせ毎に合計をとる。たとえば、「組み合わせ 1」を例にとって、スコアリングの 1 例を説明する。フロー 1に関しては、帯域に関しては、 64kbps以上が割り当てられて V、る場合は 100 X 5 (64kbpsの嗜好レベル）となる。 8kbps以上 64kbps未満の場合 は 80 X 5とスコアをつける。
[0059] 遅延差に関しては、例えば、基準となる遅延差力Omsのパスを 100点として、最も 遅いパスを 70点として、その比例計算でスコア付けするものとする。その結果、遅延 差に関するスコアは 85 X 4 (RTT (Round-Trip Time)遅延差の嗜好レベル）となる。 コストは嗜好レベル * 0なので考慮しない。安定性'モビリティに関しては、 Aなら 10 0点、 Bなら 90点、 Cなら 80点 · · ·という形で点数を付けるものとする。フロー 1に関す る組み合わせごとのスコアを図 15に示す。フローとしての得点は第 1の実施形態で説 明したように「∑ α Χ」で表すことができる。
[0060] 次にフロー 10— 2に関しては、割り振られた帯域が 100kbps未満の場合は、 80 X
3 (100kbpsの嗜好レベル） +80 X 2 (500kbpsの嗜好レベル）、 100kbps以上 500 kbps未満なら、 100 X 3 (100kbpsの嗜好レベル） + 80 X 2 (500kbpsの嗜好レべ ル）、 500kbps以上なら 100 X 3 (100kbpsの嗜好レベル） + 100 X 2 (500kbpsの 嗜好レベル）とする。
[0061] RTT遅延差は、嗜好レベル * 0なので考慮せず、コストに関してはコスト =0の場合 は 100点で、それ以降コストが 1上がる毎に 2減点することとし、コスト =0のパスなら、 100 X 4 (コストの嗜好レベル）で、コスト = 10のパスなら、 80 X 4 (コストの嗜好レベル )となる。安定性'モビリティに関しては、 Aなら 100点、 Bなら 90点、 Cなら 80点 · · ·と いう形で点数を付けるものとする。このフロー 10— 2のスコアを各組み合わせ毎に表 したものを図 16に示す。これらの結果、図 15と図 16の「組み合わせ 1」の合計スコア は、 2020となること力 Sわ力る。
[0062] 以下、全てに点数を付けていくと、結局、「組み合わせ 1」の点数が最も高いことが 分かる。スコアが入った組み合わせの例を図 17に示す。この図 17の全部または一部 を端末 11に対して送信し、フロー 10— 1、 10— 2に関して端末 11が自身の上り嗜好 (コスト上りのみであるが）を勘案し、最終的に使用するパスを選択する。
[0063] 端末 11側での動作も同様で、パスとフローのデータが揃った後、重複組み合わせ を考慮し、その場合において、各フローに帯域を割り当てる。この組み合わせの例を 図 18に示す。端末 10で説明したのと同様に、端末 11においても帯域の割当をおこ ない、各組み合わせでの各フローにスコアをつけ、組み合わせのスコアを計算する。 フロー 11 1に関する結果を図 19に、フロー 11 2に関する結果を図 20に、組み合 わせに関する結果を図 21に示す。これらの結果、端末 11側では、「組み合わせ 3」を 選択するのが最も好まし ヽ結果となった。
[0064] この図 21の結果の全部又は一部を端末 10に送信し、端末 10において最終的にフ ロー 11— 1、 11— 2に使用するパスを選択する。なお、ここで一部を選択するのに恣 意性を入れることも可能で、例えば、通信相手の通信メディアを限定し一部を選択す る等といったことも可能である。すなわち、端末 10側の図 17で見ると、相手の通信メ ディアを意識せずに最適なものを選択する場合と、相手の通信メディアを NIC110に 限る場合（=パス 1、 3し力使っていない組み合わせ)で、最高のスコアの「組み合わ せ 1」、 NIC111しか使っていない組み合わせ (パス 2、 4しか使っていない組み合わ せ)で最高のスコアの「組み合わせ 6」を選択し、この 2つの組み合わせを端末 11に 送信する（図 22 (A)、図 9中のパス優先順位通知)。
[0065] 端末 11では送信された組み合わせに対し、スコア（上り）に関するスコアを加算する 。端末 11で有するフロー情報は図 10 (A)であるので、フロー 10— 1に関するコスト（ 上り）の嗜好レベルは * 1、フロー 10— 2に関するコスト（上り）の嗜好レベルは * 5で ある。パス 1、 3の上りコストは 0である力 パス 2, 4の上りコストは 10であるので、合計 コストは図 22 (B)のようになり、「組み合わせ 1」が選択される。その選択された組み合 わせが、端末 11から端末 10に対して送信される（図 22 (C)、図 9中の選択された組 み合わせ)。
[0066] また、端末 11ではフロー 10— 1はパス 1で、フロー 10— 2に関してもパス 1で送信す る。それらの設定を MobilelP管理部 16bに設定する必要があり、この設定を図 23に 示す。これらの設定がなされる結果、 IP10 (=端末 10)宛に且つディスティネーショ ンポート番号 7080宛のパケットは、 NIC110から排出され、ソース CoAとして IP110 を用いて、ディスティネーション CoAとして IP100となる。ルーティングヘッダタイプ 2 やディスティネーションオプションヘッダの内容は MobileIPv6と同様ホームアドレス となる。
[0067] このフロー 10— 1に関するヘッダを簡単に表すと、図 24 (A)のようになる。また、 10 2に関するヘッダも図 24 (B)のようになる。端末 11では、選択された組み合わせ情 報（図 22 (C) )を送信するので、フロー 10— 1 (音声）に関しては、 64kbpsのコーデッ クに変更すること、フロー 10— 2 (画像）に関しては、 500kbpsのコーデックに変更す ることが可能と判断される。そのネットワーク状態の情報を、通信管理部 14bでは、 T V電話アプリケーション 15bに通知する。その結果、端末 11の TV電話アプリケーショ ン 15bではコーデック変更が可能と判断し、受信端末である端末 10の TV電話アプリ ケーシヨン 15aに SIPZSDP re— INVITEにて SendOnlyとしてコーデック変更を 通知する。
[0068] 端末 10の TV電話アプリケーション 15aでは、それに応じて SIPZSDP 200 OK、 ReceiveOnlyにてコーデック変更を許可する。この結果、端末 11から端末 10へのフ ローは、両方ともパス 1を用いて、且つ伝送路に応じた帯域を利用して流されるように なる。次に、端末 11側では、同様に図 21の一部または全部を、端末 10に対して送 信する。
[0069] この場合も、一部を送る場合には、相手の通信メディアを限定して送信する。限定 条件は、相手の通信メディアは気にしない、 NIC100を使用するパスだけに限定する 、 NIC101を用いるパスだけに限定する。その結果、図 25 (A)のように、「組み合わ せ 3」と「組み合わせ 8」が選択され、端末 10に送信される（図 9中のパスの優先順位 通知)。端末 10では端末 11から送信された優先順位情報に基づき、自身のフロー情 報（図 10 (B) )に基づき、上りコストを勘案して使用パスを選択する。
[0070] これにより、前述の端末 11の場合と同様に、図 25 (B)を取得する。その結果、「組 み合わせ 1」が選択され、図 25 (C)の選択された組み合わせが端末 11に送信される 。この選択された組み合わせが決定したので、端末 10では端末 11に対するフローの パスが決定し、図 26のようなパラメータを MobilelP管理部 16aに伝える。これらの設 定がなされる結果、 IP11 ( =端末 11)宛で且つディスティネーションポート番号 7080 宛のパケットは、 NIC100から排出され、ソース CoAとして IP100を用いて、ディステ イネーシヨン Co Aは IP 111となる。
[0071] また、同様に IP11 (=端末 11)宛で且つディスティネーションポート番号 9080宛の パケットは、 NIC100から排出され、ソース CoAとして IP100を用いて、ディステイネ ーシヨン CoAは IP111となる。これらのパケットを簡単に図示すると、図 24 (C) ,図 24 (D)のようになって、これらの違いはディスティネーションアドレスとポートである。
[0072] ディスティネーションアドレスが異なる結果、端末 11における到着通信メディアを区 別することが可能となる。端末 11では MobilelPに基づき ΗοΑ( = ΙΡ11)としてアプリ ケーシヨンに伝えられるため、パスを切り替えてもアプリケーションの連続動作が可能 となる。また、選択されたパスを送信した端末 10では、使用可能な帯域が決定するの で、通信管理部 14aはそのネットワーク状態を TV電話アプリケーション 15aに通知す る。
[0073] その結果、端末 10の TV電話アプリケーション 15aではコーデック変更が可能と判 断し、受信端末である端末 11の TV電話アプリケーション 15bに、 SIP/SDP re— I NVITEにて SendOnlyとしてコーデック変更を通知する。端末 11の TV電話アプリケ ーシヨン 15bでは、それに応じて SIP/SDP 200 OK、 ReceiveOnlyにてコーデッ ク変更を許可する。この結果、端末 10から端末 11へのフローは、音声がパス 5を、画 像がパス 7を用い、且つ伝送路に応じた帯域で流されるようになり、双方で使用パス が異なった伝送が可能となる。
[0074] (第 3の実施形態）
図 27〜図 31により第 3の実施形態について説明する。この実施形態は、その構成 例の模式図を図 27、シーケンス図を図 28に示すように、端末 11側の動画配信サー ノ 18、端末 10に実装された動画視聴アプリケーション 17aと通信管理部 14aと Mobi le管理部 16aから構成される。動画配信サーバ 18 (端末 11)は、 NIC110を介してィ ンターネットと接続されていて、端末 10は NIC 100及び NIC 101を介してインターネ ットに接続されているものとする。本実施形態では、端末 11から端末 10方向へのデ ータしかなぐそれは 3種類あり、 2Mbps, 3Mbps, 4Mbpsであるとする。先ず、端末 10では、フロー情報（嗜好情報含む）を RTSP (Real Time Streaming Protocol)、 HT TP (Hyper Text Transfer Protocol)等を用いて取得する。
[0075] これは、必ずしも端末 11から得るとは限らないが、フロー情報 (嗜好情報含む）にお けるソースアドレスは動画配信サーバである端末 11となって 、る。得られたフロー情 報 (嗜好情報含む)を図 29 (A)に示す。なお、本実施形態では、説明を簡単にする ため帯域データのみとした。図のように、全てのフローが最低要求帯域と最大要求帯 域が等しくなつている。フロー情報を得た端末 10では、自身の持つ通信メディア情報 (図 29 (B) )を端末 11に送信する。端末 11では、自身の NIC情報を加えて、 NIC情 報（図 29 (D) )を含むパス情報（図 29 (C) )を端末 10に送信する。ここで、片方向通 信のため不要なデータはハイフンとしてある。端末 10では、パス情報を得て足りない ネットワーク情報を得るため、データベースにアクセスし、ネットワーク情報（帯域幅 B W)を得る。その結果が埋まったパス情報を図 29 (E)に示す。
[0076] 端末 10では、パス情報が得られたので、フローとパスの重複組み合わせの表を作 成する。さらに、そこに帯域を割り当てると、図 30のような結果が得られる。この例で は、「組み合わせ 2」以外では、いずれかのフローが使用不可能な NGとなってしまつ ている。その結果、「組み合わせ 2」のみがパスの優先順位となり、端末 11に送信され る。端末 11ではその優先順位をそのまま受け入れ、使用パスとして端末 10に送信す る。
[0077] これにより、端末 11では送信データのパスが決定したので、図 31のようなパラメ一 タを MobilelP管理部 16aに伝える。その結果、フロー 1、 2はパス 1で、フロー 3はパ ス 2で通信可能となる。また、端末 10では、使用パスを得た結果、全てのフローが使 用可能で、それぞれ、 2M, 3M, 4Mbpsで通信するようにサーバにセットアップし再 生を試みることによって通信が開始される。
[0078] (第 4の実施形態）
図 32〜図 39により第 4の実施形態を説明する。この実施形態は、第 1の実施形態 の 2つの端末間での送受信に対して、 3以上の複数の通信端末間での送受信を実 施する例である。図 32にシステム構成例の模式図、図 33にそのシーケンスを示すよ うに、端末 10と端末 11と端末 12が存在するものとする。そして、端末 10は通信メディ ァ NIC100および NIC101でインターネットと接続しており、端末 11は通信メディア N IC 110でインターネットに接続して！/、て、端末 12は通信メディア NIC 120で接続して いるものとする。また、本システムは通信端末 10, 11, 12,及びこれら通信端末に実 装された通信管理部 14a, 14b, 14cと VoIPアプリケーション 13a, 13b, 13cから構 成される。 [0079] 第 1の実施形態と同様に、 VoIPで使われる呼制御プロトコルは、 SIPが多ぐ SIPを 用いる場合には、 SDPの受信が完了するまで相手端末とのフローの情報は確定しな い。呼制御すなわち SDPの送受信がお互いに完了しフローの情報が確定したら Vol Pアプリケーションはフローの情報を通信管理部に渡す。また、本実施形態において は、 SDPの受信後に最低帯域幅（8kbps)で通信を開始 (データ送信の開始)するも のとする。
[0080] SDPの情報を得たこと（SDP情報は使用可能なコーデック情報 'END端末の IPァ ドレスを含んでいる）によって、 VoIPアプリケーションでは、フロー情報（嗜好情報を 含む）が作成可能となる。各端末において、作成したフロー情報が確定したら、 VoIP アプリケーションはフロー情報を通信管理部に渡す。端末 10で渡されるフロー情報を 図 34 (A)及び図 34 (B)に、端末 11で渡されるフロー情報を図 34 (C)、端末 12で渡 されるフロー情報を図 34 (D)に示す。各端末においては、 DstAddrもしくは SrcAdd rで通信相手を識別し管理する。そのため、通信相手が異なる場合、フローやパスの 番号がかぶっても問題は無 、（図 35 (A) ,図 36 (A)参照)。
[0081] 端末 10においては、 2つの VoIPアプリケーション 13al, 13a2から別個にフロー情 報を得ることとなる。この情報は異なったタイミングでくるため、通信管理部 14aにお いて片方ずつ受信することとなる。通信管理部 14aにおいては、 1つのフロー情報を 受信するごとに動作を開始し、 2つ目以上のフロー情報を得た場合には、基本的に 最初力もシーケンスを動かす力 パス情報が作成済みの場合は、ノ ス情報は新たに は作成せず、修正だけをおこなう。
[0082] これは、例えば、図 1〜図 2の第 1の実施形態で説明したように、すでに端末 10と端 末 11が通信をしていて、そのシーケンスが終了し、パス情報を共有している場合は、 新たに通信メディア情報を送信するなどはおこなわずに、新たに加わった通信に関 して (端末に対して)パスを作成し、シーケンスを動かす。その間にすでにパスを所有 している端末間での通信に関しては、パス情報（主にノ スの使用可能な帯域に関す る部分)を更新する必要が有るかを判断し、必要であればパス情報更新メッセージを 送信する。
[0083] これらの結果、端末 10では通信をおこなう端末 11、及び端末 12とのパスを作成す ることが可能となる。端末 10と端末 11とのノ ス情報を図 35 (A)に、パス情報に含まれ る通信メディア情報を図 35 (B)に示す。次に、端末 10と端末 11との間に関してフロ 一とパスの組み合わせを作成する。本実施形態においては、下りフローが 1つなので 、組み合わせ数 =パス数となる。端末 10側で持つこの組み合わせを図 35 (C)に、端 末 11側で持つ組み合わせを図 35 (D)に示す。次に、端末 10と端末 12においても 同様にパス情報を図 36 (A)にパス情報に含まれる通信メディア情報を図 36 (B)に示 す。端末 10側で持つ組み合わせを図 36 (C)に、端末 12側で持つ組み合わせを図 3 6 (D)に示す。
[0084] 端末 10では、端末 11との通信に関する組み合わせ（図 35 (C) )と端末 12との通信 に関する組み合わせ（図 36 (C) )を持つ。ここで、端末 11と端末 12はそれぞれ端末 1 0としか通信していないものとする。端末 11及び端末 12では、端末 10としか通信して いないため、第 1の実施形態と同様の処理でおこなってもよい。すなわち、下りのフロ 一に関して組み合わせを作成し、その中から適したものを 1つ又は複数選択する。
[0085] 一方、端末 10では端末 11及び端末 12と通信しているため、端末自身が使用可能 とする帯域幅を考慮してフローの使用するパスと、帯域の割り当てをおこなう必要が 有る。下りのフローに関する組み合わせを作成し（図 37 (A) )、最適なもの 1つを選択 する。その結果力 各端末あての組み合わせを相手端末に送信する。これを表示し たものが図 37 (B)で、端末 11に関しては「組み合わせ 1」を選択し、端末 12に関して は「組み合わせ 2」を選択する。この組み合わせをそれぞれ相手に送信し、相手端末 の了解を得ることによって、各フローの使用するノ スが決定する。
[0086] 通信管理部 14aでは、これらが決定した結果、フローに帯域を割り当てることができ 、その割り当てた帯域を各アプリケーション 13al, 13a2に通知する。その結果、アブ リケーシヨンはコーデック変更の必要の有無を判断し、「有り」と判断した場合には相 手アプリケーション 13b, 13cにその旨を通知する。もう少し詳細に説明すると、端末 1 0では端末 11には「組み合わせ 1」を、端末 12には「組み合わせ 2」を送信する。ここ では、それぞれ端末 11、端末 12が OKと返答したものとする。
[0087] その結果、端末 10—端末 11間の通信で端末 11→端末 10方向のフローでは、「組 み合わせ 1」、すなわち、パス 1 (端末 11の NIC110から端末 10の NIC100に届くパ ス）を用いることとなる。また、端末 10—端末 12間の通信で端末 12→端末 10方向の フローでは、「組み合わせ 2」、すなわち、パス 2 (端末 12の NIC120から端末 10の NI C101に届くパス）を利用する。これらの結果、フローに割り当てられる帯域が決定す る。
[0088] 端末 10と端末 11でのフロー 1に、例えば、 64kbps力 端末 10と端末 12とのフロー 1にも 64kbpsが割り当てられるとする。この結果を通信管理部 14aはそれぞれ VoIP アプリケーション 13al及び 13a2に通知する。その結果 VoIPアプリケーション 13al, 13a2は相手端末に使用コーデックを変更することを要請する。これは、 SIPシグナリ ングの re— INVITEによっておこなわれる。次に、端末 11では、通信相手が端末 10 だけとなるので、第 1の実施形態と同等となる。
[0089] すなわち、端末 11において、端末 10との通信におけるフローとパスの組み合わせ（ 図 38 (A) )を作成し、スコアが最大なものを選択 (組み合わせ 2)し、端末 10に送信 する。端末 10では（上りコストを考慮して) OKとして、端末 11に通知する。その結果、 端末 10→端末 11のフロー（フロー 2)に関して使用するパスが決定し、使用可能帯域 も決定する。そして 64kbpsが割り当てられ、 VoIPアプリケーション 13bに通知される 。以上により、端末 11の VoIPアプリケーション 13bでは、コーデック変更の必要があ ると判断し、端末 10の VoIPアプリケーション 13aに対して、 re— INVITEでコーデッ ク変更を指示する。
[0090] 次に、端末 12でも端末 11と同様に通信相手が端末 10だけとなるので、第 1の実施 形態と同等となる。すなわち、端末 10との通信におけるフローとパスの組み合わせ（ 図 38 (B) )を作成し、スコアが最大なものを選択 (組み合わせ 1)し、端末 10に送信す る。端末 10では（上りコストを考慮して) OKとして、端末 12に通知する。その結果、端 末 10→端末 12のフロー（フロー 2)に関して使用するパスが決定し、使用可能帯域も 決定する。そして 64kbpsが割り当てられ、 VoIPアプリケーション 13cに通知される。 以上により、端末 12の VoIPアプリケーション 13cでは、コーデック変更の必要がある と判断し、端末 10の VoIPアプリケーション 13aに対して、 re— INVITEでコーデック 変更を指示する。
[0091] 以上の結果、すべてのフローの使用パスと帯域が決定する。これらの使用パスはデ ータ送信側でパケットが生成され、インターネット網を介して相手端末に届けられる。 そこで、パケット生成ルールのためのテーブルが作成される。送信パケット用に各端 末は、パケット生成ルールをもつ。端末 10で作成されるテーブルを図 39 (A)に、端 末 11で作成されるテーブルを図 39 (B)に、端末 12で作成されるテーブルを図 39 (C )に示す。各端末がこれらのテーブルを持つ結果、各フローに対して適切なパケット が作成され、適切な出口 ·入り口の制御が可能となる。本実施の形態では選択された 組み合わせとして、 OKの合図を送ることとした。つまり選択された組み合わせは、必 ずしも"組み合わせ"のデータとは限らな 、。
[0092] (第 5の実施形態）
図 40〜図 62は、 3以上の端末間での送受信で TV電話をしながら、動画のストリー ミングを視聴する第 5の実施形態を説明する図である。例えば、孫とその祖父が TV 電話をしながらサッカーを視聴するものとする。そして、孫側では TV電話よりもサッカ 一の視聴に重点を置き、祖父側ではサッカーよりも孫との TV電話の画質に重点を置 く。この第 5の実施形態を図 40にシステム構成例の模式図で示すように、端末 10は、 TV電話アプリケーション 15aと、動画視聴アプリケーション 17aと、通信管理部 14aと MobilelP管理部 16aから構成されている。端末 11も同様に、 TV電話アプリケーショ ン 15bと、動画視聴アプリケーション 17bと、通信管理部 14bと MobilelP管理部 16b 力も構成されている。端末 12は、動画配信サーバ 18と、通信管理部 14cと MobilelP 管理部 16cから構成されている。
[0093] また、端末 10—端末 11間の TV電話によるシーケンスを図 41に、端末 10と端末 12 の動画配信アプリケーションに関してのシーケンスを図 42に、端末 11と端末 12の動 画配信に関する動画配信のシーケンスを図 43に示す。図 41〜図 43に示す各々の シーケンス自体は、図 9に示した第 2の実施形態と同様のものとなっている。すなわち
、アプリケーションや、通信管理部間の通信には変更は不要で、通信管理部内部で のアルゴリズム.ルーチンのみ変更が必要となる。
[0094] 先ず、端末 10を持つ孫は、サッカーの動画視聴をしているものとする。ここに、端末 11を持つ祖父から TV電話が力かってきたとする。動画ビューァは、この時点で既に 端末 12との間で図 44に示すようなフロー情報を有している。フロー 10— 1はディステ イネーシヨンの IPアドレスは IPlO (HoA)で、ソースの IPアドレスは IP12 (通常の IPァ ドレス、端末 12は CNとなっている）で、ディスティネーションポートは 9200番のフロー となっている。サポートするコーデックは、 64kbps, 1Mbps, 6Mbpsの三種類で、嗜 好レベルは、最低必要帯域は 64kbps、 1Mbpsは * 2、 6Mbpsは * 5となっている。
[0095] また、遅延に関する嗜好情報は、少な 、ものを好み嗜好レベル * 2となって 、て、コ スト下りに関しては嗜好レベル * 3となって ヽる。モビリティ ·安定性に関しては両者と も高い物を好むが、嗜好レベル * 1となっていて、それほど重要視はしていない嗜好 情報となっている。端末 11から TV電話が力かってくることは、すなわち SIPZSDPの INVITEメッセージを受け取ることである。ここで、端末 10の TV電話アプリケーション 15aでは INVITEメッセージ中の SDPからフロー情報を作成し、通信管理部 14aに 通知する。このフロー情報を図 45に示す。
[0096] 図 45には 4つのフローの情報が示されている。順に説明すると、フロー 10— 2はデ イスティネーシヨンアドレスが IP10、ソースアドレスが IP11、すなわち、端末 11から端 末 10へのフローである。また、ディスティネーションポートは 7080、これは音声のフロ 一となるが、アプリケーションが何かは通信管理部 14aでは意味を成さず、このフロー に対する嗜好がどうなつているかが重要である。また、このフロー 10— 2がどのアプリ ケーシヨンと関連付けられている力も重要となる。すなわち、このフローは TV電話の フローであることは重要だ力 TV電話の音声なのか、画像なのかは重要ではないと いう意味である。ここで、このフロー 10— 2は TV電話のフローであることを通信管理 部は記憶する。この識別子は、 PIDやポート番号を用いることができる。
[0097] この嗜好を見ると、最低限必要な帯域は 8kbpsとなっている。これは、例えば、 G72 9. 1等のアプリケーションの使用コーデックと関連付けることもできる力 通信管理部 14aとしては使用するコーデックは意味を成さず、どれだけの帯域を必要とするかが 重要となる。また、帯域に対する嗜好として、同様に 64kbpsのものが * 5として与えら れる。これは、例えば、 G711 Mu— lowコーデックなどと関連付けることも可能であ る力 上述したのと同様にそのことは通信管理部 14aには意味をなさない。この 64kb psという帯域に対して、嗜好レベル * 5という嗜好を持つことが重要である。また、遅 延に対する要求は嗜好レベル * 4、コストに関しては嗜好レベル * 0で考慮しな!ヽ嗜 好となっている。また、モビリティ'安定性に関しては嗜好レベル * 1となっている。
[0098] 次のフロー 10— 3は、フロー 10— 2と同様にディスティネーションアドレスが IP10、 ソースアドレスが IP11、すなわち、端末 11から端末 10へのフローである。また、ディ スティネーシヨンポートは 9080、これは TV電話の画像のフローとなるが、アプリケー シヨンが何かは通信管理部 14aでは意味をなさず、このフローに対する嗜好がどうな つて 、るかが重要である。最低帯域は 0kbpsでこれは画像無しを許容する意味とな つていて、 100kbpsの嗜好レベルは * 3、 500kbpsの嗜好レベルは * 2となっている 。遅延に関しては嗜好レベル * 0で考慮せず、コスト（下り）に関しては嗜好レベル * 3、モビリティ'安定性に関しては嗜好レベル * 1となっている。また、このフロー 10— 3がどのアプリケーションと関連付けられている力も重要となる。すなわち、このフロー は TV電話のフローであることは重要だ力 TV電話の音声なのか、画像なのかは重 要ではないという意味である。ここで、このフロー 10— 3は TV電話のフローであること を通信管理部は記憶する。この識別子は、 PIDやポート番号を用いることができる。
[0099] 次のフロー 11 2は、ディスティネーションアドレスが IP11、ソースアドレスが IP10、 すなわち、端末 10から端末 11へのフロー言い換えれば上りフローである。なので、 上りコストのみに嗜好が存在し嗜好レベルは * 1となって 、る。フロー 11― 3も同様に 端末 10から端末 11への上りフローで、上りコストの嗜好レベルは * 0で考慮しな!ヽ設 定となっている。
[0100] これらのフロー情報を元に、通信管理部 14aは動作をおこなう。すでに、端末 12と の間においては、パス（パス 10— 12— 1、パス 10— 12— 2)が形成されている。この パス情報と NIC情報を図 46 (A) ,図 46 (B)に示す。これらのパスに対してフロー 10 —1は選択される。現在は、パス 10— 12— 2を使用しているものとする。そこへ、新た な下りフロー（フロー 10— 2、フロー 10— 3)が加わったため、通信管理部 14aではフ ローのパスへのマップをやり直す必要がある。
[0101] また、この時点では端末 10と端末 11の間にはパスが存在しないので、パスを作成 する。端末 10は、端末 11に対して NIC情報を送信し、パス情報 (パス 10— 11— 1〜 パス 10— 11— 8)を得る。ここで得たパス情報と NIC情報を、図 47 (A)、図 47 (B)に 示す。ここで得た図を完成させるためにネットワーク状態を取得する（取得方法の詳 述は省略)。この結果、端末 10においては図 48 (A)を、端末 11においては図 48 (B )を得る。
[0102] 以上によりパス情報が得られたので、フローをパスにマップする。ここでは、フローに 優先度があることを前提とする。この優先度は、あら力じめ決められていても良いし、 その都度 GUI (Graphical User Interface)などから順位を決定しても良い。この GUI の例を図 49 (A)に示す。この結果、端末 10においては、動画ストリーミングが最重要 とされ、次に TV電話の音声で、最も優先度が低いものが TV電話の画像となる。これ ら一連のフローの様子を図 50に示す。
[0103] そこで、本実施形態においては、優先度の最も高い動画ストリーミンダカも順番に パスを選択していく。先ず、フロー 10— 1がパスを選択する。この際、フロー 10— 1は 、ノ スの持つ帯域 (測定)の半分を占有できる権利があるものとする。ここで、半分ま でとするのは、 1Z2の等比級数の和（1Z2+ 1Z4+ 1Ζ8· · )力^となるためである 。帯域 (測定)の半分と、フロー情報中の帯域 (Max)との大きい値がフローに対して 割り当てられた帯域として与えられる。
[0104] フロー 10— 1は、パス 10— 12— 1もしくはフロー 10— 12— 2のどちら力からパスを 選択する。このために、各パスを利用した際に割り当てられる帯域を勘案して、スコア を計算する。その結果を図 51 (A)に示す。その結果、フロー 10— 1はパス 10— 12 —2を選択し、 6Mbpsの帯域を占有する。また、この際、パス 10— 12— 2における使 用可能な帯域は 20 -6 = 14Mbpsとなる。
[0105] 次のフロー 10— 2は、パス 10— 11— 1〜パス 10— 11— 4からパスを選択する。前 記のようにフロー 10— 1が、パス 10— 12— 2にマップされたことによって、パス 10— 1 1— 1〜ノ ス 10— 11—4の使用可能な帯域に影響を与えることもありえる力 本実施 形態においては影響がないものとする。なお、ある場合はそれを考慮に入れ、使用 可能な帯域を計算した上で、残りの帯域の半分を占有する権利が有るものとする。こ こで、フロー 10— 2が各パス（パス 10— 11— 1〜パス 10— 11—4)を選択した際に割 り当てられる帯域を勘案した、各パスのスコアを図 51 (B)に示す。その結果、フロー 1 0— 2はパス 10— 11— 2を選択する。
[0106] 次のフロー 10— 3は、パス 10— 11— 1〜パス 10— 11— 4からパスを選択する。ここ で、フロー 10— 2力 すでにパス 10— 11— 2を選択しているので、そのパスの帯域は 狭くなつてしまっている。これを勘案して、各パスを利用した際に利用可能な帯域を 勘案したスコアを図 51 (C)に示す。その結果、フロー 10— 3はパス 10— 11— 1を選 択する。
[0107] これで全てのフローの使用パスが決定したこととなる。そこで、通信管理部 14aでは 、端末 11と端末 12に対してパスの優先順位を通知する。このパス優先順位は、前述 の通り、フローとパスの組合せとする。先ず、端末 11に対しては、フローが 2つでパス 力 S4つ、すなわち 16の組み合わせのうち、フロー 10— 2はパス 10— 11— 2、フロー 1 0— 3はパス 10— 11— 1という組み合わせを、端末 11に対して送信する。本実施形 態においては、この組み合わせのみ送るものとする。これを図 52 (A)に示す。次に、 端末 12に対しては、フローが 1つでパスが 2つ、すなわち 2つの組み合わせのうち、フ ロー 10—1はパス 10— 12— 2を選択する組み合わせを送信する。これを図 52 (B)に 示す。
[0108] 端末 11では、送信された組み合わせが 1つなので、選択の余地は無ぐ OKか NG 力の判断だけおこなう。これはパス情報（図 48 (B) )中におけるコスト (上り）力も判断 される。コストに上限値が設定されていて、通知された組み合わせの優先順位のコス トがそれを上回る場合などは NGとする。本実施形態では、 OKで、選択された組み 合わせとして、前記のフロー 10— 2はパス 10— 11— 2、フロー 10— 3はパス 10— 11 —1という組み合わせを端末 10に送信する。また、この組み合わせを選択したことに よって、端末 11では送信パケットの生成ルールを作成可能となる。この送信パケット のルールを図 53 (A)に示す。
[0109] 図 53 (A)で上に示すルールは、ソースの HoAが IP11で、ディスティネーションの H oAが IP10で、ディスティネーションポートが 7080のフローのパケットは、ソースの通 信メディアには NIC111を用いて、ソース CoAには IP111、ディスティネーション Co Aには IP100を用いるルールである。また、図 53 (A)で下に示すルールは、ソース H oAが IP11で、ディスティネーション Ho Aが IP 10で、ディスティネーションのポートが 9080のフローのパケットは、ソースの通信メディアには NIC110を用いて、ソース Co Aには IP110、ディスティネーション CoAには IP100を用いるルールである。このル ールにしたがって端末 11の MobilelP管理部 16bは適切なパケット生成をおこなう。
[0110] 端末 12では、送信された組み合わせがーつなので、選択の余地は無ぐ OKか NG かの判断だけおこなう。端末 12は動画配信サーバであるので、コストは勘案しないた め、 OKとなる。その結果、フロー 10— 1はパス 10— 12— 2を選択された組み合わせ として端末 10に通知する。この組み合わせが決定したことによって、端末 12では送 信パケットの生成ルールが決定する。この生成ルールは、図 53 (B)に示すように、デ イスティネーシヨン HoAが IP10で、ソース HoAが IP12で、ディスティネーションポート 力 9200のノケットは、ソースの通信メディアには NIC 120を用いて、ソース CoAには IP12、ディスティネーション CoAには IP101を用いるルールである。このルールにし たがって端末 12の MobilelP管理部 16cは適切なパケット生成をおこなう。
[0111] また、端末 10では、端末 11から選択された組み合わせが通知される。その通知に 基づき、端末 10では TV電話アプリケーション 15aにネットワーク状態（図 54 (A) )を 通知する。このネットワーク状態は、ディスティネーション Ho Aが IP 10でソース Ho A が IP11で、ディスティネーションポートが 7080のフローに割り当てられた帯域は 64k bpsで、安定性は B、コストは 4、 RTT遅延差は 0であり、ディスティネーション Ho Aが I P10でソース HoAが IP11でディスティネーションポートが 9080のフローに割り当てら れた帯域は 500kbpsで、安定性は A、コストは 2、 RTT遅延差は 50であることを意味 している。これらの通知されるネットワーク状態はフロー 10— 2、フロー 10— 3は TV電 話のフローであることを通信管理部が把握しているため、 TV電話アプリケーションに 通知される。この通知を受けた TV電話アプリケーション 15aは、端末 11の TV電話ァ プリケーシヨン 15bに対して使用するコーデックを変更するために SIPZSDP re— I NVITE Receive Onlyを送信する。端末 11では 200 OKとして端末 10に送信す る。
[0112] 端末 10では、端末 11の通信とは別に端末 12からも使用組み合わせが通知される 。その通知に基づき、端末 10では動画視聴アプリケーション 17aにネットワーク状態 を通知する。このネットワーク状態を図 54 (B)に示す。これは、ディスティネーション H oAが IP10でソース HoAが IP12でディスティネーションポートが 9200のフローに割 り当てられた帯域は 6Mbpsで、安定性は A、コストは 5、 RTT遅延差は 50であること を意味している。これらの通知されるネットワーク状態はフロー 10— 1は動画アプリケ ーシヨンのフローであることを通信管理部が把握しているため、動画アプリケーション に通知される。
[0113] 端末 10の動画視聴アプリケーション 17aはこの情報に基づき、端末 12の動画配信 サーバ 18に対して、 RTSP SETUPでどのタイミングからどのコーデックに変えるか を通知する。動画配信サーバ 18はその要求を受け入れて、 200 OKを通信端末 10 の動画視聴アプリケーションに通知する。これで、端末 10への下りフローの最適化は 終了する。その結果、孫は、サッカーの動画視聴アプリケーション 17aをパス 10— 12 —2経由で 6Mbpsの品質で視聴し、 TV電話アプリケーション 15aでは音声をパス 10 - 11 - 2経由で 64kbpsの品質で、画像をパス 10— 11― 1経由で 500kbpsで視聴 することが可能となる。
[0114] 次に、端末 11での動作を説明する。端末 11では祖父が孫に TV電話をかける。こ れは SIPZSDPの INVITEが端末 10に通知されることで実現され、孫が電話を受け ることは、 SIPZSDP 200 OKが返されることである。端末 11の TV電話アプリケー シヨン 15bでは SIPZSDP 200 OKを受け取り、その情報を元にフロー情報を作成 する。このとき、 TV電話は最低条件（8kbpsの音声、画像なし)で接続される。この後 、祖父の手によって動画視聴のリクエストがおこなわれる。これにより、端末 11の動画 視聴アプリケーション 17bと端末 12の動画配信サーバ 18との間で RTSPのやりとりに より、フロー情報を得る。
[0115] 端末 11の通信管理部 14bは TV電話アプリケーション 15bから TV電話に関するフ ロー情報（図 55 (A) )と、動画視聴アプリケーション 17bから動画視聴に関するフロー 情報（図 55 (B) )が渡される。これらのフロー情報の特徴を挙げると、 TV電話のフロ 一情報に関しては、コストが全て嗜好レベル * 0になっていて、高品質なものを好む 設定となっている。これは孫との TV電話にはコストは度外視し、高品質なものを好む 嗜好である。これに対して動画視聴に関しては、高品質なものはあまり好まず、コスト を優先するような設定となって 、る。
[0116] 以下にフロー情報の詳細を説明する。 TV電話の上り音声フローであるフロー 10— 2及び上り画像フローである 10— 3に関してはコストの嗜好レベル * 0、すなわち考 慮に、、れな 、設定となって 、る。 TV電話の下り音声フローであるフロー 11— 2に関 しては、最低限 8kbps必須で、 64kbpsのコーデックの嗜好レベルは * 5、遅延差が 小さいことを好み嗜好レベル * 4、コストは考慮せず、安定性に関しては嗜好レベル * 2、モビリティに関しては嗜好レベル * 1という嗜好となっている。
[0117] TV電話の画像フローであるフロー 11— 3に関しては、画像無しを許容し、 lOOkbp sのコーデックの嗜好レベルは * 1、 500kbpsのコーデックの嗜好レベル * 7、遅延 差が小さいことを好む嗜好レベルは * 2、コストは考慮せず、安定性に関しては嗜好 レベル * 2、モビリティに関しては嗜好レベル * 1という嗜好となっている。動画視聴 のフローであるフロー 11—1に関しては、最低限の 64kbpsは必須で、 1Mbpsのコー デックの嗜好レベル * 1、 6Mbpsのコーデックの嗜好レベル * 1、遅延差が小さいこ とを好む嗜好レベル * 1、コストの嗜好レベル * 6、安定性に関しては嗜好レベル * 1 、モビリティに関しては嗜好レベル * 1という嗜好となっている。
[0118] 端末 11の通信管理部 14bでは、これらのフロー情報を得るので、端末 10、端末 12 とのパスを作成する。端末 10とのパスに関しては先に説明したとおりであるので、ここ では省略する。ここで、端末 12とのパスを作成する必要がある。端末 11では自身の 通信メディア情報（図 56 (A) )を端末 12に送信する。端末 12ではパスを作成し、パス 情報 (図 56 (B) )と通信メディア情報 (図 56 (C) )を送信する。
[0119] 端末 11ではフロー情報及びパス情報を取得したので、最適な組み合わせを選択 する。ここで、端末 10に図 49 (A)で示したのと同様にフローに優先順位をつける。こ れは図 49 (B)のような GUIで第 1位が TV電話動画で、第 2位が TV電話音声で、第 3位が動画視聴という順位が選択されたものとする。そこで、最初に TV電話動画、す なわちフロー 11— 3がパスを選択する。これら一連のフローの様子を図 57に示す。
[0120] フロー 11— 3は、パス 10— 11— 5〜パス 10— 11— 8からパスを選択する。前述と 同様にそのパスを利用した場合に使用可能な帯域を含めてスコアリングをおこなう。 この結果を図 58 (A)に示す。その結果、 TV電話の画像はパス 10— 11—5を選択し 、 500kbpsが割り当てられる。また、本実施形態では下位の順位に関しても考慮して おく。先ず、パス 10— 11— 5は通信相手である端末 10の通信メディア： NIC100を 用いるパスである。相手はコストの嗜好で拒否する可能性があるので、 NIC101を用 、た場合にパス 10— 11— 6とパス 10— 11― 8のどちらが良!、かを判断する。これは スコアより、パス 10— 11— 8が選択される。
[0121] 次に TV電話の音声フローのフロー 11 2がパスを選択する。フロー 11 2は、ノ ス 10— 11— 5〜パス 10— 11 - 8からパスを選択する。前述と同様にそのパスを利用 した場合に使用可能な帯域を含めてスコアリングをおこなう。この結果を図 58 (B)に 示す。その結果、 TV電話の画像はパス 10— 11— 8を選択し、 64kbpsが割り当てら れる。また、前記と同様に下位の順位のものも考慮しておく。前記の場合と同様にパ ス 10— 11— 8は、端末 10の NIC101を利用しているので、 NIC100を利用するパス 10— 11 5、パス 10— 11— 7から選択する。そうすると、パス 10— 11— 5が選択さ れる。
[0122] 最後に、動画視聴フローのフロー 11—1がパスを選択する。フロー 11— 1は、パス 1 1 - 12- 1〜ノ ス 11 - 12- 2からパスを選択する。前述と同様にそのパスを利用し た場合に使用可能な帯域を含めてスコアリングをおこなう。この結果を図 58 (C)に示 す。その結果、動画視聴フローはパス 11— 12— 1を選択し、 1Mbpsが割り当てられ る。パス 11— 12— 2を選択していた場合は 6Mbpsのフローを得られた力 コストに関 する嗜好が高いため、サッカーの視聴に関しては 1Mbpsで低額なパスを選択したこ ととなつた。
[0123] 以上から、端末 11では端末 10宛に TV電話に関するフローの組み合わせの優先 順位（図 59 (A) )を作成する。先ず、第 1位は、相手 (端末 10)の NICを気にせず選 択した「組み合わせ 1」となる。次に、相手の NICを限定したものを考慮する。すなわ ち NIC 100のみの「組み合わせ 2」と NIC 101のみを用いる「組み合わせ 3」である。こ の 2つでは、「組み合わせ 2」の方がスコアは高くなり、組み合わせの優先順位は高く なる。この組み合わせを端末 10に対して送信する。また、動画視聴に関して、端末 1 2宛に組み合わせの優先順位（図 59 (B) )を作成する。
[0124] 端末 10では、得られた優先順位に関して自身の上りのコストの嗜好情報を加えて、 使用組み合わせを選択する。上りコストのスコアを加えたものを図 60 (A)に示す。こ の結果、選択された組み合わせとして「組み合わせ 1」が選択され、図 60 (B)が端末 10から端末 11に送信される。このとき、端末 10では、端末 11に対する送信パケット に関するルールが決定するので、図 61 (A)の情報を MobilelP管理部 16aに通知す る。
[0125] この図 61 (A)の上段は、ソース HoAが IP10、ディスティネーション HoAが IP11、 ディスティネーションポートが 7080のフローは、ソース CoAとして IP101を用いて、ソ ースの通信メディアとしては NIC 101力ら、デイスティネーション Co Aには IP 111を用 いる設定となっている。下段は、ソース HoAが IP10、ディスティネーション HoAが IP 11、ディスティネーションポートが 9080のフローは、ソース CoAとして IP100を用い て、ソースの通信メディアとしては NIC100から、ディスティネーション CoAには IP11 0を用いる設定となっている。これらの設定の結果、フロー 11— 2に関してはパス 10 11 8を、フロー 11—3に関してはパス 10— 11 - 5を利用することが可能となる。
[0126] また、端末 10で決定された使用組合せを端末 11の通信管理部 14bは受け取る。
その結果、フロー 11— 2、 11— 3に対して帯域を割り当てることが可能となる。ここで、 通信管理部 14bはネットワーク状態（図 61 (B) )を TV電話アプリケーション 15bに通 知する。この図 61 (B)の上段は、ソースの IPアドレスが IP10で、ディスティネーション の IPアドレスが IP11でディスティネーションポートが 7080のフローは、 64kbpsの帯 域が割り当てられて、安定性は B、コストは 1、 RTT遅延差は 0であることを意味してい る。これらに関しても端末 10の場合と同様に通信管理部で把握しており、適切なアブ リケーシヨンにネットワーク状態は通知される。
[0127] 下段に関しては、ソースの IPアドレスが IP10で、ディスティネーションの IPアドレス が IP11でディスティネーションポートが 9080のフローは、 500kbpsの帯域力 S害 ijり当 てられて、安定性は A、コストは 3、 RTT遅延差は 90であることを意味している。これ らの情報を得た端末 11の TV電話アプリケーション 15bでは、端末 10の TV電話ァプ リケーシヨン 15aに対して、 SIP/SDP Re -INVITE Receive Onlyでコーデッ ク変更を要求する。これに端末 10の TV電話アプリケーションが SIPZSDP 200 O K Send Onlyを返すことで、コーデックが変更される。これで、 TV電話に関しては 一通りの設定が終了したこととなる。
[0128] 端末 11では、端末 10との上記のやりとりと平行して端末 12ともやり取りをおこなう。
端末 11では、図 59 (B)の組み合わせを端末 12に対して送信する。端末 12は、通信 メディアを 1つしか有していないので、複数の候補は挙げず、 1つの組合せとなってい る。端末 12では図 59 (B)の組み合わせを受け取り、その組合せで OKとし、選択され た組合せとして図 59 (B)の組み合わせをそのまま返答する。この結果、端末 12内で はパケットに関するルールが決定するので、図 62 (A)の情報を MobilelP管理部 16 cに通知する。これは、ソース HoAが IP12、ディスティネーション Ho Aが IP11、ディ スティネーシヨンポートが 9200のフローは、ソースの IPアドレスとして IP12を用いて、 ソースの通信メディアとしては NIC120から、ディスティネーション CoAには IP110を 用いる設定となっている。
[0129] 端末 12からの使用組合せを受け取った端末 11の通信管理部 14bは、動画視聴ァ プリケーシヨン 17bに対してネットワーク状態（図 62 (B) )を通知する。このネットワーク 状態を受け取った端末 11の動画視聴アプリケーションは、 RTSPZSDP Setupで コーデック変更を要求する。これに対して端末 12の動画配信サーバでは 200 OKと して返答する。
[0130] 上述した、本発明による送受信方法は、通信端末に搭載されたコンピュータによつ て実行される。このため、各種アプリケーションと通信管理部間におけるデータの送 受、及び各種通信メディアを通じての通信端末間の送受信を実行する手順を示した プログラムが用いられる。また、本発明による送受信を、コンピュータに実行させるた めの前記プログラムを記録したコンピュータ読み取り可能な記録媒体を用いて実施 することができる。

Claims

請求の範囲
[1] 複数の通信端末間で、 1以上のパスで、 1以上のフローを送受信する際に、フロー とパスの組み合わせを選択する送受信方法であって、
前記複数の通信端末において、アプリケーションは通信管理部に少なくともアドレス 情報及びネットワークに関する嗜好情報を含むフロー情報を渡し、
前記各通信端末の通信管理部は、前記フロー情報に基づき前記通信端末の有す る通信メディア情報を通信相手の通信端末に送信し、
前記通信相手の通信端末の通信管理部は、発信した通信端末の有する通信メディ ァ情報と前記通信相手の通信端末の有する通信メディア情報から、パス情報を作成 して前記発信した通信端末に送信し、
前記各通信端末の通信管理部では、それぞれ有する前記フロー情報と前記パス情 報から、パスにフローをマップする組み合わせを作成して、各組み合わせに関するス コアを送信し、
前記複数の通信端末の各々の通信管理部において、自身の上りの嗜好情報を含 めて前記スコアの高い組み合わせを選択し、各データフロー毎にパスを使用するよう に設定し、各フロー毎にパスを選択可能とすることを特徴とする送受信方法。
[2] 通信端末 Aと通信端末 B間で、 1以上のノ スで、 1以上のフローを送受信する際に、 フローとパスの組み合わせを選択する送受信方法であって、
前記通信端末 Aにおいて、アプリケーションは通信管理部に少なくともアドレス情報 及びネットワークに関する嗜好情報を含むフロー情報を渡し、
前記通信端末 Bにおいても、アプリケーションは通信管理部に少なくともアドレス情 報を含むフロー情報を渡し、
前記通信端末 Aの通信管理部は、前記フロー情報に基づき前記通信端末 Aの有 する通信メディア情報を前記通信端末 Bに送信し、
前記通信端末 Bの通信管理部は、受信した通信端末 Aの有する通信メディア情報 と前記通信端末 Bの有する通信メディア情報から、パス情報を作成して前記通信端 末 Aに送信し、
前記通信端末 A及び前記通信端末 Bの通信管理部では、それぞれ有する前記フ ロー情報と前記パス情報から、パスにフローをマップする組み合わせを作成して、各 組み合わせに関するスコアを送信し、
前記通信端末 A及び前記通信端末 Bの各々の通信管理部にお!、て、自身の上り の嗜好情報を含めて前記スコアの高い組み合わせを選択し、各データフロー毎にパ スを使用するように設定し、各フロー毎にパスを選択可能とすることを特徴とする送受 信方法。
[3] 前記嗜好情報は、アプリケーションで使用可能なコンテンツに対応した 1以上の要 求帯域情報を含むことを特徴とする請求項 1又は 2に記載の送受信方法。
[4] 前記要求帯域情報は、数値で表現される 1以上の要求帯域情報と、その各々に対 応する数値で表現される嗜好レベルと、を含むことを特徴とする請求項 3に記載の送 受信方法。
[5] 前記嗜好情報は、遅延差情報を含むことを特徴とする請求項 1又は 2に記載の送 受信方法。
[6] 前記遅延差情報は、数値で表現される嗜好レベルを含むことを特徴とする請求項 5 に記載の送受信方法。
[7] 前記嗜好情報は、課金情報を含むことを特徴とする請求項 1又は 2に記載の送受 信方法。
[8] 前記課金情報は、数値で表現される嗜好レベルを含むことを特徴とする請求項 7に 記載の送受信方法。
[9] 前記課金情報は、上りと下りに関して別に嗜好レベルを持つことを特徴とする請求 項 8に記載の送受信方法。
[10] 前記嗜好情報は、単位時間当たりのパケットロス率情報を含むことを特徴とする請 求項 1又は 2に記載の送受信方法。
[11] 前記パケットロス率情報は、数値で表現される嗜好レベルを含むことを特徴とする 請求項 10に記載の送受信方法。
[12] 前記嗜好情報は、無線通信メディアのセル情報を含むことを特徴とする請求項 1又 は 2に記載の送受信方法。
[13] 前記無線通信メディアのセル情報は、数値で表現される嗜好レベルを含むことを特 徴とする請求項 12に記載の送受信方法。
[14] フローの使用するパスが決定した後に、通信管理部はアプリケーションに少なくとも 数値で表されるフローに割り当てられた帯域を含むフロー情報を通知し、アプリケー シヨンは前記割り当てられた帯域をもとにコンテンツを選択することを特徴とする請求 項 1〜13のいずれか 1項に記載の送受信方法。
[15] 請求項 1〜14のいずれか 1項に記載の送受信方法を、コンピュータにより実行させ るためのアプリケーションプログラム。
[16] 請求項 15に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
PCT/JP2006/310205 2005-06-08 2006-05-23 送受信方法およびプログラム並びに記録媒体 WO2006132080A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/915,714 US8165022B2 (en) 2005-06-08 2006-05-23 Transmitting/receiving method and program and recording medium

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2005168285 2005-06-08
JP2005-168285 2005-06-08
JP2006-007224 2006-01-16
JP2006007224A JP3819019B1 (ja) 2005-06-08 2006-01-16 送受信方法およびプログラム並びに記録媒体

Publications (1)

Publication Number Publication Date
WO2006132080A1 true WO2006132080A1 (ja) 2006-12-14

Family

ID=37052513

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2006/310205 WO2006132080A1 (ja) 2005-06-08 2006-05-23 送受信方法およびプログラム並びに記録媒体

Country Status (3)

Country Link
US (1) US8165022B2 (ja)
JP (1) JP3819019B1 (ja)
WO (1) WO2006132080A1 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008005274A2 (en) * 2006-06-30 2008-01-10 Vonage Holdings Corp. Method and system for network path discrimination
US9049690B2 (en) * 2006-12-27 2015-06-02 Kyocera Corporation Communication system, wireless communication terminal, communication method, wireless communication method, wireless communication apparatus and control method thereof
KR100948840B1 (ko) * 2007-12-17 2010-03-22 한국전자통신연구원 무선랜 ＶｏＩＰ 시스템에서 음성 품질 보장을 위한 코덱비트율 제어 방법
US9106673B2 (en) * 2012-12-28 2015-08-11 Vonage Network, Llc Systems and methods for connecting telephony communications
CN105323216A (zh) * 2014-06-20 2016-02-10 中兴通讯股份有限公司 通信链路的发送方法、装置及终端

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005072759A (ja) * 2003-08-21 2005-03-17 Sony Corp 送信装置および方法、受信装置および方法、通信装置および方法、並びにプログラム

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6667956B2 (en) * 1998-05-01 2003-12-23 Nortel Networks Limited Multi-class network
US7515583B2 (en) * 1998-06-19 2009-04-07 Nortel Networks Limited Method and apparatus for providing a configurable quality of service threshold for voice over internet protocol
US7653002B2 (en) * 1998-12-24 2010-01-26 Verizon Business Global Llc Real time monitoring of perceived quality of packet voice transmission
US6934752B1 (en) * 2000-03-23 2005-08-23 Sharewave, Inc. Quality of service extensions for multimedia applications in wireless computer networks
US7230921B2 (en) 2001-04-02 2007-06-12 Telefonaktiebolaget Lm Ericsson (Publ) Concurrent use of communication paths in a multi-path access link to an IP network
US7218610B2 (en) * 2001-09-27 2007-05-15 Eg Technology, Inc. Communication system and techniques for transmission from source to destination
US20050152397A1 (en) * 2001-09-27 2005-07-14 Junfeng Bai Communication system and techniques for transmission from source to destination
US7542481B2 (en) * 2003-02-25 2009-06-02 Nokia Corporation Connection optimization for communications in multiple access environment
US20050058068A1 (en) * 2003-07-25 2005-03-17 Racha Ben Ali Refined quality of service mapping for a multimedia session
DE60334417D1 (de) * 2003-11-26 2010-11-11 Lenovo Singapore Pte Ltd Ienstqualität für voip über drahtlose 802.11-lans
US7212821B2 (en) * 2003-12-05 2007-05-01 Qualcomm Incorporated Methods and apparatus for performing handoffs in a multi-carrier wireless communications system
JP4829474B2 (ja) * 2004-01-30 2011-12-07 富士通株式会社 ネットワーク制御装置およびそのパス制御方法
JP2005244525A (ja) 2004-02-25 2005-09-08 Fujitsu Ltd 通信装置
EP1723795A1 (de) * 2004-03-09 2006-11-22 Siemens Aktiengesellschaft Vorrichtung und verfahren zur vergeb hrung von ber ein pakentnetz gef hrten verbindungen
US7474642B1 (en) * 2004-09-15 2009-01-06 Nortel Networks Limited Signaling reliability in using high-speed shared packet data channel
JP4454635B2 (ja) 2004-11-29 2010-04-21 シャープ株式会社 帯域割り当て方法、帯域割り当てプログラム及びプログラム記録媒体
US7450502B1 (en) * 2005-02-02 2008-11-11 At&T Corp. Method and apparatus for monitoring the potential impact of traffic surges
EP1703668A1 (en) * 2005-03-18 2006-09-20 Nederlandse Organisatie voor toegepast-natuurwetenschappelijk Onderzoek TNO System for processing quality-of-service parameters in a communication network
ATE449495T1 (de) * 2005-04-04 2009-12-15 Ericsson Telefon Ab L M Verfahren und vorrichtung zur lastverteilung auf anwendungsservern
US7715312B2 (en) * 2005-04-25 2010-05-11 Verizon Services Corp. Methods and systems for maintaining quality of service (QOS) levels for data transmissions
US8014381B2 (en) 2005-06-02 2011-09-06 Sharp Kabushiki Kaisha Communication system and communication terminal
KR20080083328A (ko) * 2005-11-17 2008-09-17 인터디지탈 테크날러지 코포레이션 셀룰러 무선 통신 네트워크를 통해 ＶｏＩＰ 서비스를지원하는 방법 및 장치
US7688724B2 (en) * 2005-12-23 2010-03-30 Avaya Inc. Call admission control for mobility-capable telecommunications terminals
US7626496B1 (en) * 2007-01-16 2009-12-01 At&T Corp. Negative feedback loop for defect management of plant protection ticket screening

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005072759A (ja) * 2003-08-21 2005-03-17 Sony Corp 送信装置および方法、受信装置および方法、通信装置および方法、並びにプログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HATA Y. ET AL: "Ido Tokasei o Jitsugen suru Association-so no Sekkei to Jisso", IEICE TECHNICAL REPORT, vol. 103, no. 692, 5 March 2004 (2004-03-05), pages 53 - 57, XP003006776 *

Also Published As

Publication number Publication date
JP3819019B1 (ja) 2006-09-06
JP2007020143A (ja) 2007-01-25
US20090279451A1 (en) 2009-11-12
US8165022B2 (en) 2012-04-24

Similar Documents

Publication Publication Date Title
JP4100182B2 (ja) 通信端末装置及びその制御方法
US8014381B2 (en) Communication system and communication terminal
EP1382214B1 (en) Binding information for ip media flows
CN102546418B (zh) 基于重叠网络多径传输的ims客户端及媒体交换方法
JP4974652B2 (ja) ストリーミング通信システム
US20080095173A1 (en) System and method for monitoring the connection of an end-user to a remote network
CN101626596A (zh) 一种生成业务分流策略的方法、装置及系统
EP1878295A1 (en) Signaling quality of service (qos) parameters for a multimedia session
JP3819019B1 (ja) 送受信方法およびプログラム並びに記録媒体
KR20070072853A (ko) 이종 환경에서의 투명한 서비스 적합화
Park et al. QoS-guaranteed Mobile IPTV service in heterogeneous access networks
JP2009206769A (ja) 呼制御システム及び呼制御方法
Yamada et al. A QoE based service control scheme for RACF in IP-based FMC networks
JP2006345174A (ja) 送受信方法およびプログラム並びに記録媒体
Tuzunkan et al. Seamless mobile data offloading in Heterogeneous Wireless Networks based on IEEE 802.21 and user experience
JP4578414B2 (ja) 階層符号化マルチキャスト通信システム
Indulska et al. Vertical handover based adaptation for multimedia applications in pervasive systems
Holma et al. UMTS services and applications
Kang et al. A study on switching voice traffic seamlessly between GSM and GPRS cellular networks
Lundan et al. Optimal 3GPP packet-switched streaming service (PSS) over GPRS networks
Bokor et al. Testbed of a novel media streaming architecture for heterogeneous wireless environment
JP5296235B2 (ja) ストリーミング通信システムおよび通信中継装置
Neto et al. Context-aware session and network control in future internet
Yalli et al. Interactive multi-media applications: Quality of service guaranteed under huge traffic
Politis QoS provisioning and mobility management for IP-based wireless LAN

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 11915714

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06756461

Country of ref document: EP

Kind code of ref document: A1