Sign In to Follow Application
View All Documents & Correspondence
View All Documents & Correspondence
"Communication System And Communication Method"
Abstract: There is disclosed a technique that a terminal receiving a service can handle QoS. According to this technique, a terminal (21) at an terminating end handles the function associated with the QoS and Qos management scheme of a terminal base achieving the QoS between terminating ends is performed. Since QoS is managed at the terminal, the terminal should grasp the network condition and other entity state to decide what kind of operations are to be performed. For example, the terminal monitors a packet, collects use information, and reports the collected data to a central server (SLA manager 28). The central server collects these information from all the terminals within its management domain. Moreover, the central server references informatio...
Get Free WhatsApp Updates!
Notices, Deadlines & Correspondence
Notices, Deadlines & Correspondence
Patent Information
Application #
Filing Date
17 April 2009
Publication Number
25/2009
Publication Type
INA
Invention Field
COMMUNICATION
Status
Email
Parent Application
Applicants
PANASONIC CORPORATION
1006, OAZA KADOMA KADOMA-SHI OSAKA 571-8501, JAPAN.
Inventors
1. CHIA PEI YEN
BLK. 865 YISHUN ST. 81 #12-09 760865 SINGAPORE.
2. CHENG HONG
BLK. 405 SERANGOON AVE. 1 #07-51 550405 SINGAPORE.
Specification
SPECIFICATION
COMMUNICATION SYSTEM AND COMMUNICATION METHOD
TECHNICAL FIELD
This invention relates to a communication system and a communication method, especially a radio communication system and a radio communication method utilizing the wireless technology in a mobile network. This invention can also be used in a heterogeneous network environment to provide end-to-end QoS guarantees.
BACKGROUND ART
IP networks were originally designed to carry best effort traffic. In best effort service, the delivery of pac:yyyy
It is obvious to anyone skilled in the art that the SLA manager 28 could send unsolicited QoS control message using the same mechanism. For example, when the network status changes or the network policy varies, the SLA manager
28 would need to adjust the QoS provision parameters of the terminal 21, and therefore trigger the sending of QoS control message to the terminal 21.
The QoS controller 23 at the terminal 21 is shared across the applications within the terminal 21. Therefore, it remains active as long as there are application activities If a new session detects the QoS controller 23 is already running, it will not start a new QoS controller 23's process but use the existing one for the monitoring, reporting and enforcement.
FIG. 4 is a block diagram showing an alternative architecture implementation for the terminal centric QoS control framework shown in FIG. 1. In this architecture, the AAA (Authentication, Authorization and Accounting) framework is utilized for establishing the QoS reporting and enforcement control. In this FIG. 4, only elements involved in the signalling and control are included. The terminal 41 comprises two entities for the signalling, the QoS Controller 42 and the AAA Stack 43. The QoS controller 42 is the QoS controller module 11A shown in FIG. 1. It performs QoS enforcement at the terminal 41 and regulates the traffic that goes out of the terminal 41. The QoS controller 42 also monitors and collects QoS usage information of the terminal 41 and feedbacks to the SLA manager 48 in the terminal 41's home network 46.
The AAA stack 43 is the entity that controls the terminal 41's AAA (Authentication, Authorization and Accounting) procedures. For example, in a 3G Network, it could be the EAP-AKA (non-patent document 9) , and in an IEEE802.Hi (non-patent document 10) WLAN, it could be the IEEE802.1x (non-patent document 11, 12) plus the key management entities. Since the AAA stack 43 is required in a standard network, this invention poses no extra requirements on the network. The terminal 41 attaches to the visited network 44, and the visited network 44 provides standard AAA facilities, the AAA proxy 45, to relay the AAA message from the terminal 41 to the AAA server 47 in the home network 46. In actual implementation, the AAA proxy 45 could be collocated with other network entities. For example, in the IEEE802.Hi system, the AAA proxy 45 could be the authenticator in the access point, which encapsulates the EAP packets from the terminal 41 into Radius/Diameter packets . The SLA manager 48 and SLA database 49 in the home network 46 are identical to the entities 15 and 18 defined in FIG. 1.
FIG. 5 is a sequence chart showing an example signalling sequence using the framework introduced in FIG. 4 to achieve the terminal centric QoS control in the embodiment of the invention. When the terminal 41 associates with the visited network 44 and wants to access certain services for the first
time, the AAA stack 43 of the terminal 41 sends an "AAA request" to the AAA proxy 45 in the visited network 44 (501: AAA request (NAI)). This "AAA request" would include the terminal 41's identity and home domain information. For example, in the 3G network, this information is in the form of a Network Access Identifier (NAI) . An example content of the NAI could be "terminall@foo.bar.com", where the "termmall" is the identity and "foo.bar.com" is the home domain information. The AAA proxy 45 forwards the request to the AAA server 47 of the user's home network 46, using the domain information described in the NAI (502: AAA request (NAI)).
After receiving the message, the home network 46' s AAA server 47 extracts the user identity and the service information from the AAA request. The AAA server 47 would further send this request to the SLA manager 48. The SLA manager 48 would check the user's subscription information to authorize the service against the user's subscription information in the SLA (503: Check User subscription) . The SLA manager 48 would extract the user's SLA from the SLA database 49 if it were no available (504: Request User SLA, 505: Obtain User SLA) . If the user' s SLA allows the requested service, the SLA manager 48 would provide further service configuration information according to the network policy and other information stored in the SLA (506: Service
Authorization Phase and configure Initial QoS). Furthermore, the SLA manager 48 would also check the capability of the terminal 41 via its NAI embedded in the AAA request. If a terminal 41 is QoS control capable, a pseudo service, "QoS control", will be requested by default together with the actual services.
For example, if the NAI is used to indicate the service, it could be in the form of "terminall@QoSControl.foo.bar.com", where the "QoS Control" right after the "@" sign indicates that the terminal 41 is QoS control capable. It is obvious to anyone skilled in the art that other forms of indication will be possible depending on the schemes adopted in the AAA procedure to identify the service.
When the SLA manager 48 finds this "QoS Control" pseudo service, it would initiate the service monitor session for the terminal 41, and configure the parameters for setting up the connections for the QoS Control. This configuration includes the setting of QoS initial parameters for the QoS Controller 42, allocating a home network address for the QoS control purpose, managing the tunnelling configurations for the control messages, etc. This special setting would be embedded to the normal service configuration and sent together to the AAA server 47 (507: Service Auth (QoS Control Setup) ) . If necessary, the SLA manager 48 would update the
SLA stored in the SLA database 49 at the same time (508 : Update SLA) . The AAA server 47 would then create a "Service Conf lg" message, embed all the settings inside and send it to the AAA stack 43 of the terminal 41 via the AAA proxy 45 in the visited network 44 (509: Service Config (QoS Control Setup, 510: Service Config (QoS Control Setup)).
When the AAA stack 43 received a "Service Config" message, it would extract all the service information embedded and pass them to corresponding application. Similarly, the configuration of "QoS Control" pseudo service would be passed to the QoS controller 42 in the terminal 41 to trigger the QoS service session (511: QoS Control Setup). The QoS controller 42 would use the initial QoS configuration embedded to enforce the QoS control at the terminal 41. The QoS controller 42 would also use the embedded tunnelling configuration to setup a tunnel towards the SLA manager 48 at the home network 46 (512: QoS Control Tunnel Setup) . This tunnel would be used by the QoS controller 42 to report QoS statistics to the SLA manager 48, and by the SLA manager 48 to send QoS enforcement command to the QoS controller 42.
In this scheme, the QoS Controller 42 behaves like a normal application to the AAA stack 43. The QoS setting and tunnelling setting are transparent to the AAA stack 43. Therefore, although the QoS controller 42 uses the AAA framework for the setup, it requires no modification to the
standard AAA stack 43. That means this makes the invention highly deployable in any standard network.
When the user session goes on, the QoS controller 42 would generate QoS statistics that reflects the service experience observed at the terminal 41. The QoS controller 42 would use the tunnel setup above to report this information to the SLA manager 48 (513: QoS Report) . FIG. 9 is a diagram showing the format of the reporting message (QoS report) for reporting QoS data froin the terminal to the SLA manager in the embodiment of the invention. Each said reporting message starts with a message_ID field 91 followed by the message length field 92 and then followed by the payload. The payload consists of attribute value pair information 93. The attributes can consist of QoS parameters or information attributes.
Examples of QoS Parameters are QoS class, bytes send, bytes received, bytes dropped, packets dropped, average bandwidth, maximum bandwidth, dropping interval, average delay, jitter, utilization and send dropping threshold. The QoS parameters can be expanded and not limited to those listed above. Fixed length attribute value pair is employed in this example, therefore only one message length field 92 is needed for the entire message. If variable length attribute value pair is employed, each pair needs an additional length field to indicate the length of the attribute value pair.
After receiving the report from the QoS controller 42, the SLA manager 4 8 would carry out some QoS management process, and decide whether any adjustment needs to be done at the terminal 41. It would also update the SLA in the SLA database 49 if necessary. If any change at the terminal 41 is necessary, the SLA manager 48 would send a QoS enforcement message to the QoS controller 42 through the QoS control tunnel setup 512 (514: QoS Enforcement Control) . FIG. 10 is a diagram showing the format of the message for QoS enforcement from the SLA manager to the terminal in the embodiment of the invention. The QoS enforcement message comprises a message_ID field 101, a message length field 102, an Action_ID field 103 and QoS parameters field 104 . The QoS enforcement message has its own set of pre-defined message templates. Similar to the said reporting message format, the QoS parameters 104 can be zero, one or many QoS data fields. An example for the Action_ID field 103 and its corresponding actions are those similar m FIG. 12.
Once the tunnel is setup in the QoS control tunnel setup 512, it is transparent to the SLA manager 48 and the QoS controller 42. These two nodes would communicate with each other like in the same subnet. The address of the SLA manager 48 and corresponding port number could be sent to the QoS controller 42 during the "QoS Control" service setup time (at the QoS control setup 511) . The address of the terminal
41 is assigned by the SLA manager 48 during the service authorization phase 506, and therefore is always available.
For end-to-end communication for the QoS control, the SLA manager 48 needs only to write to the terminal 41' s address and pre-defined port number, e.g. IP address "x x x x" at port "s s", whereas the QoS controller 42 of the terminal 41 needs to write to SLA Manager 48's address and the port number obtained in the service authorization phase 506, e.g. IP address "y y y y" at port "pp". Intermediate route is handled within the tunnelling channel. It is obvious to anyone skilled in the art that the invention could be applied to any addressing scheme instead of using an absolute address.
The tunnelling channel only needs to be setup once per terminal 41, usually at the first time it is requested for a service in the visited network 44, i.e. there is only one instance of the pseudo "QoS control" service per terminal 41. The teardown of the channel could be decided by the SLA manager 48. For example, when the terminal 41 is no longer associated with that visited network 44 or no more service session exists, the SLA manager 48 could signal the AAA server 47 to delete the settings on control nodes, e.g. GGSN.
The SLA manager 48 could also send unsolicited QoS enforcement message 514 to the QoS controller 42. The overall system works on the reporting and enforcing/updating
concept. Both the policy attendant 14 and the QoS controller 11A need to perform reporting to the SLA manager 15 in FIG. 1. The QoS controller 11A will report on the state observed at the terminal 11, and the policy attendant 14, on the other hand, will report the state and conditions of the network to the SLA manager 15. The reporting can be performed periodically or when triggered. When SLA manager 15 determined the needs to make any adjustment based on the reports from either the Policy Attendant 14 or the QoS Controller 11A, it would issue the QoS enforcement message. It is obvious to anyone skilled in the art that the SLA manager 15 could also use the policy control framework to adjust the network at the same time if necessary, which is not shown in the figures.
The two signalling explained earlier are the signalling mechanism needed to setup a path to pass QoS data from terminal 11 to home network 16 and vice versa in order to achieve end-to-end QoS control.
Once the terminal 11 receives the QoS enforcement command from the SLA manager 15, the terminal 11's QoS controller 11A will react to this enforcement command by changing current state to match that of the enforcement command. FIG. 6 is a diagram showing an example QoS monitoring at the QoS controller in the embodiment of the invention. It is modelled using the High Level Message
Sequence (non-patent document 13). When the terminal 11's QoS controller 11A starts, it will be configured with some preset initial values or those obtained from the initial configuration state (601: Set Initial configuration). These values include threshold values for the different QoS metrics used for performance of data monitoring. When the terminal 11's QoS controller 11A starts, it will start performance, and perform usage data collection and monitoring. It also performs reporting, that is to feedback the data collected earlier, pack it into a known format and then send it to a central server for consolidation (602: Monitoring performance data & reporting) . In this case, the central server shall be, for example, the SLA manager 15. During performance monitoring, it compares the performance data to its threshold values and if violation occurs (603: Threshold violation occur), it will perform the necessary correction to handle this violation (604: Handle violation) . The correction action taken here involves delaying of transmission packet, dropping the packet entirely and/or packet rescheduling if transmission bandwidth exceeds the threshold values, or self-terminating the session entirely. Therefore, transmission bandwidth can be controlled in this manner. For receiving packets, the receiving bandwidth can be controlled by minimizing the request for incoming packets and also bandwidth request for any incoming packets can be
reduced. When network condition changes, the policy server (the central server) will inform the SLA manager 15 of these changes. SLA manager 15 will then make a decision on the policy change. This involves updating the rule engine at the policy server and/or updating the configuration of the affected terminals lis' QoS controller to manage QoS in the new updated threshold values . The updating of configuration to affected terminals 11 involves passing of enforcement data to the said affected terminals 11. The said affected terminals 11 upon receiving this enforcement data (605: Receive enforcement) will perform the necessary updates or changes based on this enforcement data (606: Perform action required). The monitoring process will resume based on the new updated values.
FIG. 7 is a diagram modelling SLA manager monitoring session in the embodiment of the invention. When the performance monitoring session starts, the SLA manager 15 will load the necessary SLA information and the current rules for monitoring from the SLA database 18 (701: Load Rules). The SLA manager 15 receives reports on the status of the terminals 11 and the policy servers periodically (702: Monitoring network and terminal). The reports can also be received in a non-periodic manner, e.g. pushed to the SLA Manager 15 or upon request by the SLA Manager 15. The status will be compared to the SLA information. If an alarm or
violation is detected (703: Detect violation), the SLA manager 15 will decide the action to be taken depending on the nature of the violation and the states of both the network and the terminal 11 (704: Handle congestion and enforce new rules) . The SLA manager 15 will enforce new rules or decide on the enforcement data, pack it to a known format before it performs the enforcing mechanism by updating the policy server with new rules, or request the terminal 11 to change its configuration.
FIG. 11 is a diagram showing the architecture for the QoS controller at the terminal in the embodiment of the invention. This QoS controller 1101 comprises the following sub-components. Monitoring module 1103 comprises a metering module 1102 for collecting performance monitor data and also performing check for any threshold violation. Enforcement module 1107 comprises the classifier 1104, marker 1105 and shaper/dropper 1106 for traffic regulation. Communication module 1110 comprises the usage information and traffic profile 1108, to store all collection of performance monitoring data from the metering module 1102 and also a reporting module 1109 to communicate with SLA manager 1111. This communication module 1110 also initiates enforcement module to perform correction when enforcement data is received.
Before a data packet 1112 is sent out from the terminal,
it needs to be classified by classifier 1104 according to its priorities . Each application has a pre-defined priority After classification, it will be sent to the marker 1105 to be marked as "injprofile" or "out_profile". The metering module 1102 will check against the usage information and traffic profile 1108, and inform the marker 1105 on the current state of terminal. The marker 1105 then marks the packets as "in_proflie" or "out_proflie" depending on the current state.
After this marking process, the shaper/dropper 1106 decides whether to delay the sending of packet or to drop the entire packet. The shaper/dropper 1106 also checks the current terminal via Metering module 1102 whether to delay transmission or to drop packets. Packets marked as "out_proflie" have higher probability of dropping compared to "in_profile" packets. The outgoing data packet 1113 is the packet that is actually sent out. The reporting module 1109 will periodically performs reporting back to SLA manager 1111 and SLA manager 1111 also sends QoS Enforcement message back to the terminal via this reporting module 1109. The enforcement message will be enforced -onto relevant enforcement module 1107 if any enforcement actions are required.
FIG. 8 is a diagram showing an example of how QoS controller performs QoS monitoring and traffic regulation
in che embodiment of the invention. When congestion occurs, the SLA manager 1111 will pass QoS enforcement data to the QoS controller 1101 at the terminal for behavioural change. In this example, data packets 1112 are classified by the classifier 1104 into 4 different priority levels A, B, C and D with A being the highest priority and D the lowest priority. Transmission bandwidth allocated to the terminal is used as the determinant for performing correction. A combination of other parameters can also be used as the determining factor for performing correction.
For a scenario when QoS controller 1101 receives enforcement data telling it to lower its bandwidth, QoS controller 1101 will set the existing value to the new value received (801: Receive enforcement data and set new guaranteed value) . For the case of congestion, SLA manager 1111 decides to reduce the allocated transmission bandwidth to low priority terminal. The SLA manager 1111 passes the enforcement data with the necessary information to the affected terminal. When the terminal receives this enforcement data, it' 11 compare the enforcement data against its existing value before performing the updates. For the "total allocated bandwidth" measurement data, if the new value is less than the existing, correction will be performed.
In this example, packets of type A classification will
be given the highest priority. If the total bandwidth is insufficient to support the required bandwidth for the type A application (802: Class A bandwidth > new guaranteed value) , then the session will be terminated if there's an ongoing session (803: Terminate Class A session). Else, packets of type A will be given all the bandwidth it requires (804: Allocate full bandwidth for class A packets). After all allocation to packets of type A, then the remaining bandwidth will be allocated the types B, C and D, for example in the ratio of 7:2:1 respectively (805: Allocate 70% of remaining bandwidth for Class B, 806: Allocate 20% of remaining bandwidth for Class C and 10% of remaining bandwidth for Class C) . For packets of type B, C and D classification, bandwidth correction is performed by transmission rate control, packets dropping and delaying the packets transmission. Packets from the different classes are queued according to their allocated bandwidth and class. Based on this number, the threshold values for each type are computed (807: Reset threshold with respect to new allocated bandwidth) . Packets will also be marked as "in profile" or "out profile" depending on whether the threshold is reached. If bandwidth usage exceeds the threshold, e.g. for type B, which can be a video encoder application, the QoS controller may interface with the video encoder and instruct it to encode at a lower bit rate.
Alternatively, if there's no interface to the said application and the QoS controller can not interface with the video encoder, then QoS controller may decide to selectively drop packets in order to meet the threshold values. Incoming packets will be selective marked as "out profile" and those marked packets with "out profile" will be dropped first. For types C and D, packets of type C are queued to the transmission more often than type D. Packets of type D will be queued last based on the ratio allocated to those. The above ratio is used as illustration only. The allocation of bandwidth to the different classes can be of any ratio and classification types can be any number and not limited to types A, B, C and D. Also, the QoS controller can employ other means of scheduling and queuing mechanism such as the RED (non-patent document 14) and RIO (non-patent document 15) algorithm for queuing and not limited to the example above.
INDUSTRIAL APPLICABILITY
This invention allows the QoS management to be handled at the terminal which is the end entity enjoying the service. This will allow the source to manage the resource more efficiently and avoid causing unnecessarily congesting the network. For the case of network which does not have QoS control, the terminal would still be able to have a certain
degree of QoS guarantee when the terminal which is attached to the network has the individual QoS control, and does not clog up the network by controlling the amount of packets to be sent and the amount of request to be made. This also frees up the responsibility of the network to perform this tasks.
We Claim:
1. A terminal having a QoS control module that is capable of
monitoring whether or not measured QoS statistics exceed
threshold values, reporting the QoS statistics to a central
controller, and performing QoS control based on the QoS
enforcement data received from the central controller, the QoS
control module comprising:
a monitor module for collecting QoS information from each of terminal's running applications;
a communication module for reporting the collected QoS information to the central controller, and receiving enforcement instructions from the central controller; and
a enforcement module for regulating a behavior of the terminal according to metrics received through the communication module.
2. The terminal as claimed in claim 1, wherein the QoS control module of the terminal further comprises a local database for storing the collected QoS information.
3. The terminal as claimed in claim 2, wherein the monitor module comprises:
means for capturing the QoS information and storing the QoS information at the local database in the terminal; means for monitoring threshold violation; and means for initiating the enforcement module to perform traffic regulation when the violation is detected.
4. The terminal as claimed in claim 1, further comprising:
means for packing the QoS information in a known format
before sending the QoS information to the central controller;
means for parsing QoS enforcement information received from the central controller;
means for updating terminal state based on the QoS enforcement information received from the central controller; and
means for initiating the enforcement module to perform a relevant correction in the enforcement information received from the central controller if necessary.
5. The terminal as claimed in claim 1, wherein the enforcement module further comprises means for performing traffic regulation at the terminal in order to regulate terminal performance.
6. The terminal as claimed in claim 1, wherein the enforcement module comprises at least any one of the following means:
means for classifying packets into different priorities within the terminal;
means for managing dropping of packets within the terminal when resource quota allocated to the terminal is used up;
means for reducing congestion at the terminal by lowering a transmission rate;
means for reducing congestion at the terminal by delaying transmission of packets when insufficient resource is allocated to the terminal;
means for terminating sessions and stopping transmission of packets;
means for reducing outgoing traffic by limiting total number of outgoing sessions;
means for reducing incoming traffic by limiting total number of incoming sessions; and
means for reducing incoming traffic by requesting for less incoming traffic.
Documents
Application Documents
| # | Name | Date |
|---|---|---|
| 1 | 2524-delnp-2009-abstract.pdf | 2011-08-21 |
| 1 | 2524-delnp-2009-pct-373.pdf | 2011-08-21 |
| 2 | 2524-delnp-2009-pct-304.pdf | 2011-08-21 |
| 2 | 2524-delnp-2009-claims.pdf | 2011-08-21 |
| 3 | 2524-delnp-2009-pct-237.pdf | 2011-08-21 |
| 3 | 2524-delnp-2009-correspondence-others.pdf | 2011-08-21 |
| 4 | 2524-delnp-2009-description (complete).pdf | 2011-08-21 |
| 4 | 2524-delnp-2009-pct-210.pdf | 2011-08-21 |
| 5 | 2524-delnp-2009-form-5.pdf | 2011-08-21 |
| 5 | 2524-delnp-2009-drawings.pdf | 2011-08-21 |
| 6 | 2524-delnp-2009-form-3.pdf | 2011-08-21 |
| 6 | 2524-delnp-2009-form-1.pdf | 2011-08-21 |
| 7 | 2524-delnp-2009-form-2.pdf | 2011-08-21 |
| 8 | 2524-delnp-2009-form-3.pdf | 2011-08-21 |
| 8 | 2524-delnp-2009-form-1.pdf | 2011-08-21 |
| 9 | 2524-delnp-2009-form-5.pdf | 2011-08-21 |
| 9 | 2524-delnp-2009-drawings.pdf | 2011-08-21 |
| 10 | 2524-delnp-2009-description (complete).pdf | 2011-08-21 |
| 10 | 2524-delnp-2009-pct-210.pdf | 2011-08-21 |
| 11 | 2524-delnp-2009-correspondence-others.pdf | 2011-08-21 |
| 11 | 2524-delnp-2009-pct-237.pdf | 2011-08-21 |
| 12 | 2524-delnp-2009-pct-304.pdf | 2011-08-21 |
| 12 | 2524-delnp-2009-claims.pdf | 2011-08-21 |
| 13 | 2524-delnp-2009-pct-373.pdf | 2011-08-21 |
| 13 | 2524-delnp-2009-abstract.pdf | 2011-08-21 |