Mobile TV has become a reality offered on several mobile delivery systems. Among them is the Advanced Television System Committee (ATSC) system for mobile and handheld digital television services, known as ATSC Mobile DTV or ATSC M/H, which has moved from standardization to implementation. As the North American broadcast industry is preparing to provide Mobile DTV service to consumers, this work discusses important technical parameters that affect the TV service quality and capacity. Since additional error correction mechanisms were added to overcome mobile transmission problems, the available payload for M/H services is limited. This creates a need to efficiently use the available M/H bandwidth. The paper aims to optimize the Mobile DTV service capacity while maintaining an acceptable perceived quality. It presents tradeoffs between several factors affecting service capacity and signal robustness, which is prominent for designing Mobile TV broadcasting scenarios.

1. Introduction

The concept of television viewed on mobile devices has been a reality since 2005, when South Korea began satellite and terrestrial TV. Japan followed soon thereafter with US cellular carriers such as Sprint Verizon and AT & T. Content providers, such as MobiTV, Slingbox, and Hulu, offer episodes and clips from standard programs delivered on cellular networks. The North American broadcast industry formed an association called Open Mobile Video Coalition (OMVC) to assist ATSC in developing a standard for providing TV content to mobile handsets. The final standard of ATSC Mobile DTV, designated as A/153 [1], was ready in late 2009. Beside TV, the new standard provides a flexible framework for applications, such as video and audio streaming, real-time mobile commerce, participation and interactive television and advertising that allows M/H viewer to engage in real time with the program.

ATSC Mobile DTV has the potential to be the ubiquitous system for delivery of content to devices that move. The main purpose of the standard is to enable reception of DTV broadcaster’s signal on handheld and mobile receivers at vehicular speeds. Based on it, a broadcaster can devote a portion of the station’s assigned channel capacity to mobile service. This portion, however, is overly coded to combat rabidly the changing multipath conditions and poor signal-to-noise ratios usually associated with mobile devices and small antennas. The mobile signal is not decodable by legacy fixed receivers but is compatible as a valid legacy signal.

The overall structure of ATSC M/H is partitioned into three layers: presentation, management, and physical. The presentation layer mainly includes audio and video coding and other data as closed captions. The management layer includes all functions associated with transport, demultiplexing, and associating data with a particular service or program.

A number of existing standards and protocols were incorporated into this layer. Data, video, and audio transport is via Internet Protocol (IPv4) and User Datagram Protocol (UDP). Real-time programs, including video and audio, are further carried via the Real-time Transport Protocol (RTP) and its associated control protocol (RTCP). The UDP additionally carries Network Time Protocol (NTP) and service map tables that associate data streams with services. The payload interface between the management and physical layers is a two-dimensional block of data called an RS frame. The RS frame payload consists of concatenated IP datagrams, with each row of the frame starting with mobile/handheld (M/H) transport (TP) header that provides IP datagram locating information.

The physical layer incorporates the mobile data into the legacy ATSC transmission. It includes all the features of ATSC signals and incorporates new features unique to ATSC M/H, which include two-dimensional block forward error correction coding (i.e., Reed-Solomon error coding) of RS frame for byte errors and serial concatenated convolutional coding (SCCC) of the mobile payload for improved signal-to-noise ratio. That is, the mobile payload data is serially coded by preceding the legacy ATSC trellis code with an SCCC code. This provides legacy receivers with a signal that is normally coded while mobile receivers can take advantage of the concatenated codes to perform iterative turbo decoding that can greatly improve the signal.

Although the ATSC mobile DTV is built around a highly robust transmission system coupled with flexible IP-based transport system and efficient video and audio coding, some of these features add to the overheads that constraint the payload carried by the channel. That is, including other protocols (i.e., IP, UDP, and RTP) introduces signalling information that needs to be carried along with the transported data. And since the RF channel capacity is the same, extra channel coding, intended for increasing signal robustness, limits the effective bandwidth, that is, the payload size available for carrying mobile data.

In fact, the total bandwidth needed for the mobile DTV service depends on several factors, including the number and type of program services, the quality level, and the level of robustness desired, typically ranging from less than one megabit per second to many megabits per second. Even, if a bandwidth portion is designated for mobile DTV, the service capacity, in terms of mobile TV services, will be affected by the same factors as well.

The specifications of the different transport and transmission features are detailed in the ATSC M/H standard, which is divided into nine parts. Among them, part 2 [2] specifies the transmission system characteristics, including the Reed-Solomon (RS) and SCCC coding, and discusses different payload data rates. Part 3 [3] covers the service multiplex and transport system, describing transport signalling and streaming. Parts 7 [4] and 8 [5] describe video and audio systems, respectively, mainly formats and codecs. There is also the recommended practice [6] (i.e., A/154), whose purpose is to explain what is enabled by the standard technically and functionally and to provide recommendations for the emission systems. However, neither the standard nor the recommended practice translates these specs into service capacity or discusses capacity usage optimality.

Beside the standards, recently the OMVC discussed some ATSC M/H broadcast scenarios based on program quality [7]. Companies, providing transmission and reception equipment, focused more on link budget and site planning [8], the inherent challenges, and the technology added to adapt the ATSC physical layer to mitigate the mobile fading channel and to enable ATSC Mobile DTV reception [9].

The study in this paper brings forward the optimization of mobile DTV service capacity, by maximizing the number of TV services without compromising the service quality. It discusses it within the boundaries dictated by the requirements for link robustness and compatibility with legacy system. The paper is organized as follows: Section 2 presents the problem modeling, Section 3 illustrates the results and discusses tradeoffs and potentials of TV quality versus robustness, and Section 4 concludes the paper.

2. Problem Modeling

Mobile DTV is carried in the same RF channel as standard digital broadcast service (i.e., main A/53-compatible service) using a portion of the total 19.4 Mbps allocated for that service. Experts in broadcasting think that the most-readily conceived service will be consumer access to free and pay television programming over a mobile device [10]. That is why, in this paper, we focus on linear TV program services, either real-time broadcast or non-real-time on-demand services, in formulating the problem. This is also done within the scope of the Core Mobile Mode (CMM) defined in [2], in which mobile DTV services are transmitted while reserving a minimum of 4.7 Mbps for main A/53-compatible services. Nevertheless, experts have recently worked on extending the standard with a new mode, called Scalable Full Channel Mobile Mode (SFCMM) that scales capacity up to the total bandwidth for M/H services [11]. It is worth noting that the work done in this study can be easily extended to cover the whole bandwidth.

As mentioned before, the ATSC bandwidth portion dedicated for mobile and handheld services carries, along with service streams, forward error coding (FEC), signalling, and transport protocol overheads. The robust channel coding has to be considered as well in order to estimate the effective bandwidth available for carrying mobile data. In fact, a major part of this bandwidth is given up for signal robustness by an SCCC coding that can hoard, to the least, half of the M/H bandwidth, and, to the most, three quarters of that bandwidth.

Thus, among the main factors affecting the effective bandwidth and, hence, the service capacity are the FEC and channel coding rates, the overhead of M/H signalling, including tables similar to that of ATSC, and the overhead of transport protocols. Of course, the number of services carried in this bandwidth depends also on the quality intended for each service and which controls the service encoding bit rate. Other parameters specified in the standard, such as the frame mode and number of groups, have also an impact on the effective bandwidth, which the standard calls the payload data rate (PDR).

The interaction of all these factors and their impact on service capacity can be depicted by understanding the composition of the data frame (i.e., RS frame) that carries the IP packets of the M/H services from and to the physical layer. Before physical transmission, video and audio in ATSC-M/H are originally transported via RTP over UDP in IP packets as most of the mobile multimedia applications.

The RS frame is the basic data delivery unit into which the IP streams are encapsulated every 986 ms. Each RS frame is composed of 187 rows of bytes, Figure 1, where is primarily determined by the level of robustness (i.e., channel coding rate and RS coding) selected by the physical layer. Each row of the RS frame starts with an M/H Transmission Parameter (TP) header that includes type of network protocol, whether an error is detected or stuffing bytes are included in this row, and the offset to the start of a new IP packet. After the M/H TP header, IP packets are carried within the row of the RS frame. Each row can carry multiple IP packets and IP packets can wrap from one row to another. If data is not available to fill either the current row or the remainder of the RS frame, then stuffing bytes can be used.

Another parameter that determines the value of is the number of groups (NoG) of the M/H ensemble. In fact, the M/H data to be transmitted is packaged into a set of consecutive RS frames, where this set of RS frames logically forms an M/H ensemble. The data from each RS frame to be transmitted during a single M/H frame is split up into chunks called M/H groups and the M/H groups are organized into M/H parades, where an M/H parade carries the M/H groups from one RS frame. The maximum number of groups per parade is 8 and this number is always multiplied by 5.

PDR is the payload data rate of an RS frame and, thus, it is mainly a function of the size of an RS frame. So in its turn, the PDR also depends on the same factors, which are the level of robustness and the number of groups allocated for an ensemble. A requirement for successfully transmitting M/H services is that the PDR of the RS frame carrying these services should fit the ensemble bit rate, which is the sum of the bit rates of the services in this ensemble. However, as mentioned before, the RS frame also carries signalling tables, transport signalling packets (i.e., RTCP and NTP), and the transport protocol overhead, which is the RTP/UDP/IP headers added to the service packets before being organized in the RS frame. The study objective is to maximize the number of M/H TV services.

If we define service capacity as the number of media (in our case linear TV) services that the payload can carry, the optimization of the M/H service capacity can be described as the maximization of the number of M/H TV services Nc per ensemble. However, this was done by optimizing the media bit rate as well to ensure the best media quality for a given number of services. This objective was realized to be subject to several constraints that needed to be met, namely, the media bit rate constraint , the PDR that has to fit not only the TV service bit rates, but also all the signalling overheads, and the RS frame size (consequently the PDR) defined by the required signal robustness level, that is, the RS code and the channel coding rate.

Mathematically, the problem can be formulated as follows:

In the optimization problem (1), the optimization variables are the number of services Nc and the service bit rate . The first constraint depicts that the number of services is limited by the PDR and the overhead of signalling and transport. In other words, the PDR has to fit different types of overhead in addition to the media bit rates. and are the IP video and audio bit rates, respectively, of media service . These rates include the overhead of IP/UDP/RTP headers added to media data packets. is the fixed overhead per RS frame, consisting of the NTP packet and the fixed part of M/H signaling tables. is the overhead added with each M/H service , which includes extra information added for each service to the signaling tables and RTCP packets for each IP stream. The service bit rate variation is also reflected in this constraint. It is worth noting that although the video and audio service components are encoded at constant bit rates, a 10% range of bit rate fluctuation was usually observed. Accounting for this variation is important, since any overflow will result in packet loss at the receiver and service display interruption. Although researchers in [12] had recently proposed a buffering technique in the implementation of the transmitter to absorb this overflow, we saw that it is better to account for it, since it was not yet adopted by the standard.

The second constraint concerns the bit rate of video stream. The standard specifies that AVC video compression should conform to the baseline profile of AVC video at level 1.3 [4]. According to the AVC compression standard [13], 768 kbps is the maximum encoding bit rate at this level. It is worth noting that the standard has been lately amended to optionally support the main profile. is the overhead percentage that needs to be added to encoding bit rate to account for IP/UDP/RTP headers.

The RS frame carries a column of 2-byte width for M/H TP headers. That is, a TP header of 2 bytes is always present for each row. This reduces the payload size available for service data to bytes. That is why, in our optimization problem, payload data rate is called PDReff (i.e., effective PDR) to reflect a payload without TP headers. The PDR, as defined in [2], is the total payload bits per second of the M/H multiplex, having in its numerator the RS frame size. Thus, the third constraint depicts the PDReff with the effective payload size (i.e., . The PDR is also function of the parade repetition cycle (PRC), which is the frequency of transmission of the parade carrying the ensemble. This parade is transmitted in one M/H frame per PRC M/H frames. To follow the study objective, a parade needs to get the maximum possible bandwidth to give a best service quality. Thus, the PRC is set to 1; that is, the parade containing the designated ensemble is transmitted in every M/H frame.

As represented by the fourth constraint, other parameters determine , the number of RS frame columns. is a function of the number of groups per M/H subframe (NoG), the number of SCCC payload bytes per a group (PL), and the number of RS parity bytes per RS frame column () [2]. The NoG allocated for a parade depends on the bit rate required for transmitting the services of the ensemble carried by this parade. It should be selected so that the PDReff fits the ensemble data rate. To make best use of the PDReff and, hence, maximize service capacity, NoG was set to 8, which is the maximum number of groups per subframe for a parade.

PL is also called RS frame Portion Length. It depends on the RS frame mode, the SCCC block mode, and the SCCC outer code mode. The frame mode determines whether one or two RS frames are carried in the parade. A single frame mode means that there is only a primary RS frame for the parade carrying a primary M/H ensemble, while a dual frame mode indicates a primary frame and a secondary frame for the same parade carrying a primary and a secondary ensemble, respectively. The dual mode is only used in case a service has basic and enhanced components (e.g., service encoded with scalable video coding (SVC)), which means a different level of error correction is assigned to each component. It was recommended in the standard [3] to assume that receivers deployed in the initial M/H market have only the ability to decode single mode frames and, thus, to restrict each service to a single ensemble for initial M/H broadcasts.

As PL is the FEC redundancy bytes per group, another two important parameters determine its value: the SCCC block mode and outer code rate. The block processor of the M/H transmission system processes an M/H group into SCCC blocks that are mapped to 10 M/H blocks. The M/H blocks are divided into four sets called group regions (, , , ). The processor has two SCCC block modes: separate and paired. In case of separate SCCC block mode, the SCCC outer code rate is set independently for each group region. Each region (, , , or ) may have either 1/2 or 1/4 code rate. This makes 16 combinations. However, if the block mode is paired, then the SCCC outer code rate is identical for all group regions; and therefore is given by either the all 1/2 rate case or the all 1/4 rate case. That is, the code rate combinations of the paired block mode are a subset of the code rate combinations of the separate block mode.

The fifth constraint represents PL as a function of the code rates of the four group regions , , , and , respectively. The code rate of each region can be either 1/2 or 1/4. Depending on the combination of code rates, PL takes specific integer values that can be found in [2].

is the number of RS parity bytes per RS frame column. The RS () coding encodes the 187 bytes (column size) into one of three options: 211, 223, or 235 bytes. That is, RS encoding is performed for each of the -columns of the RS frame payload and the RS parity bytes () are added at the bottom of each column. Thus, can take one of three values: 24, 36, or 48 (bytes). The higher the , the smaller the RS frame size.

It is worth noting that there is a tradeoff between payload size and robustness. Low code rate and high parity bytes mean highly robust signal; however, at the expenses of low data rate.

The optimization problem in (1) has continuous variables, namely the number of services and the service bit rate, and discrete variables such as PL, , that take specific values. Also, some constraints are nonlinear. Thus, it is a Mixed Integer Nonlinear Programming (MINLP) problem. MINLP refers to mathematical programming with continuous and discrete variables and nonlinearities in the objective function or/and constraints. MINLP problems are precisely so difficult to solve, because they combine all the difficulties of both of their subclasses: the combinatorial nature of mixed integer programs (MIP) and the difficulty in solving nonlinear programs (NLP). Subclasses MIP and NLP are among the class of theoretically difficult problems (NP complete).

Nevertheless, in constrained optimization, the general aim is to transform the problem into an easier subproblem that can then be solved and used as the basis of an iterative search process. In fact, one of the most successful methods for solving MINLP problems is branch and bound [14]. It is a general framework for solving integer and combinatorial problems. The combinatorial part of the problem (determining the optimal integer assignment) is solved by a tree search in which nonlinear problems of the MINLP problem are solved and noninteger solutions are eliminated by adding simple bounds (branching). By using lower and upper bounds it is possible to limit the tree search, thus avoiding complete enumeration.

Thus, the problem in (1) was solved using a branch-and-bound algorithm that searched a tree whose nodes correspond to continuous nonlinearly-constrained optimization problems. In each nonlinear problem (node), the integer variables ( and PL) were fixed according to the branch assignment. The nonlinear problems were solved using Sequential Quadratic Programming (SQP). SQP methods represent the state of the art in nonlinear programming methods. The author of [15] implemented and tested a version that outperformed every other tested method in terms of efficiency, accuracy, and percentage of successful solutions, over a large number of test problems.

The method mimics Newton’s method for constrained optimization just as is done for unconstrained optimization. At each major iteration, an approximation is made of the Hessian of the Lagrangian function using a quasi-Newton updating method. This is then used to generate a quadratic programming (QP) subproblem whose solution is used to form a search direction for a line search procedure [16, 17]. The approximation of the Hessian matrix can be updated by any of the quasi-Newton methods. The Broyden-Fletcher-Goldfarb-Shanno (BFGS) method was used as it is considered the most popular [18].

It is worth noting that a nonlinearly-constrained problem can often be solved in fewer iterations than an unconstrained problem using SQP. One of the reasons for this is that, because of limits on the feasible area, the optimizer can make informed decisions regarding directions of search and step length.

3. Results

In order to solve the above problem, the model needs to be fed with adequate values of the parameters included in the constraints. These values were based on statistics collected form real traces, generated by an ATSC M/H signal generator and validated by the analysis of the received RS frames and in-carried services. Figure 2 shows a layout of an RS frame payload as organized by the M/H signal generator. The explanation of the content is provided below as needed.

As is the fixed overhead per RS frame, it consists of the fixed part of M/H signaling tables and the NTP packet. The A/153 part 3 defined the MH service signaling tables carried in each MH ensemble. They include the service map table (SMT), the guide access table (GAT), the service labeling table (SLT), the cell information table (CIT), and the rating region table (RRT). The CIT is only useful for a multifrequency network environment, so the user would be able to continue watching the same service when traveling between different coverage areas. The GAT is supposed to be transmitted every minute. RRT is much less frequent, required one time per hour. If we consider that one M/H frame spans 968 ms (~1 second), the overhead of CIT, GAT, and RRT may be negligible. The SMT and SLT delivery is more frequent though. SLT must be delivered at least once per M/H frame, while SMT must be included for the designated ensemble at least once every RS frame. So only the overhead of SMT and SLT was considered. The fixed overhead, which corresponded to the size of the tables without any service specific information, was 75 bytes.

According to the standard and the recommended practice, an NTP packet should be sent for each service in each RS frame. However, if we assume that the services of each ensemble are generated by the same encoder to fill an RS frame, one NTP packet per RS frame would be enough to designate the same timestamp for these services. In other words, all the IP streams in this RS frame would have the same local clock. The NTP packet size is normally 88 bytes.

is the overhead added with each M/H service . This includes specific information added for each service to the signaling tables in addition to RTCP packets for each IP stream. The linear TV services, which were the main services considered in the study, have two components representing an IP video stream and an IP audio stream per each service. Based on this, each TV service added 72 bytes to SMT and 15 bytes to SLT. In addition, two RTCP packets, one for each component, were included for each service. One RTCP packet per service component is supposed to be sent in every RS frame, as suggested by the recommended practice. An RTCP packet usually has a size of 80 bytes. These overheads were converted into percentage using the payload size of each test case.

The standard did not specify video or audio encoding bit rates. Since the video bit rate is considerably higher than the audio bit rate, the service bit rate mainly depended on the encoding rate of the video component. A HE-AAC v2 audio component of 40 kbps [9] was a reasonable compromise for good quality audio of an MH TV service. Thus, was set to 48 Kbps, which includes the overhead of IP/UDP/RTP headers wrapping the audio packets. Hence, the service bit rate varied solely due to change in video encoding rate.

is the overhead percentage that needs to be added to video encoding bit rate to account for IP/UDP/RTP headers. By analyzing several traces generated by different encoders with different bit rates, the percentage was found to have a mean value of 4%, with a confidence interval of ±0.15%. For simplicity, we fed the model with the mean value (4%) as the IP/UDP/RTP overhead.

As the standard did not recommend encoding bit rate(s) for video components, several companies and organizations have been testing different bit rates. The best study to which we had referred was [19], which was also well accepted in NAB 2010. Bit rates were selected based on the study in [19].

Although bit rates from 0 to 768 Kbps were considered in the problem solving, the results focused on bit rates starting from 230 Kbps, which corresponded to the lowest rate for fair quality and for 50% of viewer acceptability.

As stated before, to maximize service capacity, NoG was set to 8, which is the maximum number of groups per subframe for a parade. The integer parameters (PL and ) were assigned values according to [2], as mentioned in the previous section. Since the total number of groups to be transmitted for the next M/H Frame is 16 [2], TV services can span 2 parades carrying 8 groups each. However, a service should not be split over 2 ensembles unless it is coded in different components and, thus, needs a secondary ensemble. The number of TV services in the results is reported per parade; however, they may be doubled as explained.

The platform used for simulation was Matlab. The optimization problem has linear constraints whose complexity is of as well as nonlinear constraints. The nonlinear ones are of low order of complexity, ). As the number of groups was fixed to maximize the number of services, and the variables , PL, and PRC had limited number of discrete values, the complexity of simulating the nonlinear constraints became of , which made the complexity of simulations lower than the one of the proposed algorithm.

The results gave the maximum number of TV services with respect to the service bit rate at different robustness levels. For illustration purposes, the results of only 8 robustness levels are shown in Figure 3. It is worth noting that all the services were assumed to have the same bit rate, for a certain maximum number of services. The plotted service bit rate is the one expected at the IP layer; that is, it includes all the overhead of all the upper layers and the audio component as well.

Although the maximum encoding bit rates of level 1.3 is 768 kbps, the curves of Figure 3 present the highest encoding bit rate that a TV service can have for a given number of TV services per ensemble. The increase in service bit rate was mainly attributed to video component, since the audio bit rate was sufficient for good quality. The increase goes beyond the encoding level limit reflected in the second constraint; however, it is presented for the sake of illustrating to what extent the encoding bit rate can be stretched to fill the RS frame and the corresponding video quality. Bit rates up to 1500 Kbps are plotted.

Figure 3 shows, using dotted lines, the video quality range corresponding to the service bit rate. The first one is the poor-fair range, which, in this case, represents mainly fair quality that is closed to poor, since, as mentioned above, the bit rates were chosen so that video quality remained in fair and beyond fair quality categories. The second range is fair-good, which represents fair (close to good) and good (close to fair) qualities. The last one is the good-excellent range, mainly describing good, close-to-excellent, quality. The ensemble of these quality ranges corresponds to a viewer acceptability ranging from 50 to 95% [19].

All the curves take an exponential decay shape, suggesting an important effect of low service bit rates on the maximum number of TV services per ensemble, versus a lessened effect as the service bit rate rose.

The biggest capacity, representing the highest maximum number of TV services per parade, was achieved with services providing fair video quality. This capacity can be up to 9 services per parade if the least robust link can be tolerated. It goes down to 4 mobile TV services having fair video quality if the highest link robustness is required.

Most of the change in service capacity occurred within the range of service bit rates providing fair-good quality, which is almost 500 Kbps wide. Indeed, as the service bit rate increased in this video quality range, the maximum number of services per parade dropped considerably. At the end of this range, the service capacity of the most robust MH signal would have 3 services in less than what was spotted at the beginning of the quality range. This difference in capacity went to 4 services in less for the least error-protected signal.

Increasing service bit rate above a certain level did not considerably affect service capacity. For code rates starting with 1/2 1/2, increasing bit rates, bringing further good-excellent video quality, did not change the maximum number of services, which remained at 2. For robust code rates starting with 1/4 1/4, the same behaviour was observed for lower bit rates corresponding to good video quality. The number of services was floored to 1 for a wide range of bit rates spanning both good and good-excellent qualities.

If high signal robustness levels are targeted, good-excellent video quality will only be possible if broadcasters are comfortable with transmitting one service per ensemble. However, increasing this service bit rate to span the entire frame does not bring considerable quality advantage. Hence, if the bit rate is limited to the boundary of good-excellent video quality, a considerable part of RS frame will be stuffed with null bytes or could be used by other types of services.

Figure 4 shows the maximum number of MH TV services per parade in function of service bit rates that maximize the quality, around this bit rate, and above which the quality of the received video does not undergo noticeable enhancement. These service bit rates do not necessarily fill the whole available payload space. Thus, any remaining space of the RS frame, that is not enough for carrying an extra TV service of the same bit rate, will be filled with packets of other services, such as file transfer, or simply with null bytes. The number of services in Figure 4 is plotted for different robustness levels including four SCCC code rates and two RS codes.

Figure 4(a) illustrates results for RS code of 24. It can be seen that SCCC code rates having 1/2 in regions and gave the highest number of services. Code rates starting with 1/2 1/2 gave the same number of services, for IP service bit rate between 400 and 700 Kbps. However, a robustness code rate of 1/2 1/2 1/4 1/4 allowed one service in less compared to the least robust code (1/2 1/2 1/2 1/2) when service bit rate fell below (i.e., less than 400 Kbps) or above (i.e., more than 700 Kbps) this range.

The same number of services was achieved for code rates having 1/4 in regions and , when service bit rate was above 450 Kbps. Lower service rates gave an advantage of one extra TV service to 1/4 1/4 1/2 1/2 code rate, which offered more payload space than the most robust code rate (i.e., 1/4 1/4 1/4 1/4).

The results of 48 RS parity bytes are illustrated in Figure 4(b). Contrary to what was found with , the number of services achieved with codes rates starting with 1/2 1/2 were the same when service rates fell outside the 400–700 Kbps range. However, with the all 1/2 code rate, one more TV service could be carried, compared to 1/2 1/2 1/4 1/4 code rate, when service rates fell within this range.

Nevertheless, the same behavior, as the one observed with , was found for code rates starting with 1/4 1/4. In fact, the same number of services was obtained for IP service bit rates higher than 450 Kbps. It is worth noting that, at the lowest service rate (corresponding to the fair video quality boundary), the service capacity was similar for both 24 and 48 parity bytes and limited to 4 services when using these robust code rates.

In general, service capacity dropped to half when regions and had 1/4 code rate, compared to the number of services expected when a 1/2 code rate could be tolerated in these two regions. Moreover, the RS code had lower effect on service capacity than that of SCCC outer code rate. The parity bytes effect on number of services was mainly spotted when accompanied with less robust code rates starting with 1/2 1/2. This was when the service capacity decreased by one as the parity bytes increased from 24 to 48.

This suggests that the main player in service capacity is the SCCC outer code rates. At the most robustness level, the effect of is almost negligible on the maximum number of services a parade can carry. That is, as code rates start with more 1/4’s, the maximum service capacity does not notably change with the variation of Reed-Solomon coding for all video quality ranges.

As mentioned above, the TV services may not fill the whole RS frame. And as described, increasing the service bit rate to span the unused space does not improve the video quality. This unused part of RS frame may represent a negligible percentage as it can be a considerable amount.

The standard suggested filling the RS frame space with TV service data. However, the results of Figures 3 and 4 suggest that filling the space, by increasing service bit rate beyond certain limits, does not bring noticeable enhancement to the service quality. Thus, the proposed algorithm sets optimal options for sending mobile TV services. These options, shown in Figures 3 and 4, optimize the space of RS frame, not only by maximizing the number of services, but also by using service bit rates that maximize the quality within a quality range while not filling the space with unnecessary packets. Thus, the unused space would be available for sending other services, mainly, non-real-time objects. The following results, presented in Figure 5 as explained in details below, show that the unused space could attain a considerable percentage that would be exploited by parallel services. These services will be transmitted without the need of extra bandwidth, as would be the case if the conventional method of filling the frame is followed.

Figure 5 shows the percentage of data payload that is expected not to be exploited by the MH TV services, in function of the service bit rate and given that the maximum service capacity is attained at this service bit rate. The percentage is plotted when four different code rates are applied and for two RS codes.

The shape of the curves is quite interesting, suggesting that some service bit rates resulted in very small unused payload while others highly raised this unexploited portion. Moreover, the values of these service bit rates differed according to the robustness level of the signal.

In fact, the relation took the form of oscillations that became stronger as the service bit rate increased. This may be attributed to the fact that, as the service rate increased, the number of services that could be stacked in the RS frame decreased. Hence, any small increase in the service bit rate may reduce the number of services by one, leaving a considerable unoccupied space.

With code rates having 1/2 in regions and , the percentage of unused payload showed lower-pitched fluctuation than what was found with code rates starting with 1/4. This is due to the fact that the service capacity, when lower code rates are used in regions and , is almost the double of that when the same regions have 1/4 rates.

In fair (close to poor) video quality range, the potential unused payload, for code rates starting with 1/4 and with 24 parity bytes, experienced two peaks: 18% and 24% at service bit rates of 280 Kbps and 320 Kbps, respectively. With 48 parity bytes, for the same code rates, these peaks were observed at 240 Kbps and 300 Kbps.

In fair-good video quality range, the percentage value of the peaks went above 30% with service bit rates ranging from 400–550 Kbps, and it approached 50% at 600 Kbps and up, in case of robust signals coded with 1/4 in regions and .

Either in fair or good quality range, for code rates starting with 1/2, the maximum percentage of unused PDR did not attain the same high values reached with code rates starting by 1/4. However, it may attain 24% at service bit rates around 600 Kbps.

It is worth noting that the RS coding did not affect the percentage of unused PDR. However, the service bit rates, at which the highest percentage values were observed, changed depending on the number of parity bytes. That is, the same percentage peaks can be obtained with lower service rate when using higher RS parity bytes.

The nonexploited payload space can be used to carry data for other mobile services, such as non-real-time (NRT) services or triggered downloadable objects (TDOs). In case that the space was filled with stuffing bytes, it can be used for iterative decoding. In fact, since the location of the stuffing bytes is known a priori to be usually carried at the end of the RS frame, a cross-layer iterative channel decoding may benefit from these bytes to improve error correction capability [20].

The amount of stuffed (unexploited) space may be important and, hence, may increase the robustness of the signal when coded with less robust code rates such as all 1/2 rate (1/2 1/2 1/2 1/2). At this code rate, up to 12% of unused PDR can be obtained for fair video quality services and up to 24% in good video quality range.

In fact, the results of Figures 4 and 5 illustrate how to get an optimal tradeoff between service capacity and the available proportion of the RS frame that can be used for other purposes, including NRT services and the iterative decoding. In a certain video quality range, an optimal balance can be achieved between the number of services and the amount of stuffing bytes that can be granted to NRT services and TDOs transmission. Another alternative would be to use the stuffing bytes to augment the effectiveness of iterative decoding in increasing the channel robustness.

4. Conclusion

The study in this paper formulated and solved the service capacity problem for ATSC mobile DTV system. The problem solution succeeded in optimizing mobile DTV service capacity, by maximizing the number of TV services without compromising the service quality. The paper presented tradeoffs between service capacity, TV quality, and signal robustness, which are important for designing Mobile TV broadcasting scenarios. The optimization technique was also found to be an effective method of tracking the unused payload space, without affecting service quality and capacity. Broadcasters may benefit from this space, which might be exploited by other services or used to increase the effectiveness of new iterative decoding techniques.