WO2010094320A1

WO2010094320A1 - Methods and apparatuses for adjusting the medium access latency on radio links

Info

Publication number: WO2010094320A1
Application number: PCT/EP2009/051849
Authority: WO
Inventors: Sandro Grech; Petri Antero Jolma; Roman Pichna
Original assignee: Nokia Siemens Networks Oy
Priority date: 2009-02-17
Filing date: 2009-02-17
Publication date: 2010-08-26

Abstract

There are provided measures for adjustment of medium access latency on radio links, said measures exemplarily comprising a detection of a traffic state (i.e. traffic activity or inactivity) on a connection between an access device of a wireless access system and a terminal device, and the adjustment of a medium access latency state of the connection in accordance with the traffic state detected. The latency adjustment may comprise at least one of the switching between scheduling services having high or low medium access latencies and the adaptation of a polling interval of a polling-based medium access scheduling service for use on the connection.

Description

Title of the invention

METHODS AND APPARATUSES FOR ADJUSTING THE MEDIUM ACCESS LATENCY ON RADIO LINKS

Field of the invention

The present invention generally relates to an adjustment of medium access latency on radio links.

Background of the invention

In the development of radio communication systems, such as mobile communication systems (like for example GSM (Global System for Mobile Communication) , GPRS (General Packet Radio Service) , UMTS (Universal Mobile Telecommunication System) or the like) , efforts are made for an evolution of the radio access part thereof. In this regard, the evolution of radio access networks (like for example the GSM EDGE radio access network (GERAN) and the Universal Terrestrial Radio Access Network (UTRAN) or the like) is currently addressed in research and development as well as in standardization. In this regard, an example for an applicable broadband access system may be IEEE 802.16 also known as WiMAX (Worldwide Interoperability for Microwave Access) . In the context of mobile communication systems, it is spoken about mobile WiMAX. The air interface of mobile WiMAX is standardized by IEEE 802.16e.

It is to be noted that the following specification specifically refers to WiMAX as a non-limiting example for a wireless access system standard being applicable. However, any other wireless access system may be applied equally well, as long as the features described below hold for such another wireless access system.

In recent implementations of WiMAX, TCP (Transmission Control Protocol) traffic can be handled as best effort (BE) traffic. That is, a terminal willing to send TCP traffic has to request bandwidth using contention-based bandwidth requests each time it has a traffic packet to send. That means that each time there is a traffic packet to send, bandwidth request latency is added to the packet transmission latency. Accordingly, best effort scheduling results in the addition of latency for each UL (uplink) packet and poor TCP performance in the DL (downlink) because UL TCP ACK (Uplink TCP Acknowledgement) packets experience additional latency. This is illustrated by Figure 1.

Figure 1 shows a schematic procedure for the transmission of best effort traffic packets.

In Figure 1, it is assumed as an example that a file transfer download by the File Transfer Protocol (FTP) over TCP is to be accomplished between terminal device MS (mobile station) and access device BS (base station) .

When a UL TCP ACK packet for the FTP download arrives at the service access point at the mobile station, the mobile station sends a CDMA (Code Division Multiple Access) code to the base station, with which a contention-based bandwidth request (BR) procedure starts (step 1) . Then, in step 2, the base station allocates a unicast BR transmission opportunity and signals it to the mobile station in UL-MAP (uplink map) using a CDMA allocation information element (IE) . In step 3, the mobile station transmits a BR header to the base station, and the base station responds thereto by allocating resources for the uplink user plane and signaling it to the mobile station in the UL-MAP (step 4) . Finally, in step 5, the mobile station transmits the packet, i.e. the UL TCP ACK packet, to the base station.

As is illustrated on the right hand side of Figure 1, each of the above steps adds additional uplink medium access latencies, which totally amount to a round trip time (RTT) of (at least) 40 ms for a setup of a layer 2 (L2) connection between mobile station and base station. This latency is added for each UL packet, while a TCP ACK transmission is used as an example only.

It is to be noted that step 1 involves a CDMA contention- based transmission with a certain probability of success. The success or failure rate depends on the level of contention depending on two factors, namely the amount of resources dedicated to the contention ranging opportunities configured in the base station, and the load of the network. Thus, the latency contribution of step 1 can be dramatically increased, if the network is loaded more than the contention resources were dimensioned for (i.e. in any heavily loaded network) . In such a case, the message sent in step 1 will be lost, resulting into timeout and retransmission latencies. This congestion resolution process can be repeated many times for each packet, resulting in rapidly increasing packet transport latencies in the case of network load.

In an error and interference-free case, as mentioned above, the best effort scheduling (e.g. for TCP traffic) adds about 40 ms of latency (or round trip time) to each UL packet in the uplink. Such a latency (or round trip time) has impacts on the throughput of TCP-based (e.g. FTP) transports. Namely, the round trip time (RTT) limits the TCP throughput, if the TCP window size (W) configured in the IP stack causes the ratio W/RTT ratio to be lower than the link would otherwise allow. The default value of W in a typical PC (operated with a Windows operating system) is 64512 Bytes. Accordingly, when assuming a round trip time of 150ms (e.g. for an error and interference-burdened case), this results in a data rate of ~3.4 Mbps (which is much less than possible with WiMAX) .

Therefore, in recent implementations of WiMAX systems in combination with wireless/cellular access systems, problems regarding traffic performance and throughput have emerged.

Namely, it has been found that there is a major discrepancy between traffic throughput achieved for UDP (User Datagram Protocol) and TCP (Transmission Control Protocol) transports. The throughput using TCP-based transports (which is required for certain services such as file transfer, e.g. by FTP (File Transfer Protocol), email, world wide web, and the like) has been found to be up to 60% lower than in UDP-based transports.

Such a discrepancy has not been observed in other networks such as for example DSL (Digital Subscriber Line) having high data rate links and low latencies, and cellular access networks having low data rate links with high latencies. In neither case the other network has not reached the TCP window limit configured in the IP stack in the testing devices. Thus, there is obviously a specific problem regarding traffic performance and throughput in system arrangements in which the high data rates offered e.g. by WiMAX (or another broadband wireless access system) are combined with wireless/cellular access network latencies, in particular but not exclusively for TCP throughput as compared with UDP throughput.

Therefore, a solution is needed for improving traffic performance and throughput in such system arrangements including broadband wireless access systems such as for example WiMAX.

While there are several possible ways of improving TCP performance using existing mechanisms, none of these is efficient in terms of resource occupation.

Namely, a conceivable way could be not to use best effort (BE) service at all, but to initiate another service. For such an approach, a non-real-time polling service could be applied, which offers BE-like contention-based service together with periodic grants such as those achievable by an unsolicited grant service, that can be used for transmitting, e.g. TCP ACK packets. The frequency of grant allocations has to be high enough to have a positive effect on the latency budget. The cost of such approach is the need to frequently schedule transmission opportunities for every mobile station, even if there is no traffic for an extended period of time. Given that PCs or other Internet terminals send and receive very little (TCP) traffic all the time, very few terminals will ever go into idle mode, which means that the whole population of terminals in a sector will load its capacity with unused scheduled UL grants. Similar notions also apply for known real-time polling, extended real-time polling and unsolicited grant services. Thus, such an approach leads to a wasting of resources, again resulting in detriments in terms of performance and throughput.

Accordingly, there does not exist any feasible solution for improving traffic performance and throughput in such system arrangements e.g. including broadband wireless access systems such as for example WiMAX.

Summary of embodiments of the invention

The present invention and exemplary embodiments thereof are made to provide a feasible solution for improving traffic performance and throughput. For example, traffic performance and throughput may be improved in system arrangements e.g. including broadband wireless access systems such as for example WiMAX.

According to an exemplary first aspect of the present invention, there is provided a method comprising detecting a traffic state on a connection between an access device of a wireless access system and a terminal device, and adjusting a medium access latency state of the connection in accordance with the traffic state detected.

According to further developments or modifications thereof, one or more of the following applies:

- said adjusting a medium access latency state may comprise switching a medium access scheduling service for use on the connection between a scheduling service having a high medium access latency and a scheduling service having a low medium access latency,

- the method may comprise switching from a scheduling service having a high medium access latency to a scheduling service having a low medium access latency, when a traffic activity state is detected, and/or switching from a scheduling service having a low medium access latency and a scheduling service having a high medium access latency, when a traffic inactivity state is detected,

- the method may comprise selecting a scheduling service for use on the connection in accordance with at least one of terminal device capabilities and traffic packet size,

- said adjusting a medium access latency state may comprise adapting a polling interval of a polling-based medium access scheduling service for use on the connection, - the method may comprise shortening the polling interval, when a traffic activity state is detected, and/or extending the polling interval, when a traffic inactivity state is detected,

- the method may further comprise selecting a polling interval for use on the connection in accordance with at least one of terminal device capabilities and traffic packet size,

- a medium access scheduling service having a low medium access latency may comprise one of an unsolicited grants service, a real-time polling service, a non-realtime polling service, and an extended real-time polling service, and/or a medium access scheduling service having a high medium access latency may comprise a best-effort service, and/or a polling-based medium access scheduling service may comprise one of a real-time polling service, a non-real-time polling service, and an extended realtime polling service,

- said detecting a traffic state may comprise detecting an uplink traffic state from the terminal device towards the access device, and/or detecting a downlink traffic state from the access device towards the terminal device, and/or detecting an open transmission session concerning the connection between the access device and the terminal device, - said detecting a traffic state comprise determining activity of transmission control protocol traffic on the connection,

- said detecting a traffic state may comprise detecting a traffic activity state, when receiving traffic relating to the connection, and/or detecting a traffic inactivity state, when a predetermined inactivity period of an inactivity timer has expired,

- said connection between the access device and the terminal device may be based on an air interface in accordance with an IEEE 802.16 standard,

- said method may be executable at/by said access device or at/by said terminal device,

- the method may further comprise requesting, by the one of said access device and said terminal device executing said method, the other one of said access device and said terminal device to perform traffic handling on the basis of the adjusted medium access latency state of the connection, and/or

- said requesting may comprise transmitting a dynamic service change request indicating the adjusted medium access latency state.

According to an exemplary second aspect of the present invention, there is provided an apparatus comprising a detecting unit configured to detect a traffic state on a connection between an access device of a wireless access system and a terminal device, and an adjusting unit configured to adjust a medium access latency state of the connection in accordance with the traffic state detected by said detecting unit. According to further developments or modifications thereof, one or more of the following applies:

- said adjusting unit may comprise a service switching unit configured to switch a medium access scheduling service for use on the connection between a scheduling service having a high medium access latency and a scheduling service having a low medium access latency,

- said service switching unit may be configured to switch from a scheduling service having a high medium access latency to a scheduling service having a low medium access latency, when a traffic activity state is detected by said detecting unit, and/or switch from a scheduling service having a low medium access latency and a scheduling service having a high medium access latency, when a traffic inactivity state is detected by said detecting unit,

- said adjusting unit may comprise a service selecting unit configured to select a scheduling service for use on the connection in accordance with at least one of terminal device capabilities and traffic packet size,

- said adjusting unit may comprise an interval adapting unit configured to adapt a polling interval of a polling- based medium access scheduling service for use on the connection,

- said interval adapting unit may be configured to shorten the polling interval, when a traffic activity state is detected by said detecting unit, and/or extend the polling interval, when a traffic inactivity state is detected by said detecting unit,

- said adjusting unit may comprise an interval selecting unit configured to select a polling interval for use on the connection in accordance with at least one of terminal device capabilities and traffic packet size, - a medium access scheduling service having a low medium access latency may comprise one of an unsolicited grants service, a real-time polling service, a non-realtime polling service, and an extended real-time polling service, and/or a medium access scheduling service having a high medium access latency may comprise a best-effort service, and/or a polling-based medium access scheduling service may comprise one of a real-time polling service, a non-real-time polling service, and an extended real- time polling service,

- said detecting unit may be configured to detect an uplink traffic state from the terminal device towards the access device, and/or detect a downlink traffic state from the access device towards the terminal device, and/or detect an open transmission session concerning the connection between the access device and the terminal device,

- said detecting unit may be configured to determine activity of transmission control protocol traffic on the connection,

- said detecting unit may be configured to detect a traffic activity state, when traffic relating to the connection is received at said apparatus, and/or detect a traffic inactivity state, when a predetermined inactivity period of an inactivity timer at said apparatus has expired,

- said connection between said apparatus and the terminal device may be based on an air interface in accordance with an IEEE 802.16 standard, - said apparatus may be operable as/at said access device or as/at said terminal device,

- the apparatus may further comprise a requesting unit configured to request, by the one of said access device and said terminal device executing said method, the other one of said access device and said terminal device to perform traffic handling on the basis of the adjusted medium access latency state of the connection, and/or

- said requesting unit may comprise a transmitting unit configured to transmit a dynamic service change request indicating the adjusted medium access latency state.

According to an exemplary third aspect of the present invention, there is provided a computer program product comprising program code means being arranged, when run on a processor of an apparatus, to perform the method according to the first aspect or any one of its developments or modifications.

According to further developments or modifications thereof, said apparatus may be operable as/at an access device of a wireless access system or as/at a terminal device .

According to an exemplary fourth aspect of the present invention, there is provided a method comprising receiving a request to perform traffic handling on the basis of an adjusted medium access latency state of a connection between an access device of a wireless access system and a terminal device, and performing traffic handling on the connection on the basis of the adjusted medium access latency state.

According to further developments or modifications thereof, one or more of the following applies: - said receiving a request may comprise receiving a dynamic service change request indicating the adjusted medium access latency state,

- the adjusted medium access latency state may comprise at least one of a switched and/or selected medium access scheduling service and/or an adapted and/or selected polling interval of a polling-based medium access scheduling service,

- a medium access scheduling service may comprise one of an unsolicited grants service, a real-time polling service, a non-real-time polling service, an extended real-time polling service, and a best-effort service, and/or a polling-based medium access scheduling service may comprise one of a real-time polling service, a non- real-time polling service, and an extended real-time polling service,

- said connection between the access device and the terminal device may be based on an air interface in accordance with an IEEE 802.16 standard, and/or

- said method may be executable at/by said access device or at/by said terminal device.

According to an exemplary fifth aspect of the present invention, there is provided an apparatus comprising a receiving unit configured to receive a request to perform traffic handling on the basis of an adjusted medium access latency state of a connection between an access device of a wireless access system and said apparatus, and a traffic handling unit configured to perform traffic handling on the connection on the basis of the adjusted medium access latency state.

- said receiving unit may be configured to receive a dynamic service change request indicating the adjusted medium access latency state,

- said connection between the access device and said apparatus may be based on an air interface in accordance with an IEEE 802.16 standard, and/or

- said apparatus may be operable as/at said terminal device or as/at said access device.

According to an exemplary sixth aspect of the present invention, there is provided a computer program product comprising program code means being arranged, when run on a processor of an apparatus, to perform the method according to the fourth aspect or any one of its developments or modifications.

According to further developments or modifications thereof, said apparatus is operable as/at a terminal device or as/at an access device of a wireless access system.

By way of exemplary embodiments of the present invention, there are provided mechanisms for an activity-based adjustment of medium access latency on radio links. Stated in other words, exemplary embodiments of the present invention may provide mechanisms for emulating a wireless/cellular packet data-like bearer setup for best effort packets, for example using existing signaling mechanisms in WiMAX/IEEE802.16e . In brief, exemplary embodiments of the present invention may be capable of removing medium access latencies due to best effort scheduling even for best effort services (such as e.g. TCP) .

According to exemplary embodiments of the present invention, referring to the above numerical example, the round trip time of a traffic packet may e.g. be improved by 40 ms . Thus, a resulting round trip time may be 110 ms, which may lead to a data rate of -4.7 Mbps (which is a significant increase of about 40%) .

Stated in other terms, by way of exemplary embodiments of the present invention, throughput and performance of any traffic, e.g. transmission control protocol (TCP) traffic may be enhanced. To this end, there may be provided measures to reduce the round trip time (RTT) experienced by the traffic, e.g. a TCP flow, such that e.g. faster TCP acknowledgments may be achieved and bandwidth may be saved.

Brief description of the drawings

In the following, the present invention will be described in greater detail by way of non-limiting examples with reference to the accompanying drawings, in which

Figure 1 shows a schematic procedure for the transmission of best effort traffic packets,

Figure 2 shows a flowchart of a generic method according to exemplary embodiments of the present invention, Figure 3 shows a flowchart of a first example of a method according to exemplary embodiments of the present invention,

Figure 4 shows a flowchart of a second example of a method according to exemplary embodiments of the present invention,

Figure 5 shows a flowchart of another generic method according to exemplary embodiments of the present invention,

Figure 6 shows a schematic procedure for the transmission of best effort traffic packets according to exemplary embodiments of the present invention, when traffic detection and the like is executed at an access device side,

Figure 7 shows a schematic procedure for the transmission of best effort traffic packets according to exemplary embodiments of the present invention, when traffic detection and the like is executed at a terminal device side,

Figure 8 shows a block diagram of an apparatus according to exemplary embodiments of the present invention, and

Figure 9 shows a block diagram of another apparatus according to exemplary embodiments of the present invention.

Detailed description of embodiments of the present invention The present invention is described herein with reference to particular non-limiting examples. A person skilled in the art will appreciate that the invention is not limited to these examples, and may be more broadly applied.

In particular, the present invention and exemplary embodiments thereof are mainly described in relation to IEEE specifications being used as non-limiting examples for certain exemplary network configurations. In particular, a WiMAX radio access network according to IEEE 802.16e is used as a non-limiting example in this regard. As such, the description of exemplary embodiments given herein specifically refers to terminology which is directly related thereto. Such terminology is only used in the context of the presented non-limiting examples, and does naturally not limit the invention in any way. Rather, any other network configuration or radio access implementation may also be utilized as long as compliant with the features described herein.

In the following, various exemplary embodiments and implementations of the present invention and its aspects or embodiments are described using several alternatives. It is generally to be noted that, according to certain needs and constraints, all of the described alternatives may be provided alone or in any conceivable combination (also including combinations of individual features of the various alternatives) .

In most generic terms, a method according to exemplary embodiments of the present invention may comprise detecting a traffic state on a connection between said access device and a terminal device, and adjusting a medium access latency state of the connection in accordance with the traffic state detected. Such a method may be equally executed by/at an access device of a wireless access system, such as for example a WiMAX base station, and by/at a terminal device, such as for example a WiMAX-capable mobile station.

Figure 2 shows a flowchart of a generic method according to exemplary embodiments of the present invention.

For the sake of simplicity, the subsequent description assumes that this method may be performed at/by an access device, while it may be equally performed at/by a terminal device as well. It is generally assumed that the access device performing this method has a radio link with a terminal device. This radio/air interface may support one or more connections. Therefore, the below description of activity-based latency adjustment may be performed for each connection on the radio/air interface, thus leading the several instances of activity detection and latency state adjustment in case of several connections being present over the radio/air interface. While any single connection on the radio/air interface may support one or more traffic flows, e.g. according to current WiMAX standards, in the following it may be assumed that one connection carries one traffic flow. When one connection carries more than one flow, the below description of activity-based latency adjustment may be performed e.g. either per flow or per connection.

In operation S2-1, the access device may detect a traffic state, i.e. an activity/inactivity state, on the connection to the terminal device. In operation S2-2, the access device may adjust the medium access latency state of the connection in response to the thus detected traffic state. In particular, in response to the change of the traffic state from active to inactive or from inactive to active, the medium access latency of the connection may be adjusted accordingly. Thereafter, the procedure may return to the detection of a traffic state according to operation S2-1 for monitoring the connection for subsequent traffic state changes.

Basically, for adjusting the medium access latency state of the connection, a medium access scheduling service (which may also be referred to as MAC or MAC QoS (quality-of-service) scheduling service) may be switched between one having low medium access latency and one having high medium access latency, and/or a polling interval may be adapted, if a polling-based scheduling service is used on the connection.

As a first example for activity-based latency adjustment, when referring to TCP traffic as one example of best effort traffic, in response to the detection of traffic activity, the usually used best effort (BE) scheduling may for example be transitioned to one of the following services: an unsolicited grants service (UGS), a realtime polling service (rtPS) , a non-real-time polling service (nrtPS) , and an extended real-time polling service (ertPS) ; and vice versa.

The Unsolicited Grant Service (UGS) is a grant service, where the access device regularly gives to the terminal device fixed grants of uplink (UL) resources for the user-plane traffic. It is designed for real time traffic that regularly generates bursts of traffic.

In the Real-time Polling Service (rtPS) , the access device periodically grants unicast request opportunities to the terminal device. It is designed to support real time traffic of variable data packet size, such as MPEG (Moving Pictures Expert Group) video. A terminal device can use those to request resources needed for transmission of user plane packets in the uplink.

In the non-real time Polling Service (nrtPS) , the access device periodically grants unicast request opportunities to the terminal device like in rtPS, but in addition to that the terminal device is also allowed to use contention-based bandwidth requests. This service is basically a BE service combined with UGS.

In the Extended rtPS (ertPS) , the access device periodically grants UL resources to the terminal device for the user plane like in UGS, thus saving the latency of a bandwidth request. While UGS allocations are fixed, ertPS allocations are dynamic. It is designed to support bursty traffic like VoIP (Voice over Internet Protocol) with the active and "comforting noise" periods.

In the Best Effort (BE) service, as mentioned above, the terminal device has to request bandwidth using contention-based bandwidth requests each time it has a packet to send. That means that each time there is a packet to send, bandwidth request latency is added to the packet transmission latency.

In the context of scheduling service switching for medium access latency adjustment, the nrtPS scheduling may be considered to be optimum due to BE-like flexibility. The ertPS scheduling is similar to UGS scheduling with the flexibility to accommodate traffic bursts. The UGS scheduling is good for small packets, but not flexible to accommodate more traffic changes (e.g., occasional http (Hypertext Transfer Protocol) requests on top of resources needed for TCP ACKs) . Also, for UGS, there is a difficult trade-off between wasted resources and reduced latency. The rtPS scheduling has some benefit relative to BE latency, since unicast request opportunity grants are given to the access device, which should be of benefit in heavily loaded networks where many contention-based transmissions will fail and revert to chains of retransmissions .

In the scheduling service switching for medium access latency adjustment according to exemplary embodiments of the present invention, the selection of the scheduling service to be used may also depend from other parameters in addition the connection activity. That means that one of multiple appropriate scheduling services may be selected in view of such additional parameters. For example, it may depend from terminal device capabilities and/or traffic packet size. Regarding terminal capabilities, the access device may decide to activate one of those scheduling services that a particular terminal device of the connection in question supports. The most suitable alternative may be nrtPS (when supported by the terminal device in question) . Regarding traffic packet size, small packets, e.g. TCP ACK packets, may be transmitted very quickly using UGS-like allocations. If larger bursts have to be transmitted, either a contention-based request may be used in nrtPS or grant is increased using ertPS mechanisms.

As a second example for activity-based latency adjustment (which may also be combined with the above first example) , when referring to TCP traffic as one example of best effort traffic, the polling interval of a polling- based scheduling service may be shortened in response to the detection of traffic activity, or it may be extended in response to the detection of traffic inactivity. Namely, the activity detection may be used as a trigger to dynamically adapt the uplink polling intervals. During activity periods, the access device may allocate frequent UL polling opportunities (e.g. in every subframe) . During inactivity periods, the access device may withdraw UL polling opportunities in such a way that the terminal device may use contention-based bandwidth requests for the first UL transmission, which may then again trigger the access device to adapt to more frequent UL polling opportunities .

Similar as in the first example, in the scheduling service switching for medium access latency adjustment according to exemplary embodiments of the present invention, the adaptation of the polling interval to be used may also depend from other parameters in addition the connection activity. That means that one of multiple appropriate polling intervals may be selected in view of such additional parameters. For example, it may depend from terminal device capabilities and/or traffic packet size .

The traffic activity may be detected both on the uplink and/or on the downlink. Since traffic for TCP flows on the downlink usually correlates with and thus implies traffic on the uplink (e.g. a TCP acknowledgment) to be sent soon thereafter, the access device detecting downlink traffic activity may adjust the medium access latency state of the connection in a proactive manner. The detection of traffic activity may for example be based on the reception of traffic concerning the connection on question, and/or on recognition of a open transmission session for the relevant connection. The detection of traffic inactivity may for example be based on an inactivity timer. Such an inactivity timer may be started/set with a predetermined inactivity period (e.g. 5 seconds) by the access device, when an activity has been detected. When the inactivity timer expires, i.e. when there has been no traffic activity on the connection for the predetermined inactivity period, the access device may adjust the medium access latency accordingly, i.e. in a state of higher medium access latency.

Figure 3 shows a flowchart of a first example of a method according to exemplary embodiments of the present invention. In the exemplary method depicted in Figure 3, the activity-based latency adjustment may be based on the switching/transition of scheduling services. In accordance with Figure 2 above, the subsequent description assumes that this method may be performed at/by an access device, while it may be equally performed at/by a terminal device as well.

In traffic state detection of operation S3-1, when assuming that the connection in question has been inactive at the beginning, there may be firstly detected an activity state (operation S3-11), e.g. by receiving an UL or DL message concerning the connection between the access device and a correspond terminal device. In response thereto, in latency adjustment of operation S3- 2, a scheduling service may be switched from one having high latency (e.g. BE) to one having low latency (e.g. nrtPS) in operation S3-21. Optionally, the scheduling service to be switched to may be selected from multiple appropriate scheduling services (e.g. ertPS and nrtPS) using additional parameters such as e.g. packet size and/or terminal capabilities (operation S3-22) . Thereupon, the terminal device (i.e. the other side of the connection) may be requested to perform (uplink) data handling according to the thus adjusted latency state, i.e. the thus switched scheduling service (operation S3- 3), e.g. by transmitting a (dynamic) service change request message with corresponding contents. Also, although not depicted, the access device may initiate some measure for detecting inactivity of the connection, e.g. by starting an inactivity timer with a predetermined inactivity period. Then, an inactivity state may be detected (operation S3-12) in traffic state detection of operation S3-1 using the thus initiated measure. Upon detection of connection inactivity in operation S3-12, e.g. by timer timeout, in latency adjustment of operation S3-2, a scheduling service may be switched from one having low latency (e.g. nrtPS) which has been switched to beforehand to one having high latency (e.g. BE) in operation S3-23. Optionally, the scheduling service to be switched to may be selected from multiple appropriate scheduling services using additional parameters such as e.g. packet size and/or terminal capabilities (operation S3-24) . Thereupon, the terminal device may be requested to perform (uplink) data handling according to the thus adjusted latency state, i.e. the thus switched scheduling service (operation S3-3) , e.g. by transmitting a service change request message with corresponding contents. Also, the access device may return to the traffic state detection of operation S3-1 for monitoring connection traffic activity for the future.

Figure 4 shows a flowchart of a second example of a method according to exemplary embodiments of the present invention. In the exemplary method depicted in Figure 4, the activity-based latency adjustment may be based on the adapting of polling intervals of polling-based scheduling services. In accordance with Figure 2 above, the subsequent description assumes that this method may be performed at/by an access device, while it may be equally performed at/by a terminal device as well.

In Figure 4, like operations are denoted by like reference signs as in Figure 3. Since the method of Figure 4 is similar to that of Figure 3, a detailed description thereof is omitted here, and reference is made to the description of Figure 3. The differences of the method of Figure 4 as compared with that of Figure 3 are in the latency adjustment of operation S4-2.

Namely, upon activity detection in operation S4-11, a polling interval may be adapted to a shorter polling interval (operation S4-21), while an appropriate polling interval may be selected using additional parameters

(operation S4-22) . Upon inactivity detection in operation S4-12, a polling interval may be adapted to a longer polling interval (operation S4-23) , while an appropriate polling interval may be selected using additional parameters (operation S4-24) .

With respect to the exemplary methods depicted in Figures 3 and 4, it is to be noted that these may be combined such that the activity-based latency adjustment may be based on both the switching/transition of scheduling services and the adapting of polling intervals of polling-based scheduling services. To this end, the operation of medium access latency adjustment may comprise both operations S3-21 and S4-21 as well as both operations S3-23 and S4-23 as well as both operations S3- 22/24 and S4-22/24, or any conceivable combination thereof .

In most generic terms, another method according to exemplary embodiments of the present invention may comprise receiving a request to perform traffic handling on the basis of an adjusted medium access latency state of a connection between an access device of a wireless access system and said terminal device, and performing traffic handling on the connection on the basis of the adjusted medium access latency state. Such a method may be equally executed by/at a terminal device, such as for example a WiMAX-capable mobile station, and by/at an access device of a wireless access system, such as for example a WiMAX base station, depending on which one of these devices executes medium access adjustment (at the other side of the connection in question) .

Figure 5 shows a flowchart of another generic method according to exemplary embodiments of the present invention .

For the sake of simplicity, the subsequent description assumes that this method may be performed at/by a terminal device, while it may be equally performed at/by an access device as well. It may generally be assumed that the terminal device performing this method has a radio link with an access device. This radio/air interface may support one or more connections. Therefore, the below description of traffic handling according to an activity-based latency adjustment may be performed for each connection on the radio/air interface. While any single connection on the radio/air interface may support one or more traffic flows, e.g. according to current WiMAX standards, in the following it may be assumed that one connection carries one traffic flow. When one connection carries more than one flow, the below description of traffic handling according to an activity- based latency adjustment may be performed e.g. either per flow or per connection. In operation S5-1, the terminal device may receive a request with an adjusted medium access latency state of the connection, i.e. a switched scheduling service and/or an adapted polling interval in case of a polling-based scheduling service), e.g. by receiving a (dynamic) service change request message with corresponding contents. In response thereto, in operation S5-1, the terminal device may adapt its (uplink) traffic handling for the relevant connection accordingly. This procedure may be repeated upon any request from the access device.

Basically, a terminal device according to exemplary embodiments of the present invention may be adapted to follow (i.e. to act corresponding to) medium access latency state adjustments by the access device of the respective connection.

While exemplary operations of an access device and a terminal device according to exemplary embodiments of the present invention have been described basically apart from each other above, in the following an exemplary cooperation of an access device and a terminal device according to exemplary embodiments of the present invention is described.

Figure 6 shows a schematic procedure for the transmission of best effort traffic packets according to exemplary embodiments of the present invention, when traffic detection is executed at an access device side. The same assumption regarding radio interface, connections and flows, as outlined above in connection with Figures 3 and 4, may be made here as well. In Figure 6, a mobile station MS (e.g. also referred to as subscriber station SS) may represent a terminal device, and a base station BS may represent an access device.

In step 1, the mobile station (MS) is in active (non- idle) mode. A best effort (BE) radio link (i.e., MAC (medium access control) flow) may have been set up for uplink (UL) and downlink (DL) , which may be inactive but ready for transmission. In step 2, the mobile station (MS) may generate a packet ready for transmission in the uplink (UL) . This packet may for example be a TCP packet or a TCP-based FTP packet. In step 3, the BE service used may mandate a contention-based bandwidth request (BR) procedure which starts with a BR CDMA code transmission in the UL. In step 4, the base station may allocate unicast BR transmission opportunity and may signal it to the mobile station in UL-MAP (uplink map) using a CDMA allocation information element (IE) . In step 5, the mobile station may transmit a BR header to the base station. In step 6, the base station may allocate resources for the uplink user plane and may signal it to the mobile station in the UL-MAP. In step 7, the mobile station may transmit the packet to be sent to the base station. This packet may be considered as actual traffic on the connection (link) in question. After reception of the packet, i.e. activity detection, the base station may initiate the latency adjustment (e.g. scheduling service change and/or polling interval adaptation) for the flow from a higher medium access latency state to a lower medium access latency state. The thus adjusted latency state may be signaled to the mobile station using a DSC procedure in steps 8 to 10. Namely, in step 8, a DSC-REQ request message with corresponding contents may be transmitted from the base station to the mobile station, wherein in the present non-limiting example a scheduling service change (from BE) to ertPS or nrtPS may be requested. In step 9, the mobile station may reply with a DSC-RSP response message, and in step 10, the base station may acknowledge the completion of latency adjustment with a DSC-ACK acknowledgment message to the mobile station.

In step 11, UL traffic may be flowing with reduced medium access latency, improving the packet transmission latency budget and the resulting TCP performance (for both uplink and downlink, uploading or downloading) . When no traffic may be detected, an inactivity timer may be started e.g. with 5 seconds (step 12), and inactivity may be detected when the inactivity timer expires (step 13) .

Then, upon inactivity detection, e.g. after the expiry of the inactivity timer in the previous step, the base station may initiate a reverse latency adjustment, i.e. switching to a scheduling service and/or adapting a polling interval with a higher latency state, which may be better suited for inactivity periods, e.g. BE. This may again be accomplished using a DSC procedure with corresponding contents. Thus, steps 14 to 16 may be similar to steps 8 to 10 above. In step 14, in the present non-limiting example, a scheduling service change (from the previously adjusted service) to BE may be requested.

Finally, in step 17, the connection (link) may be inactive, and no periodic user-plane resources may be allocated to the mobile station, which may increase the radio resource efficiency of the whole system.

Although it may be assumed in the above description that the packet reception at the base station in step 7 may result in a traffic activity detection for the MS-BS connection, this is only an illustrative example. Such an example may be based on the (non-limiting) assumption that a kind of bearer may be set up (by way of the first packet) , and the subsequent packets may use the thus set up bearer, such that only the first packet may experience some setup latency, but the subsequent packets may not experience any BE-like latencies. However, such an exemplary assumption may not be mandatory. Rather, a traffic activity detection according to exemplary embodiments of the present invention may for example equally result from the reception of a BR transmission at the base station in step 3. Then, the respective adjustment using the DSC procedure already may start by including the respective DSC messages in the earlier frames starting with step 4.

It is to be noted that the latency adjustment according to exemplary embodiments of the present invention may also be initiated for example in step 8 or step 4, when DL activity may be detected (instead of UL activity) , or when BS traffic lookup may indicate an open active TCP (Transmission Control Protocol) or SCTP (Stream Control Transmission Protocol) session.

Figure 7 shows a schematic procedure for the transmission of best effort traffic packets according to exemplary embodiments of the present invention, when traffic detection is executed at a terminal device side. The procedure of Figure 7 is similar to the procedure of Figure 6, with the exception that the roles of the access device and the terminal device are exchanged such that according to the procedure of Figure 7 the terminal device MS (instead of the access device) performs traffic detection and associated operations, and otherwise the access device BS (instead of the terminal device) follows the instructions from the terminal device. Thus, for details reference is made to the description of Figure 6 above .

Namely, in step 8, upon receipt of a packet in step 7, traffic activity may be detected and a medium access latency state of the connection may be adjusted by the mobile station in accordance with any one Figures 2 to 4. A DSC request is sent from the MS to the BS, a DSC response is sent from the BS to the MS, and a DSC acknowledgement is sent from the MS to the BS (steps 8 to 10) . In steps 12 and 13, traffic inactivity may be detected (e.g. by way of a timer at the MS) and a medium access latency state of the connection may be adjusted by the mobile station in accordance with any one Figures 2 to 4. A message exchange between the MS and the BS in steps 14 to 16 corresponds to that of steps 8 to 10 above . Accordingly, the procedures of Figures 6 and 7 basically differ in the location of the respective functionalities and the direction of respective message transfers.

Although in the foregoing exemplary embodiments of the present invention have been described mainly with reference to exemplary methods, procedures and functions, corresponding exemplary embodiments of the present invention also cover respective exemplary apparatuses, network nodes, including both software and/or hardware thereof .

Respective exemplary embodiments of the present invention are described below referring to Figures 8 and 9, while for the sake of brevity reference is made to the detailed description of respective corresponding exemplary methods and operations according to Figures 2 to 7, respectively. In Figures 8 and 9 below, the solid line blocks are basically configured to perform the basic operations. The entirety of solid line blocks may basically be configured to perform the exemplary methods and operations as described above, respectively. With respect to Figures 8 and 9, it is to be noted that the individual blocks are meant to illustrate respective functional blocks implementing a respective function, process or procedure, respectively. Such functional blocks are implementation- independent, i.e. may be implemented by means of any kind of hardware or software, respectively. The lines interconnecting individual blocks are meant to illustrate an operational coupling there-between, which on the one hand is implementation-independent (e.g. wired or wireless) and on the other hand may also comprise an arbitrary number of intermediary functional entities not shown .

Further, in Figures 8 and 9, only those functional blocks are illustrated, which may relate to any one of the above-described exemplary methods, procedures and functions. A skilled person may acknowledge the presence of any other conventional functional blocks required for an operation of respective structural arrangements, such as e.g. a power supply, a central processing unit, respective memories or the like.

Figure 8 shows a block diagram of an apparatus according to exemplary embodiments of the present invention. The thus depicted apparatus may for example be an access device of a wireless access system, such as for example WiMAX base station, as depicted in Figure 6 above. Yet, it may equally be a terminal device, such as a WiMAX- capable mobile station, as depicted in Figures 7 above. For the sake of simplicity, without limiting the present invention thereto, the subsequent description exemplarily assumes that the thus depicted apparatus may be operable at/as an access device.

The thus depicted apparatus of an access device may be assumed to be connected to a terminal device such as e.g. a WiMAX mobile station by way of an air/radio interface.

According to the exemplary embodiment depicted in Figure 8, the thus depicted apparatus of an access device may comprise a traffic detector, a latency state adjuster, and a requester. According to an exemplary implementation as depicted in Figure 8, the traffic detector may comprise an activity state detector, which may comprise a receiver and/or session detector, and an inactivity state detector, which may comprise an inactivity timer. Also, the latency state adjuster may comprise at least one of a scheduling service switcher, scheduling service selector, a polling interval adapter, and a polling interval selector .

Stated in general terms, the traffic state detector may represent means for detecting a traffic state on a connection between said apparatus and a terminal device, and the latency state adjuster may represent means for adjusting a medium access latency state of the connection in accordance with the traffic state detected.

According to the depicted implementation, the activity state detector may represent means for detecting a traffic activity state, when traffic relating to the connection is (expected to be) present. This may include detecting an uplink traffic state and/or detecting a downlink traffic state and/or detecting an open transmission session for the connection. This is illustrated by the block denoted "receiver/session detector". According to the depicted implementation, the inactivity state detector may represent means for detecting a traffic inactivity state, when no traffic relating to the connection is (expected to be) present. This may include setting/starting an inactivity timer with a predetermined inactivity period (e.g. 5 seconds), and determining when the predetermined inactivity period of the inactivity timer has expired. This is illustrated by the block denoted "inactivity timer".

According to the depicted implementation, the scheduling service switcher may represent means for switching a medium access scheduling service for use on the connection between a scheduling service having a high medium access latency (e.g. BE) and a scheduling service having a low medium access latency (e.g. UGS, rtPS, nrtPS, ertPS) . It may be configured to perform the switching as set out in connection with operation S3-21 and S3-23 of Figure 3 above. The scheduling service selector may represent for selecting a scheduling service out of appropriate scheduling services in accordance with at least one of terminal device capabilities and traffic packet size.

According to the depicted implementation, the polling interval adapter may represent means for adapting a polling interval of a polling-based medium access scheduling service for use on the connection. It may be configured to perform the adapting as set out in connection with operation S4-21 and S4-23 of Figure 4 above. The polling interval selector may represent means for selecting a polling interval out of appropriate polling intervals in accordance with at least one of terminal device capabilities and traffic packet size

According to the depicted implementation, the requester may represent means for requesting the terminal device to perform traffic handling on the basis of the adjusted medium access latency state of the connection, i.e. the switched scheduling service and/or the adapted polling interval. The requester may thus comprise a transmitter (sender) representing means for transmitting a (dynamic) service change request, such as a DSC-REQ message, indicating the adjusted medium access latency state.

Figure 9 shows a block diagram of another apparatus according to exemplary embodiments of the present invention. The thus depicted apparatus may for example be a terminal device, such as for example a WiMAX subscriber or mobile station, as depicted in Figure 6 above. Yet, it may equally be an access device, such as a WiMAX base station, as depicted in Figures 7 above.

For the sake of simplicity, without limiting the present invention thereto, the subsequent description exemplarily assumes that the thus depicted apparatus may be operable at/as a terminal device

The thus depicted apparatus of a terminal device may be assumed to be connected to an access device such as e.g. a WiMAX base station by way of an air/radio interface.

According to the exemplary embodiment depicted in Figure 9, the thus depicted apparatus of a terminal device may comprise a data handling request receiver and a data handler . Stated in general terms, the data handling request receiver may represent means for receiving, from a base station or an access device of a wireless access system, a request to perform traffic handling on the basis of an adjusted medium access latency state of a connection between the base station or access device and said apparatus. It may be configured to receive a (dynamic) service change request, such as a DSC-REQ message, indicating the adjusted medium access latency state. The adjusted medium access latency state may be a switched scheduling service and/or an adapted polling interval, as set out above. The data handler may represent means for performing (uplink) traffic handling on the connection on the basis of the adjusted medium access latency state.

Any one of the above-outlined exemplary apparatuses may represent an autonomous entity according to respective exemplary embodiments of the present invention, while their interworking entirety or any conceivable combination thereof may represent a system according to respective exemplary embodiments of the present invention. Such a system may for example be a (mobile) WiMAX system, the air/radio interface of which being in compliance with the IEEE 802.16e standard.

In general, it is to be noted that respective functional blocks or elements according to above-described exemplary aspects may be implemented by any known means, either in hardware and/or software, respectively, if it is only adapted to perform the described functions of the respective parts. The mentioned method steps may be realized in individual functional blocks or by individual devices, or one or more of the method steps may be realized in a single functional block or by a single device. Generally, any method step may be suitable to be implemented as software or by hardware without changing the idea of the present invention. Devices and means may be implemented as individual devices, but this does not exclude that they may be implemented in a distributed fashion throughout the system, as long as the functionality of the device is preserved. Such and similar principles may be considered as known to those skilled in the art.

Software in the sense of the present description may comprise software code as such comprising code means for performing the respective functions, as well as software (or a computer program or a computer program product) embodied on a tangible medium such as a computer-readable storage medium having stored thereon a respective data structure or code portions or embodied in a signal or in a chip, potentially during processing thereof.

Generally, for the purpose of the present invention as described herein above, it should be noted that - an access technology may be any technology by means of which a user equipment or terminal device can access an access network (e.g. via a base station or generally an access device) . Any present or future technology, such as WLAN (Wireless Local Access Network) , WiMAX (Worldwide Interoperability for Microwave Access) , BlueTooth, Infrared, and the like may be applicable; access technologies may be distinguishable in at least two categories or access domains such as packet switched and circuit switched, but the existence of more than two access domains does not impede the invention being applied thereto, - an access network may be any device, apparatus, unit or means by which a station, entity or other user equipment may connect to and/or utilize services offered by the access network; such services include, among others, data and/or (audio-) visual communication, data download etc.;

- a user equipment or terminal device may be any device, apparatus, unit or means by which a system user may experience services from an access network such as a mobile phone, personal digital assistant PDA, or computer;

- method steps and functions likely to be implemented as software code portions and being run using a processor at one of the entities, a network element, or a terminal (as examples of devices, apparatuses and/or modules thereof, or as examples of entities including apparatuses and/or modules thereof) , are software code independent and can be specified using any known or future developed programming language, such as e.g. Java, C++, C, and Assembler, as long as the functionality defined by the method steps is preserved;

- generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the invention in terms of the functionality implemented; - method steps, functions, and/or devices, apparatuses, units or means likely to be implemented as hardware components at a terminal or network element, or any module (s) thereof, are hardware independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as MOS (Metal Oxide Semiconductor) , CMOS (Complementary MOS) , BiMOS (Bipolar MOS), BiCMOS (Bipolar CMOS), ECL (Emitter Coupled Logic), TTL (Transistor-Transistor Logic), etc., using for example ASIC (Application Specific IC (Integrated Circuit)) components, FPGA (Field- programmable Gate Arrays) components, CPLD (Complex Programmable Logic Device) components or DSP (Digital Signal Processor) components; in addition, any method steps and/or devices, units or means likely to be implemented as software components may for example be based on any security architecture capable e.g. of authentication, authorization, keying and/or traffic protection; - devices, apparatuses, units or means can be implemented as individual devices, apparatuses, units or means, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device, apparatus, unit or means is preserved, - an apparatus may be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such chip or chipset; this, however, does not exclude the possibility that a functionality of an apparatus or module, instead of being hardware implemented, be implemented as software in a (software) module such as a computer program or a computer program product comprising executable software code portions for execution/being run on a processor; - a device may be regarded as an apparatus or as an assembly of more than one apparatus, whether functionally in cooperation with each other or functionally independently of each other but in a same device housing, for example.

The present invention also covers any conceivable combination of method steps and operations described above, and any conceivable combination of nodes, apparatuses, modules or elements described above, as long as the above-described concepts of methodology and structural arrangement are applicable. There are provided measures for adjustment of medium access latency on radio links, said measures exemplarily comprising a detection of a traffic state (i.e. traffic activity or inactivity) on a connection between an access device of a wireless access system and a terminal device, and the adjustment of a medium access latency state of the connection in accordance with the traffic state detected. The latency adjustment may comprise at least one of the switching between scheduling services having high or low medium access latencies and the adaptation of a polling interval of a polling-based medium access scheduling service for use on the connection.

Even though the invention is described above with reference to the examples according to the accompanying drawings, it is to be understood that the invention is not restricted thereto. Rather, it is apparent to those skilled in the art that the present invention can be modified in many ways without departing from the scope of the inventive idea as disclosed herein.

Claims

1. A method comprising detecting a traffic state on a connection between an access device of a wireless access system and a terminal device, and adjusting a medium access latency state of the connection in accordance with the traffic state detected.

2. The method according to claim 1, said adjusting a medium access latency state comprising switching a medium access scheduling service for use on the connection between a scheduling service having a high medium access latency and a scheduling service having a low medium access latency.

3. The method according to claim 2, comprising switching from a scheduling service having a high medium access latency to a scheduling service having a low medium access latency, when a traffic activity state is detected, and/or switching from a scheduling service having a low medium access latency and a scheduling service having a high medium access latency, when a traffic inactivity state is detected.

4. The method according to claim 2 or 3, comprising selecting a scheduling service for use on the connection in accordance with at least one of terminal device capabilities and traffic packet size.

5. The method according to any one of claims 1 to 4, said adjusting a medium access latency state comprising adapting a polling interval of a polling-based medium access scheduling service for use on the connection .

6. The method according to claim 5, comprising shortening the polling interval, when a traffic activity state is detected, and/or extending the polling interval, when a traffic inactivity state is detected.

7. The method according to claim 5 or 6, comprising selecting a polling interval for use on the connection in accordance with at least one of terminal device capabilities and traffic packet size.

8. The method according to any one of claims 2 to 7, wherein a medium access scheduling service having a low medium access latency v one of an unsolicited grants service, a real-time polling service, a non-real-time polling service, and an extended real-time polling service, wherein a medium access scheduling service having a high medium access latency comprises a best-effort service, and wherein a polling-based medium access scheduling service comprises one of a real-time polling service, a non-real-time polling service, and an extended real-time polling service.

9. The method according to any one of claims 1 to 8, said detecting a traffic state comprising detecting an uplink traffic state from the terminal device towards the access device, and/or detecting a downlink traffic state from the access device towards the terminal device, and/or detecting an open transmission session concerning the connection between the access device and the terminal device .

10. The method according to any one of claims 1 to 9, said detecting a traffic state comprising determining activity of transmission control protocol traffic on the connection.

11. The method according to any one of claims 1 to 10, said detecting a traffic state comprising detecting a traffic activity state, when receiving traffic relating to the connection, and/or detecting a traffic inactivity state, when a predetermined inactivity period of an inactivity timer has expired.

12. The method according to any one of claims 1 to 11, said connection between the access device and the terminal device being based on an air interface in accordance with an IEEE 802.16 standard.

13. The method according to any one of claims 1 to 12, said method being executed at/by said access device or at/by said terminal device.

14. The method according to any one of claims 1 to 13, further comprising requesting, by the one of said access device and said terminal device executing said method, the other one of said access device and said terminal device to perform traffic handling on the basis of the adjusted medium access latency state of the connection.

15. The method according to claim 14, said requesting comprising transmitting a dynamic service change request indicating the adjusted medium access latency state.

16. An apparatus comprising a detecting unit configured to detect a traffic state on a connection between an access device of a wireless access system and a terminal device, and an adjusting unit configured to adjust a medium access latency state of the connection in accordance with the traffic state detected by said detecting unit.

17. The apparatus according to claim 16, said adjusting unit comprising a service switching unit configured to switch a medium access scheduling service for use on the connection between a scheduling service having a high medium access latency and a scheduling service having a low medium access latency.

18. The apparatus according to claim 17, said service switching unit being configured to switch from a scheduling service having a high medium access latency to a scheduling service having a low medium access latency, when a traffic activity state is detected by said detecting unit, and/or switch from a scheduling service having a low medium access latency and a scheduling service having a high medium access latency, when a traffic inactivity state is detected by said detecting unit.

19. The apparatus according to claim 17 or 18, said adjusting unit comprising a service selecting unit configured to select a scheduling service for use on the connection in accordance with at least one of terminal device capabilities and traffic packet size.

20. The apparatus according to any one of claims 16 to 19, said adjusting unit comprising an interval adapting unit configured to adapt a polling interval of a polling-based medium access scheduling service for use on the connection.

21. The apparatus according to claim 20, said interval adapting unit being configured to shorten the polling interval, when a traffic activity state is detected by said detecting unit, and/or extend the polling interval, when a traffic inactivity state is detected by said detecting unit.

22. The apparatus according to claim 20 or 21, said adjusting unit comprising an interval selecting unit configured to select a polling interval for use on the connection in accordance with at least one of terminal device capabilities and traffic packet size.

23. The apparatus according to any one of claims 17 to 22, wherein a medium access scheduling service having a low medium access latency comprises one of an unsolicited grants service, a real-time polling service, a non-realtime polling service, and an extended real-time polling service, wherein a medium access scheduling service having a high medium access latency comprises a best-effort service, and wherein a polling-based medium access scheduling service comprises one of a real-time polling service, a non-real-time polling service, and an extended real-time polling service.

24. The apparatus according to any one of claims 16 to

23, said detecting unit being configured to detect an uplink traffic state from the terminal device towards the access device, and/or detect a downlink traffic state from the access device towards the terminal device, and/or detect an open transmission session concerning the connection between the access device and the terminal device .

25. The apparatus according to any one of claims 16 to

24, said detecting unit being configured to determine activity of transmission control protocol traffic on the connection.

26. The apparatus according to any one of claims 16 to

25, said detecting unit being configured to detect a traffic activity state, when traffic relating to the connection is received at said apparatus, and/or detect a traffic inactivity state, when a predetermined inactivity period of an inactivity timer at said apparatus has expired.

27. The apparatus according to any one of claims 16 to

26, said connection between said apparatus and the terminal device being based on an air interface in accordance with an IEEE 802.16 standard.

28. The apparatus according to any one of claims 16 to

27, said apparatus being operable as/at said access device or as/at said terminal device.

29. The apparatus according to any one of claims 16 to

28, further comprising a requesting unit configured to request, by the one of said access device and said terminal device executing said method, the other one of said access device and said terminal device to perform traffic handling on the basis of the adjusted medium access latency state of the connection .

30. The apparatus according to claim 29, said requesting unit comprising a transmitting unit configured to transmit a dynamic service change request indicating the adjusted medium access latency state.

31. A computer program product comprising program code means being arranged, when run on a processor of an apparatus, to perform the method according to any one of claims 1 to 15.

32. The computer program product according to claim 31, said apparatus being operable as/at an access device of a wireless access system or as/at a terminal device.

33. A method comprising receiving a request to perform traffic handling on the basis of an adjusted medium access latency state of a connection between an access device of a wireless access system and a terminal device, and performing traffic handling on the connection on the basis of the adjusted medium access latency state. - A l -

34. The method according to claim 33, said receiving a request comprising receiving a dynamic service change request indicating the adjusted medium access latency state.

35. The method according to claim 33 or 34, the adjusted medium access latency state comprising at least one of a switched and/or selected medium access scheduling service and/or an adapted and/or selected polling interval of a polling-based medium access scheduling service.

36. The method according to claim 35, wherein a medium access scheduling service comprises one of an unsolicited grants service, a real-time polling service, a non-real-time polling service, an extended real-time polling service, and a best-effort service, and wherein a polling-based medium access scheduling service comprises one of a real-time polling service, a non-real-time polling service, and an extended real-time polling service.

37. The method according to any one of claims 33 to 36, said connection between the access device and the terminal device being based on an air interface in accordance with an IEEE 802.16 standard.

38. The method according to any one of claims 33 to 37, said method being executed at/by said access device or at/by said terminal device.

39. An apparatus comprising a receiving unit configured to receive a request to perform traffic handling on the basis of an adjusted medium access latency state of a connection between an access device of a wireless access system and said apparatus, and a traffic handling unit configured to perform traffic handling on the connection on the basis of the adjusted medium access latency state.

40. The apparatus according to claim 39, said receiving unit being configured to receive a dynamic service change request indicating the adjusted medium access latency state.

41. The apparatus according to claim 39 or 40, the adjusted medium access latency state comprising at least one of a switched and/or selected medium access scheduling service and/or an adapted and/or selected polling interval of a polling-based medium access scheduling service.

42. The apparatus according to claim 41, wherein a medium access scheduling service comprises one of an unsolicited grants service, a real-time polling service, a non-real-time polling service, an extended real-time polling service, and a best-effort service, and wherein a polling-based medium access scheduling service comprises one of a real-time polling service, a non-real-time polling service, and an extended real-time polling service.

43. The apparatus according to any one of claims 39 to 42, said connection between the access device and said apparatus being based on an air interface in accordance with an IEEE 802.16 standard.

44. The apparatus according to any one of claims 39 to 43, said apparatus being operable as/at said terminal device or as/at said access device.

45. A computer program product comprising program code means being arranged, when run on a processor of an apparatus, to perform the method according to any one of claims 33 to 38.

46. The computer program product according to claim 45, said apparatus being operable as/at a terminal device or as/at an access device of a wireless access system.