a r X i v :0704.3228v 2 [c s .N I ] 17 J u l 2007
Technical Report v2
Characterization of P2P IPTV Tra?c:
Scaling Analysis
Thomas Silverston,Olivier Fourmaux and Kav′e Salamatian
Universit′e Pierre et Marie Curie -Paris VI Laboratoire LIP6/CNRS,UMR 7606
104avenue du pr′e sident Kennedy 75016Paris,France
Email:{thomas.silverston,olivier.fourmaux,kave.salamatian }@lip6.fr
Abstract
P2P IPTV applications arise on the Internet and will be massively used in the future.It is expected that P2P IPTV will contribute to increase the overall Internet tra?c.In this context,it is important to measure the impact of P2P IPTV on the networks and to characterize this tra?c.Dur-ing the 2006FIF A World Cup,we performed an extensive measurement campaign.We measured network tra?c generated by broadcasting soc-cer games by the most popular P2P IPTV applications,namely PPLive,PPStream,SOPCast and TVAnts.From the collected data,we charac-terized the P2P IPTV tra?c structure at di?erent time scales by using wavelet based transform method.To the best of our knowledge,this is the ?rst work,which presents a complete multiscale analysis of the P2P IPTV tra?c.
Our results show that the scaling properties of the TCP tra?c present periodic behavior whereas the UDP tra?c is stationary and lead to long-range depedency characteristics.For all the applications,the download tra?c has di?erent characteristics than the upload tra?c.The signaling tra?c has a signi?cant impact on the download tra?c but it has negligible impact on the upload.Both sides of the tra?c and its granularity has to be taken into account to design accurate P2P IPTV tra?c models.
1Introduction
P2P live streaming applications like P2P IPTV are emerging on the Internet and will be massively used in the future.The P2P tra?c counts already for a large part of the Internet tra?c and this is mainly due to P2P ?le-sharing applications as BitTorrent [1]or eDonkey [2].Video streaming services like Youtube [3]appeared only a few months ago but contribute already to an im-portant part of the Internet tra?c.It is expected that P2P IPTV will largely
1
contribute to increase the overall Internet tra?c.It is therefore important to study P2P IPTV tra?c and to characterize its properties.
The characterization of P2P IPTV tra?c will allow us to understand its impact on the network.P2P IPTV applications have stringent QoS constraints (e.g.bandwidth,delay,jitter)and their tra?c characterization will enable to understand their exact needs in network resources.The knowledge of the tra?c properties enables the development of synthetic tra?c generation models that are key input parameters when modeling or simulating these systems.Indeed, the modeling or simulating steps are necessary to design judiciously applica-tions.From a tra?c engineering point of view,well understanding P2P IPTV tra?c is essential for Internet service providers to forecast their internal traf-?c and ensure a good provisioning of their network.And last but not least, global knowledge of the tra?c properties will highlight some drawbacks of the applications and will make it possible to improve the design of new P2P IPTV architectures.For instance,an important concern of these systems is the scal-ability.The tra?c characterization may help estimate the impact of overhead tra?c generated by the signaling.
In this paper,we present a multiscale analysis of the structure of the traf-?c generated by the most popular P2P IPTV applications,namely PPLive[4], PPStream[5],SOPCast[6]and TVAnts[7].
During the2006FIFA World Cup,we performed an extensive measurement campaign.We measured the network tra?c generated by broadcasting soccer games by the previously mentioned applications.The multiscale behavior of the collected tra?c is analyzed using a wavelet transform based tool.In this paper,we characterize the network tra?c of P2P IPTV systems at di?erent time scales and compare their properties.To the best of our knowledge,this is the?rst work that does a comparative multiscale characterization of P2P IPTV tra?c.
Our multiscale P2P IPTV tra?c analysis shows signi?cant di?erences in the scaling behaviors of TCP and UDP tra?c.the TCP tra?c presents periodic behavior while the UDP tra?c is stationary and presents long-range dependency characteristics,which will a?ect the quality of the video reception.The signaling tra?c has an impact on the download tra?c but it has negligible impact on the upload tra?c.The upload tra?c generated by P2P IPTV systems have di?erent scaling characteristics compare to the download tra?c and both sides of the tra?c has to be taken into account to design judiciously P2P IPTV tra?c models.Moreover,the tra?c granularity has to be considered while using tra?c models to simulate these systems.
The rest of the paper is organized as follows.Firstly,we present the related work in section2.In section3,we give an overview of the measured applications and describe our measurement experiment setup.In section4,we present our methodology to analyze the tra?c at di?erent time scales.We present our P2P IPTV tra?c analysis in section5and discuss the results in section6.Finally,
2
we conclude the paper and give perspectives in section7.
2Related Work
Nowadays,an increasing number of P2P IPTV measurement studies is con-ducted to analyze the mechanisms of such systems.
Zhang et.al[8]present the?rst measurement results about their protocol Donet[9],which were deployed on the Internet and called Coolstreaming.They provide network statistics,like user’s behavior in the whole system and the qual-ity of video reception.
Hei et al.[10][11]made a complete measurement of the popular PPLive appli-cation.They made active measurements by instrumentalizing their own crawler and give many architecture and overlay details like bu?er size or number of peers in the networks.Vu et al.[12]made also active measurements of the PPLive system and derive mathematical models for the distributions of channel population size or session length.
In our previous work[13],we passively measured the network tra?c generated by several popular applications during a worldwide event.We compared the measured applications by inferring their underlying mechanisms and highlight their design di?erences and similarities.Ali et al.[14]made passive measure-ments of PPLive and SOPCast applications and analyze the performance and characteristics of such systems.
Still in their previously mentioned works,Ali et al.provide their own method-ology to study the data exchanges of such P2P applications.Based on their measurement studies,Hei et al.[15]developed also a methodology to estimate the overall perceived video quality throughout the network.
All these works studied P2P IPTV systems by measuring the tra?c and tried to infer their mechanisms,but they did not characterize the correlation structure of the generated tra?c at di?erent time scales to understand its properties and its impact on the network.
3Experiments
3.1P2P IPTV applications overview
For our P2P IPTV tra?c measurement experiments,we chose four applications, namely PPLive,PPStream,SOPCast and TVAnts because they were very pop-ular on the Internet.Whenever these applications are freely available,their source codes are not open and their exact implementation details and used pro-tocols are still widely unknown.We can only rely on reverse engineering to understand their transmission mechanisms.
All these applications claim to use swarming protocol like Donet.Similarly to BitTorrent,video data?ows are divided into data chunks and each peer down-loads the chunck of data to other peers concurrently.The peers know how to
3
Figure1:Measurement experiments platform.Each node is a common PC directly connected to the Internet via campus network.
Table1:Packet traces summary
PPStream TVAnts
13,32112,198
Size(MB)4,1213,992
Download(%)20.5024.76
14.090.23
UDP010.05
Upload(%)79.5075.24
85.81 3.89
UDP013.57
download the video data chunks by exchanging randomly with other peers in-formation about the data chunks they have or neighbor peers they know.With this signaling tra?c,each peer discovers iteratively new peers,new available data chunks and is able to download video from several peers.In these P2P protocols,there are two kinds of tra?c:video tra?c where peers exchange data chunks with each other and signaling tra?c where peers exchange information to get the data.
As we show in[13],all the applications transport video and signaling tra?cs di?erently:PPStream uses exclusively TCP for all tra?cs while PPLive adds UDP for some signaling tra?c.SOPCast uses almost entirely UDP and TVAnts is more balanced between TCP(≈75%)and UDP for all kinds of tra?c.
In the next section,we will present the measurement experiments platform we used to collect the P2P IPTV tra?c.
3.2Measurement experiments platform
Our measurement experiments take place during the2006FIFA World Cup from09June to09July.We collected a huge amount of data,measuring most of the World Cup soccer games with di?erent applications at the same time and under di?erent network environments:campus Ethernet access and residential ADSL access.
4
In this paper,we focus on four packet traces collected on June30in our cam-pus network:one for each measured application.In all our data,we selected these packet traces because they are well representative of all of them.The traces are made available on our traces sharing service[16].Two soccer games were scheduled,one in the afternoon(Germany vs.Argentine)measured by PPStream and SOPCast and one in the evening(Italy https://www.doczj.com/doc/b016818963.html,raine)measured by PPLive and TVAnts.We selected the four traces from di?erent applications to be able to characterize the P2P IPTV tra?c without being closely related to the design of the applications.
Our measurement experiment set up is described on Fig.1.To collect the packets,we used two personal computers with1.8GHz CPU and com-mon graphic card capabilities.The operating system running on the PCs was Windows XP.The PCs(nodes)were situated in our campus network and were directly connected to the Internet with100Mbps Ethernet access.During a game,each node was running a P2P IPTV application and we used tcpdump on each measuring node to collect all the packets.For all the measurement experi-ments,the consumed bandwidth was always relatively low and does not exceed 10Mbps.The Ethernet cards did not su?er any packet loss and captured all the packets.For all the experiments,nodes were watching CCTV5,a Chinese TV channel available for all the measured applications.It was important to watch the same TV channel with all the applications to assure that the behavior of users will be similar in each trace.For example,during the advertisement,what-ever the applications,an user may stop watching the channel and switches the application o?and then switch it on a few minutes later.All the applications used MPEG4video encoding.
Our platform has high-speed access and our observations can not be directly generalized to residential peers with common access to the Internet(e.g.20/1 Mbps or512/128Kbps).However,residential network capacities are quickly increasing and will have such high-speed access in only a few years when P2P IPTV would be commonly used.
Table1summarizes the four presented traces.At?rst,we can notice in these traces that PPLive,TVAnts and PPStream use massively TCP whereas only SOPCast uses mainly UDP.The duration of the traces is longer than the duration of a soccer game(≈105minutes).We chose to collect the tra?c a few minutes before and after the games to capture all the e?ects that the live interest of a soccer game could produce on the behavior of users(e.g.?ash crowds).
5
P e r c e n t a g e o f P a c k e t s (%)
Packet size (Bytes)(a)PPLive
P e r c e n t a g e o f P a c k e t s (%)
Packet size (Bytes)
(b)SOPCast
P e r c e n t a g e o f P a c k e t s (%)
Packet size (Bytes)(c)PPStream
P e r c e n t a g e o f P a c k e t s (%)
Packet size (Bytes)
(d)TVAnts
Figure 2:Packet distributions for all the applications
4
Analysis Methodology
4.1
Video and signaling tra?cs
The packet size distributions for all the applications are presented in Fig.2.PPLive has 75%of its packets larger than 1300Bytes and the other packets are very small (≈17%are 100Bytes length).Di?erently,SOPCast counts only about 30%of large packets (>1300Bytes)and 60%of its packets are very small (<100Bytes).PPStream counts more than 40%of packets bigger than 1400Bytes,almost 40%of its packets are 100Bytes and a small part is https://www.doczj.com/doc/b016818963.html,Ants packets seems more balanced in three equal parts:one part is 100Bytes,a second part is 1100Bytes and the third part is 1400Bytes.All the packets distributions of these applications are di?erent but we can distinguish two sets of packets within these packet distributions:small-size pack-ets (<200Bytes)and large-size packets (>1000Bytes).As we explained in section 3,the studied P2P applications generate two kinds of tra?c:video and signaling.
It is expected that the video tra?c is essentially composed of large-size packets.Most of the video packets should belong to the large-size packets set (>1000Bytes).The video data are also delay sensitive since video packets have to re-6
Table2:Signaling Tra?c Ratio
PPStream TVAnts
4.1%19.3%
Upload10.8%7.8%
19.2%48.5%
4.3Validation of the signaling heuristic
The measured applications are proprietary and we do not have any implemen-tation detail.We do not know exactly if a packet is for signaling tra?c or video tra?c.The heuristic used to?lter the signaling tra?c relies mainly on the packet size.The heuristic will perform well if it removes only signaling packets without removing any part of the video tra?c.
From Table2,we notice that the download signaling tra?c ratio computed by the heuristic for SOPCast is48.5%,which is a high ratio indicating that half of the tra?c would have been signaling tra?c.This high ratio of download signaling tra?c may eventually come from the inaccuracy of the heuristic.
To validate the?ltering heuristic,we compute the resulting video bitrate after removing the signaling tra?c.Realistic computed video bitrate will con-?rm the e?ciency of the heuristic.We compute the video bitrate for download tra?c because it is the only video tra?c we can deduce.The download tra?c is provided by other peers on the Internet and all the video?ows received by our controlled nodes compose the downloaded video.The video upload tra?c is not provided to a single consumer peer.We can not estimate the video bi-trate received by remote peers because they mix video?ows from many other providers peers to receive the entire video.In the following,we compute for all the traces the video download bitrate received by our controlled nodes by removing signaling tra?c with the presented heuristic.
Fig.2(b)indicates that SOPCast has more than60%of its packets smaller than100Bytes.These packet are certainly signaling packets according to their size.The design of SOPCast introduces a large amount of signaling packets and the heuristic removes these packets from the video tra?c.
Table1shows that the SOPCast download tra?c represents16.13%of the collected tra?c(5,475MBytes)and the download signaling ratio represents 48.5%of the overall download tra?c.The average bandwidth used by SOPCast to download the video at its bitrate can be computed by dividing the amount of received video data by the measurement experiment duration(12,198s).
(5475?220?8?0.1613)?(1?0.485)
Table3:Video Download Bitrate computed with the signaling?ltering heuristic
PPStream TVAnts
445305/360
For all the produced logscale diagrams,the X-axes are the octaves of the tra?c, which are the time scales of the packet arrivals.The right-most part of the graph is relative to large time scales and the left part is relative to small time scales.The Y-axes are the data energy spectra.A logscale diagram can be understood as follows:an octave j(X-axes)is a time scale of the packet tra?c energy spectrum.Since our bin is20ms,the octave j=8means the time scale t=28?20ms=5.12s.
LDEstimate is a tool that allow to visually observed the properties of the mea-sured tra?c.In a produced diagram,a bump in the energy spectrum indicates a possible periodic behavior of the tra?c,a constant energy spectrum a pos-sible memoryless process and a linear increase indicates a possible long-range dependency of the tra?c(LRD).
5Results Analysis
5.1Presentation
In the rest of the paper,we will refer to the tra?c trace of an application by the name of the application.For example,we will refer to SOPCast packet trace by SOPCast.
For each application,we study the tra?c by separating the upload tra?c and the download tra?c.In both tra?c directions,we separated the video tra?c from the overall tra?c by using the?ltering heuristic presented in section4.2.Then, each application is characterized by four distinct logscale diagrams:overall up-load tra?c,video upload tra?c,overall download tra?c and video download tra?c.Fig.3presents the logscale diagrams of the energy spectra for PPLive, Fig.4the energy spectra for SOPCast,Fig.5for PPStream and Fig.6for TVAnts.
Table1indicated previously that three of the measured applications use massively TCP(PPLive,PPStream and TVAnts)whereas only SOPCast uses mainly UDP.We will refer to an application using massively TCP as TCP ap-plication and UDP application for an application using UDP.
In the following,we will present tra?c di?erences between TCP and UDP applications in section5.2.In section5.3we will highlight the impact of the signaling tra?c for P2P IPTV applications.Then we discuss the stationnarity of the tra?c in section5.4.We will extend our?ndings in section5.5.The results are summarized and discussed in section6.
5.2TCP applications vs.UDP applications
For the TCP applications(PPLive,PPStream and TVAnts),the two upload energy spectra look similar for all the time scales(Fig.3(a)and3(b),Fig.5(a) and5(b),Fig.6(a)and6(b))The two download energy spectra look similar
10
(a)Upload:overall packet tra?c(signaling and video tra?c)
(b)Upload:video packet tra?c
(c)Download:overall packet tra?c(signaling and video tra?c)
(d)Download:video packet tra?c
Figure3:PPlive packet tra?cs energy spectra.Bin duration is20ms.(Ex: Octave j=8is for scale process at t=28?20ms=5.12s).
until j=9and after they are di?erent(Fig.3(c)and3(d),Fig.5(c)and5(d), Fig.6(c)and6(d)).The upload energy spectra of TCP applications(3(a)and 3(b),5(a)and5(b),6(a)and6(b))do not look like their download energy spec-tra(3(c)and3(d),5(c)and5(d),(6(c)and6(d)).
All the TCP applications have similar energy spectra whatever the kind of tra?c and direction(e.g.overall or video).The observations for TCP applications may be generalized for all of those we measured(PPLive,PPStream and TVAnts). For UDP applications(SOPCast Fig.4),the four energy spectra look similar whatever the tra?c direction or the tra?c nature(e.g.overall or video tra?cs). The energy spectra of TCP applications(Fig.3,5and6)are di?erent from the energy spectra of UDP applications(Fig.4).
Regarding TCP applications energy spectra more precisely,we can observe an energy bump in all the logscale diagrams about time scale j=8(5.12s). The energy bump is more clearly de?ned in upload tra?c(Fig.3(a)and3(b),
11
(a)Upload:overall packet tra?c(signaling and video tra?c)
(b)Upload:video packet tra?c
(c)Download:overall packet tra?c(signaling and video
tra?c)
(d)Download:video packet tra?c
Figure4:SOPCast packet tra?cs energy spectra.Bin duration is20ms.(Ex: Octave j=8is for scale process at t=28?20ms=5.12s).
Fig.5(a)and5(b),Fig.6(a)and6(b))than download tra?c(Fig.3(c)and3(d), Fig.5(c)and5(d),Fig.6(c)and6(d)).
The energy bump exists for all the applications using mostly TCP.The energy bump indicates a possible periodic behavior at these time scales whatever the tra?c direction or its nature.The energy bump phenomenon has to be con-?rmed by studying the stationnarity of the tra?c.We study tra?c stationnarity in section5.4.However,the stationnarity analysis shows that the energy bumps observed in the spectra are essential phenomena and not simply artifact coming from non-stationnarity.
The energy bumps are observed for all the TCP applications but not for the UDP applications.The well known TCP mechanisms used to transport data and TCP retransmission mechanisms could lead to such periodic tra?c behav-iors.However,the periodic behaviors are observed for time scale j=8(5.12s). A5seconds duration is a very long duration for TCP mechanisms.It is not so obvious that this periodic behavior is provided by TCP mechanisms.
12
(a)Upload:overall packet tra?c(signaling and video tra?c)
(b)Upload:video packet tra?c
(c)Download:overall packet tra?c(signaling and video tra?c)
(d)Download:video packet tra?c
Figure5:PPStream packet tra?cs energy spectra.Bin duration is20ms.(Ex: Octave j=8is for scale process at t=28?20ms=5.12s).
The periodic behaviors could also come from the video broadcasted in the net-work.However,SOPCast does not show any energy bump in its energy spectra and SOPCast broadcasts also video in the network.
Currently,we can not surely establish the source of these periodic behaviors.It does not seem to come from TCP mechanisms nor broadcasted video.We are still investigating the periodic behavior we observed in the TCP applications energy spectra.
The energy bumps are characteristics shared by all the measured applications using massively TCP.They illustrate how the application design may impact the properties of the generated network tra?c.
13
(a)Upload:overall packet tra?c (signaling and video tra?c)
(b)Upload:video packet
tra?c
(c)Download:overall packet tra?c (signaling
and video tra?c)
(d)Download:video packet tra?c
Figure 6:TVAnts packet tra?cs energy spectra.Bin duration is 20ms.(Ex:Octave j =8is for scale process at t =28?20ms =5.12s ).
5.3Impact of the signaling tra?c
For all the applications,whatever the transport protocol they use,their video upload energy spectra look like their overall upload energy spectra.This is illustrated on Fig.3(a)and 3(b),4(a)and 4(b),5(a)and 5(b),6(a)and 6(b).Removing the signaling tra?c has no impact on the upload tra?c.
Regarding the download tra?c,the video download energy spectra (Fig.3(d)4(d)5(d)and 6(d))are di?erent from their corresponding overall download en-ergy spectra (Fig.3(c)4(c)5(c)and 6(c)).Removing signaling tra?c from the download tra?c has clearly an impact on the download tra?c because it mod-i?es the download energy spectra.
Table 2shows the signaling tra?c ratio for all the applications in upload and download.For all the applications,the signaling tra?c represents a larger part in the download tra?c than the upload tra?c.
The upload signaling tra?c is only provided by our controlled node to other
14
peers in the Internet.Since our node has high bandwidth capabilities,it serves video to many other peers.Table1indicates that the amount of upload tra?c is3to6times larger than the amount of download tra?c.The signaling tra?c sent by our node to other peers in the Internet counts only for a small part of the overall upload tra?c.
The download signaling tra?c is provided by other peers in the Internet to our controlled node.Our node just needs to download the video at the video bitrate. The download signaling tra?c coming from many other peers counts for a large part of the overall download tra?c.This explains the impact of signaling tra?c on the download tra?c.
To summarize our observations,the signaling tra?c has no impact on the upload tra?c but it has an impact on the download tra?c.In the following,we will discuss the stationnarity of the tra?c that will help to better characterize the properties of the P2P IPTV signaling tra?c.
5.4Tra?c stationnarity
From all the upload energy spectra(Fig3(a)3(b),Fig4(a)4(b),Fig5(a)5(b), and Fig6(a)6(b)),we observe a linear increase,starting from j=6for SOP-Cast,from j=9for PPLive,from j=12for PPStream or j=10for TVAnts. We also show that the linear increase exists in the download tra?c(Fig.3(c) 4(c)5(c)and6(c))but it is modi?ed(Fig.4(d))or wasted(Fig.3(d)5(d)6(d)) when removing signaling tra?c.
We already show that signaling tra?c has an impact on the download tra?c because it count for a larger amount of data.The signaling tra?c may also lead to the linear increase in the download energy spectra.
A linear increase indicates a possible long-range dependency of the tra?c (LRD).It means that the tra?c?uctuates largely and is not predictable.With such tra?c?uctuations,it becomes impossible to forecast the tra?c behavior or to make network provisioning.
The signaling tra?c is used by peers to get the video chunks they need.If the signaling tra?c is responsible for LRD,the signaling tra?c generates itself the troubles to download the video.In other words,the design of the appli-cations would be not e?cient if the signaling tra?c generates the long-range dependency of the tra?c.
For a P2P network,a LRD tra?c indicates,there is no stability in the network tra?c.Then,it becomes a hard task to provide QoS parameters(delay,band-width,jiiter)to users because networks conditions are always changing. Regarding P2P IPTV systems,which are delay sensitive,the tra?c LRD has to be avoided because it will directly a?ect and decrease the quality of video reception.For example,under a high churn of peers,each peer has always to discover new peers and to establish new partnerships with other peers to receive the video data chunks.In this case,there would be no stability in the overlay
15
(a)Upload:overall packet tra?c(signaling and video tra?c)
(b)Upload:video packet tra?c
(c)Download:overall packet tra?c(signaling and video tra?c)
(d)Download:video packet tra?c
Figure7:TCP applications:PPLive.Tra?c stationarity for the three equal parts of the tra?c.The blue solid line is the?rst part,the dashed red line is the second part and the dash-dotted green line is the third part of the tra?c. network because of the disruptions in the peers connections and communica-tions.This would lead to non-predictable tra?c and long-range dependency of the tra?c.
In this section,we want to know if we really observe a long-range depen-dency of the tra?c.To this end,we study the stationnarity of the tra?c.We split each trace in three equal parts,and we used the previous wavelet transform method to analyze all the parts of the tra?c.We visually control the tra?c stability with LDEstimate.
Due to space limitations,we only present one example for TCP applications (PPLive,Fig.10)and one example for UDP application(SOPCast,Fig.11). The other TCP applications energy spectra are similar to the TCP example (Fig.10)and can be found in the appendix.
In each logscale diagram,we plot the three parts of the trace.The blue solid
16
(a)Upload:overall packet tra?c(signaling and video tra?c)
(b)Upload:video packet tra?c
(c)Download:overall packet tra?c(signaling and video tra?c)
(d)Download:video packet tra?c
Figure8:UDP applications:SOPCast.Tra?c stationarity for the three equal parts of the tra?c.The blue solid line is the?rst part,the dashed red line is the second part and the dash-dotted green line is the third part of the tra?c. line is the?rst part of the trace,the dashed red line is the second part and the green dash-dotted line is the third part of the trace.The tra?c is stationary if each part of the tra?c looks like the other parts and has the same energy level.
For TCP applications(Fig.10),the three parts of the energy spectra are similar at small time scales but become di?erent at large time scales(about j=10).There is stationnarity in the tra?c until j=10.The tra?c is not stationary beyond j=10.
As shown in section5.2,the TCP applications experiment a bump in their en-ergy spectra at time scale j=8,whatever the tra?c direction or its nature. At this time scale,the tra?c is stationary and it demonstrates that the ob-served energy bumps are essential phenomenon and not simply artifact from non-stationnarity.On the contrary,the linear increase observed from j=9is not a long-range dependency of the tra?c.
17
(a)PPLive Download:overall packet tra?c (signaling and video tra?c)
(b)PPLive Download:video packet tra?c
(c)SOPCast Download:overall packet tra?c (signaling and video
tra?c)
(d)SOPCast Download:video packet tra?c
Figure9:Top download?ows
For UDP applications(Fig.11),the three parts of the tra?c are similar and increase linearly.The tra?c of UDP applications is stationary.The linear increase characterizes a long-range dependency of the UDP applications tra?c represented by SOPCast.Removing signaling tra?c modi?es the linear increase in the SOPCast download tra?c.For UDP applications,signaling tra?c may lead the to the long-range dependency in the tra?c.
In this section,we show an important design di?erence between TCP and UDP applications.The tra?c of UDP applications is stationary and present long-range dependency whereas the tra?c of TCP applications is not stationary and does not experiments long-range dependency.
18
Table4:Top download?ows
Overall tra?c Video tra?c
Volume(MB)Volume(MB)
PPLive82,42876,797
13.2111.79
SOPCast63,05447,187
53.8652.13
We notice for the two applications that their video energy spectra look sim-ilar to their overall energy spectra.This was expected because these?ows are sent by the top contributor peers and transport almost entirely video packets and not signaling packets.Removing signaling tra?c on these?ows can only have a limited impact,depending on the signaling packets in the?ows.
For example,the top download?ow of SOPCast transport15,867packets of signaling tra?c(63054?47187)counting for2.71MBytes whereas PPLive top download?ow transport only5,731signaling packets(82428?76797)counting for0.33MBytes.
Regarding TCP applications Fig.12(a)and12(b),until time scale j=10, the energy spectra of the top?ow look similar to the aggregate tra?c.Beyond this time scale,the energy spectra of the top download?ow are di?erent from the aggregate tra?c because the energy spectra of the top?ow are increasing. With UDP applications,until time scale j=11,the energy spectra of the top ?ow are di?erent from the aggregate tra?c.Fig.12(c)and12(d)show an energy bump at time scale j=3,then the energy spectra increase slightly from j=4 to j=11.Beyond j=11,we observe the linear increase usually observed for the UDP energy spectra.
In this experiment,we observe that the top?ows in the download tra?c do not have the same scaling properties as the aggregate download tra?c.We did the same experiments for the10th top download?ows(i.e.the10th?ow according to data volume transported).The10th top?ows present the same scaling properties as the top?ows.The plots for the10th top?ows can be shown in the appendix.
The aggregate tra?c is not only the mix of every single?ow.The granularity of the P2P IPTV tra?c has to be taken into account when designing P2P IPTV tra?c models.
6Results Discussion
In this work,we analyzed the P2P IPTV tra?c by using a wavelet based trans-form method.This allows us to characterize this tra?c and to understand its properties and impact on the network.Thanks to our original P2P IPTV tra?c analysis,we have many new?ndings and observations that have to be summa-rized and discussed.
First of all,we observed that the energy spectra of TCP applications are di?erent from the energy spectra of UDP applications(section5.2).One of the most relevant di?erence is the energy bump observed in the spectra of TCP applications at time scale j=8(5.12s),which indicates a possible periodic be-havior in the tra?c.Intuitively,we could believe these di?erences come from the two di?erent transport protocols used.However,a5seconds periodic be-haviors is a very long duration for TCP mechanisms and TCP should not be the
20
中兴IPTV解决方案 IPTV承载网融合在运营商的整个城域网络架构中，和其他业务在城域网共用一个接入平台，IPTV业务经由在宽带接入网中DSLAM、接入交换机、汇聚交换机等设备汇聚，由业务控制管理设备(BRAS或SR)充当业务呈现点(POP)。 IPTV业务发展初期，普通业务和IPTV业务共用一个BRAS设备接入并分流，IPTV业务以PPPoE方式提供，这样对整网的改动小，业务开展快。随着业务规模的发展，越来越多的运营商将IPTV业务割接到SR上，以IPoE方式提供，宽带上网业务通过原有BRAS接入，IPTV业务通过SR接入，这样既消除了IPTV业务和其他业务之间的相互影响，也保证了大流量IPTV业务自身的需要，IPTV业务和其他业务在二层汇聚设备进行分流。 采用IPoE方式提供IPTV业务，对网络设备和网络规划提出了一些新的要求。 1 IPTV业务流程简介 IPTV业务的基本流程如图1所示，包括四个步骤，首先是网络进入认证，在用户层和网络层之间交互;其次是业务接入认证，在用户层和业务层之间交互；接下来是用户频道选择(包括点播和直播频道)，也是在用户层和业务层之间交互;最后当用户关机或者其它故障情况，流媒体服务器检测到媒体流中断，停止计费。
图1：IPTV业务的基本流程 IPTV业务的计费和宽带上网不同，宽带上网的流量统计和时间统计都需要BRAS 来做，时常计费由用户进入认证开始。但是IPTV用户有可能长时间在线，但没有看任何节目，即进入网络但没有接入业务，所以不应该由进入认证计算时常，所以IPTV的计费通常由IPTV的业务支撑系统来做。并且IPTV 节目预览的流量不应计费，所以网络流量计费也不适合IPTV，IPTV中不同点播节目的收费标准是不一样的，由业务支撑系统计费较Internet业务惯用的网络流量和网络时常计费具有更好的灵活性。 2 用户进入网络认证 网络进入认证，并统计网络流量和用户在线时长，是为了研究用户行为、辅助网络优化的目的。 如果IPTV业务由BRAS作为POP点，则通常采用PPPoE的方式提供，Radius认证。如果由业务路由器(SR)作为POP点，通常采用 IPoE方式提供，DHCP认证。 DHCP接入的优点是STB实现简单，组播报文在IPOE通道上承载，不需要对组播报文作PPP封装处理，因此组播复制工作不限定在终结PPPoE 的BRAS设备进行，可以根据业务量灵活地部署在业务路由器(SR)、汇聚交换机，甚至在接入设备(DSLAM或园区交换机)上，在集中的业务控制与业务规模对单设备组播复制性能两方面取得综合平衡。 另外还有一种DHCP + Web Portal的认证方式，采用了二次地址分配技术，但是考虑到STB 一般都是哑终端，不建议在IPTV业务中采用。 采用DHCP方式时，DHCP报文可以携带OPTION60/82参数，相关服务器根据OPTION60/82携带的信息，进行业务区分，IP地址分配以及认证等工作。在DHCP包文中引入OPTION82选项，实现用户和线路的精确绑定，保证了DHCP 接入的安全性和真实性;对于存在多个终端同时使用DHCP帐号的场合，如一个家庭拥有多台IPTV终端，为了区分这些终端，还需引入OPTION60选项。DHCPOPTION82选项通常由 DSLAM/交换机设备将用户的端口信息和设备信息插入到用户的DHCP报文，DHCP服务器通过识别OPTION82来执行IP地址分配策略或其它策略。OPTION60选项通常由终端自带，不同类型的终端可以通过设置不同的OPTION60来识别。通过OPTION60选项，可以实现对不同的终端分配不同的地址空间。 DHCP属于数据和认证分离的控制方式，安全性不及PPPoE，为防止用户静态配置IP地址，或者网络盗用，可以在接入设备或者业务路由器上部署 MAC+IP绑定功能。启用DHCP snooping或DHCP relay的节点上，在侦听到DHCP offer消息时，生成IP和MAC的绑定关系，只有源MAC和原IP匹配的IPoE帧才可以通过，否
什么是IPTV协议 IPTV即交互式网络电视，是一种利用宽带有线电视网，集互联网、多媒体、通讯等多种技术于一体，向家庭用户提供包括数字电视在内的多种交互式服务的崭新技术。用户在家中可以有两种方式享受IPTV服务：(1)计算机，(2)网络机顶盒+普通电视机)。它能够很好地适应当今网络飞速发展的趋势，充分有效地利用网络资源。IPTV既不同于传统的模拟式有线电视，也不同于经典的数字电视。因为，传统的和经典的数字电视都具有频分制、定时、单向广播等特点；尽管经典的数字电视相对于模拟电视有许多技术革新，但只是信号形式的改变，而没有触及媒体内容的传播方式。 IPTV关键技术 IPTV是利用计算机或机顶盒+电视完成接收视频点播节目、视频广播及网上冲浪等功能。它采用高效的视频压缩技术，使视频流传输带宽在800Kb/s时可以有接近DVD的收视效果(通常DVD的视频流传输带宽需要3Mb/s)，对今后开展视频类业务如因特网上视频直播、远距离真视频点播、节目源制作等来讲，有很强的优势，是一个全新的技术概念。 传统电视播放存在的问题传统的电视是单向广播方式，它极大地限制了电视观众与电视服务提供商之间的互动，也限制了节目的个性化和即时化。如果一位电视观众对正在播送的所有频道内容都没有兴趣，他(她)将别无选择。这不仅对该电视观众来说是一个时间上的损失，对有线电视服务提供商来说也是一个资源的浪费。另外，目前实行的特定内容的节目在特定的时间段内播放对于许多观众来说是不方便的。一位上夜班的观众可能希望在凌晨某个时候收看新闻，而一位准备搭乘某次列车的乘客则希望离家以前看一场原定晚上播出的足球比赛录像。现在看来是不可能的。 IPTV的特点及应用 IPTV是利用宽带有线电视网的基础设施，以家用电视机作为主要终端电器，通过互联网络协议来提供包括电视节目在内的多种数字媒体服务。特点表现在： 1)用户可以得到高质量(接近DVD水平的)数字媒体服务。 2)用户可有极为广泛的自由度选择宽带IP网上各网站提供的视频节目。 3)实现媒体提供者和媒体消费者的实质性互动。IPTV采用的播放平台将是新一代家庭数字媒体终端的典型代表，它能根据用户的选择配置多种多媒体服务功能，包括数字电视节目，可视IP电话，DVD/VCD播放，互联网游览，电子邮件，以及多种在线信息咨询、娱乐、教育及商务功能。 4)为网络发展商和节目提供商提供了广阔的新兴市场。目前我国通信事业正在迅猛地发展，用户对信息服务的要求越来越高，特别是宽带视频信息。可以说中国已基本具备了大力发展IPTV的技术条件和市场条件。 一般所说的IPTV与数字电视，既有相似点，又有区别。烽火网络公司的技术专家从以下方面阐述了二者的异同。 1．技术体系
IPTV即交互式网络电视，是一种利用宽带网，集互联网、多媒体、通讯等技术于一体，向家庭用户提供包括数字电视在内的多种交互式服务的崭新技术。它能够很好地适应当今网络飞速发展的趋势，充分有效地利用网络资源。IPTV 已经在公众中形成一定的知名度，包括运营商、内容提供商、设备商、终端厂商在内的产业链各个环节均在积极推动IP产业的发展。那么IPTV电视系统安装哪家好，以及IPTV电视系统都有哪些好处呢？下面我们一起来了解下吧。 IPTV电视系统安装哪家好？推荐郑州云网智能科技有限公司。 郑州云网智能科技有限公司是一家专业从事视频监控系统、安全防范系统、出入口控制系统、入侵报警系统、计算机网络系统、楼宇智能系统、家居智能系统、弱电智能化系统等多种技术系统的集成设计、工程安装以及技术服务。公司自成立以来，一直以高质量的施工、周到的技术服务和专业的经营理念，赢得广大客户信任和大力支持。 最近，IPTV被国内外普遍认为是“三网融合”过程中最有价值的“杀手
级”业务。与非交互型的数字电视相比，IPTV因具有IP网的对称交互优势，具有十分灵活的交互特性和优势，这主要体现在： 首先，IPTV能够提供多种形式的内容服务。数字电视依赖广播电视网向用户提供电视节目，用户可根据自己的需要点播节目制作公司预先提供的电视节目，实现个性化收看。而对于IPTV来说，电视节目只是它其中的一小部分内容。 目前电信部门可以提供如下三类IPTV业务：电视类业务、通信类业务以及各种增值业务。电视类业务有广播电视、点播电视、个人视频录制等；通信类业务主要有基于IP的语音业务、即时通信服务、电子邮件、电视短信等；增值业务主要包括电视购物、互动广告、网络游戏、电子理财、远程教育、远程医疗等。 其次，IPTV真正实现了互动。数字电视优于模拟电视，在于它弥补了电视线性传播的劣势，使受众在收看电视节目时能根据自己的个人喜好进行选择，部分地实现了互动。数字电视对于模拟电视的许多技术革新，只是信号形式的改变，而没有触及媒体内容的传播方式。虽然数字电视通过设置一定的菜单供用户挑选，可以实现用户简单的互动，但不能实现真正意义上的多种交互式服务。
第一章 什么是软件测试？软件测试的目的和作用是什么? 答： 软件测试是在受控制的条件下对系统或应用程序进行操作并评价操作的结果。 软件测试的目的是以最少的时间和人力，系统地找出软件中潜在的各种错误和缺陷。测试是为了证明程序有错，而不是证明程序无错。一个成功的测试是发现了至今未发现的错误的测试。 软件测试的原则包括：所有的测试都应追溯到用户的需求；尽早地和不断地进行软件测试；不可能完全的测试，因为输入量太大，执行路径太多；注意测试中的群集现象；避免测试自己的程序；设计周密的测试用例。 软件缺陷产生的原因？ 答：A．软件需求说明书编写的不全面，不完整，不准确，而且经常更改B．软件设计说明书C．软件操作人员的水平D．开发人员不能很好的理解需求明书和沟通不足 软件测试的意义？ 意义： 对产品质量完成全面的评估，为软件产品发布（如验收测试）、软件系统部署（如性能规划测试）、软件产品鉴定（第三方独立测试）委托方和被委托方纠纷仲裁（第三方独立测试）和其它决策提供信息； 通过持续的测试（包括需求评审、设计评审、代码评审等）可以对产品质量提供持续的、快速的反馈，从而在整个开发过程中不断地、及时地改进产品的质量，并减少各种返工，降低软件开发的成本； 通过测试发现所要交付产品的缺陷，特别是尽可能地发现各种严重的缺陷，降低或消除产品质量风险，提高客户的满意度，扩大市场份额，提高客户的忠诚度。 通过对缺陷进行分析，找出缺陷发生的根本原因（软件过程中的问题，包括错误的行为方式）或总结出软件产品的缺陷模式，避免将来犯同样的错误或产生类似的产品问题，达到缺陷预防的目的 软件测试与软件开发的关系？ 答：软件开发是一个系统的工程。包括需求分析，设计，编码，测试，维护等等几个环节。测试是整个软件开发流程中的一个环节。 简述软件测试过程v模型和w模型的主要区别： V模型是软件开发完了之后才开始测试活动。 而W模型则是软件测试活动伴随着软件开发活动。和软件开发同时开展。 W模型更加敏捷，对于软件的交付期和品质的保证能力更强。 第二章 测试计划的目的是什么？ 答：软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。 什么是黑盒测试?黑盒测试主要采用的技术有哪些? 答：黑盒测试又称为功能测试、数据驱动测试和基于规格说明的测试。它从用户观点出发的测试。用这种方法进行测试时，把被测试程序当作一个黑盒，在不考虑程序内部结构的内部
XXXXXXXXXXXX IPTV 方案 2017年2月
目录 1.俱乐部现有IPTV分析 .................................................... 错误!未定义书签。 1.1.原有系统介绍............................. 错误!未定义书签。 1.2.原有系统优缺点........................... 错误!未定义书签。 1.3.现在市场主流IPTV介绍.................... 错误!未定义书签。 2.方案简述.......................................................................... 错误!未定义书签。 2.1.改造方案简述............................. 错误!未定义书签。 2.2.升级方案简述............................. 错误!未定义书签。 2.3.改造和升级方案对比....................... 错误!未定义书签。 2.3.1 技术优点缺点对比.............................................. 错误!未定义书签。 2.3.2 造价对比.............................................................. 错误!未定义书签。 2.4.施工流程................................. 错误!未定义书签。 3.维护售后服务内容.......................................................... 错误!未定义书签。 3.1.应急响应服务............................. 错误!未定义书签。 3.2.电视信号巡检服务......................... 错误!未定义书签。 3.3.高清信号变更服务......................... 错误!未定义书签。 4.服务标准和质量.............................................................. 错误!未定义书签。 5.服务实施管理要求.......................................................... 错误!未定义书签。 6.公司概况.......................................................................... 错误!未定义书签。 6.1.公司的业务............................... 错误!未定义书签。 6.2.我们的优势............................... 错误!未定义书签。 6.3.我们的用户............................... 错误!未定义书签。 1.概述 1.1.XXXXX现有IPTV分析 XXXXXX基地投入使用前，设计安装了现在使用的网络电视系统，满足了XXX
第一章软件测试概述 1. 名词解释 软件缺陷： 即计算机系统或者程序中存在的任何一种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷、瑕疵。缺陷会导致软件产品在某种程度上不能满足用户的需要。 软件缺陷的准确定义，通常有以下5 条描述： （1）软件未实现产品说明书要求的功能。 （2）软件出现了产品说明书指明不会出现的错误。 （3）软件超出实现了产品说明书提到的功能。 （4）软件实现了产品说明书虽未明确指出但应该实现的目标。 （5）软件难以理解，不易使用，运行缓慢或者终端用户认为不好 软件测试： 软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。通常对软件测试的定义有如下描述：软件测试是为了发现错误而执行程序的过程。 静态测试：静态测试就是通过对被测程序的静态审查，发现代码中潜在的错误。 动态测试：动态测试的对象必须是能够由计算机真正运行的被测试的程序 黑盒测试： 黑盒测试是一种从用户观点出发的测试，又称为功能测试，数据驱动测试和基于规格说明的测试。 白盒测试： 白盒测试基于产品的内部结构来进行测试，检查内部操作是否按规定执行，软件各个部分功能是否得到充分利用。 单元测试: 单元测试是针对每个单元的测试，是软件测试的最小单位。 集成测试： 集成测试是对已测试过的模块进行组装，进行集成测试的目的主要在于检验与软件设计相关的程序结构问题。 确认测试: 是检验所开发的软件能否满足所有功能和性能需求的最后手段，通常采用黑盒测试方法。系统测试: 系统测试的主要任务是检测被测软件与系统的其他部分的协调性。 验收测试: 验收测试是软件产品质量的最后一关。这一环节，测试主要从用户的角度着手，其参与者 主要是用户和少量的程序开发人员。 2. 简述软件测试发展的历史及软件测试的现状
a)连线 如果初次安装，请您不要担心连线问题，我们的现场工作人员会为您解决这个问题。如果您想自己了 解这方面的情况，这里将为您作简要介绍。 iTV机顶盒面板如下图所示： 连线方式有以下要点： ◆将＜视频输出＞和＜音频左/右＞与电视机的＜视频输入＞和＜音频输入＞相连。 ◆将WAN输入接口与网线相连。 具体连线方式如下图所示： b)设置
如果初次安装，请您不要担心设置问题，我们的现场工作人员会为您解决这个问题。如果出现故障，请您尽量打10000号联系我们，我们的工作人员将上门为您服务。 用户自己进行设置时，请您必须了解以下参数：iTV PPPOE帐号、iTV PPPOE密码、iTV 业务认证帐号、iTV 业务认证密码和域名服务器，如果没有这些参数，请拨打10000号与我们联系。 打开机顶盒电源后，连续按遥控按钮“＃1”或“9721＃”，电视机上将出现如下图所示的屏幕。 ·设置域名 温州iTV域名为https://www.doczj.com/doc/b016818963.html, 选择“域名设置”菜单后按遥控“确认”键，电视机上将出现如下图所示的屏幕： 按照下述方法输入域名： 按遥控器上的”切换”(P042C按F1)键，电视机屏幕下方将显示输入法，通过遥控“*”、“#”可以切换 不同的输入法和符号，如图：
连续按“#”键切换到“abc”小写字母输入模式，然后按遥控数字键“2”，按遥控左右键选中字符“b”，然后按“确认”键，所选字符就自动输入到“域名”文本框中。重复上述步骤，完成其他字母的输入。（这里以 域名“https://www.doczj.com/doc/b016818963.html,”为例说明） 然后按遥控“*”键切换到符号输入界面，左右键选择“.”，按“确认”键，完成输入“.”。 再按遥控“#”切换回小写字母输入模式，重复“步骤2”操作，完成完整域名的输入。 ※说明：按遥控器上的“返回”键可以删除文本框内的最后一个字符。 再次按遥控”切换”(P042C按F1)键，返回到正常模式。按遥控器上的方向键选中“确定”按钮，然后按遥控确认键，提交所输入的域名，返回到配置主页面。
IPTV 网络电视解决方案 市场部提
一、IPTV网络电视系统IPTV网络电视系统的组成：
1.IPTV网络电视系统组成描述： 整个方案架构是由采集和发布来组成: 视音频源编码器->Nowcaster pro直播服务器->Nowview管理端(发布)->接收（客户端IPTV机顶盒）->观看（电视机）。 EPG由Nowview管理端进行直播的节目源、频道以及字幕的管理。 Nowview流媒体点直播平台（以下简称Nowview平台）是一个面向IPTV网络用户的新媒体视频点播系统，同时支持WEB、机顶盒、以及桌面程序播放。用户可以自由选用机顶盒、PC、手机等各种终端访问我们的点播系统。它主要由WEB服务器、频道视频应用服务器、数据库服务器构成。 Nowview平台采用分布式可扩展体系架构，能够动态地、自主地构建网络，支持大规模用户并发访问，支持多频道同时发布，支持频道和内容分类管理。系统支持高清与标清品质的视频节目内容，支持超大规模并发流IPTV视音频应用服务，具有良好的安全性、稳定性、扩展性、易用性等特性。 Nowview平台是一个WEB应用程序，它作为一个桥梁作用的IPTV解决方案的各个组成部分（机顶盒，服务器，视频点播，计费等）。 Nowview平台通过网络浏览器进行管理支持浏览器：IE 6.x 及以上版本。 Nowview平台采用Java技术。这项技术的优势（跨平台，高性能，安全性），能方便的融入更多的服务体系中，通过开放的协议接口来满足客户的需要，。 Nowview平台可以部署在用途广泛的servlet应用服务器Apache Tomcat 5.x 及6.x，同时也支持jboss 以及weblogic 应用服务器。可选择MySQL（5.x）、Oracle9i & 10g 等数据库。 2.IPTV网络电视直播构架 3. IPTV网络电视直播系统-功能特点 1、采用标准的B/S、 C/S构架，完全基于Web方式。 2、采用linux操作系统，更加稳定、安全，不易受病毒感染。 3、全面支持组播（Multicast），利用组播技术可以大大的减轻服务器的负担，不管有多少
华为 IPTV 解决方案-通信解决方案 随着宽带网络的不断建设，各地的运营商愈来愈感觉到宽带放号和用户发展的后劲不足，运营商发现有吸引力的业务才是人们愿意付费成为宽带用户的根本原因，可见要使宽带用户数有大的提高，必须引入受欢迎的业务。同 时，原有的宽带网络收费模式只针对接入，显得过于简单，使重要的业务和内容的市场白白流逝。“电脑－网络－应用”似乎成为人们对网络发展的一种理解定式，其实电视机作为已经进入千家万户的终端，完全能够使人们体验到宽带网络带来的娱乐和享受，这就是IPTV的作用。 很多有实力的电信运营商早在2000年左右就开始IPTV的试验，有的已经接入商用了。例如日本Yahoo! BB、美国的Comcast、法国NEUF和韩国电信的HomeMedia等。 应用模式 IPTV业务是采用流媒体技术在宽带数据网络开展的面向公众的一种视频业务，最常见的业务是节目点播VOD和直播电视BTV，另外还有远程教育、购物和信息查询等等。 IPTV主要以宽带数字机顶盒STB+电视机TV为用户终端，向用户提供电信级的服务和使用简便的电视式体验，使原来电脑上网的知识性体验拓展为电视机观
赏的娱乐共享。开展了与以往的不同体验的IPTV，运营商将会受益于：吸引新的宽带用户，增加宽带接入放号 宽带用户贡献内容业务收入，提高宽带ARPU值 驱动宽带网络发展的规模化和智能化的良性成长 最终用户体验IPTV将会有全新的感受： 任君选择海量的电影和音乐歌曲，体会新颖的电视频道 在家或宾馆里与家人、朋友共享娱乐休闲 简单熟悉的遥控器操作 DVD的画面、Hi-Fi的音质效果 方案介绍 基于对IP电信网的深入理解，华为提供完整的IP TV宽带视频解决方案。具备终端业务感知能力，业务可控、可规划、可管理，完美实现免费业务和收费
我的e家IPTV无线解决方案 进线端
电视端
二、设备连接方式： iptv 口 lan 口 外线 ADSL MODEM 主无线路由器 副无线路由器 机顶盒 电视机 所需设备：1、ADSL MODEM （安装时电信赠送） 2、2台无线路由器（任何型号度汛，但必须有WDS 或bridge 桥接功能） 3、机顶盒（安装时电信赠送）
主要事项： 1、MODEM与主路由器必须用2根网线连接，一根连接MODEM的Internet出口（或网络1）和路由器的W AN口，另一根连接MODEM的IPTV出口 （或网络2）和路由器的任意一个LAN口。 2、副路由器的任意一个LAN口用网线与机顶盒的WAN口连接。 3、主副路由器要进行桥接设置（具体可以查找有关教程），关键步骤是2个路由器都要开启WDS或bridge桥接功能或选择AP(WDS+AP)工作模式，主 路由器桥接设置中MAC（或BSSID）输入副路由器的地址，副路由器的MAC（或BSSID）输入主路由器的地址。地址一般情况为：40-16-9F-52-5E-19也有个别华硕的路由器不用分隔符的如：40169F525E19。 4、主无线路由器要进行上网一般选择PPPoE方式，设置账号、密码就可以了，具体根据宽带接入方式不同而略有不同。
5、为了防止跟别人的无线路由器重名造成路由器不能桥接，应把自己的无线路由器明（或SSID号）设置的长一点，而且2个路由器的名字不能相同。 6、主路由器LAN的IP地址若为192.168.1.1，副路由器LAN的IP地址应与主路由器为同一网段不同地址，如：192.168.1.2，而且主路由器的DHCP服 务器要选择启用，副路由器的DHCP服务选择不启用。 7、设置完成一般情况就可以同时无线上网和无线看电视了，可以省掉那条从MODEM到机顶盒恼人的网线啦。
IPTV 无线解决方案 一、简介。 由于目前大多数用户在装修时客厅电视机背后都没有预留网线接口，而modem 一般又放在书房，这样要使用IPTV 时，不得不布放一根明线来连接modem 和机顶盒。这样既不美观又不方便。如果有某种无法连接方式，那上面的问题就迎刃而解。经过我们实际测试，使用无线AP 加无线网桥的方式可以解决布明线的问题。 这种方式除传统的AP 外，还需要一台无线网桥，其作用是将无线信号与以太网电信号进行互相转换。连接方式视ADSL 或FTTB 不同接入方式而有些许差别，但总体原则是一致的：一，进线第一级设备（多端口modem 或小交换机）其internet 口与无线AP 的WAN 口连接，AP 设置PPPOE ，其下PC 机以有线或无线的方式通过AP 转发上网。二，第一级设备的IPTV 口与AP 的LAN 口连接，机顶盒通过反跳线与无线网桥的以太口连接；AP 与网桥以无线方式互联。 此无线方案优点在于：功能强大，可绑定天翼通。 缺点在于：对承重墙穿透能力弱。有一定的范围局限性。可以通过室内改线路，缩短直线距离可增强效果。 摆放方式：无线AP 与modem 放置在一起，而无线网桥和IPTV 机顶盒放置在一起。无线网桥的以太口用反跳线和IPTV 机顶盒的WAN 口连接。注意AP 和网桥之间以间隔一堵承重墙为宜。示意图如下： 另外无线局域网的三个重要指标是：无线路由器的发射功率、无线网卡或接收网桥的接收灵敏度（天线的大小）以及低速率连接（速率越低，性能越稳定，传输距离越远） 二、设备连接方式： iptv Room-A Room-B Room-C 无线网桥 无线AP Internet STB TV ADSL MODEM FE FE FE
1.什么是软件测试？软件测试的目的和作用是什么? 答： 软件测试是在受控制的条件下对系统或应用程序进行操作并评价操作的结果。 软件测试的目的是以最少的时间和人力，系统地找出软件中潜在的各种错误和缺陷。测试是为了证明程序有错，而不是证明程序无错。一个成功的测试是发现了至今未发现的错误的测试。 软件测试的原则包括：所有的测试都应追溯到用户的需求；尽早地和不断地进行软件测试；不可能完全的测试，因为输入量太大，执行路径太多；注意测试中的群集现象；避免测试自己的程序；设计周密的测试用例。 2.软件缺陷产生的原因？ 答： A．软件需求说明书编写的不全面，不完整，不准确，而且经常更改 B．软件设计说明书 C．软件操作人员的水平 D．开发人员不能很好的理解需求明书和沟通不足 3.软件测试的意义？ 意义： 1.对产品质量完成全面的评估，为软件产品发布（如验收测试）、软件系统部 署（如性能规划测试）、软件产品鉴定（第三方独立测试）委托方和被委托 方纠纷仲裁（第三方独立测试）和其它决策提供信息； 2.通过持续的测试（包括需求评审、设计评审、代码评审等）可以对产品质量 提供持续的、快速的反馈，从而在整个开发过程中不断地、及时地改进产品 的质量，并减少各种返工，降低软件开发的成本； 3.通过测试发现所要交付产品的缺陷，特别是尽可能地发现各种严重的缺陷， 降低或消除产品质量风险，提高客户的满意度，扩大市场份额，提高客户的 忠诚度。 4.通过对缺陷进行分析，找出缺陷发生的根本原因（软件过程中的问题，包括 错误的行为方式）或总结出软件产品的缺陷模式，避免将来犯同样的错误或 产生类似的产品问题，达到缺陷预防的目的 4.软件测试与软件开发的关系？ 答：软件开发是一个系统的工程。包括需求分析，设计，编码，测试，维护等等几个环节。测试是整个软件开发流程中的一个环节。 5.简述软件测试过程v模型和w模型的主要区别： V模型是软件开发完了之后才开始测试活动。 而W模型则是软件测试活动伴随着软件开发活动。和软件开发同时开展。 W模型更加敏捷，对于软件的交付期和品质的保证能力更强。
IPTV业务到底需要什么样的交换机支持 IPTV即交互式网络电视,是一种利用宽带有线电视网,集互联网、多媒体、通讯等多种技术于一体;向家庭用户提供包括数字电视在内的多种交互式服务的崭新技术。用户在家中可以有两种方式享受IPTV服务：(1)计算机，(2)网络机顶盒+普通电视机。 它采用高效的视频压缩技术，使视频流传输带宽在800Kb/s时可以有接近DVD的收视效果(通常DVD的视频流传输带宽需要3Mb/s)，对今后开展视频类业务如因特网上视频直播、远距离真视频点播、节目源制作等来讲，有很强的优势，是一个全新的技术概念。 IPTV是利用宽带有线电视网的基础设施，以家用电视机作为主要终端电器，通过互联网络协议来提供包括电视节目在内的多种数字媒体服务。 发展前景 在很长一段时间内会出现两者并存的状况。发展数字电视是国家早就计划的政策，IPTV 是在众多的电视节目中增加一个节目频道，并不代替有线数字电视。因为IPTV的实时性广播有一定的使用成本，所以完全用IPTV代替掉有线或卫星电视意义并不大。但是，因为IPTV 的众多吸引人们的功能，它作为一个独立的节目频道还是十分有生命力。从信息产业发展角度看，IPTV还是三网合一的最大切入点。 用户在家中可以有三种方式享受IPTV服务： 1.计算机； 2.网络机顶盒+普通电视机； 3.移动电话 IPTV业务是基于宽带互联网与宽带接入，以机顶盒或其他具有视频编辑码能力的数字化设备作为终端，通过聚合SP的各种流媒。 网络体系 IPTV采用IP宽带网，通常要在边缘设置内容分配服务节点，配置流媒体服务及存储设备，存储及传送的内容是以MPEG-4为编码核心的流媒体文件。 技术改进难度 在互联网上开展IPTV业务，带宽、频道切换时延、QoS等还差强人意，组播技术离满足IPTV的高要求还有很大距离，CDN（内容分发网络）技术还不十分成熟，技术改进难度较大，短期难以完成。同时，为了获得更多的用户，还必须提高IPTV的出口速率以及收视用户的接入速率。 IP机顶盒的构成与功能 IP 机顶盒 机顶盒由软件和硬件两大部分组成，机顶盒的硬件包含了主芯片、内存、调谐解调器、回传通道、CA（Conditional Access）接口、外部存储控制器以及视音频输出等几大部分。软件则分成应用层、中间解释层和驱动层三层，每一层都包含了诸多的程序或接口等。 与传统的数字机顶盒相比，IP机顶盒实现了视频、语音、数据三者的融合，即所谓的三
第一章软件测试概述 1.名词解释？ 软件缺陷： 即计算机系统或者程序中存在的任何一种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷、瑕疵。缺陷会导致软件产品在某种程度上不能满足用户的需要。 软件缺陷的准确定义，通常有以下5条描述： （1）软件未实现产品说明书要求的功能。 （2）软件出现了产品说明书指明不会出现的错误。 （3）软件超出实现了产品说明书提到的功能。 （4）软件实现了产品说明书虽未明确指出但应该实现的目标。 （5）软件难以理解，不易使用，运行缓慢或者终端用户认为不好 软件测试： 软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。通常对软件测试的定义有如下描述：软件测试是为了发现错误而执行程序的过程。 静态测试： 静态测试就是通过对被测程序的静态审查，发现代码中潜在的错误。 动态测试： 动态测试的对象必须是能够由计算机真正运行的被测试的程序 黑盒测试： 黑盒测试是一种从用户观点出发的测试，又称为功能测试，数据驱动测试和基于规格说明的测试。 白盒测试： 白盒测试基于产品的内部结构来进行测试，检查内部操作是否按规定执行，软件各个部分功能是否得到充分利用。 单元测试: 单元测试是针对每个单元的测试，是软件测试的最小单位。 ： 集成测试： 集成测试是对已测试过的模块进行组装，进行集成测试的目的主要在于检验与软件设计相关的程序结构问题。 确认测试: 是检验所开发的软件能否满足所有功能和性能需求的最后手段，通常采用黑盒测试方法。系统测试: 系统测试的主要任务是检测被测软件与系统的其他部分的协调性。 验收测试: 验收测试是软件产品质量的最后一关。这一环节，测试主要从用户的角度着手，其参与者
酒店IPTV在连锁酒店是很常见的，有多家酒店和多个酒店式公寓，共有2万多台播放终端（部分是机顶盒和部分是智能电视机），这些酒店和公寓已通过光纤连成一个内部的广域网。那么客户要酒店iptv解决方案，首先建立一个覆盖所有用户终端的IPTV系统，要求：（1）共享一个直播源。 （2）能够实现直播、广告消息推送等功能。 （3）每个酒店或酒店公寓都有自己风格主页，可以自定义服务菜单和关于酒店的宣传。（4）可以集中对所有酒店IPTV系统进行维护和管理。 （5）可以对所有终端设备或APP进行升级和维护。 1.推荐酒店iptv解决方案 从客户规模来看，一般方案可以建议用IP组播方案，但传统的IP组播方案，交互性很差，无法满足酒店自定义服务和互动性需求，而且，传统的IP组播要求传输过程中的所有网络设备必须支持组播，会增加网络设备投资，并给调试带来困难。 针对这个状态，我推荐酒店iptv解决方案是秒开网络公司产品：应用层组播系统+酒店互动电视系统多店版的组合方案。 酒店iptv解决方案拓扑图如下： 方案说明： （1）在中心机房进行直播源采集，如果直播源不是H.264编码，需将全部的直播源转为H.264编码（主要是降低在传输中带宽占用）。 （2）把全部直播源接入秒开应用层组播系统，应用层组播系统充当直播源种子发布服务器。（3）中心机房设置一台秒开酒店互动电视系统多店版服务器，为使用所有酒店提供服务个性化主页服务。 （4）使用秒开专用机顶盒的酒店或公寓直播流通过应用层组播系统构建P2P网络进行传输，通过P2P网络传输，因为是P2P机制，随着机顶盒终端量的增加，也无需增加服务器。（5）在使用安装APP电视机的酒店或公寓，由于电视机无法作为P2P节点，只能单播或组播传输，所以需在这些酒店或公寓部署一台iTV媒体网关进行本地推流，电视机通过与本
有线电视与电信IPTV区别
有线数字电视与电信IPTV 的比较 1、IPTV需求面较窄。由于IPTV以收费节目为主，所以主要服务对象为那些支付能力较强的高端用户。在互联网上开展IPTV业务，带宽、频道切换时延、QoS等还差强人意，组播技术离满足IPTV 用户的高要求还有很大距离，CDN（内容分发网络）技术还不十分成熟，技术改进难度较大，短期难以完成。同时，为了获得更多的用户，还必须提高IPTV的出口速率以及收视用户的接入速率。IPTV产业最主要的驱动力——电信运营商就面临重重障碍。首先是政策因素，电信运营商有足够能力在IPTV上大有作为，但苦于政策瓶颈，只能采取与IPTV牌照持有者合作来实现业务落地，扮演一个纯粹网络提供商角色。有线数字电视为合法网络运营，对现有电视网改变较小，以广大普通观众为服务对象，在原有系统体系不变的情况下，实现双向网络和数字化流程更为简单。 2、硬件与安装收看。电信ITV的安装较为繁琐,而且前提是必须安装电信的宽带,硬件是需要一个Modem和ITV机顶盒,所以安装时就要先解决宽带的安装,再通过宽带的Modem用五类线连接到ITV 机顶盒,然后通过机顶盒的输出口(视音频口、S端口)接入电视机,如果Modem与机顶盒相距较远不在一个房间,安装起来就比较麻烦而且不好看。有线数字电视的硬件只需增加一台机顶盒,安装也非常方便,是在原有的有线电视的基础上,把有线电视信号线接入数字电视机顶
7、IPTV在电视接收机中的图像效果和解析度更无法与数字高清电视相比，且受网速制约较大。现在都是大屏电视、高清电视，在清晰度方面IPTV是没有优势的，最多只达vcd清晰度。随着生活品质的提高，高清势必成为一个趋势，当然IPTV可以提高带宽流量，那势必味着又会增加用户的费用，加重用户经济负担。有线数字电视3D高清电视更是家居高档娱乐的象征，清晰度是原有标清节目的8倍，带来纤发毕现的高清晰图像，全屏实景呈现影片中的壮阔景象。3D节目更带来身临其境般的影音双重震撼，在家里也能享受到星级影院般撼动视听的非凡体验。
一根网线看IPTV高清解决方案大全 网线一分二、中继、电力猫、VLAN、iTV路由 名词解释： iTV是指电信/移动/联通等运营商推出的基于IPTV的电视业务,通常情况是其配套的光猫上有一个网口上标注有iTV字样,并且有一个配套的机顶盒.而不是自己在网店或者商场自购的电视机顶盒或者电视机.他的显著特点是配套的机顶盒要直接插在光猫的iTV口,中间还不能经过路由器甚至交换机之类的网络设备,更不能使用无线来连接. iTV困扰： iTV的好处这里就不说了，本贴只是针对问题整理了一些解决方案。 iTV带来的问题是如果要在客厅看电视,就需要在客户布一根iTV的专用网线,如果要在卧室看电视也要在卧室布一根iTV专用网线.当我们只布有一根网线,并且这根网线用于上网的话,就看不了电视了. 如果用于看电视,就上不了网!
注：本贴讨论的是弱电箱到每个房间只预埋了一根网线情况下，同时实现无线上网和看IPTV高清电视。 方案一 单网线8芯分双线4芯解决方案（某宝有成品网线一分二） 设备清单：水晶头4个或成品一分二2个 装修是只预埋了1根网线是正常情况，但这时又要解决无线和iTV问题怎么办？ 将网线一分为二，前提条件预埋的网线是8芯的。 使用百兆网络时，8芯的网线只用1、2、3、6，其余是闲置的，这样就可以把一根网线变两根。 做网线水晶头时要注意，网线插入水晶头的1、2、3、6位置，两头要对应。 正常安装了一个网口墙插，需要在面板上开个孔让另一根网线接出来，一根网线接无线路由，另一根网线实现光猫的iTV口和机顶盒直连。 这里要注册无线路由建议放在电视柜上，一般客厅是个开放的位置无线信号会更好一些。 优点：无需另外购买设备，可以看高清IPTV。 缺点：带宽最大100兆（升级200M带宽用不了），要打孔不美观，需要网管安装，不能两个房间同时看IPTV高清电视。 推荐指数:★★★★☆ 方案二 电力猫中继解决方案 设备清单：电力猫2台
一．项目背景 电视是医院必不可少娱乐设备和信息发布设备。 医院电视经历了从模拟闭路电视系统到数字闭路电视系统，再从数字闭路电视系统升级到网络电视，目前，随着医院向智慧智慧方向发展，医院电视系统也发展到目前的智慧IPTV系统阶段了。 它不仅能提供传统电视系统的电视直播，而且可以和医院的要求相结合，提供各种互动功能，如高清视频点播、在线服务呼叫、信息查询、语音遥控等服务。而且随着科技发展带来了价格的下降，原来只能是档次高的医院才配置的系统，现在也成为一般医院标配了。 提供的系统解决方案是同行方案中具有比较优势的方案，在酒店、医院等行业中有广泛应用。 用户利益： ●省钱：本方案是高性价比的，一次性投资终身受益。 ●省心：多年技术研发和改进，成千用户使用，品质有保障，维护省心。 ●品牌：个性化主页，进行全方面品牌价值传播。 ●满意度：高清的视觉效果，人性化的互动体验，带来满意度提升。 ●智慧化：让电视成为向智慧型医院迈进标志。 二．系统组成及构架 系统基于HLS流媒体技术开发，能部署在任何IP网络上（包括无线网络），适应性强，配合专用APP，适用于所有带安卓系统终端播放设备（机顶盒、智能电视、投影电视、智能手机、平板电脑等）。 系统构架：
三．系统功能 这个系统是根据医院使用场景研发的IPTV类产品，其功能概述如下： 1. 医院可以个性化风格设置，包括：开机视频、自定义欢迎词、主页风格及背景、菜单及内容。 2. 电视操作界面有多种语言可选。 3. 能接入各种直播源，包括：卫星源、广电源、运营商源、自办节目源等。 4. 提供直播回看和EPG服务。 5. 提供多种影视点播解决方案。 6. 直播和点播都支持高清1080P、超清4K（需播放终端支持）。 7. 满足医院提供就医方面需求，包括：就诊指南、健康教育等。 8. 满足医院功能设施及服务展示需求，利用图文或视频介绍医院及科室介绍、医生及医疗设施等。 9. 满足医院进行增值服务需求，包括：视频点播、在线点餐、商品销售等服务。 10. 满足病人获得有用信息需求，包括：天气、费用查询（需对接HIS）等信息。 11. 信息发布服务，可按科室分别插入文字滚动信息、图文广告或强制推送信息，如：紧急报警等。 12. 有接口模块，可对接各种设备或系统，如：语音遥控器、语音音箱、HIS（医院信息系统）等。 四．功能展示 1. 开机广告
1开头错误代码主要为网络故障代码 1302 错误提示：连接服务器失败，请稍后再试一次。 故障原因：1、EPG主页地址没有通过有效性检测；2、针对EPG主页地址的域名解析失败；3、多次重试连接EPG主页地址失败，无法与其建立连接 处理方法：1.新开户的机顶盒请检查机顶盒的主认证服务器地址是否配置正确2.配置的地址为域名方式，可以通过Monitor工具连5030端口查看日志，确认是否域名解释失败3.检查机顶盒实际连接边缘EPG的MTU值的设置是否正确 1305 错误提示：非常抱歉，网络接入失败！请稍后再试一次，如果仍然失败，请拨打客户服务热线进行咨询故障原因： 故障原因：1、DHCP服务没有能够获得有效的IP地址；2、DHCP/DHCP+协议交互收到服务器返回的错误码 处理方法：检查机顶盒的DHCP相关配置参数是否正确，如鉴权、接入用户名和密码 1306 错误提示：设备异常，无法提供服务！请拨打客户服务热线进行咨询 故障原因：1、机顶盒没有进行初始化配置，没有任何配置信息；2、机顶盒的关键配置信息（比如MAC地址、EPG主页地址等）无效 处理方法：出现该故障，该机顶盒必须返修，需要通过串口或PC配置工具检测配置信息 1401 错误提示：非常抱歉，网络接入失败！请稍后再试一次，如果仍然失败，请拨打客户服务热线进行咨询 故障原因：ADSL拨号收到DSLAM/BAS的拒绝响应。 处理方法：机顶盒打开双栈时ADSL帐号或密码配置错误会提示1401，可进入系统设置界面修改，用户开通时，这些信息应该是已经配置正确的，如果使用过程中出现这个错误，应该只能向运营商咨询
1402 错误提示：非常抱歉，网络接入失败！请稍后再试一次，如果仍然失败，请拨打客户服务热线进行咨询 故障原因：ADSL拨号成功，但没有收到BAS服务器的响应 处理方法：网络原因与上层BAS链路异常，或者BAS服务异常 1403 错误提示：非常抱歉，宽带接入帐号或密码错误，网络接入失败！请稍后再试一次，如果仍然失败，请拨打客户服务热线进行咨询 故障原因：ADSL帐号或密码配置有误 处理方法：可进入系统设置界面修改，用户开通时，这些信息应该是已经配置正确的，如果使用过程中出现这个错误，应该只能向运营商咨询 1404 错误提示：非常抱歉，网络接入失败！请稍后再试一次，如果仍然失败，请拨打客户服务热线进行咨询 故障原因：ADSL拨号超时没有响应 处理方法：多次重试请检查上联的modem是否状态正常 1901 错误提示：非常抱歉，线路连接异常！请检查网线是否脱落或网络接入设备是否加电。检查后再试一次，如果仍然失败，请拨打客户服务热线进行咨询 故障原因：网线未插上 处理方法：确认网线是否接口松动 1902 错误提示：非常抱歉，无线网卡加载失败！请检查无线网卡是否连接正常，稍后再试一次，如果仍然失败，请拨打客户服务热线进行咨询 故障原因：用户选择无线接入模式，但没有检测到无线网卡