HK1151909B - A method and a user equipment for reserving bandwidth - Google Patents

Description

Method and user equipment for reserving bandwidth

Technical Field

The present invention relates generally to a method of bandwidth reservation associated with channel switching for user equipment participating in an IPTV session, and user equipment for performing the method.

Background

With the transition of Television (TV) from one-way distribution services to providing two-way interactive services for end users, and from being limited to distribution only to stationary locations to services that can be distributed virtually anywhere and can be viewed on various types and sizes of screens, we will witness the birth of a whole new mass market for TV programming, advertising, interactive games and different types of interactive services.

As for the attraction of new customers to their respective networks, Internet Protocol Television (IPTV) offers new revenue opportunities for telecommunication service providers to offset the declining voice traffic revenue. Work on IPTV is ongoing in a number of different environments, including for example the ongoing development of open IPTV forums, which specify end-to-end platforms for providing multimedia and IPTV services over the internet to end users with IPTV enabled User Equipment (UE), and the development of managed networks with controlled quality of service (QoS) capabilities. A release 1.1 specification of a functional IPTV architecture is available at www.openiptvforum.org, where the architecture described is based on the IP Multimedia Subsystem (IMS) specified by the third generation partnership project (3 GPP). The UE can access services provided over IMS in many different ways: via wired access, such as via ethernet, cable modem, or digital subscriber line; or wireless access, such as via a cellular radio specified by 3GPP or by using IEEE 802.11 or IEEE 802.16 standards.

IMS is specified in 3GPP Technical Specification (TS)23.228 v8.4.0, IP Multimedia Subsystem (IMS) Stage 2(Release 8), March 2008 and previous versions of TS 23.228. In addition, a different approach to IMS-based IPTV is in the M.Cedervall et al, "Open IPTV Forum-aware an Open IPTV Standard",Ericsson Reviewno.3, pp.74-78(2007) and T.Cagenius et al, "Evalving the TVexperience: anytime, Anywhere, anydevice ",Ericsson Reviewno.3, pp.107-111 (2006).

For a UE (which may be a set-top box (STB) or an entity integrating STB capabilities, such as a computer, TV, PDA, mobile phone or any other IPTV capable mobile device accessing IPTV services via IMS), the UE registers into a serving call session control function (S-CSCF), which is an IMS core node essentially operating as a SIP server. A typical IMS also includes a number of additional nodes, including a proxy CSCF (P-CSCF), a Media Gateway Control Function (MGCF), and one or more Border Gateways (BGs), which mediate UE access to and through the core nodes to media content residing on one or more media servers.

In conventional IMS-based IPTV networks, session modification may be performed, which may include bandwidth reservation for sessions already established from user equipment in order to ensure that the required services are provided to the end users. In this context, a session may be: a unicast session, such as a video-on-demand session transmitted via a unicast stream; or a broadcast session, to the listening end-users via a multicast stream.

The bandwidth reservation procedure ensures that there are enough network resources in the last mile of the network infrastructure or in the converged network so that the IPTV operator can guarantee a sufficient user experience with a minimal risk of interruption of the selected service.

If, for example, two sessions taken together exceed the amount of bandwidth available to the IP operator over the last mile, packets associated with the two sessions will compete for available network resources, and therefore packets of the two flows will most likely be dropped, resulting in a degradation of the quality of at least one session. Once bandwidth is reserved for one or more sessions, it is important not to allow new sessions to have a negative impact on existing sessions.

Fig. 1 is a signaling scheme according to the prior art illustrating how a typical IPTV service setup may be performed between a UE100 and an IPTV network 102 for providing one or more IPTV services to the UE100 via an IMS network, represented by a core network 101 in the figure.

It should be understood that although both the IPTV network 102 and the IMS network represented by the IMS core network 101 typically comprise a plurality of network nodes, each of these networks has been represented by a respective node in fig. 1 for the sake of simplicity.

In two initial steps 1:1 and 1:2, the UE100 registers with the IMS core network 101, which IMS core network 101 typically responds with a 200OK message. In the following steps 1:3-1:6, the UE100 requests IPTV services to be provided from the IPTV network 102 via SIP subscription. Once the procedure is completed by the UE100 receiving a 200OK message from the IMS core 101, as shown in step 1:6, the UE100 has been provided with IPTV service data, typically referred to as IPTV service discovery data, comprising a channel list indicating all channels that can be provided by the respective IPTV service providers of the IPTV network 102. A typical IPTV service discovery signaling procedure is illustrated as steps 1:7-1:10 in fig. 1. Once provided with information about available frequency channels, the UE100 may select to pick the desired service. In the present example, this is illustrated as an HTTP GET message sent from the UE100 to the IPTV network 102 via the IMS core network 101 in step 1: 11.

In a subsequent step 1:12, the IPTV network 102 responds by providing the UE100 with a list, typically referred to as a linear TV channel list, which comprises, among other IPTV channel-related information, bandwidth requirement information associated with the IPTV channels available from the IPTV network 102. This information is provided to the UE100 as TISPAN service packets, which are typically referred to as broadcast provisioning (broadcast provisioning) of broadcast service records.

The broadcast offering typically comprises a plurality of elements or attributes, each of which carries different types of information relating to the available IPTV channels. For each channel, the broadcast offering may include the following information: for example, a DVB triplet, implements IPTV channel identification at the UE; a text identifier representing a corresponding IPTV channel name; a service location as an indication of where to find the corresponding channel; and a maximum bit rate as an indication of a maximum bit rate required for the corresponding service.

In a next step 1:13, information provided from the broadcast provision is stored in a memory of the UE 100. At this stage, the end user of the UE100 may make a selection to choose a preferred IPTV channel from the channels available in the broadcast offering, typically by activating a remote control or via another user interface associated with the UE 100. In step 1:14, the end user makes this selection and, in response to the channel selection, the UE100 initiates a bandwidth reservation procedure to reserve the appropriate bandwidth for the selected channel. In the figure, this is illustrated as an invitation, typically referred to as a SIP invitation, which is forwarded to the IMS core network 101 as shown in a further step 1: 15.

If the required bandwidth is not available, or if the required bandwidth cannot be allocated to the UE100 for any other reason, the UE100 is informed about this, as shown in step 1:16 a. In this case, the end user may choose to make another retry on the same channel, or attempt to pick another channel.

However, if the bandwidth request is granted by the IMS network, the bandwidth is reserved to the UE100, as shown in another step 1:16 b. The bandwidth reservation procedure is then completed by informing the IPTV network 102 of the allocated bandwidth and acknowledging the information through the IPTV network 102, as shown in steps 1:17 and subsequent steps 1:18, and the acknowledgement is also performed to the UE100, as shown in steps 1:19 and subsequent steps 1: 20.

The requested IPTV service can now be initiated with the required bandwidth reserved to the UE 100. In this example, this is done by the UE100 sending an IGMP Join to the IPTV network 102, as shown in step 1.21. As shown, the IPTV network 102 responds to such a service request by transmitting the selected IPTV channel to the UE100 via a multicast stream, as shown in the final step 1: 22.

The overall problem with bandwidth reservation is: how to get the appropriate information about how much bandwidth is actually needed for negotiating the selected broadcast session. As described above, the broadcast channel information, typically transmitted in the broadcast offering, necessary for establishing an IPTV session available from an IPTV operator may include an indication of the maximum bit rate of the respective IPTV channel. The purpose of this information is to ensure that sufficient bandwidth will be available from the IMS core network 101 once resources have been allocated and an IPTV channel has been selected.

However, the problem of basing the bandwidth renegotiation process on the maximum bitrate attribute according to the above procedure is that: the required signaling will result in processing delays that may impair the user experience of the user switching between different channels. Session modifications, which may include bandwidth re-negotiations, must be made before the end user can view the selected channel, and thus, through such bandwidth re-negotiations, the end user will experience a delay before the channel can actually be viewed.

This problem is particularly annoying when the end user switches between different channels that have been assigned different maximum bit rates before deciding to view one of the available channels more persistently. The repeated delays can be very annoying to the end user, while at the same time, from the operator's point of view, almost nothing can be obtained by initiating the bandwidth re-negotiation immediately in response to the channel switch initiated by the end user.

Furthermore, the currently known solutions for performing bandwidth re-negotiations also fail to give any control over the use of available bandwidth to the IPTV operator.

Disclosure of Invention

The object of the present invention is to provide a method for reducing the number of bandwidth renegotiations of user equipments participating in an IPTV session. More particularly, the present document relates to a mechanism that allows to postpone the decision whether to perform bandwidth reservation in association with a channel switch of a user equipment participating in an IPTV session in certain situations. By deferring such a decision for a channel switch from a channel with higher bandwidth requirements to a channel to which a switch is required, the number of bandwidth renegotiations actually performed may be reduced without negatively impacting user experience or network performance.

According to a first aspect, a method of managing bandwidth re-negotiation in association with a channel change at a user equipment participating in an IPTV session provided by an IPTV network is provided.

A conditional bandwidth renegotiation procedure associated with the requested channel switch is applied when it is determined that the requested channel requires less bandwidth than the currently selected channel. This conditional bandwidth renegotiation process includes performing a number of steps, starting with switching to the requested channel, and then starting a timer. The purpose of the timer is to delay the decision whether or not to perform a bandwidth re-negotiation. If a timeout is identified, a bandwidth re-negotiation is initiated and performed, typically according to conventional process steps.

If another channel switch request is identified before the timer times out, no bandwidth re-negotiation is performed for the previous channel switch, and therefore the pending timer is terminated before another evaluation procedure is initiated to determine whether a conditional bandwidth re-negotiation procedure is to be applied in response to the latest channel switch request as well.

According to the proposed method, the bandwidth requirements on which the conditional bandwidth renegotiation procedure depends are evaluated by: the value of the bit rate attribute associated with the requested channel and corresponding to the bandwidth required by the requested channel is compared with a value indicating the maximum bit rate currently available to the user equipment and corresponding to the bandwidth allocated to the current channel.

In an exemplary embodiment, the bit rate attribute is already provided to the user equipment from the IPTV network prior to the channel change. This can be achieved by forwarding the bit rate attribute, typically together with other bit rate attributes, in the broadcast offering. The bit rate attributes provided to the user equipment may be predefined on a per-channel basis or on a per-channel group basis. Such grouping may have been based on one or more different criteria if predefined on a per-channel group basis.

Furthermore, typically, timer values for the conditional bandwidth re-negotiation procedure may already be provided from the IPTV network to the user equipment. Such a timer value may be a value that has been specified to be valid for all channels provided from the IPTV network, or may be a channel specific timer value that has been predefined for a particular channel. Furthermore, the timer value may have been provided to the user equipment in a broadcast provision.

According to another aspect, the claimed invention also relates to a user equipment configured to perform the above method.

The proposed method provides a mechanism for limiting the number of bandwidth re-negotiations that is easy to implement in the user equipment.

The proposed method also enables the operator to, at least to a limited extent, enable how to allocate available resources during the upcoming bandwidth re-negotiation.

Further details and features of the proposed method and associated user equipment and advantages thereof will be explained in more detail in the detailed description.

Drawings

The invention will now be described in more detail by way of example embodiments and with reference to the accompanying drawings, in which:

fig. 1 is a signaling diagram illustrating how an IPTV session may be established between a user equipment and an IPTV network according to the prior art.

Fig. 2 is a flow chart illustrating a method of delaying a decision whether or not to perform a bandwidth re-negotiation procedure according to an example embodiment.

Figure 3 is a signalling diagram illustrating how the method described with reference to figure 2 may be applied by a user equipment according to a series of example scenarios.

Fig. 4a is a table illustrating information that may be the basis for performing the method described with reference to fig. 2 according to one embodiment.

Fig. 4b is another table illustrating information that may be the basis for performing the method described with reference to fig. 2 according to another embodiment.

FIG. 5 is a diagram illustrating how a configuration can perform referencing according to an example embodiment

Fig. 2 depicts a simplified block diagram of a user equipment of the method.

Detailed Description

As discussed above, a certain amount of bandwidth requirements needs to be defined for the available IPTV channels to enable the IMS core network to perform bandwidth reservation for UEs that need to establish an IPTV session with the IPTV network.

Today, the information available for this purpose is metadata that has been provided in a broadcast offering from the IPTV network to the UE before the respective session can be established and that gives an indication of what bitrate must be available for the respective session (i.e. the bitrate that must be guaranteed for the respective IPTV channel).

It should also be apparent from the above that: renegotiation of bandwidth on a per channel basis is a situation that should be avoided to the greatest extent from the end user's point of view, since channels can only be viewed after the bandwidth required for the selected channel has been granted to the respective UE.

Therefore, a method for limiting the number of renegotiations performed is needed. One way is to try to avoid performing bandwidth renegotiations, which may be considered unnecessary. Therefore, a bandwidth re-negotiation method is proposed that applies conditional re-negotiation, thereby reducing the number of delays introduced by the complete re-negotiation procedure.

What is also needed is: an IPTV operator providing IPTV services to end users in the form of IPTV channels via an IPTV network is able to, at least to some extent, have a greater impact on how the available resources, and more particularly the available bandwidth, are used for IPTV service distribution.

According to the proposed conditional bandwidth renegotiation method, the bandwidth is negotiated for a group of channels rather than for a single channel, so that when an end user jumps between different IPTV channels, the decision on whether it is actually necessary to perform a bandwidth renegotiation may be postponed in some cases. By deferring the decision, it may be determined that bandwidth renegotiation is unnecessary in some cases, and thus, the amount of delay caused by the performed bandwidth renegotiation procedure may be reduced.

In order to get better control over bandwidth re-negotiation according to the proposed method, a timer is introduced at the UE. Preferably, the timer value will be provided from the IPTV operator to the UE. To this end, a new element or attribute is introduced for representing one or more timer values, which will be referred to below as, for example, TimeToRenegotiation (TTR).

In this context, TTR is an attribute that is typically provided to the UE via broadcast provisioning prior to channel switching. The TTR can be used to delay the decision whether or not to perform a bandwidth re-negotiation procedure at the UE in response to a channel switch initiated by the end user of the UE, rather than unconditionally performing the bandwidth re-negotiation procedure.

The bandwidth re-negotiation procedure that is required due to the fact that the end user has switched the channel to a channel requiring less bandwidth than the currently viewed channel is not time critical, since the end user will also be provided with the required new channel by using the bandwidth already reserved for the UE without performing the re-negotiation.

Thus, in this case, the bandwidth re-negotiation decision may be delayed based on a specific timer value, e.g. specified by the TTR, without diminishing the user experience, allowing to defer the re-consideration of whether a re-negotiation procedure is actually necessary, depending on whether any subsequent additional, requested channel switching occurs before the timer value expires.

More specifically, the proposed method will be configured such that if a switch to another channel is selected before the timer times out, the timer will be reset and started again for the most recent switch if a corresponding situation also occurs for the most recent channel selection, i.e. if the most recently selected channel also requires less bandwidth than the first selected channel.

On the other hand, if the most recently selected channel requires more bandwidth than the currently viewed channel, a conventional bandwidth re-negotiation process is initiated and performed instantaneously.

Thus, by introducing such a conditional bandwidth renegotiation procedure, a renegotiation procedure involving a switch to a channel requiring a lower bandwidth is only performed if no subsequent channel switch is identified before the timer for the viewed channel times out.

As mentioned above, the timer value to be applied may be chosen by the IPTV operator as a suitable value and may be chosen from a range of values starting from a relatively low value (e.g. 5 seconds) up to a range of minutes (e.g. a timer value having a duration of 5 minutes).

How the timer value is selected may depend on one or more different criteria, such as user behavior, the number of available channels and/or the available bandwidth.

As an alternative to having the timer attribute as a single value valid for all channels provided by the IPTV operator, the timer attribute may instead be defined as a vector for which different timer values have been specified for different channels or groups of channels. If the timer attribute is different for different channels, the selection may be based on criteria such as how popular the respective channel is, the channel type, or the estimated user behavior of the respective channel.

The timer value may for example have a lower value specified for the more popular channel and a higher timer value is selected for the less popular channel to even further optimize the renegotiation process.

By introducing the proposed timer-based conditional bandwidth renegotiation mechanism, the number of bandwidth renegotiations can be reduced and the bandwidth renegotiation is actually started only in case it is determined that the end user has maintained the respective selected channel tuned for a certain duration (i.e. for the duration of the relevant timer value).

One way of implementing such a mechanism in a UE will now be described in more detail with reference to the flow chart of figure 2, according to an example embodiment.

It should be appreciated that the described flow chart only describes one possible way of determining when to start the bandwidth re-negotiation procedure (if any), and that mechanisms based on the above general principles may also be applied by other alternatives of implementation.

As a premise, assuming that the end user is tuned to an IPTV channel and has started a conditional bandwidth re-negotiation function at the UE, the UE may typically be any of the following, for example: a computer, PDA, set-top box or TV including set-top box functionality, or mobile phone, or any other type of mobile device configured to request and display one or more IPTV services/IPTV channels. The start of such a conditional function is indicated by a first step 200.

In a next step 201, it is determined whether the end user has requested a channel switch. Once the UE identifies the requested channel switch, it determines whether the bandwidth required for the selected channel is equal to the bandwidth required for the currently viewed channel, i.e., the bandwidth already allocated to the UE, and thus whether a switch to a new channel can be performed without any bandwidth renegotiation. This condition is evaluated in step 202 and if it is found that the required bandwidth remains unchanged, a channel switch is performed in the next step, as shown in the subsequent step 203. After performing a channel switch, the described cycle is repeated, starting at step 201, waiting for another channel switch to begin.

However, if the bandwidth requirements are different for different channels, another evaluation step starts, as shown in a next step 204. In the second evaluation step, it is determined whether the bandwidth required by the selected channel is less than the bandwidth required by the current channel. If not, i.e. additional bandwidth is needed in order to be able to provide the selected service/channel to the end user, an unconditional renegotiation procedure will be performed, typically according to conventional procedures, as shown in a next step 205, before the requested channel change is performed as shown in step 203, after which the loop is restarted again, starting with step 201.

If, however, it is instead determined that the currently allocated bandwidth is larger than the bandwidth required for the selected channel, the proposed method continues by performing the requested channel switch, as shown in step 206, and, in association with the channel switch, by starting a timer set to the duration of the predefined timer value specified for the selected channel or for the group of channels to which the respective channel belongs, as shown in subsequent step 207.

As long as the end user has not initiated a new channel switch, the timer will run as indicated by the loop comprising step 208 and the "no" branch (208b) continuing at subsequent step 210. As shown in the depicted loop, if a new channel switch occurs before the timer times out, i.e., according to the "yes" branch of step 210 (210a), a delayed bandwidth re-negotiation decision dependent on the currently running timer is now taken by considering that the previous channel switch no longer requires bandwidth re-negotiation, so that the next activity following such a decision will reset the pending timer associated with the previous channel switch, as shown in step 211, before beginning with the condition of considering the newly requested channel switch in step 202.

If instead a timer timeout occurs before the end user activates any new channel switch, as shown by the "yes" branch (208a) of step 208, the bandwidth renegotiation is set to start for the most recently requested channel switch, typically in accordance with a conventional bandwidth renegotiation procedure, as shown by another step 209.

According to one embodiment, the bandwidth requirement assessment process performed at steps 202 and 204 may be performed by: the correlation values of the maximum bitrate attribute, e.g. already provided to the UE by the broadcast offering, specified for the selected channel and the current channel, respectively, are compared.

An example scenario for describing how a UE may perform a conditional bandwidth re-negotiation procedure (e.g., the procedure described above with reference to fig. 2) will now be described with reference to the signaling diagram of fig. 3.

It will be appreciated that fig. 3 is a simplified schematic signalling diagram with emphasis on illustrating the differences between different zapping scenarios in which a conditional bandwidth re-negotiation procedure according to the principles described above is applied. In the figure, the different situations in which the proposed conditional bandwidth re-negotiation procedure is to be activated are indicated with a symbol labeled "S".

For simplicity, after initiating the conditional renegotiation process, only the steps important for a full understanding of the general principles of the proposed conditional bandwidth renegotiation process to be performed in response to different alternative scenarios are shown in the figures, while a complete process applicable to all described scenarios may be identified by following the flowchart of fig. 2 and the accompanying text above.

As a precondition, for the figure, it is also assumed that a UE 300 adapted to apply the conditional bandwidth renegotiation procedure is connected to the IPTV network 102 via the IMS network, represented by the IMS core network 101, and participates in an IPTV session, i.e. the IPTV channel is currently presented on the UE 300.

In a first step 3:1, the end user actively switches channels, typically by activating a remote control in a conventional manner, and thus initiates a conditional bandwidth renegotiation procedure. In this particular case, it is assumed that the requested channel requires more bandwidth than is allocated for the currently selected channel, and therefore, the bandwidth renegotiation decision is not delayed, but rather a bandwidth renegotiation is initiated, typically including the performance of steps 1:15-1:20 described above with reference to fig. 1. In fig. 3, these steps are represented by corresponding steps 3:2-3: 7.

Once the bandwidth re-negotiation process has been successfully completed, the selected program may be shown to the user via the respective IPTV channel, i.e. steps corresponding to steps 1:21 and 1:22 of fig. 1 will be performed. In this example, these steps are represented by step 3:8 in FIG. 3.

Once the user selects to pick another channel, a new conditional bandwidth re-negotiation procedure will be initiated, as shown in another step 3: 9. However, in this case, instead, it is assumed that the current bandwidth exceeds the bandwidth required by the selected channel, and therefore, a channel switch may be performed without having to decide whether any bandwidth re-negotiation procedure is to be performed on the fly. Accordingly, a channel switch is performed and the requested IPTV service is provided to the UE 300, as shown in a next step 3: 10. However, once a channel has been selected, a timer is started, thereby also starting the procedure for delaying the bandwidth re-negotiation decision, as shown in the next step 3: 11.

After some time has elapsed, it is assumed that the end user performs another channel switch that initiates another conditional bandwidth re-negotiation procedure, as shown in subsequent step 3:12, which corresponds to step 210 of fig. 2.

It is assumed that a new channel selection occurs before the timer triggered by the previous channel switch initiated by step 3:9 times out, and therefore it is determined that it is not necessary to perform a bandwidth re-negotiation of the channel selected in step 3: 9. Thus, the pending timer is terminated, as shown in step 3:13, before it is determined again whether a delayed bandwidth re-negotiation is to be performed or whether an immediate unconditional bandwidth re-negotiation is to be initiated instead.

Furthermore, it is assumed at this point that the current bandwidth exceeds the bandwidth required for the requested channel, and therefore the requested channel may be provided to the user, as shown in step 3:14, corresponding to step 206 of fig. 2, before starting another timer and starting another delayed bandwidth re-negotiation procedure, as shown in step 3:15 (corresponding to step 207 of fig. 2).

The latest scenario may represent the following events: the user is switching between different channels to direct himself to available programs, but does not decide to choose to continue watching any of the programs. In this case, bandwidth re-negotiation will result in unnecessary delay, especially in view of the operator's few gains from the point of view of striving to achieve efficient use of the allocated bandwidth.

However, at this point it is assumed that no new channel has been selected before the timer initiated at step 3:15 times out. This is indicated by the expiry of a timer of a further step 3: 16. Due to the timeout, a bandwidth re-negotiation procedure will now be initiated, since the user will now be more likely to remain connected to the current channel, and thus the UE 300 will be able to continue to receive the selected IPTV channel using the smaller bandwidth allocated to it. This initiation step, shown as step 3:17 in fig. 3, corresponds to step 1:15 in fig. 1 and the "yes" branch of step 208 in fig. 2. After this step, a bandwidth re-negotiation procedure (not shown) corresponding to steps 1:16a or 1:16b to 1:20 of fig. 1 will be started.

As described above, conditional bandwidth re-negotiation procedures, such as the procedures presented herein, are based on specified bandwidth requirements. Further as described above, such information may be provided to the UE from an IPTV network providing one or more IPTV services, typically via broadcast provisioning.

Fig. 4a is an example table 400a illustrating how information of input data to be provided to a UE to form a conditional bandwidth re-negotiation procedure may typically be configured by an operator. Table 400a includes indications of the maximum bitrates listed in a "maximum bitrate" column 402, each of the listed maximum bitrates being specified for a respective IPTV channel listed in a "channel" column 401. Table 400a also includes the timer values specified for each channel listed in "TTR" column 403.

As indicated above, typically the maximum bitrate attribute is provided to the UE in broadcast provision, e.g. according to the known open IPTV forum standard. In addition to this information, one or more relevant timer values may be provided to the UE, e.g. in a new TTR attribute of the broadcast offering.

Alternatively, for the purposes of this description, another variable may be defined and used, which may instead be an indication of the maximum bit rate of the designated group of channels, referred to herein as the reserved maximum bit rate, and indicated in the "reserved maximum bit rate" column 404. Table 400b is an exemplary illustration of a possible configuration in which a plurality of channels, each having an associated maximum bit rate assigned to it, have been grouped into one of two groups.

In typical embodiments, the maximum bitrate attribute 402 (if individual bitrates are to be considered) or the reserved maximum bitrate attribute (if grouped bitrates are to be considered) is provided to the UE along with the TTR attribute. At this point, the conditional bandwidth renegotiation process will depend on the values provided in the received bit rate attribute and TTR attribute.

The main purpose of introducing a reserved maximum bit rate is to enable grouping of different classes of channels based on the bandwidth requirements specified for the channels.

In fig. 4b this is illustrated by the two channels SVT-1 and SVT-2 being grouped together, by giving a common reserved maximum bit rate value for the group, whereas canal +, TV-4 and TV-3 have been grouped together and assigned another higher reserved maximum bit rate value.

If the evaluation steps illustrated for steps 202 and 204 in fig. 2 are to be based on a reserved maximum bitrate value specified according to a predefined policy (e.g. based on an end user behavior pattern), the number of bandwidth renegotiation procedures initiated may be reduced even more than if the bitrate requirements are specified on a per-channel basis (i.e. according to the maximum bitrate attribute assigned to the respective channel), since no new bandwidth renegotiation is required as long as the selected channel and the current channel belong to the same group.

The respective maximum bit rate value and/or reserved maximum bit rate value may be specified by the operator and may be selected according to one or more predefined criteria, thereby enabling the operator to have at least some control over how bandwidth is used for distributing IPTV channels.

The implementation of the proposed timer-based conditional bandwidth re-negotiation mechanism does not require any large modifications on the IPTV network side and, as will be clearly shown below, will also require only small modifications to the UE configured to apply such a mechanism.

A UE configured to apply the mechanism as described above according to the simplified example embodiment will now be described with reference to fig. 5.

The UE 300 of fig. 5 includes: the processor 501, which may include one or more sub-processors, is configured to manage one or more software modules and/or applications to enable the UE to perform the operations and processes described above, as well as any other conventional operations typically run on a communication entity of the type set forth.

The UE 300 includes: a transceiver 502 adapted to exchange information with one or more network entities represented by the IMS core network 101 and to communicate with an IPTV operator represented by the IPTV network 102 in the figure.

User input may be provided to the UE 300 via a User Interface (UI)503, which User Interface (UI)503 may already be integrated with the UE 300 or configured as part of a separate entity, such as a remote control. The UE 300 further includes: a display 504 for presenting information associated with IPTV set-up and IPTV media content to an end user. Alternatively, if the UE 300 has touch screen capability, the display 504 may be configured as a display integrated with the user interface 503.

Software applications for the UE 300 are typically stored in the application memory 505 and information such as broadcast offers may be downloaded and/or cached in the separate memory 506 and subsequently retrieved from the separate memory 506.

Finally, the UE 300 further includes: a timer 507 adapted to run based on a predefined timer value, which may have been provided from the IPTV network to the UE 300, e.g. via a TTR attribute forwarded in the broadcast provision.

By renegotiating the bandwidth for a plurality of channels or groups of channels, the operator will be able to achieve an optimization of the resource reservations available for the IPTV services provided by the operator. This optimization may be applicable by negotiating the bandwidth for individual channels or groups of channels. If, for example, a bandwidth has been negotiated for a channel group with Standard Definition (SD) and the user then selects a High Definition (HD) channel, when the user has selected to channel switch between channels belonging to different channel groups, session modification including bandwidth re-negotiation will be performed for that channel group. The session will then be established with the maximum bandwidth/bit rate specified for the respective group and, if the user subsequently selects a different group of channels, a new maximum bandwidth/bit rate will be specified instead.

The proposed timer-based mechanism is based on a very simple and straightforward scheme that can be easily implemented in various types of stationary and mobile devices.

By introducing two new attributes, providing the UE with a predefined bit rate value and one or more delay values in the broadcast offering, the information necessary for the purpose of performing bandwidth reservation for a single channel or group of channels will be easy to manage, since the incoming data can be easily retrieved.

The maximum bandwidth requirement for all channels need not be resolved, but instead the corresponding field is simply looked up in the broadcast provisioning information stored at the UE when determining whether the bandwidth re-negotiation decision should be postponed.

The IPTV operator will get at least some control over how bandwidth reservations are handled in the access line, so that no additional signaling is needed when switching between channels having only slightly different bandwidth characteristics.

Support for HD channels may also be provided without having to persistently reserve channels. Again with the conditional timer-based renegotiation method, the operator has in its deployment an explicit means of controlling the bandwidth reservation for the HD channel.

The proposed mechanism also provides support for Picture-in-Picture (Picture & Picture), which typically requires a small bandwidth and a mosaic type view, where multiple streams are presented on a single display. With the proposed method, many multicast streams can be set up and clear bandwidth requirements can be used. Typically, such a flow is considered to be an incorrect SD or HD flow for this situation, where an access device such as a DSLAM can assume that 3 flows represent a limit and can in fact support potentially up to 15 such streamlets. Such a drawback can be handled by the proposed method, since it results in a reduced number of bandwidth renegotiations.

Furthermore, while the present invention has been described with reference to specific example embodiments, the description is in general only intended to illustrate the inventive concept and should not be taken as limiting the scope of the invention, which is defined by the appended claims.

Abbreviations

BG border gateway

DSLAM digital subscriber line access multiplexer

IMS IP multimedia subsystem

HD high definition

MGCF media gateway control function

P-CSCF proxy-call session control function

S-CSCF service-Call Session control function

SD standard definition

STB (set Top Box)

UE user equipment

Claims (19)

1. A method at a user equipment (300) of managing bandwidth renegotiation in association with channel switching when the user equipment is engaged in an IPTV session provided from an IPTV network (102), the method characterized by:

applying a conditional bandwidth renegotiation process associated with the requested channel switch (201, 210) when it is determined (204) that the requested channel requires less bandwidth than the currently selected channel, wherein the conditional bandwidth renegotiation process comprises performing the steps of:

-switching (206) to the requested channel;

-starting (207) a timer, the purpose of which is to delay the decision whether or not to perform a bandwidth re-negotiation; and

-initiating (209) a bandwidth re-negotiation in response to identifying (208a) that the timer has expired,

wherein if a switch to another channel is requested before the timer times out, the timer is reset and started again if said another channel requires less bandwidth than the currently selected channel, and

if the other channel that was recently requested requires more bandwidth than the currently selected channel, a bandwidth re-negotiation procedure is initiated and performed immediately.

2. The method of claim 1, further comprising the steps of:

-terminating (211) the timer in response to identifying (210a) another channel switch request before the timer times out.

3. The method of claim 1, wherein after terminating the timer, determining (202, 204) whether a conditional bandwidth re-negotiation procedure is to be applied further in response to a most recent channel switch request.

4. The method of claim 1 or 2, wherein the determining (204) that the requested channel requires less bandwidth than the currently selected channel comprises: the value of the bit rate attribute associated with the requested channel and corresponding to the bandwidth required by the requested channel is compared with the maximum bit rate currently available to the user equipment (300) and corresponding to the bandwidth allocated to the current channel.

5. The method according to claim 4, wherein the bitrate attribute is provided from the IPTV network (102) to a user equipment (300).

6. The method according to claim 4, wherein the bit rate attribute is provided to the user equipment (300) in a broadcast offering.

7. The method of claim 4, wherein the bitrate attribute comprises a bitrate value predefined on a per-channel basis.

8. The method of claim 6, wherein the bitrate attribute is a maximum bitrate attribute.

9. The method of claim 4, wherein the bitrate attribute is a new attribute comprising a value predefined on a per channel group basis.

10. A method according to claim 1, wherein said timer is set according to a timer value, TTR, provided from said IPTV network (102) to a user equipment (300).

11. A method according to claim 10, wherein said timer value TTR is a common timer value predefined for all channels provided from said IPTV network (102).

12. A method according to claim 10, wherein said timer value TTR is a channel specific timer value predefined for a specific channel.

13. A method according to claim 10, wherein said timer value TTR is a group specific timer value predefined for a specific channel group.

14. The method according to claim 10, wherein said timer value TTR is a new attribute provided to the user equipment (300) in a broadcast provision.

15. A user equipment (300), the user equipment (300) managing bandwidth re-negotiation in association with performing a requested channel switch when the user equipment (300) is engaged in an IPTV session with an IPTV network (102), the user equipment (300) characterized by:

-a memory (506) configured to store bandwidth requirement information associated with at least two IPTV channels;

-a processor (501) configured to initiate a conditional bandwidth renegotiation procedure in response to a requested channel switch if the bandwidth required by the requested channel is less than the bandwidth required by the currently selected channel;

-a timer (507) controllable by the processor (501) such that during a conditional bandwidth renegotiation procedure the timer is set to delay a decision whether or not a bandwidth renegotiation is to be initiated;

the processor (501) is further configured to initiate a conditional renegotiation procedure by switching to the requested channel, and to initiate a bandwidth renegotiation in response to identifying a timeout, the timeout being defined by one of one or more predefined timer values TTR,

wherein if a switch to another channel is requested before the timer times out, the processor (501) is further configured to reset and start the timer again if the other channel requires less bandwidth than the currently selected channel, and

the processor (501) is further configured to initiate and perform a bandwidth re-negotiation procedure on-the-fly when the other channel most recently requested requires more bandwidth than the currently selected channel.

16. A user equipment (300) according to claim 15, wherein the memory is further adapted to store at least one predefined timer value, TTR, associated with at least two IPTV channels, used by the timer.

17. The user equipment (300) of claim 15, wherein after terminating the timer, the processor (501) is further configured to determine whether a conditional bandwidth renegotiation procedure is to be applied further in response to the most recent channel switch request.

18. The user equipment (300) of claim 15, wherein the processor (501) is further configured to evaluate the bandwidth requirement by: a bit rate value of a bit rate attribute associated with the requested channel and corresponding to a bandwidth required by the requested channel is compared with a maximum bit rate currently available to the user equipment (300) and corresponding to a bandwidth allocated to the current channel.

19. The user equipment (300) according to claim 15 or 16, wherein the user equipment (300) is any one of: a set-top box; a PDA; a TV; a computer or a mobile phone.