Streaming mp3 using GPRS! - PPP

This is a discussion on Streaming mp3 using GPRS! - PPP ; BTW is channel bonding also possible for mobile phones, I mean using two mobile phones with GPRS to get more bandwidth? And if it's possible how could it be done? Also is there any other way of doing this, with ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Streaming mp3 using GPRS!

  1. Streaming mp3 using GPRS!

    BTW is channel bonding also possible for mobile phones, I mean using
    two mobile phones with GPRS to get more bandwidth? And if it's
    possible how could it be done?

    Also is there any other way of doing this, with something like
    tunneling or similar.? I can manipulate with both, transmitter (pc
    connected to two mobile phones) and receiver (server).

    ...../-m1-----\
    pc - ISP ----server
    .....\-m2-----/

    This is a simple scheme that I need to realise, m1 and m2 are these
    two mobile phones, with ISP I mean mobile service provider and server
    is receiver.

    Forgot to mention that data flow is mainly from pc to server (upload),
    using either UDP or TCP or combination with both of them. Main purpose
    of this is streaming live audio data to server, something similar like
    videoconforencing with 3G networks.

    Sincerely,
    Dave

    > Try a Google search for modem channel bonding


  2. Re: Streaming mp3 using GPRS!


    "Davidson" wrote in message
    news:c7fc94ee.0402250942.93781b1@posting.google.co m...
    > BTW is channel bonding also possible for mobile phones, I mean using
    > two mobile phones with GPRS to get more bandwidth? And if it's
    > possible how could it be done?


    It probably is with the correct software but why would you want to. Put up
    with the slow speed and enjoy broadband at home.



  3. Re: Streaming mp3 using GPRS!

    dlb@flash.lv (Davidson) writes:
    > BTW is channel bonding also possible for mobile phones, I mean using
    > two mobile phones with GPRS to get more bandwidth? And if it's
    > possible how could it be done?


    Do you actually want bonding or multilink PPP?

    The former is an ISDN concept and relies on very tight timing
    tolerances. The latter is just a PPP mechanism (RFC 1990) that can
    make multiple links look like one faster link.

    > This is a simple scheme that I need to realise, m1 and m2 are these
    > two mobile phones, with ISP I mean mobile service provider and server
    > is receiver.


    Multilink PPP doesn't care about the underlying physical layer. It
    should work as well with mobile services as with any other service.
    The only questions are whether your mobile provider actually permits
    multilink operation and whether the implementation you're using
    supports it, and those are things we can't answer. Only your provider
    and you can answre them.

    > Forgot to mention that data flow is mainly from pc to server (upload),
    > using either UDP or TCP or combination with both of them. Main purpose
    > of this is streaming live audio data to server, something similar like
    > videoconforencing with 3G networks.


    Multilink PPP should work ok for that, though if there's delay skew
    among the links, the performance will suffer badly.

    --
    James Carlson, IP Systems Group
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

  4. Re: Streaming mp3 using GPRS!

    In article , James Carlson wrote:
    > Multilink PPP doesn't care about the underlying physical layer. It
    > should work as well with mobile services as with any other service.
    > The only questions are whether your mobile provider actually permits
    > multilink operation and whether the implementation you're using
    > supports it, and those are things we can't answer. Only your provider
    > and you can answre them.


    James is correct with the multilink and bonding issues, but with GPRS
    the PPP link ends at the mobile phone. The protocol layers look something
    like this:

    Client GPRS phone GPRS provider Internet Server
    UDP/TCP/ICMP <--------------------------> (NAT/NAPT) <------------> UDP/TCP/ICMP
    IP <--------------------------> (NAT/NAPT) <------------> IP
    PPP <-------> PPP to GPRS <----> GPRS to ?? <----...-----> ??


    Or a very special case is this where PPP really goes to some network element
    and the Packet Data Protocol (PDP) is set to PPP:

    Client GPRS phone GPRS provider Company GW for ex.
    UDP/TCP/ICMP <------------------------------------------> UDP/TCP/ICMP
    IP <------------------------------------------> IP
    PPP <------------------------------------------> PPP
    GPRS <-----> GPRS to ?? <---> ??

    But this seems to be very rare, usually operators provide only IP connectivity.

    So, to the original question, if you really want multiple GPRS links between
    the client and server, then PPP may not be the right protocol to
    do that, unless you do something as strange as encapsulate PPP into UDP
    or TCP packets and send those between the client and the server, like PPPoUDP
    instead of PPPoE. The Network Address and Port Translation (NAPT) is one,
    that really brakes everything, so UDP and TCP are most likely the protocols
    that can actually reach the server. (But its not uncommon that a bulk GPRS
    service only allows HTTP queries through a proxy, in which case even
    UDP and TCP won't reach the server, sigh.)

    What you'll have with multiple GPRS phones and connections is multiple
    IP network interfaces. With those you can do load balancing for UDP or TCP
    streams and perhaps get the effect you were after, but in my opinion that
    would only be good for throughput (larger in-transit buffer) and would not
    decrease the latencies with GPRS (especially if you use the same GPRS operator
    with the GPRS phones, which most likely puts them in the same cell and the
    basestation and its cell confiquration and shared GSM/GPRS radio interface
    becomes the bottleneck).

    btw. When I got my hands on a working GPRS phone and network connection, the
    first thing we did was to download an MP3 stream from Shoutcast, and the
    20 kbit streams even worked without glitches, using large buffers. The phone
    had something like 1 (x ~9600 bits/s) uplink and 3 (x ~9600 = ~28800 bits/s)
    downlink time slots. These days phones and networks can do better, but the
    basestation cells are more crowded etc, so there you go, you get what you get
    if you get

    -Mikko

  5. Re: Streaming mp3 using GPRS!


    "Mikko Rapeli" skrev i melding
    news:c1j6ti$iuc$1@plaza.suomi.net...
    | In article , James Carlson wrote:
    | James is correct with the multilink and bonding issues, but with GPRS
    | the PPP link ends at the mobile phone. The protocol layers look something
    | like this:

    No, the PPP links ends in the connected pc (or whatever equipent is used).
    The pc dials, ie. ATD*99#, the phone set up the gprs connection and leaves the
    control back to the pc which gets the
    CONNECT xxxxx string (or numerical connect string if selected). From there, ppp
    starts negotiation.

    Regards
    Arne


  6. Re: Streaming mp3 using GPRS!

    In article , Arne wrote:
    > No, the PPP links ends in the connected pc (or whatever equipent is used).
    > The pc dials, ie. ATD*99#, the phone set up the gprs connection and leaves the
    > control back to the pc which gets the
    > CONNECT xxxxx string (or numerical connect string if selected). From there,
    > ppp starts negotiation.


    I think we're talkin about the same thing from different directions. The
    PPP links is used between the user equipment (PC, PDA etc) and the terminal
    equipment (the phone, hope I didn't mess up the 3gpp terms here).

    Do we aggree? =)

    -Mikko


+ Reply to Thread