JP2009105949A - TERMINAL CAPABLE OF EXECUTING QoS CONTROL - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To enable a serviced terminal of termination to deal with QoS. <P>SOLUTION: In the present invention, a terminal 21 of termination deals with a function relating to QoS, and a terminal-based QoS management scheme for achieving QoS between termination points is performed. In order to perform management of QoS at a terminal, it is necessary to recognize network conditions or other entity statuses and to know which kind of operation is to be performed. For example, the terminal monitors a packet or collects utilization information and reports collected data to a central server (SLA manager 28). The central server collects the information from all terminals within a management domain thereof. Furthermore, the central server refers to information about a service level or the like set for each terminal to determine the operation to be performed by each terminal and allows the terminal to perform the determined operation. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to a terminal capable of executing QoS control, and more particularly, to a terminal capable of executing QoS control in a mobile network using a radio technology. The present invention can also be applied in heterogeneous network environments in order to guarantee QoS between termination points.

  IP networks were originally designed to carry best effort traffic. In the best-effort service, packet transmission is not guaranteed. For delay sensitive applications such as real-time multimedia applications, the data needs to arrive within a specific delay that is limited to be available. Therefore, these applications require a certain level of service guarantee to arrive properly on time from the network so that these data are available. However, best effort services are not sufficient to meet the requirements of these applications.

  Therefore, quality of service (QoS) support has become an essential element in the system in order to provide a certain level of service assurance to the user receiving the service. Two very popular methods for providing QoS to a system are the Integrated Service (IntServ) (Non-Patent Document 1) and the Differentiated Service (DiffServ) (Non-Patent Document 2). ), Or mutations thereof.

  The IntServ framework has evolved with the Internet Engineering Task Force (IETF) to provide QoS guarantees specific to individual application sessions (flows). It requires individual sessions that can reserve sufficient resources to ensure that the QoS between endpoints is satisfied. IntServ operates based on individual flows. The resource reservation for each flow in IntServ includes the need for the router to process the resource reservation and maintain the flow state of each flow through the router. This causes a large amount of overhead to maintain the respective state of each flow, and the IntServ solution is not very scalable.

  In order to solve the scalability problem, the DiffServ solution was later recommended by the IETF. In the DiffServ solution, flows with similar characteristics are collected into classes. The number of classes is predetermined by the network that supports the DiffServ framework. In this framework, the packet carries its own state with several bits of the IP header (DSCP: Differentiated Services Code Point) and does not require a router to maintain the state of each flow. Moreover, in contrast to IntServ, packets in the same flow may not follow the same path. Each packet is treated as a special transfer based on this DSCP. The value of this DSCP determines how this packet is handled, for example, a packet with a high priority DSCP will be transferred first.

Normally, support for IntServ and DiffServ is handled by the network, and the terminal at the end does not know that these are being handled. Any marking, scheduling, and policing is performed by network components in the network on behalf of the terminating terminal. With these methods, the network as a whole, rather than the individual terminal terminals, handles the functionality associated with QoS based on current network conditions. Therefore, when better knowing what the terminal itself is in, the terminating terminal itself needs to perform QoS functionality handling in order to provide better QoS between the terminating points. .
IETF Integrated Service working group, http://www.ietf.org/html.charters/intserv-charter.html IETF Differentiated Service Working Group, http://www.ietf.org/html.charters/diffserv-charter.html IETF Resource Reservation Protocol (RFC2205), http://www.ietf.org/rfc/rfc2205.txt 3GPP, http://www.3gpp.org 3GPP2, http://www.3gpp2.org “Network Architecture” 3GPP TS 23.002 V5.8.0 (2002-09), ftp://ftp.3gpp.org/specs/archive/23_series/23.002/ SIP: Session Initiation Protocol-RFC2543 SDP: Session Description Protocol-RFC2327 EAP AKA Authentication, http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-08.txt “Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications: Specification for Enhanced Security”, IEEE Std 802.11i / D3.0, November 2002 “IEEE Standard for Local and Metropolitan Area Networks Port-Based Network Access Control”, IEEE Std 802.1x-2001 “DRAFT IEEE Standard for Local and Metropolitan Area Networks−Port Based Network Access Control−Amendment 1: Technical and Editorial Corrections”, IEEE DRAFT P802.1aa / D4 November 5, 2002 ITU-T Z.120 Message Sequence Chart, 11/1999 Floyd, S., and Jacobson, V., Random Early Detection gateways for Congestion Avoidance V.1 N.4, August 1993, pp.397-413 D. Clark and W. Fang, “Explicit allocation of best effort packet delivery service”, IEEE Trans. Networking, 6 (4), 1998, pp.362-373.

  Nowadays, quality of service (QoS) support has become one of the essential elements to create a good system. Traditionally, QoS is handled by a network that provides services to users. The terminal only performs QoS processing at the application level. For example, the terminal uses RSVP (Non-Patent Document 3) to request a predetermined resource from the network based on the application request. However, in a wireless environment, RSVP is no longer suitable for QoS control. A mobile terminal may change its point of attachment from time to time, so that it may use a different data path even before the end of a service session. Furthermore, RSVP requires support for every node along the data path, which is not always possible in large and complex systems.

  When paying attention to QoS between termination points, a mobile terminal that is a content receiver and a service user always constitutes one termination. That is, the terminal must always participate in QoS control. Conventional network-based QoS control is localized, that is, the control is only based on local network conditions. For example, in a terminal that sends 2 Mbps traffic to another terminal through some networks, packets may be lost in each network. Also, each network performs its control separately, and this type of non-adjustment control is not optimized and is inefficient. However, since the mobile terminal is the final consumer of traffic, it has all the information about QoS performed at this mobile terminal, and in a system that uses this information to control QoS, the user gets better service It is possible.

  In addition, in the QoS control centered on the network (QoS control performed by a network element in the relay network), the network is only queuing (queuing: packet transfer order control) in order to reduce traffic congestion. Alternatively, only dropping (packet discard control) could be performed, but this did not completely solve the problem. For example, when congestion occurs due to fast transmission by a terminal, the terminal or other terminals receive a bad service by performing network dropping or queuing. Therefore, it should be allowed for the source and the mobile terminal to perform its traffic scheduling in an appropriate way by a better method, and it is necessary to develop signaling and traffic control for the mobile terminal.

  Even in the extreme case where the network is unable to perform QoS management, terminal-centric QoS control may still provide some QoS guarantees. If the terminal itself operates and does not unnecessarily put a load on the network, it is possible to completely avoid congestion.

  In order to solve the above problem, the present invention moves the QoS control module from the network to the terminal. Instead of letting the terminal know the traffic conditions and leave the control to the network, when the correction is necessary, the terminal itself makes the correction. As a result, it is possible to prevent the traffic from being unnecessarily congested and not to depend on the network management system that handles all the functions related to QoS.

  Further, when a network management system exists, there is an advantage that management can be performed at an additional level. Even when there is no network management system, for example, the terminal itself performs QoS implementation and operation such as transmission at a lower transmission rate or transmission of a packet indicating setting to a lower priority. Has the ability to adapt modifications. In addition, even in a network that does not have QoS capability, if a terminal connected to this network can perform all operations, the terminal can still maintain a predetermined level of QoS.

  Further, the terminal terminal itself needs to know the transmission capacity in accordance with the state of the network. In order to know the network conditions, a centralized entity such as a central server needs to collect and integrate actual data and network conditions and perform feedback correction on each terminal.

  According to the present invention, it is possible to handle QoS at a terminal that is a terminal entity that receives a service. This allows the source to manage resources efficiently and avoids unnecessary network congestion. Even in the case of a network that does not have QoS control, if a terminal connected to the network has individual QoS control, the terminal still has a certain amount of QoS guarantee, and the terminal has a certain amount of packets to transmit. Controlling the amount of requests and requests does not interfere with network operation. This also eliminates the need for the network to perform this QoS control.

  In the present invention, the QoS management function is transferred to the terminal in order to perform more effective QoS management between termination points. The mobile terminal has a QoS management capability such as managing the transmission rate, and further managing the reception rate by controlling the number of requests to be acquired. And a central server that monitors all terminals directly based on a service level agreement between the service provider and the service provider. The central server exists in the user's home network. This home network is a network in which a user subscribes to a service. The terminal also has a QoS control module that performs reporting and monitoring. The QoS controller can also react to the operation change even when it receives implementation data telling the terminal which value should be changed, after which the QoS controller can react to the new value threshold and its range. Operate within.

  Hereinafter, an apparatus and method for adapting a terminal to QoS service control of a packet based on a communication network are disclosed. To assist in understanding the present invention, the following definitions are used.

  “WLAN” refers to a wireless local area network. This includes any number of devices to provide LAN services to mobile terminals through wireless technology.

  “3G network” refers to a third generation public access network. For example, it is a system defined by 3GPP (Non-Patent Document 4) or 3GPP2 (Non-Patent Document 5).

  “Mobile Terminal (MT)” refers to a device used to access services provided by a WLAN or other network through wireless technology.

  “Home network” indicates a network to which a mobile terminal first belongs in a scenario of mutual connection of mobile terminals.

  “Destination network” indicates a network to which the mobile terminal is connected. This network provides access services to mobile terminals.

  “Network element” refers to any device that functions in a network that performs information processing.

  The “rule engine” indicates a network element that executes a rule set by the following rule server and interpreted by the following rule interpreter into a locally specific command.

  The “rule interpreter” reads the rules given by the following rule server, interprets them with appropriate parameters into commands specific to the local technology, and supplies the network elements that are supplied to the rule engine that executes the commands. Show.

  The “rule server” indicates a network element that transmits an appropriate set of rules to a rule interpreter or a rule engine when a request is received or not.

  “Air interface” refers to any radio access technology for a mobile terminal to access a WLAN.

  A “stream” is a collection of packets that share a predetermined attribute and are transferred over a network.

  “Traffic” is a collection of streams transferred over a network.

  “Flow” indicates a network resource necessary for a data path or a data path used when a stream is transmitted.

  “QoS” is a term that indicates the quality of service of a data stream or traffic.

  “Message” indicates information exchanged between network elements to control the interconnection.

  An “operation sequence” refers to a sequence of message exchanges between any network elements in any order with respect to the control of the interconnection.

  The “upper layer” indicates any entity located above the entity that processes a packet passed from an entity.

  “SLA” indicates a service level agreement (Service Level Agreement).

  “User SLA” indicates a service level agreement between the service provider and the user.

  “Network SLA” indicates a service level agreement between a service provider and another service provider.

  “AAA” indicates authentication (Authentication), authorization (Authorization), and accounting (Accounting) regarding service provision to the mobile terminal.

  In the following description, specific numbers, times, structures, protocol names, and other parameters are used to provide a thorough understanding of the present invention. It will be apparent to those skilled in the art that the invention may be practiced. Also, in each case, well-known components and modules are shown in block diagram form in order not to obscure the present invention.

  FIG. 1 is a schematic diagram showing a configuration for realizing QoS between termination points in terminal-based control according to an embodiment of the present invention. Here, a 3G network or the like is used as the system architecture, but it is obvious to those skilled in the art that the system architecture can be applied to other networks having a similar architecture and control method.

  Each mobile terminal (hereinafter also simply referred to as a terminal) 11 is installed with a terminal QoS controller module 11A. The terminal QoS controller module 11A has a capability of executing QoS management such as traffic adjustment, operation monitoring, and packet rescheduling. The access point 12 is a terminal connection point to the destination network 13. The destination network 13 is a network that provides an access service to the terminal, and is connected to the home network 16 of the terminal via one or a plurality of relay networks 17. The relay network 17 may be of any type including, for example, an IP backbone and an ATM network.

  The policy attendant 14 exists in each destination network 13. This policy attendant 14 functions as a rule engine of the destination network 13 and executes rules acquired by the policy control framework in order to implement QoS control in the destination network 13. The policy attendant 14 controls connection permission based on the local policy in the destination network 13.

  The SLA manager 15 is a special server existing in the home network 16 and accesses a main database including an SLA database 18 having information on the SLA of every user who joins the network. Further, the SLA database 18 includes, for example, service status of each user such as location and service usage information. In the 3G network, an example of such a database is an HSS6 server (Non-Patent Document 6). The SLA manager 15 functions as a processing server in the home network 16 and determines service provision based on the user's subscription profile and network policy. This decision is transmitted to the mobile terminal 11 by the policy attendant 14 of each network by the policy control framework and the signaling method of the present invention.

  The mobile terminal 11 and the policy attendant 14 can operate appropriately to provide services to the user with the desired QoS. The policy control method used here depends on the network arrangement. In the present invention, an existing policy control framework is used and no additional conditions are given to the policy control framework. In this embodiment, signaling is performed by a protocol based on IP. However, it is obvious to those skilled in the art that it can be realized by another communication protocol such as SS7 or ATM.

  Since the terminal is mobile, it can be connected to different networks at different connection points. The network to which the terminal is connected is the home network 16 or the destination network 13 (any network other than the home network 16). When the terminal is directly connected to the home network 16, a signal path directly connected to the SLA manager 15 is guaranteed. When the terminal connects to the destination network 13, all requests from the terminal need to be sent to the destination network 13, and the destination network 13 needs to transfer the request to the home network 16. . That is, bidirectional communication is performed between the home network 16 and the destination network 13. There are several methods for establishing a signal path to the mobile terminal 11 in such a situation, and they are introduced as follows.

  FIG. 2 is a block diagram illustrating a detailed architecture of the terminal-centric QoS control framework in the embodiment of the present invention. In this figure, only those related to signaling and control are shown, and entities unrelated to them are omitted. In this architecture, a session management protocol is utilized for terminal QoS reporting and feedback control. For example, SIP can be used as a session management protocol. It will be apparent to those skilled in the art that other session management protocols can be operated with the minimum necessary modifications. Below, the function of each module in this architecture is briefly described.

  The terminal 21 is a user device, for example, a mobile terminal. This is equivalent to the terminal 11 and the QoS controller module 11A of FIG.

  The SIP application 22 is an application of the terminal 21 that uses SIP, which is a basic protocol for session management.

  The QoS controller 23 is an entity that manages QoS in the terminal 21, and performs operation monitoring and traffic adjustment such as packet rescheduling, packet queuing, packet discard, and adjustment of the amount of requests to be executed. This is an example of the QoS controller module 11A shown in FIG.

  The destination network 24 is a network to which the terminal 21 is currently connected.

  The SIP proxy 25 in the destination network 24 functions as a point for transferring the SIP message to the actual destination.

  The policy attendant 26 has a function of managing local processing of the destination network 24 and is connected to the SLA manager 28 of the home network 27 by the policy control framework.

  The home network 27 is a network to which the terminal 21 subscribes for service.

  The SLA manager 28 is a controller module that accesses the SLA database 29, collects user reports, and determines QoS handling and implementation.

  The SLA database 29 is a centralized data storage unit that stores all SLA, and includes an SLA between a user and a service provider and an SLA between service providers. Furthermore, for example, the service status regarding each user such as the location and the requested service is also held. The home SIP proxy 30 is a SIP proxy that exists in the home network 27.

  FIG. 3 is a sequence chart showing signaling for QoS reporting and feedback when the terminal is not directly connected to the home network, which is used in the architecture of FIG. The terminal 21 is connected to the destination network 24 and cannot use a direct IP connection to the home network 27. In order to access the services provided by the home network 27, the terminal 21 needs to use some session management mechanism, in this example SIP is shown. It should be apparent to those skilled in the art that other session management protocols can operate.

  When the terminal 21 starts a session with a request party (Callee party), the SIP application 22 issues “INVITE”, also known as an SDP message, with a corresponding session description protocol (301: INVITE (SDP )). A QoS control capability tag indicating that this terminal has a QoS control capability is embedded in the SDP. The “INVITE” message first passes through the SIP proxy 25 of the destination network 24. The SIP proxy 25 of the destination network 24 examines this packet and transfers the SIP message to the home SIP proxy 30 of the home network 27 (302: INVITE (SDP)). The home SIP proxy 30 is a SIP proxy residing in the home network 27 that sends the service request to the SLA manager 28 that authorizes the requested service before forwarding the request to another entity for further processing. (303: Check Srv Req). This information is a part of the requesting SLA stored in the SLA database 29.

  When the SLA manager 28 does not hold the requesting SLA, the SLA manager 29 performs an operation of extracting the requesting SLA from the SLA database 29 (304: CheckSLA). And the request source SLA information is passed (305: SLA OK). At this time, the passed SLA information may not be complete of the user's SLA, and only includes information related to the service request indicated by the SLA manager 28 in the message (CheckSLA). When the service is permitted based on the requesting SLA, the SLA manager 28 notifies the home SIP proxy 30 to continue the session processing (306: Srv Req OK). On the other hand, if the service is not permitted, the SLA manager 28 rejects the session request and stops the subsequent processing.

  Next, in response to the service request, the home SIP proxy 30 forwards the SIP message to a service platform such as a home SIP proxy for which the service is requested, for further processing (307: service). Req transfer to platform). If the service platform process in the process 307 is successful, the home SIP proxy 30 receives the SIP 183 message (Non-Patent Documents 7 and 8). If the QoS control capability tag is included in the SDP message from the terminal 21, the home SIP proxy 30 issues a “Start PMSession” message to the SLA manager 28 (308: Start PMSession). When this “Start PMSession” is received, the SLA manager 28 starts a monitoring session.

  Further, as necessary, the SLA manager 28 updates the SLA of the user stored in the SLA database 29 (324: SLA update). It should be apparent to those skilled in the art that the same mechanism for updating the SLA can be applied as necessary. At the same time, the home SIP proxy 30 relays the SIP 183 message in which the QoS control capability tag is embedded to the SIP proxy 25 of the destination network 24 (309: SIP 183 (SDP)). The QoS control capability tag of this approval message (SIP183 message) informs the terminal 21 that the QoS controller module can be started. Before transferring this message to the terminal 21, the SIP proxy 25 of the destination network 24 checks with the policy attendant 26 whether the terminal 21 is permitted to use the resources of the destination network 24 (310: Auth). req (SDP)).

  When the requested service is permitted, if the resource is available, information indicating authorization (Authorize Token) is sent from the policy attendant 26 to the SIP proxy 25 of the destination network 24 ( 311: Ack (Auth token)). After receiving the authorization token, the SIP proxy 25 of the destination network 24 transfers the SIP 183 message together with this token to the terminal 21 (312: SIP 183 (SDP, Auth Token)). When receiving this message, the terminal 21 notifies the QoS controller 23 of information related to this session, and the operation of the QoS controller 23 is started (313: Start QoS Controller).

  If the policy attendant 26 cannot permit the service due to a local policy or because the resource is limited, the message 311 includes information indicating invalidity. When the information indicating the invalidity is received, the SIP proxy 25 of the movement destination network 24 does not send the SIP 183 message to the user, but instead sends the SIP 488 error message together with the information indicating the invalidity to the terminal 21. When the terminal 21 receives the information indicating invalidity, the terminal 21 starts a “BYE” message for passing the session through the SIP proxy 25. Note that this message exchange process in the scenario in which the authorization fails is not shown in FIG.

  After the terminal 21 receives the SIP 183 message, the terminal 21 starts a normal service session controlled by SIP (314: user session). During this service session, the QoS controller 23 creates a QoS report for the service session and feeds back to the SLA manager 28 of the home network 27 using the SIP signal path.

  The QoS controller 23 periodically passes a QoS report related to the service session to the corresponding SIP application 22 (315: QoS Report). To do this, a new SIP method can be defined, for example for the message “REPORT”. The SIP application 22 generates a “REPORT” message and inserts the QoS report information acquired from the QoS controller 23 into the SDP attribute field. The destination address for this message is the SIP proxy 30 of the home network 27. Then, the SIP application 22 transfers this report message to the SIP proxy 25 of the destination network 24 (316: Report (QoS Report)), and the SIP proxy 25 of the destination network 24 sends a specific destination address ( Transfer to home SIP proxy 30) (317: Report (QoS Report)). If the SIP proxy 25 of the destination network 24 does not support this REPORT method, the SIP proxy 25 handles this as an “option” method.

  Upon receiving this method request, the home SIP proxy 30 extracts the embedded QoS report information and forwards it to the SLA manager 28 for further processing (318: QoS Report). After receiving the QoS report information, the SLA manager 28 performs QoS control management using the network policy and other related information (319: QoS control management). In this management, adjustment of QoS parameters assigned to the terminal 21 and / or updating of corresponding data in the SLA database 29 are also performed.

For example, the “REPORT” message is as follows:
/ * New REPORT method to carry QoS reports * /
REPORT sip: foo.bar.com SIP / 2.0
From: sip: terminal1@foo.bar.com / * SIP address of terminal * /
To: sip: main@home.com / * Home SIP proxy address * /
Cseq: 1 REPORT
a = packet_sent: xxxx / * Attribute field carrying QoS parameter information * / a = packet_recv: xxxx
a = avg_bandwidth: xxxx

  Other QoS parameters that can be included for reporting include: QoS class, transmission capacity (transmit bytes), receive capacity (receive bytes), discard capacity (discard bytes), number of discarded packets, average bandwidth, maximum bandwidth, Examples include a discard interval, an average delay time, jitter, usage information, and a transmission discard threshold. The QoS parameter can be further expanded and is not limited to the above.

  When QoS adjustment is necessary, the SLA manager 28 sends a QoS control message together with the identifier of the terminal 21 to the home SIP proxy 30 (320: QoS Control). At this time, the home SIP proxy 30 creates a SIP message having a special code indicating that QoS control is the purpose, and puts the received QoS control message therein. For example, another new method can be defined, the QOS_ENFORCE message. The home SIP proxy 30 transfers this QOS_ENFORCE message to the SIP proxy 25 of the destination network 24 of the terminal 21 (321: QOS_ENFORCE (QoS Control)). The SIP proxy 25 of the destination network 24 immediately transfers this message to the SIP application 22 of the terminal 21 (322: QOS_ENFORCE (QoS Control)).

  When reading the code indicating the QoS control, the SIP application 22 of the terminal 21 extracts the embedded QoS control information from the SIP TBD message, and sends the extracted QoS control message to the QoS controller 23 together with the service session information. Send (323: QoS Control). Then, the QoS controller 23 operates according to the instruction provided by the QoS control message, and adjusts the operation of the terminal 21 so as to achieve better QoS for the service session. FIG. 12 is a template of operation_ID (Action_ID) in the embodiment of the present invention. As described below, for example, the above instruction is carried in the “operation_ID” attribute field. The “operation_ID” attribute field includes, for example, those listed in the table of FIG.

QOS_ENFORCE sip: home.com SIP / 2.0
From: sip: main@home.com
To: sip: terminal1@foo.bar.com
Cseq: 1 QOS_ENFORCE
A = action_id: xxxx / * action attribute * /
A = <Qos Parameter>: yyyy

  It should be apparent to those skilled in the art that SLA manager 28 can also send unsolicited QoS control messages using the same mechanism. For example, when the network state changes or the network processing is different, the SLA manager 28 needs to adjust the QoS control parameter of the terminal 21, thereby sending a QoS control message to the terminal 21. Is possible.

  Further, the QoS controller 23 of the terminal 21 is shared across applications in the terminal 21. Therefore, as long as the application is operating, the QoS controller 23 is in a valid state. If a new session detects that the QoS controller 23 is already running, the new process of the QoS controller 23 does not begin, and the existing one is monitored, reported and implemented.

  FIG. 4 is a block diagram illustrating an example of an alternative architecture for the terminal-centric QoS control framework shown in FIG. In this architecture, an AAA (authentication, authorization, billing) framework is utilized to establish QoS reporting and control implementation. In FIG. 4, only the elements related to signaling and control are shown. The terminal 41 has two components, a QoS controller 42 and an AAA stack 43 for signaling. The QoS controller 42 is the QoS controller module 11 </ b> A shown in FIG. 1, performs QoS at the terminal 41, and controls traffic output from the terminal 41. The QoS controller 42 also monitors and collects the QoS usage information of the terminal 41 and feeds it back to the SLA manager 48 in the home network 46 of the terminal 41.

  The AAA stack 43 is an entity that controls the AAA (authentication, authorization, and billing) procedure of the terminal 41. For example, EAP-AKA (Non-Patent Document 9) can be used in a 3G network, and IEEE 802.1x (Non-Patent Documents 11 and 12) in an IEEE802.11i (Non-Patent Document 10) WLAN system. It is possible to use a key plus an entity that manages keys. The AAA stack 43 is necessary in a standard network, and therefore the present invention does not make extra demands on the network. The terminal 41 is connected to the movement destination network 44. The destination network 44 provides standard AAA equipment, that is, an AAA proxy 45 for relaying AAA messages from the terminal 41 to the AAA server 47 in the home network 46. In practice, the AAA proxy 45 can coexist with other network elements. For example, in an IEEE802.11i system, the AAA proxy 45 can be an authentication device in an access point, As a result, the EAP packet from the terminal 41 is encapsulated in a Radius / Diameter packet. The SLA manager 48 and SLA database 49 in the home network 46 are identical to the components 15 and 18 defined in FIG.

  FIG. 5 is a sequence chart showing an example of a signal sequence using the framework introduced in FIG. 4 in order to achieve terminal-centered QoS control in the embodiment of the present invention. When the terminal 41 is connected to the destination network 44 and accesses a service for the first time, the AAA stack 43 of the terminal 41 sends an “AAA request” to the AAA proxy 45 in the destination network 44 (501: AAA request ( NAI)). This “AAA request” includes identification information of the terminal 41 and home domain information. For example, in a 3G network, this information exists in the form of a network access identifier (NAI). The contents of the NAI can be, for example, “terminal1@foo.bar.com”. Here, “terminal1” is an identifier, and “foo.bar.com” is home domain information. The AAA proxy 45 uses the domain information described in the NAI to forward the request (AAA Request, hereinafter also referred to as AAA request) to the AAA server 47 of the user's home network 46 (502: AAA request ( NAI)).

  After receiving the message, the AAA server 47 of the home network 46 extracts the user identifier and service information from the AAA request. The AAA server 47 further sends this request to the SLA manager 48 to check whether the service is permitted for the subscription information of the user in the SLA (503: check subscription information of the user). If unavailable, the SLA manager 48 extracts the user's SLA from the SLA database 49 (504: request SLA, 505: get SLA). On the other hand, if the requested service is granted based on the user's SLA, the SLA manager 48 provides further service configuration information according to the network policy stored in the SLA and other information in the SLA (506: In addition, the SLA manager 48 checks the capability of the terminal 41 by the NAI embedded in the AAA request. If the terminal 41 can perform QoS control, the pseudo service “QoS control” is requested by default along with the actual service.

  For example, if NAI is used to indicate a service, the format terminal1@QoSControl.foo.bar.com is also possible. Here, “QoS Control” immediately to the right of “@” indicates that the terminal 41 can perform QoS control. It should be apparent to those skilled in the art that other instruction information can be used depending on the scheme employed in the AAA procedure to identify the service.

  When the SLA manager 48 finds this “QoS Control” pseudo service, it starts monitoring the service of the terminal 41 and configures a parameter for setting a connection for QoS control. This configuration includes setting QoS initial parameters for the QoS controller 42, assigning home network addresses for QoS control, managing the tunnel configuration for control messages, and the like. Such special settings may be included in the normal service configuration. In this case, the special settings are collectively sent to the AAA server 47 (507: Service Auth (QoS Control Setup)). If necessary, the SLA manager 48 simultaneously updates the SLA stored in the SLA database 49 (508: SLA update). Then, the AAA server 47 creates a “Service Config” message, embeds all settings therein, and sends it to the AAA stack 43 of the terminal 41 via the AAA proxy 45 of the destination network 44 (509). : Service Config (QoS Control Setup), 510: Service Config (QoS Control Setup)).

  When receiving the “Service Config” message, the AAA stack 43 extracts all the embedded service information and passes them to the corresponding application. Similarly, the configuration of the “QoS Control” pseudo service is passed to the QoS controller 42 of the terminal 41 (511: QoS Control Setup), and a QoS service session is started. The QoS controller 42 uses the initial QoS configuration embedded in the AAA request in order to perform QoS control at the terminal 41. Further, the QoS controller 42 uses the tunnel configuration embedded in the AAA request in order to set up a tunnel toward the SLA manager 48 of the home network 46 (512: QoS control tunnel setting). This tunnel is used by the SLA controller 42 to report QoS statistics to the SLA manager 48, and the SLA manager 48 is used to send QoS execution instructions to the QoS controller 42.

  In this scheme, the QoS controller 42 operates on the AAA stack 43 like a normal application. The QoS setting and tunnel setting are obvious to the AAA stack 43. Thus, even if the QoS controller 42 uses the AAA framework for its configuration, no changes from the standard AAA stack 43 are required. That is, this shows that the present invention has high adaptability in any standard network.

  As the user session progresses, the QoS controller 42 generates a QoS statistic that reflects the service observed by the terminal 41. The QoS controller 42 reports this information to the SLA manager 48 using the above tunnel setting (513: QoS report). FIG. 9 is a diagram showing a format of a report message (QoS report) for reporting QoS data sent from the terminal to the SLA manager in the embodiment of the present invention. The report message first has a message_ID field 91, followed by a message length field 92, and further a payload. The payload is composed of attribute value pair information 93, and the attribute includes a QoS parameter or an attribute of information.

  Examples of QoS parameters include QoS class, transmission capacity (transmission bytes), reception capacity (reception bytes), discard capacity (discard bytes), discarded packets, average bandwidth, maximum bandwidth, discard interval, average delay time, jitter , Usage information, transmission discard threshold, and the like. The QoS parameter can be further expanded and is not limited to the above. In this example, fixed length attribute value pairs are used, so only the message length field 92 is the only information needed for the entire message. If variable length attribute value pairs are employed, each pair requires an additional length field that indicates the length of the attribute value pair.

  After receiving a report from the QoS controller 42, the SLA manager 48 performs some QoS management process to determine whether any adjustments need to be made at the terminal 41. If necessary, the SLA in the SLA database 49 is updated. When any change is necessary in the terminal 41, the SLA manager 48 sends a QoS execution message to the QoS controller 42 in the QoS control tunnel setting 512 (514: QoS execution control). FIG. 10 is a diagram showing a format of a QoS execution message sent from the SLA manager to the terminal in the embodiment of the present invention. The QoS execution message has a message_ID field 101, a message length field 102, an operation_ID field 103, and a QoS parameter field (attribute value pair information) 104. A QoS execution message has a set of predefined message templates. Similar to the format of the report message described above, the QoS parameter field 104 may be zero, one, or multiple QoS data fields. An example of the operation_ID field 103 and the corresponding operation is the same as that shown in FIG.

  Once a tunnel is set in the QoS control tunnel setting 512, the tunnel is usable for the SLA manager 48 and the QoS controller 42. The two nodes communicate with each other so that they are in the same subnet. It is also possible to transmit the address of the SLA manager 48 and the corresponding port number to the QoS controller 42 during the setting time of the “QoS control” service (in the case of QoS control setting 511). The address of the terminal 41 is assigned by the SLA manager 48 during the service authorization phase 506 and is always available.

  In communication between end points for QoS control, the SLA manager 48 needs to write only the address of the terminal 41 and a predetermined port number, for example, the IP address “xxxx” of the port “ss”. On the other hand, the QoS controller 42 of the terminal 41 needs to write only the address of the SLA manager 48 and the port number acquired in the service permission stage 506, for example, the IP address “yyyy” of the port “pp”. The relay route is handled in the tunnel channel. It should be apparent to those skilled in the art that the present invention can be applied to any addressing method instead of using an absolute address.

  The tunnel channel needs to be set for each terminal 41, and is normally requested first by a service in the destination network 44. In other words, only one pseudo service “QoS control” exists for each terminal 41. The SLA manager 48 can decide to cancel the channel. For example, if the terminal is no longer connected to the destination network 44, or if the service session no longer exists, the SLA manager 48 may delete the configuration at the control node (eg, GGSN) 47 can be signaled.

  The SLA manager 48 can also send unsolicited QoS execution control messages 514 to the QoS controller 42. The entire system also operates on the concept of reporting and execution / update. Both the policy attendant 14 and the QoS controller 11A shown in FIG. 1 need to operate while reporting to the SLA manager 15. The QoS controller 11A reports on the status observed at the terminal 11, while the policy attendant 14 reports the network status and conditions to the SLA manager 15. Reporting can be done regularly or when requested. When the SLA manager 15 determines the necessity of adjustment based on the report from one of the policy attendant 14 and the QoS controller 11A, the SLA manager 15 issues a QoS execution message. It should be apparent to those skilled in the art that the SLA manager 15 can further adjust the network at the same time if necessary using a policy framework (not shown).

  The two signaling described above are signaling mechanisms that need to set up a path for passing QoS data from the terminal 11 to the home network 16 or vice versa in order to achieve QoS control between termination points.

  Once the terminal 11 receives the QoS execution instruction from the SLA manager 15, the QoS controller 11A of the terminal 11 replaces the current state with the one instructed by the QoS execution instruction in accordance with the QoS execution instruction. FIG. 6 is a diagram illustrating an example of QoS monitoring of the QoS controller according to the embodiment of the present invention. This is modeled using a high level message sequence (13). When the QoS controller 11A of the terminal 11 is started, an initial value of a preset or an initial value acquired from an initial configuration state is configured (601: initial configuration setting). These values include different QoS metrics that are used to monitor operational data. When the QoS controller 11A of the terminal 11 is activated, it starts operating and collects and monitors usage data. Further, the collected data is fed back, packed in a known format, and sent to the central server that is performing the integration (602: monitoring and reporting of operation data). In this case, the central server is, for example, the SLA manager 15. During operation monitoring, the central server compares the operation data with its threshold, and if a violation occurs (603: threshold violation occurs), performs the necessary corrections to handle this violation (604: violation). Processing).

  The corrective action performed here is a delay of the transmitted packet, complete discard of the packet and / or rescheduling of the packet, or complete termination of the session if the transmission bandwidth exceeds the threshold. Therefore, the transmission bandwidth can be controlled in this way. When receiving a packet, it is possible to minimize the input packet request, control the reception bandwidth, and further suppress the bandwidth request of all input packets. When the network state changes, the policy server (central server) notifies the SLA manager 15 of these changes. Then, the SLA manager 15 makes a decision regarding policy change. This includes updating the rule engine of the policy server and / or updating the configuration of the QoS controller of the affected terminal 11 in order to manage the QoS with the new threshold after the update. In updating the configuration of the affected terminal 11, execution data is passed to the affected terminal 11. The affected terminal 11 receives the execution data (605: reception of execution data), and performs necessary update or change based on the request for this data (606: performs the requested operation). Then, the monitoring process is resumed based on the updated new value.

  FIG. 7 is a diagram modeling a session monitored by the SLA manager in the embodiment of the present invention. When the operation monitoring session starts, the SLA manager 15 reads necessary SLA information and current rules from the SLA database 18 for monitoring (701: reading of rules). The SLA manager 15 periodically receives reports on the status of the terminal 11 and the policy server (702: network and terminal monitoring). For example, the SLA manager 15 can receive a report in an aperiodic manner by actively transmitting to the SLA manager 15 or responding to a request from the SLA manager 15. The status is compared with the SLA information. If a warning or violation is detected (703: violation detected), the SLA manager 15 determines the operation to be performed (704) depending on the nature of the violation and the state of both the network and the terminal 11 (704). : Congestion avoidance processing, execution of new rules). For example, the SLA manager 15 executes an execution mechanism that updates a policy server with a new rule by executing a new rule or determining execution data, filling the information in a known format, or It requests to change its configuration.

  Moreover, FIG. 11 is a figure which shows the architecture for the QoS controller of the terminal in embodiment of this invention. This QoS controller 1101 has the following subcomponents. The monitoring module 1103 includes a measurement module 1102, collects operation monitoring data, and further confirms a threshold violation. The execution module 1107 also includes a classification device 1104 that performs traffic reduction, a marker 1105, and a packet delay / packet discard device 1106. The communication module 1110 also has usage information and traffic profile 1108 for collecting and storing all operation monitoring data from the measurement module 1102, and a report module 1109 for communicating with the SLA manager. Note that the communication module 1110 also functions as an execution module to execute correction when receiving execution data.

  Before being output from the terminal, the data packet 1112 needs to be classified by the classifier 1104 according to its priority. Each application has a predefined priority, and after classification by the classification device 1104, the data packet 1112 is sent to the marker 1105 and marked as “in_profile”, “out_profile”. The measurement module 1102 checks the usage information and the traffic profile 1108 and notifies the marker 1105 of the current state of the terminal. The marker 1105 marks the packet as “in_profile” or “out_profile” according to the current state.

  After this marking process, the packet delay / packet discard device 1106 determines whether to delay the transmission of the packet or to discard the entire packet. Further, the packet delay / packet discard device 1106 checks the current terminal through the measurement module 1102 regardless of the packet delay or discard. Packets marked with “out_profile” are discarded with a higher probability than packets marked with “in_profile”. The output data packet 1113 is a packet that is actually output. The reporting module 1109 periodically reports to the SLA manager 1111, and the SLA manager 1111 sends a QoS execution message back to the terminal through the reporting module 1109. If any execution action is requested, a QoS execution message is executed in the associated execution module 1107.

  FIG. 8 is a diagram illustrating a method in which the QoS controller performs QoS monitoring and traffic control according to the embodiment of the present invention. When congestion occurs, the SLA manager 1111 passes the QoS execution data to the QoS controller 1101 of the terminal to change the operation. In this example, the data packet is classified by the classifier 1104 into four different priorities A, B, C, D. A indicates the highest priority and D indicates the lowest priority. Also, the transmission bandwidth allocated to the terminal is used as a determinant for performing the correction. In addition, other parameters can be used as determinants to perform the correction.

  When the QoS controller 1101 receives QoS execution data instructing to reduce its bandwidth, the QoS controller 1101 changes the current value to the received new value and sets a new guaranteed value (801: Receive execution data, set new guaranteed values). In addition, when congestion occurs, the SLA manager 1111 reduces the allocated transmission bandwidth to the same level as the low priority terminal, and sends execution data including necessary information to the affected terminal. send. When receiving the execution data, the terminal compares the execution data with the value before the update. In addition, regarding the measurement data of “total allocated bandwidth”, correction is executed when the new value is less than or equal to the existing value.

  In this example, the highest priority is given to packets classified as type A, but for type A applications, the guaranteed total bandwidth cannot adequately support the requested bandwidth. In this case (802: class A bandwidth> new guaranteed value), the current class A session is terminated (803: class A session is terminated). On the other hand, if the guaranteed total bandwidth can support the requested bandwidth, the type A packet will be given all of the requested bandwidth (804: complete for class A packets). Allocate bandwidth). After allocating all of the type A packets, the remaining bandwidth is allocated to types B, C, and D, for example, in a ratio of 7: 2: 1 (805: 70 of the remaining bandwidth to class B) 806: 20% of the remaining bandwidth for class C and 10% of the remaining bandwidth for class D). In classes B, C, and D, the bandwidth is adjusted according to the transmission rate, packet discard, packet transmission delay, and the like. Packets are queued for different classes according to the number of bandwidths and classes allocated in this way, and thresholds for each type are calculated (807: thresholds are re-established according to newly allocated bandwidths). Setting). Also, “in_profile” and “out_profile” are marked in the packet according to whether the threshold is reached. For example, in the case of a video encoder application, if the bandwidth usage exceeds the threshold for Type B, the QoS controller can connect to the video encoder and instruct to encode at a lower bit rate.

  Also, if there is no interface to the above application and a connection cannot be made, the QoS controller can also decide to selectively discard the packet to meet the threshold. Input packets are selectively marked as “out_profile”, and packets marked with “out_profile” are discarded first. For types C and D, type C packets are queued more frequently than type D packets, and type D packets are queued last based on the assigned ratio. The above ratio is merely an example, and any ratio is possible by allocating bandwidth to different classes. Further, the classification type can be any number of classifications, and is not limited to types A, B, C, and D. Furthermore, the QoS controller can use other scheduling means such as RED (Non-Patent Document 14) and RIO (Non-Patent Document 15), and the queuing mechanism QoS controller can use other means of scheduling.

The schematic diagram which shows the structure which implement | achieves QoS between termination | terminus points by the terminal-based control in embodiment of this invention The block diagram which shows the detailed architecture of the terminal-centered QoS control framework in embodiment of this invention Sequence chart showing signaling for QoS reporting and feedback when the terminal is not directly connected to the home network, used in the architecture of FIG. Block diagram illustrating an example of an alternative architecture for the terminal-centric QoS control framework shown in FIG. FIG. 4 is a sequence chart showing an example of a signal sequence that uses the framework introduced in FIG. 4 in order to achieve terminal-centric QoS control in the embodiment of the present invention. The figure which shows an example of the QoS monitoring of the QoS controller in embodiment of this invention The figure which modeled the session which the SLA manager in embodiment of this invention has monitored The figure which shows the method in which the QoS controller in embodiment of this invention performs QoS monitoring and traffic control The figure which shows the format of the report message (QoS report) for reporting the QoS data sent to the SLA manager from the terminal in embodiment of this invention The figure which shows the format of the QoS execution message sent to a terminal from the SLA manager in embodiment of this invention. The figure which shows the architecture for the QoS controller of the terminal in embodiment of this invention The figure which shows the template of operation_ID (Action_ID) in embodiment of this invention

11, 21, 41 Mobile terminal (MT, terminal)
11A, 23, 42, 1101 QoS controller module (QoS controller)
12 Access point 13, 24, 44 Destination network 14, 26 Policy attendant 15, 28, 48, 1111 SLA manager 16, 27, 46 Home network 17 Relay network 18, 29, 49 SLA database 22 SIP application 25 SIP proxy 30 Home SIP proxy 43 AAA stack 45 AAA proxy 47 AAA server 1102 Measurement module 1103 Monitoring module 1104 Classification device 1105 Marker 1106 Packet delay / packet discard device 1107 Execution module 1108 Usage information and traffic profile 1109 Reporting module 1110 Communication module 1112 Data packet 1113 Output data packet

Claims (6)

It is possible to monitor whether the observed QoS statistics exceed a predetermined threshold, report the QoS statistics to the central controller, and execute QoS control based on the QoS execution data received from the central controller A terminal having a QoS control module,
The QoS control module is
A monitoring module that collects QoS information from the terminal and the running application;
A communication module for reporting information on the collected QoS to the central controller and receiving an execution instruction from the central controller;
An execution module for controlling the operation of the terminal according to a QoS metric received from the communication module;
Terminal with.   The terminal according to claim 1, wherein the QoS control module of the terminal further comprises a local database for storing information on the collected QoS. The monitoring module is
Means for obtaining information relating to the QoS and storing the information relating to the QoS in a local database of the terminal;
A means of monitoring threshold violations;
Means for causing the execution module to initiate traffic control if the violation is detected;
The terminal according to claim 2. Means for packing the QoS information in a known format before sending the QoS information to the central controller;
Means for analyzing information relating to QoS execution received from the central controller;
Means for updating the status of the terminal based on information relating to the execution of the QoS received from the central controller;
Means for causing the execution module to make an appropriate correction in the information relating to the execution of the QoS received from the central controller, if necessary;
The terminal according to any one of claims 1 to 3.   The terminal according to claim 1, wherein the execution module further includes means for performing traffic control in the terminal, and controls the operation of the terminal. The execution module is
Means for classifying packets into different priorities in the terminal;
Means for managing packet discard in the terminal when resource allocation allocated to the terminal is exhausted;
Means for reducing congestion at the terminal by lowering the transmission rate;
Means that suppresses congestion at the terminal by delaying packet transmission when sufficient resources are not allocated to the terminal;
A means to terminate the session and stop sending packets;
Means to reduce output packets by limiting the total number of sessions currently running;
Means to reduce ingress traffic by limiting the total number of sessions to egress,
The terminal according to claim 5, comprising at least one of means for reducing input traffic by making a request to reduce input traffic.