IP over DVB-S2

    • Official Post

    IP datagrams or other network level packets can be transmitted over DVB-S2 satellite links using the Generic Stream Encapsulation (GSE).

    DVB-S2X is implementing the most efficient modulation and coding techniques, very close to the Shannon limit. QO-100 shall be a perfect ground for experimenting with new IP over DVB-S2 packet oriented communication protocols. This could also include Voice-over-IP and other things. Symbol-rates could be as low as 66kS or perhaps even less for data only...

    IP Encapsulation will allow to send IP datagrams even together with a DATV signal.

    It shall be possible to setup a ground station or Hub with connection to the amateur radio "hamnet", supporting several lower speed uplinks. This could be installed for example at the AMSAT HQ in Bochum where we already have HamNet access.

    We are looking for an open discussion and supporters, i.e. software developers.

  • DB2OS

    Approved the thread.
  • DB2OS Everything is possible but your own WB tpx operating rules speak explicitly about 'TV' (DATV, DVB-S2 + bandplan etc). TV has a visual component, i.e. its intention is to transmit pictures/movies etc where sound and/or data component are 'by-catches'. If we leave that perception all (WB) experiments -regardless of their mode of transmission- are 'allowed' on the WB tpx.

    • Official Post

    hmm.. just checked the WB op rules and I cannot find anything that says that the DVB-S2 stream needs to be video. So even by the rules, IP encapsulation is totally fine and if not, we can/should clarify on this because in my personal opinion IP-encapsulation in DVB-S2 is much more suitable for sat ops than any of the HF modes (Winlink, etc.) on the NB.

    Just beware that with IP encapsulation the traffic still needs to be transparent according to hamradio rules. No encrypted traffic (no https and no ssh for example).

    And don't forget Wednesday:

    On Wednesdays (UTC time), experimenters are encouraged to try other modes – perhaps 6 MS using the whole transponder for brief (less than 10 minute) periods. It is essential that users to announce their plans on the chat room page, and to always monitor it.

  • Clear explanation, but then the term 'DATV' , 'TV' , 'ATV' needs to be replaced with 'DVB-S2' (to name a suggestion). In the professional world (like SNG (satellite news gathering) several audio channels (digital, VoIP) are normal e.g. to have communication with the studio control room or camera men.

  • Gentlemen,
    with all respect, we have less bandwidth than stations in die WB-transponder for DATV. If we are starting to do pure data-services, where is the bandwidth for TV? What are the next plans to overcrowd that transponder?

    Right now, there is already a standard for IP over DVB-S2.
    But on the the other hand, we have done data over TV even in the analogue days. Did somebody remember Videotext? In DVB we are just talking about PIDs. If either we are doing SCTP, or MCTP, both are multiplexes.

    Right now, even if we transmit a "simple" TV-channel, we are already talking about PMT,PAT, Video PID and Audio PID. Did anybody recognize, that the program-name is our callsign? In fact, we are sending a simple EPG as well.

    If there is the need for a "data-channel", just decrease the symbol-rate for video in the beacon and use f.e. 500kSym/s of that stream to multiplex IP-over-DVB-S2 into an new PID.

    What are we loosing, when implementing data-services as a new PID into the beacon? Nothing, except a loop-video, we've seen for the past month with full bandwidth.

    Just my 2 cents.

  • Not in an amateur capacity, I have done IP-over DVB-S using a C-band transponder in Kampala, Abuja and a few other places.
    This was quite a common way to get bandwith to Africa before fiber infra existed. As Peter suggests, it has a pretty good bit/hz radio and DVB-S2 is probably better. In my case, this was for downstream only; upstream was using common BPSK if memory serves.

    The receivers were small PC's with a "DVB-S PCI card" running Linux. I'm not sure about the encapsulation used, too busy making the link work and dealing with other issues and the comfort of doing work in tropical conditions.

    Setting up an uplink on a commercial transponder is quite something different than what we are used to on QO100. You don't "just adjust the power"; you call the operator, put your signal on a special test frequency, have the signal optimized (maximal polarization isolation; optimal skew adjustments are a requirement!), have it adjusted for RF signal levels and when all is OK you would be told to move to your allocated frequency. If you would turn up your RF power by as much as 3dB afterwards you will find your transponder notched and you need to call the operator again.

    C-band is much more popular because it is less affected by the weather (if you've been in an equator rainstorm, you will understand).

    Latency, of course, is an issue. Using decent protocol stacks (FreeBSD) made quite the difference.

    I'm currently not set up for the WB transponder but learned *a lot* making this work. If you have the cycles, do try, if must be on a Wednesday..

  • As a side note, the EUMETCAST service uses DVB-S2 these days to distribute meteo products via IP streams / commercial broadcast sats. This is the METEOSAT/MSG2 data. Beautiful if you ask me, and free for non-commercial/amateur use.

    I used to receive it from a sat 5E (?? IIRC, it is a while ago and I forgot the sats name).

    In those days it was still DVB-S (non-S2 in other words). I currently do not have a PCI DVB-S2 card so I cannot receive


  • Hello,

    I'm the inventor of "New Packet Radio" (NPR), take a look here: https://hackaday.io/project/164092

    My thoughts about the discussion:

    DVB-S(2) is only well suited for a continuous stream of data at constant bitrate. It's not well suited for burst IP trafic, like we have most of the time when we use IP (web page browsing, e-mail exchange, text tchat). Especially when we consider uplink trafic (from users to servers) for dozens of users, then dozens of constant bitrate channels become a waste of precious radio ressources.

    I think I could adapt my NPR protocol (which already transports IP over radio) in order to fit on a portion of the QO-100 WB transponder. It would need lots of modification, but it should be feasible. We could name it "NPR-VSAT".

    It could be MF-TDMA (Multiple Frequencies Time Division Multiplexing Access), therefore using multiple timeslots inside multiple frequencies/chanels (for example 5 chanels, each 200kHz wide). Stations would transmit by bursts (instead of continuously for DVB-S2).

    A central station (the satellite hub) would allocate dynamically (in real time) these ressources (frequencies and timeslots) between users, according to their need.

    All this would be SDR-based, I will try the Adalm Pluto and Lime SDR Mini. The topology could be full-mesh, multipoint to multipoint.

    Each user station would transmit on one single frequency at a time (switching fastly between frequencies when needed), and each user station would listen to all frequencies/chanels simultaneously (with one single SDR, it should be feasible).

    It would be more efficient than pure DVB streams because of the "burst" type of trafic.

    The modulation scheme would be probably less efficient than DVB-S2: 4-levels GMSK seems easy to implement for burst radio frames.

    But all together, I still see a great overall improvement compared to the DVB-S2 uplinks initially proposed.

    We could even associate it with one single IP-over-DVB downstream channel from the central satellite hub point (Bochum?), in order to optimize the "server to client" trafic.

    I agree with DL4OCH : This downstream could even share a single DVB-S2 carrier/chanel with the existing "beacon video".

    - "Hub to user" trafic would be IP over DVB.

    - "User to user" and "user to hub" IP trafic would be NPR-VSAT.

    Tell me what do you think about this ambitious idea.

    Do you think it could be usefull that I work on such a project?

    Do you accept other modulation scheme than DVB over QO-100 WB?

    If we start working together, it would take a lot of time developing such a project, probably more than one year, but I think it’s feasible (not 100% sure yet). For example, it took me 2 years to develop NPR: 1 year for having a proof of concept, and 1 additional year to reach a useable solution.

    I'm currently quite busy with my NPR-70 project, but I could start working on this QO-100 project rapidly.

    And that's really the kind of thing I like to develop!

    Do you know if someone else has already begun to work on an equivalent project?

    • Official Post

    Dear Guillaume and all,

    thanks for taking this discussion up again.

    I realized that I missed to go more into details and should have added a few more points what I was really thinking about.. Sometimes I have too many things in the head too ;)

    Usually there is more datarate needed in the downlink rather than in the uplink.

    As you already mentioned MF-TDMA with several low rate uplinks and one common highspeed downlink, which could be an continuous DVB-S2 stream. For example our already existing DATV Beacon. Or comparable to the PACSAT satellites many years ago, where you had one continuous downlink and several uplinks channels..

    Actually I had two different things on my mind:

    1) A kind of PACSAT BBS or HamNet access

    as described above...

    2) A successor for P4-A which would replace the Analog Linear Transponder Downlink by a regenerative digital transponder with a single DVB-S2 downlink.

    Part of the Uplink would be still "linear" as it is for SSB/CW/etc., but just like a remote SDR which will stream the "passband" down as I/Q data on the DVB-S2 downlink.

    The DVB-S2 Downlink would always run constant power, no more problems with stations over-powering the uplink. In the example above the full NB uplink passband could be segmented into several channels with own AGC or "STELLA" leveling of the uplink signals..

    So more Uplink power does not mean more Downlink power.

    No "under-performing" receive station. Either it works or it works not.

    No GPSDO needed on the DVB-S2 Downlink, just a standard LNB would do..

    Indeed such a system requires some amount of onboard processing power, but the cooling and electrical power would be available.

    This could be a next generation transponder and indeed we could try it on the ground first, very similar to 1) by having several low rate channels received in Bochum and encapsulated into the DVB-S2 downlink..

    Well.. everything is in very early stage, still brainstorming ;)

    But also thanks to QO-100 we see a lot of interesting developments on SDR and DVB-S2 technology..

    Not so many years ago, nobody would have thought what's already doable today..

    What do you think about it?

    73s Peter