Telecoms Announce "One Voice" Initiative To Promote LTE Wireless Broadband Stand 39
suraj.sun writes to mention that Long Term Evolution (LTE) networks may have just gotten a boost over WiMax in the battle for wireless broadband dominance. A group of telecom companies has created the "One Voice" initiative, designed to promote a standard that will provide interoperability for broadband voice and SMS. "LTE has been fine at supporting data, which uses IP-based packet switching. But it's faced challenges trying to incorporate traditional circuit-based switching voice and SMS services onto IP-based networks. One Voice is the group's attempt to resolve that issue. The new specification will use existing functionality known as IP Multimedia Subsystem (IMS), which already defines how to provide data, voice, and other content over an IP-based network. IMS was established by the 3rd Generation Partnership Project (3GPP), a group comprised of telecom industry associations trying to set standards for 3G mobile networks."
Some large companies are missing (Score:5, Interesting)
Re: (Score:1)
Sprints Clearwire wimax hardware can be switched over to LTE apparently with just a firmware update.
If LTE takes off, Sprint/Clearwire will almost certainly adopt it.
SMS? (Score:3, Insightful)
Hard to see how SMS is not compatible with packet switching. TFA just seems to say Voice and SMS everywhere as if they were the same thing.
Re:SMS on the Internet, efficiency issues. (Score:5, Interesting)
Well, they have to keep up the whole SMS racket. If each SMS message went through as one IP packet, how could they charge $0.20 each?
Putting SMS on the Internet can be botched. though. Google just did it. Google Voice supports SMS send and receive. Google's site can be queried for SMS in XML and JSON. There's a Python library for this. [google.com] All this works. But Google's returned XML has so much useless dreck in it that each poll returns about 100K of data, even if there's no new SMS traffic. Thus, if you poll every 30 seconds and get no new messages, you use a quarter of a gigabyte a day of bandwidth just polling. So don't do that in an iPhone app to save on SMS charges.
Google needs to put Google Voice on something like RSS, where there's a way to cheaply poll to find out if anything changed. When polling RSS, you send back the ID from the previous poll reply. If you get a 304 status and no data, nothing changed. It would also help if they got the RSS implementation right. Some RSS servers return a new unique ID every time, even when nothing changed. (Twitter, I'm looking at you here.)
There are thus some widely used services which waste vast amounts of bandwidth trying to do by pull and poll what can be cheaply done by push.
Re:SMS on the Internet, efficiency issues. (Score:5, Interesting)
And if you poll, you'll consume so much battery that the iPhone won't make it through a working day. Seriously. In any mobile application (be it iPhone, Android, WebOS or other), you should not poll, and definitely not every 30 seconds, because you'll eat up battery in no time - the CPU and radios just suck power when you do. It's why Apple has the whole push notification deal - getting notified is far better on the battery than polling.
If GV requires this for SMS, then you as app developer should setup a notification server and do the polling there.
And SMS does require special handling since the target may not be awake when you need to push it out. You can't just send it to the phone, you have to send a wakeup to the phone first then send the packet out. In regular GSM, the control channel is what notifies the radio, and the radio handles all the SMS transfer. In IP based network, it may be pushed off onto the main processor to use its IP stack.
Re:SMS on the Internet, efficiency issues. (Score:4, Informative)
Re: (Score:2, Insightful)
That's because the SMS system there was (is?) so broken that people had to use email.
Re: (Score:2)
And if you poll, you'll consume so much battery that the iPhone won't make it through a working day....And SMS does require special handling since the target may not be awake when you need to push it out.
So this stuff isn't really my area of expertise, but insofar as the problem is in the polling/pushing over IP, doesn't it make sense to come up with a generalized solution that can be used freely for things other than SMS? There are lots of things that people want some kind of "push" technology for, including emails, IM, social networking updates, and even file changes. Doesn't it make sense to just make a standard for pushing whatever data needs to be pushed rather than coming up with something special f
Re: (Score:2)
Re: (Score:3, Interesting)
Wait wait wait...
Why are we talking polling with regard to the iPhone?
Iphone and android have push notifications. (Basically sleeping tCP/IP connections similar to Microsoft Active Sync.
You have a TCP connection is opened to the server, and if there is nothing to send the server just doesn't send anything, and the phone shuts down its transmitters.
In 12 to 18 minutes, if no traffic occures the connection times out and drops, the socket becomes readable to the phone, the phone wakes up and creates a new conn
Re: (Score:2)
I was just using the iPhone as an example. I just need an API that accesses Google Voice for SMS. "pygooglevoice" has the right functionality, but once I got it working, I realized that underneath, the efficiency is awful. [google.com]
Eventually Google's developers will figure this out, and either block programmable clients or add an API. Google inherited this thing from Grand Central, which never had that many users, and it needs some rework for scaleup.
Several commercial SMS gateways deliver SMS messages to web
Re: (Score:2)
A simple solution: use a dedicated server (say $30-per-month VPS) to work as an adapter for their clumsy protocols.
Re:SMS? (Score:4, Informative)
Strictly speaking, SMS has more in common with voice than the regular data traffic (email, http, etc). SMS travels across the digital control channel within the broadcast messages for the voice channels. Within the core of the network, it's transported on the SS7 network, which is the control network used for voice. So it is segregated from regular data.
IMS-based instant messaging will adapt fine to a 4G network, but there has to be some sort of standardized SS7 and IP gateway mechanism for the IMS network. It's not hard, but it's easier for operators if there's a reference that the operators can use.
Re: (Score:2)
It's still just a couple hundred bytes. It wouldn't take a genius to encapsulate the exact same data (in both directions) into a UDP packet. All you have to know is an IPv6 (or non-routable IPv4) address of that particular wireless client (which you already have obtained for voice call handling anyway), and the device obviously has to have the IP number for the other end, but you already have an IP-based server for MMS that could handle ACKs and outbound messages on
Re: (Score:2)
Oops. Got those TLAs backwards. I meant to say:
And of course MMS is even easier. It's just a glorified HTTPS request. The only difference is that it occurs in response to a WAP push (SMS). So once you get basic SMS and IP-based networking working, you get MMS support for free.
Oh... my... god. (Score:2)
VOIP? (Score:2)
Re: (Score:2)
Re: (Score:3, Informative)
You have to tax calls, manage pre-paid and post-paid plans. You need to have rules for roaming between operators and types of access, guarantee privacy, but also ensure the the authorities can listen and trace calls if ordered by a court of law. You have QOS, policy enforcement (ex: terminate calls if you have no $$), call forwarding,
And all this must be integrated to other existing operators seamlessly and without braking any existing features.
It is ve
Re:VOIP? (Score:4, Insightful)
Re: (Score:2)
Exactly. If it's an all-IP network, you should just be able to buy a connection from your wireless provider, and buy voice service from whomever you want. That's how it works with fixed Internet connections today.
Re:VOIP? (Score:4, Insightful)
a kilobyte of voice takes exactly the same effort to deliver as a kilobyte of data
Not true. If my voice packets have 200ms of jitter then the conversation will be unintelligible. If my YouTube video data (for example) has 200ms of jitter then I won't even notice.
Re: (Score:3, Informative)
Almost GSM (Score:1)
First we have GSM: made for voice, pefect for voice.
Then HSPA come. And VoIP over HSPA: HSPA is not good enough. So HSPA+ is tried, not good enough for voice.
So we need LTE to deliver voice over IP for IMS in order to have what GSM already provides.
Re: (Score:2)
We need LTE to deliver VoIP to have what GSM provides, but without all the @#$& ELF or SLF radiation from the (@$#$(@( transmitter turning rapidly on and off making every audio device within 30 feet chatter just so it can check in with the tower.
WiMax may have lost its opportunity. (Score:2)
It seems that LTE (4G) is going to fit very well in the core GSM(2G)/UMTS(3G) infrastructure and there's already some fuzz about it.
Re: (Score:2)
Isn't this what SIP is for? (Score:1)
SIP provides the control part of the stream as well as messaging (think SMS or IM). RTP is used along side SIP for media. That media can be voice or video. Throw in some QoS so that the data that is along side the SIP and RTP media doesn't overwhelm the pipe and you have a workable, scalable solution based on open standards. No need to come up with a brand new protocol when one already exists and is in use on IP networks around the world.
Re: (Score:3, Informative)
Firstly, you need stuff to handle routing your call to those on other networks (PSTN, other mobile networks, GSM/UMTS/CDMA/etc).
Secondly you need stuff to handle hand-offs when you walk from the LTE coverage area to a GSM/CDMA/UMTS coverage area.
Also you need to be able to charge differently for voice and messaging (voice on mobile networks also has government taxes and charges that dont apply to data in various parts of the world)
LTE, WiMax, IMS, UMA, One Voice, and VoLGA (Score:5, Informative)
LTE and WiMAX are the main competing 4G technologies. Both LTE and WiMAX are all-IP networks. No circuits. No dedicated channels for voice. If you run voice on 4G it will be packet voice no matter the other technology choices.
One Voice is what this consortium is calling IMS for 4G. IMS uses SIP for signaling. That makes IMS more like the kind of packet voice you find in Asterisk. Except IMS includes a lot of additional standards that, among other things, enables it to replace the signaling used in circuit switched networks and still interface to those networks. Some people favor IMS because it is the officially accepted 3GPP standard for these types of networks. Other people don't like IMS because it is too complicated and includes a lot of stuff that is unlikely to be used, including stuff like using SIP to initiate Web sessions so you can charge for them. Not that anyone would accept that kind of product.
The other consortium that pushing a voice call standard for LTE is called VoLGaA Forum. VoLGA stands for "Voice over LTE General Access." It works like UMA, which is a way of extending the circuit switched mobile signaling over IP. So you can buy these UMA "femtocells" - a really small cell site - and put them in your home or office and hook them up to your Internet service to extend mobile access to those locations. VoLGA is UMA scaled up to the whole network. Pretty suave, especially for the networks that already support UMA - you can re-use a lot of the same systems.
WiMAX never flirted with UMA (as far as I know) and I think most WiMAX networks that support voice will use IMS. Which is what One Voice is promoting for LTE. So that's no disadvantage for WiMAX.
You may be thinking "If it's all packet voice, why don't I put a SIP client on my smartphone and use my company's IP PBX? Or, why don't I use a smartphone Skype app?" That's called an over-the-top service (OTT). Which is why SMS is so... "important" to this discussion: The only thing you lose by using an OTT service, is SMS.