Patent Application
20160211982
The present disclosure relates to a method for providing a HTTP streaming service from a network node to a user equipment via broadcasting, and processing devices which are capable of executing such a method.
Multimedia Broadcast Multicast Services (MBMS) is a point to multipoint interface specification for existing and upcoming 3GPP cellular networks, which is designed to provide efficient delivery of broadcast and multicast services, both within a cell, as well as within the core network. For broadcast transmission across multiple cells, it defines transmission via single-frequency network configurations. Target applications include mobile TV and radio broadcasting, as well as file delivery and emergency alerts. Evolved Multimedia Broadcast Multicast Services (eMBMS) is a corresponding broadcasting service offered via Evolved Packet Systems including E-UTRAN (LTE) and UTRAN access.
One typical use case of MBMS or eMBMS is to deliver content, such as e.g. sport game related video content, or other types of content to a large number of mobile users gathered at a specific location, such as e.g. a sports arena, a conference or fair building.
In case e.g. eMBMS is applied, the MBMS Download Delivery Method (UDP/FLUTE) may be used as protocol to deliver live TV content to user equipments (UEs). In addition, media segments according to the Hypertext Transfer Protocol (HTTP) Live Streaming (HLS) protocol or according to Dynamic Adaptive Streaming over HTTP (DASH) may be delivered as files over MBMS download as well.
Another typical use case is distribution of Android updates, where eMBMS can use the MBMS Download Delivery Method (UDP/FLUTE) as protocol to deliver popular files, such as Android update, YouTube clip preloading or major news event.
One simplified example of an MBMS or eMBMS architecture according to the prior art is illustrated in
In order to be able to remedy failure to receive broadcasted or multicasted user content correctly, by at least one of the UEs, the architecture described above is typically also provided with functionality which is configured to enable the BM-SC 110 to re-transmit parts of the user content to those UEs 160 reporting failure to receive the user content correctly. In the context of MBMS or eMBMS, such a process is typically referred to as a file repair process, or more specifically HTTP Unicast File repair. For enabling file repair, the BM-SC 110 is therefore normally provided also with at least one, but typically with a plurality of file repair servers (not shown), capable of providing lost or corrupted file fragments of the distributed user content to each requesting UE, by way of re-transmission of the previously transmitted, but not correctly received user content. For eMBMS, 3GPP TS 26.346 defines a User Service Bundle Description (USD), which is used for grouping user services available via eMBMS in one or more USD instances.
A USD instance contains one or more Delivery Method descriptions, which is/are used to describe for a UE how a service is delivered to a UE. The Delivery Method description refers to a Session Description Instance, which describes the delivery related parameters that the UE need to be aware of to be able to receive transmitted user content. An Associated Delivery Procedure Description (ADPD) may also be referenced by the Delivery Method description to provide a complementary delivery method for the service, such as e.g. file repair and/or reception reporting in eMBMS. In addition, the Delivery Method description may also reference to a Security Description in order to provide for relevant service protection information.
MBMS download can be used to deliver an arbitrary number of files from a single source to many receivers. MBMS Download uses the File Transport over Unidirectional Transport (FLUTE) protocol for file delivery. FLUTE, which is further described e.g. in RFC3926, is designed to provide massive file delivery over unidirectional links, such as digital broadcast deliveries. Since HTTP and TCP are not feasible for point-to-multipoint communication, a newly developed protocol is used.
From hereinafter it is to be understood, that whenever MBMS is mentioned it is to be referred to as meaning any of MBMS or eMBMS.
After an MBMS bearer has been established, the BM-SC starts sending the actual MBMS user data. The BM-SC can send one or more files using MBMS. All files require an entry in the FLUTE FDT, which are provided using FLUTE FDT Instances.
An Associated Delivery Procedures (ADP) is optionally executed after the MBMS data transfer phase. Two types of associated delivery procedures are defined by the MBMS Service Layer, namely the file repair procedure ensures the reliability of transmissions. A reception reporting procedure is used to collect reception statistics. For the MBMS Download Delivery method, the reception reporting procedure is used to either report the complete reception of one or more files, or to report statistics on the stream, or to do both. For the MBMS Streaming Delivery method, the reception reporting procedure is used to report statistics on the stream.
If the BM-SC provided parameters requires reception reporting confirmation then the UEs capable of operating as MBMS receivers confirms the user content reception, while if reception reporting is requested for statistical purposes the BM-SC may specify the percentage subset of MBMS receivers it would like to perform reception reporting.
However, in current MBMS solutions, associated delivery procedures for reception reporting can only be initiated subsequent to an MBMS data transmission phase. Consequently, there is no mechanism available for broadcasted sessions, provided e.g. via MBMS, for providing any feedback on an ongoing streaming session.
It is an object of the present document to at least alleviate the problem described above.
In order to cope with the disadvantage of not having access to the mentioned type of feedback during an ongoing streaming session a method is suggested which which is suitable for execution on a network node capable of providing a HTTP streaming service to a UE via broadcasting or multicasting. The suggested method is initiated by determining, at the network node, that runtime reception reporting is required from a UE for a determined HTTP streaming service, followed by determining reporting parameters to be applicable for the runtime reception reporting, and providing the determined reporting parameters to the UE.
Thereby a UE receiving the reporting parameters will have all information necessary for conducting measuring of certain given metrics, as well as information on which conditions that shall apply for reporting measured data in a runtime reception report.
The reporting parameters may include at least one of a measure resolution period and a measuring range for indicating conditions for how to perform the requested measuring.
Typically, the reporting parameters also comprise a threshold value, which value is indicating to the UE when to trigger transmission of a runtime reception report.
According to one embodiment, the runtime reception reporting is based on Loss of Objects metrics indicated in the reporting parameters, and the threshold value is set as a percentage of loss of objects over all objects of the HTTP streaming service received by the UE, such that transmission of a runtime reception report from the UE is triggered when the percentage of loss of objects exceeds the threshold value.
According to one embodiment, the reporting parameters are provided to the UE in association with provisioning the HTTP streaming service.
An advantage with providing the reporting parameters this way is that signalling already used between the communication network and the UE is used also for the purpose of providing for the solution as is suggested and described in this document.
At least some of the reporting parameters, such as e.g. the runtime reception report type and the threshold value, may be provided in an SDP file, while other reporting parameters, disclosing information indicative of at least one of the runtime reception report type and the threshold value may be provided in an ADPD file.
As indicated above, files already used by the communication network when communicating with the UE may be used also for the purpose of providing reporting parameters to the UE, and thus, no additional signalling will be required for achieving this task.
The reporting parameters may include at least one of a measure resolution period and a measuring range for indicating conditions for how to perform the requested measuring.
Subsequent to execution of the steps mentioned above, the network node may eventually receive a runtime reception report from the UE, where such a report has been assembled according to the previously provided reporting parameters. Following the reception of such a report, the method may continue by considering at least one transmission related amendment, associated with the ongoing HTTP streaming service, at least partly on the basis of content of the received runtime reception report.
Such an amendment may comprise at least one of: increasing the FEC overhead percentage applied for the ongoing HTTP streaming service; increasing the service area applied for the ongoing HTTP streaming service, and updating the RAN configuration by optimized radio settings applied for the ongoing HTTP streaming service.
According to another aspect a first processing device for providing a HTTP streaming service from the processing device to a UE via broadcasting or multicasting is suggested, which comprise a processor, and a memory, storing computer readable instructions which when executed by the processor causes the first processing device to: determine that runtime reception reporting is required from a user equipment for a determined HTTP streaming service; determine reporting parameters to be applicable for the runtime reception reporting, and provide the determined reporting parameters to the UE.
The first processing device may comprise compute readable instructions which when executed by the processor causes the first processing device to determine reporting parameters comprising a threshold value indicating to the UE when to trigger transmission of a runtime reception report.
The first processing device may also comprise computer readable instructions which when executed by the processor causes the first processing device to execute the providing step in association with provisioning the HTTP streaming service.
Computer readable instructions may cause the processing device to provide at least some of the reporting parameters in an SDP file, when the instructions are executed by the processor. According to one embodiment, information indicative of at least one of the runtime reception report type and the threshold value is provided in an SDP file
Alternatively, information indicative of at least one of the runtime reception report type and the threshold value may be provided in an ADPD file.
The first processing device also comprise computer readable instructions which when executed by the processor causes the first processing device to: receive a runtime reception report from the UE and consider at least one transmission related amendment associated with the ongoing HTTP streaming service dependent on content of the received runtime reception report, where such considerations may comprise at least one of: increasing the FEC overhead percentage applied for the ongoing HTTP streaming service; increasing the service area applied for the ongoing HTTP streaming service, and updating the RAN configuration by optimized radio settings applied for the ongoing HTTP streaming service.
The first processing device mentioned above is forming part of a network node of the communication network which is broadcasting or multicasting a HTTP streaming service to the UE, wherein that network node may be or may be connected to a BM-SC, thereby enabling the first processing device to make use of signalling which is normally conducted by a BM-SC.
According to another aspect, the first processing device mentioned above may be configured as comprising a plurality of interacting modules, where, according to one embodiment, such a processing device comprise: a determining module for determining that runtime reception reporting is required from a UE for a determined HTTP streaming service and for determining reporting parameters to be applicable for the runtime reception reporting, and a providing module for providing the determined reporting parameters to the UE.
According to yet another aspect, a computer program is provided which program comprise computer readable instructions which, when executed on a network node causes the network node to determine that runtime reception reporting is required from a UE for a determined HTTP streaming service; determine reporting parameters to be applicable for the runtime reception reporting, and provide the determined reporting parameters to the UE.
According to yet another aspect, a computer program product is provided, where the computer program product comprise a computer program, such as the one described above and a computer readable means on which the computer program is stored.
According to another aspect, a method suitable for being executed on a UE for receiving a HTTP streaming service from a network node via broadcasting or multicasting is provided. The method comprise the steps of: determining that runtime reception reporting has been enabled by a network node providing a determined HTTP streaming service; receiving reporting parameters to be applicable for the runtime reception reporting; measuring runtime statistics on the basis of the determined reporting parameters, and transmitting (3:6) measured runtime statistics to the network node upon recognising (3:5) a reporting trigger.
The reporting parameters may comprise at least one of a measure resolution period and a measuring range.
According to one embodiment, Loss of Objects metric are used as reporting input, and a threshold value is given as a percentage of loss of objects over all received objects, such that transmission of a runtime reception report is triggered when the percentage of loss of objects exceeds the threshold value.
The receiving step may be executed in association with receiving provisioning of the HTTP streaming service from the network node.
At least some of the reporting parameters, such as e.g. the runtime reception report type and the threshold value may be received in an SDP file. Alternatively, or in addition, information indicative of at least one of the runtime reception report type and the threshold may be received in an ADPD file.
According to another aspect, a second processing device which is suitable for receiving a HTTP streaming service from a network node via broadcasting or multicasting, and for executing the method for providing runtime reception reports to a network node as described above is provided. Such a processing device comprise, according to one embodiment, a processor, and a memory storing computer readable instructions which when executed by the processor causes the processing device to: determine that runtime reception reporting has been enabled by a network node providing a determined HTTP streaming service; receive reporting parameters to be applicable for the runtime reception reporting; measure runtime statistics on the basis of the determined reporting parameters, and report measured runtime statistics upon recognising a reporting trigger.
According to one embodiment, Loss of Objects metrics are used as reporting input and a threshold value is indicating a percentage of loss of objects over all received objects, and wherein the memory is further comprising computer readable instructions which when executed by the processor causes the second processing device to provide a runtime reception report and transmit the report to a network node, when the percentage of loss of objects exceeds the threshold value.
The memory may comprise computer readable instructions which when executed by the processor (610) causes the second processing device to receive the reporting parameters in association with receiving a provisioning of the HTTP streaming service from the network node.
The memory may further comprise computer readable instructions which when executed by the processor causes the second processing device to receive at least some of the metrics in an SDP file. More specifically reporting parameters indicative of at least one of the runtime reception report type and the threshold value may be provided in an SDP file. Alternatively reporting parameters indicative of at least one of the runtime reception report type and the threshold value may be provided in an ADPD file.
According to another aspect the second processing device mentioned above, which is suitable for receiving a HTTP streaming service from a network node via broadcasting or multicasting is configured as comprising a plurality of interacting modules, which, according to one embodiment is arranged as: a determining module for determining that runtime reception reporting has been enabled by a network node providing a determined HTTP streaming service; a measuring module for measuring runtime statistics on the basis of the determined reporting parameters, upon having received, from the network node, via a receiving unit, reporting parameters to be applicable for the runtime reception reporting, and a reporting module for reporting measured runtime statistics via a transmitting unit upon recognising a reporting trigger.
The second processing device described above, which is suitable for receiving a HTTP streaming service from a network node via broadcast or multicast typically form part of a UE.
According to yet another aspect, a computer program is provided, which comprise computer readable instructions which, when executed on a UE causes the UE to perform measurements as suggested above while receiving a HTTP streaming service from a network node via broadcast or multicast. More specifically, the UE is caused to: execute a method for determine that runtime reception reporting has been enabled by a network node providing a determined HTTP streaming service; receive reporting parameters to be applicable for the runtime reception reporting; measure runtime statistics on the basis of the determined reporting parameters, and report measured runtime statistics upon recognising a reporting trigger.
According to another aspect a computer program product is provided which comprise a computer program, such as the one described above, and a computer readable means on which the computer program is stored.
Embodiments will now be described in more detail in relation to the accompanying drawings, in which:
As already mentioned above, HTTP DASH streaming is a download delivery method which is available for the eMBMS solution. For the currently available solution, there is however no runtime reception reporting procedure available for HTTP streaming status using the download delivery method. Thus an operator cannot get immediately feedback about the receiving quality at a UE and therefore cannot tune its network parameters while still receiving a HTTP streaming session.
The ability to be able to make adjustments to download delivery conditions is particularly essential during live broadcasting scenarios where possible broadcasting problems need to be handled instantly. In case downloading is executed with incorrect or non-optimal network configurations, UEs operating as eMBMS clients may lose DASH segments during certain periods and thereby, as a result end up with an unsatisfactory user experience. However in such a situation, the operator will not be able to receive any immediate feedback from any UE and therefore he will not be able to take immediate actions by tuning the network accordingly.
At least for the reason mentioned above, a method is suggested, where the operator can choose to apply runtime reception reporting, on a session by session basis. More specifically, a mechanism is suggested where the network node can provide information indicating to a UE that it shall initiate measuring of certain runtime statistics, and to report the result of such measuring to the network node when reporting is triggered at the UE, based on one or more trigger parameters provided to the UE from the network node. Thereby the operator will be able to get immediate feedback about any continuous download delivery method applied for DASH streaming. Based on such feedback, the operator will then be able to take immediate action to improve the broadcast delivery.
For this purpose a new reception report type need to be introduced. This new report type can be chosen e.g. when a download delivery method for continuous DASH streaming delivery and Quality of Experience (QoE) metrics use Loss of Objects as an input parameter.
One new reception report type need to be introduced in order to enable a network node to instruct a UE to perform such reception reporting, and can be chosen on the network side at least whenever a download delivery method for continuous DASH streaming delivery is applied. By way of example, QoE metrics using Loss of Objects may be used as basis for the reporting.
Below a method executable at a network node which provides for a provisioning at the server side of a network is described. Such a network node may, as suggested in the given example, be a BM-SC, or may be provided as a stand alone network node which is connected to, and capable of interacting with the BM-SC, or any other type of network node, which is capable of distributing broadcasted content to UEs.
Once it has been decided at the network node, typically initiated by an operator, to provision one HTTP streaming service through a continuous file delivery broadcasting method, such as MBMS or eMBMS, in the present example via a BM-SC, a method as illustrated in
In a next step 2:2, it is determined, typically by input from the operator, whether or not a runtime statistical report is required in order to provide for streaming delivery feedback of the previously determined continuous file delivery method. Such a decision may be taken automatically, manually or in a combination thereof. An operator may e.g. choose to apply runtime statistics reporting by default for every streaming and choose to disable reporting only for those streaming sessions which are considered to be of less importance and for which it is therefore decided the this type of feedback is not needed.
In case no such reporting is required the described process is terminated, while in case reporting is required, the process continues by determining parameters to be applied in the reporting process, as indicated in a subsequent step 2:3. From herein after these parameters are to be referred to as reporting parameters and include all settings provided from the network node to the UE for the purpose of making the runtime reception reporting described herein possible from the UE. Which parameters to determine may e.g. be determined from input provided by the operator, from previously defined and stored default values, or from a combination of both. Among other issues, he report type, which in the present example is referred to as “RtStaR-all”, is set at this stage.
According to one exemplary embodiment, this report type use Loss of Objects metrics as a report input. In the latter case the reporting parameters include an indication that Loss of Objects shall be measured and form basis of later reporting. In addition, a measure resolution and a measure range are preferably also determined in order to provide instructions to a UE on when, and under what conditions to measure data which can later form basis for a report. A typical measure resolution can e.g. be set to 30 seconds, while a typical measure range e.g. can be set to the whole or half the period of one broadcast session. Alternatively one or more of the mentioned parameters may be pre-set as default value/s.
When applying the suggested report type at a UE, the number of loss of objects will be summed up over each measure resolution period of the given measure range at a UE, capable of receiving a HTTP streaming service. In addition, a trigger decisive for when to generate a report at the UE need to be determined. According to one embodiment, a threshold value can be specified and provided to the UE, such that when the threshold value is reached at the receiving UE, a report is generated by the UE and provided to the network node. By way of example, a threshold value set to 15 will indicate that when the loss of objects over all received objects reach 15% over a specified measure resolution period the UE is triggered to complete a report and to transmit it back to the network node which originally requested such reports, thereby enabling the UE to report bad quality of an on-going session at short notice, and also enabling the network node to initiate actions on the network side and thereby allow an operator to get immediate feedback on continuous delivery status for live streaming and to react to quality deterioration in due time. Such a feature can be very important e.g. in case the streaming quality is very unsatisfactory due to a Forward Error Correction (FEC) overhead which has not been configured high enough, or due to use of a broadcast area which has been under dimensioned.
In a next step 2:4, the reporting parameters are assembled and provided to the UE, typically together with and incorporated into, a transmitted service announcement, i.e. as part of the provisioning initiated in step 2:1, thereby preparing the UE for the upcoming service, i.e. HTTP streaming reception. In the latter case the parameters are distributed in an already used message, and thus no new signalling need to be introduced for this purpose. More specifically an SDP file and an ADPD file, already used in signalling between the two mentioned entities, may be used for providing the information necessary to initiate preparations for reporting. More specifically the BM-SC generates an SDP file, which, in addition to already presently provided information, also includes the determined reporting parameters and an ADPD file, which typically includes an indication of the report type, here “RTStaR-all”, as well as a selected threshold value, provided as a new “threshold” attribute, in addition to already previously provided information, such as e.g. file repair related information. Alternatively, for the purpose of maintaining backwards compatibility, in situations where no threshold attribute can be used in the ADPD, then also the threshold value and report type may instead be provided in the SDP file.
In case a net threshold attribute can be applied in the ADPD, an ADPD schema update may look as suggested below:
As stated in the schema, one new reportType “RtStaR-al”I has been introduced for identifying a request for runtime statistic reporting to a receiving UE. In our example, a new attribute threshold is also introduced in “reportProcedureType” if the reportType is set to “RtStaR-all”. If the suggested schema is set as indicated above, and if the percentage of loss of objects exceeds the threshold value provided as the specified “threshold” value, the UE will need to take the obtained parameters into consideration, apply the suggested method and determine if immediately reception reporting is needed. As indicated in the schema, the report type and threshold values are indicated as optional input parameters, which will only be considered by UEs adapted to handle such information accordingly. Conditions for handling such information at a UE will be more apparent below.
Alternatively, the threshold value can be defined in 3GPP-QoE-Metrics if a threshold attribute cannot be applied in the ADPD. A new attribute: Measure-Threshold can in such a case instead be added to the other relevant 3GPP-QoE-Methrics in a SDP file, e.g. given as:
As indicated in a next step 2:5, the required HTTP streaming can commence, since provisioning has now been executed at the server side. At the network side runtime statistics reports can now be received and handled accordingly. This is indicated with the loop, denoted step 2:6. Once a report has been received from the UE, any available adaptation of the operation of the broadcasting network which can be used for trying to improve the performance can be considered or initiated by the network node, based on the content of the runtime statistics report. The latter step is indicated in step 2:7. It is to be understood that the process described in
It is also to be understood, that, although,
According to one embodiment, an increase of the presently applied FEC overhead percentage is considered at the network node, in order to increase the reception quality based on the content of received reports. This approach may be especially beneficial e.g. in a situation where bad quality has been reported from most of the broadcast service areas of a broadcasting network.
According to another embodiment, an increase in the applied service area is considered at the network node, e.g. in case most of the reception reporting is associated with the edge of a broadcast service area. The fact that the reporting is associated with the edge of the broadcast service area can be determined e.g. from location information, indicating the location of the UE, which information, according to one alternative embodiment, may be provided in a reception report as well.
According to yet another embodiment an update of the RAN configuration presently applied by the network is considered at the network node, in order to use more optimized radio settings for on-going sessions. Such configuration update may typically include Modulation and Coding Scheme (MCS) and Multiple Service Provider (MSP) updates.
It is to be understood that the scope of this disclosure is to suggest a mechanism for providing for runtime reception reporting, i.e. for allowing a network node to inform a UE to initiate such reporting and to provide parameters necessary for initiation of such reporting. Apart from the given examples, the way this information is actually used for adapting the network is out of the scope of this disclosure, especially since numerous ways of adapting a network is already well known to the skilled person, while ways of initiating such an activity, given the present circumstances, are so far not disclosed
In a first step 3:1, the UE initiates a HTTP streaming service reception, after first having received an USD for a specific HTTP streaming service. In a next step 3:2, the UE determines if runtime statistics reporting has been enabled by a network node, such as the one described above, e.g. from interpreting content received in an ADPD file and/or a SDP file. If this is not the case the process is terminated. If however information indicative of such reporting is identified by the UE, the process continues by receiving reporting parameters, specifying how to execute the reporting, as indicated with step 3:3.
Typically these parameters are received in the same file(s) as indicated above. As already mentioned above for the network node, the reporting parameters may typically comprise a specified measure resolution and measure range, which may be received e.g. in an SDP file, while an indication of the report type, here “RTStaR-all” and a selected threshold value may be provided in an ADPD file or SDP file. Based on the reporting parameters the UE then starts to measure runtime statistics as specified, as indicated in step 3:4, e.g. by measuring loss of objects according to a given measure resolution and measure range.
As indicated in the specification 3GPP 26.346 “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs” (Rel-9), measure resolution is defined as the time over which each metric value is calculated; splits a session duration into a number of equally sized periods, where each period is of the length specified by the “measure-resolution” field, while measure range define the time range in the stream for which QoE metrics will be reported.
Once runtime statistics reporting has been triggered at the UE, as indicated in the loop, referred to as 3:5 in
Such a providing step is indicated as step 3:6 in
A possible configuration of a processing device, from hereinafter referred to as a first processing device, which is forming part of a network node capable of providing for use of runtime reception reporting, as suggested above, according to one embodiment, will now be described in further detail below with reference to
The first processing device 400 comprises a processor 410, and a memory 420 capable of storing computer readable instructions 450 which when executed by the processor 410 causes the processing device 400 to determine that runtime reception reporting is required from a UE 600, 700 for a specific HTTP streaming service, typically by receiving input from the operator responsible for the respective streaming session. Such instructions also causes the first processing device to determine which reporting parameters to be applicable for the runtime reception reporting, which determination may be executed either by applying parameters set by default, or by adapting parameters for the respective session, and provide the determined reporting parameters to the UE 600,700, by transmitting them via a transmitting unit, TX 430.
The memory 420 typically also comprise computer readable instructions which when executed by the processor 410 causes the first processing device 400 to determine relevant reporting parameters, comprising a threshold value, indicating to the UE 600 under which conditions to trigger transmission of a runtime reception report.
The memory 420 may also comprise computer readable instructions which when executed by the processor 410 causes the first processing device 400 to execute the providing step in association with provisioning the HTTP streaming service, i.e. at the same time as executing a conventional provisioning process. In such a scenario, the UE is provided with information indicating that runtime reception reporting is to be applied for the respective service, and also with information indicative of the necessary reporting parameters to be applied for the reporting.
According to one embodiment, the memory 420 may comprise computer readable instructions which when executed by the processor 410 causes the first processing device 400 to provide at least some of the reporting parameters in an SDP file, while information indicative of at least one of the runtime reception report type and the applicable threshold value is provided in an ADPD file. Alternatively, e.g. if it is not possible to apply a new threshold attribute in the ADPD, the threshold attribute may instead be provided in a SPD file.
Once the indication to apply runtime reception reporting has been provided to a UE 600, 700, as indicated above, computer readable instructions contained in the memory 420 may, when executed by the processor 410, cause the processing device 400 to receive a runtime reception report transmitted from the UE 600, and allowing the first processing device 400 to consider or initiate at least one transmission related amendment associated with the ongoing HTTP streaming service, dependent on content of the received runtime reception report. The latter process may imply to make one or more adjustments, not only to the network node on which the first processing device 400 resides, but also to other functionality of the communication network which may be involved in the transmission of the relevant streaming session. For that purpose, the computer readable instructions may include also routines for how to interact with various functionality of the communication network e.g. for collecting or exchanging parameters and measuring values for evaluation, together with the information provided in a runtime reception report, and also for interacting with the operator, e.g. in case a semi-automatic process is used. However, since such interaction is commonly applied between network nodes of various communication networks, such details are out of the scope of this document.
In the latter case the operator may be provided with certain measured metrics, on the basis of which the operator can later make a decision to make adjustments and thereby making an attempt to improve conditions for an ongoing streaming session at relatively short notice.
Alternatively, the memory 420 may be arranged as a computer program product 470, which comprises computer readable medium and a computer program 450, comprising executable, computer readable means, here in the form of instructions, which when executed by the processor causes the first processing device to operate as described above, with reference to
As illustrated in
Similar to the embodiment described above, with reference to
According to yet another alternative embodiment processor 510 may configured as a number of suitable integrated circuits, capable of interacting in a way which corresponds to the interacting modules described above, and may be arranged e.g. as an Application Specific Integrated Circuit) ASIC, or any other type of available electronic configuration. Alternatively, a processor configuration may constitute a combination of software and hardware implemented units and modules.
A processing device 600, which is suitable for implementation in a UE, according to one embodiment, which processing device is capable of applying runtime reception reporting according to information provided from a network node as suggested above will now be described in further detail below with reference to
As indicated in
As already mentioned above, Loss of Objects metric may be used as reporting input in combination with a threshold value indicating a certain percentage of loss of objects over
all received objects. In such a situation the memory may further comprise instructions which when executed by the processor causes the UE to provide a runtime reception report and transmit the report to a network node when the percentage of loss of objects exceeds the threshold value. Information on what metrics to measure may be provided in an SDP file.
The memory 620 may comprise computer readable instructions which when executed by the processor 610 causes the second processing device 600 to receive the reporting parameters in association with receiving a provisioning of the HTTP streaming service from the network node, i.e. in addition to receiving information on a conventional provisioning, the second processing device 600, also receive information on possible enablement of runtime reception reporting as described herein.
The second processing device 600 may receive reporting parameters in different ways. According to one embodiment, the memory comprise computer readable instructions which when executed by the processor 610 causes the second processing device 600 to receive at least some of the metrics in an SDP file, together with information normally provided to the second processing device 600 in an SDP file.
If applicable, the memory 620 may comprise computer readable instructions which when executed by the processor 610 causes the second processing device 600 to receive reporting parameters indicative of at least one of the runtime reception report type and the threshold in an ADPD file, together with information normally provided in an ADPD file.
Although the processors described in the different embodiments herein are presented as one single processor, the processor may be one single Central Processing Unit (CPU) or may comprise a plurality of interacting processors. In a corresponding way, the processing units may be provided as one or a plurality of interacting processing units.
As indicated with
Any of the second processing device 600, 700 may also comprise a computer program product 670, 770 which comprises computer readable medium and a computer program 650,750, comprising computer readable instructions which when executed by the processor 610, 710 causes the second processing device 600,700 to operate as described above, with reference to
Alternatively, the processor 710 may be configured by suitable integrated circuits, and may e.g. be arranged e.g. as an Application Specific Integrated Circuit) ASIC, or any other type of available electronic configuration, or be arranged as a combination of interacting software modules and hardware units, which are configured to provide functionality as described in any of the embodiments described above with reference to
It is to be understood that the choice of interacting units, as well as the naming of the units within this disclosure are only for exemplifying purpose, and that nodes suitable to execute any of the methods described above may be configured in a plurality of alternative ways in order to be able to execute the suggested procedure actions.
It should be noted that the arrangements as described with reference to any of
While this document disclose several alternative embodiments, it is contemplated that alternatives, modifications, permutations and equivalents thereof will become apparent upon reading of the specifications and study of the drawings. It is therefore intended that the following appended claims include such alternatives, modifications, permutations and equivalents as fall within the scope of the embodiments and defined by the pending claims.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/CN2013/082245 | 8/26/2013 | WO | 00 |
