Slashdot Mirror

The cellular AT commands are specified by the 3GPP Open Standard document 27.007.

Anyone can download the latest doc from http://www.3gpp.org/ftp/Specs/...

There was no need to reinvent the wheel because the old Hayes inspired AT command technology could easily be applied to modern cellular devices.

Bluetooth can use AT commands for transferring contact information between devices and therefore AT commands are not restricted to the USB to serial interface. In other words, Bluetooth can provide virtual serial links over the Bluetooth radio link which I suspect an attacker would like to exploit remotely.

When implementing an AT command interpreter, care is needed to not allow unauthorised entities from executing actions that are deemed to be dangerous to the integrity of the system.

However, vendors can create their own vendor specific commands. That can be a weakness because they won't be tested in conformity testing for 27.007 and other AT command specifications.

here are the E-UTRA/LTE/LTE Advanced specifications. They very much exist.

There seem to be no place to put even a single 500MHz channel anywhere below 6GHz, yet alone a 2GHz one?

Harmonization in "4G" LTE is called carrier aggregation.

Get this Zip and open the MS Word doc inside, both with LibreOffice and MSO. Compare and report.

There's hundreds of other snags, either related to compatibility, missing functionality, usability or plain correctness that make LO too unreliable for certain purposes. Yes, the last one was eventually fixed, in version 4.2.

Hi there. I'm not following 3G closely but in LTE the encryption schemes are secure. You have two options, both 128 bits: SNOW 3G (inherited from 3G as you can guess ;) and an AES scheme. Both secure as of today. In R10 or R11 a Chinese scheme called ZUC has been added too, also 128 bits. The operator decides on which scheme is used, and the device must support both SNOW 3G and AES today.

The big thing is that the encryption is between the device and cell (base station). The assumption is that the cell is secure, and behind the operator network is secured by other means. So it's important to protect the cell (eNB in LTE) against compromises. A fake cell won't work as in LTE the authentication is mutual: the UE won't work with any cell, except for an emergency call.

For more details have a look at the 3GPP 33.401 spec, for example the latest R9 version.

you are mixing stuff up, very badly. '4G' LTE is an overall product, CDMA or WCDMA is a only a wireless system.

LTE is an overall product that doesn't use CDMA for its air interface; instead, it uses OFDMA.

That's correct, it's done geographically, there is not a big federal list of each person's phone number. For example, take a look at 3GPP TS 25.419 (SABP). This is the interface between the CBC and an RNC (UMTS). http://www.3gpp.org/ftp/specs/html-info/25419.htm The broadcast request message is called Write-Replace. There are similar protocols between the CBC and BSCs (GSM).

LTE-Advanced did qualify for 4G,

http://www.3gpp.org/ITU-R-Confers-IMT-Advanced-4G

but it's just a set of standards for now afaik, that still need to be implemented.

The root cause of this weakness is that whereas the 2G network can authenticate the handset (both the SIM and the ME), the handset cannot authenticate the network. It's assumed the 2G network is trustworthy, which in this case, it isn't. There's a stack load of problems with 2G (GSM) security including unilateral authentication, which leads to network impersonation; weak encryption (short keys and broken algorithms); lack of end-to-end or virtually end-to-end encryption; weak confidentiality; no data integrity algorithms; lack of visibility to the user that encryption is on, etc. A lot of these are fixed in 3G. See http://www.3gpp.org/ftp/tsg_sa/WG3_Security/_Specs/33120-300.pdf and http://www.arib.or.jp/IMT-2000/ARIB-spec/ARIB/21133-310.PDF. In this second PDF, section A.4 Hijacking of services describes this attack.

This isn't necessarily true. Operators can use ciphers of their choice for functions that occur within the SIM card (such as authentication and key derivation), but data sent over the air can only be encrypted with Kasumi or (since UMTS Rel-7) Snow 3G. http://www.3gpp.org/ftp/Specs/html-info/33102.htm

All 3G cards I've seen have used rijndael (AES).

ridiculous! if your coders suck... fire them.

You certify the end products via third party testing (like GSM cell phones GCF testing!) to ensure quality.

http://www.3gpp.org/ftp/Specs/html-info/51010-1.htm

Mobile networks are actually pretty robust, and the standards and protocols are indeed open (GSM/UMTS, OMA).

Nevertheless, mobile phones are usually sold as locked black boxes because:
1. Government regulations require that equipment must not be able to use frequencies other than those they are licensed to;
2. The same regulations require that transmit power be limited to a safe level; and
3. Mobile carriers want to be able to enact anti-competitive measures (SIM locking) and/or screw consumers (disabling software features).

Hmm, you could be right, not sure. I was thinking of 3GPP 21.111, section 9 "Electrical characteristics and transmission protocols":

"Electronic signals and transmission protocols shall be in accordance with the specifications in TS 31.101.
The electrical specifications shall at least cover the 1.8V and 3V voltage ranges as specified in GSM 11.12 [9] and GSM 11.18 [10]. Lower voltages may be added in the future. 3G terminals shall not support 5V on the ME-UICC interface."

Linky: http://www.3gpp.org/ftp/Specs/latest/Rel-6/21_series/21111-630.zip

For GSM R99, 5V is specified, but that is quite old. For 3G, looks like terminals are required not to support 5V SIMs, so I'd expect lower voltage only SIMs to follow suit. I could be completely wrong though!

Mike
PS: I was joking about the soldering - if that's really you, thanks for making the video; I liked it.

Furthermore, the ITU---and telecomms in general---aren't exactly known for good, simple (cheap to implement from scratch) protocol design. They tend to produce overcomplicated beasts like OSI, GSM, and ASN.1.

Why anyone in-the-know would want to leave Internet protocols in the hands of the telecomms is a mystery to me.

Poor receive sensitivity? Maybe. Phones only have to do better than -104dB to pass FTA testing, per 3GPP TS 45.005 . But the best performing phones can achieve up to -111dB for low bands and maybe 1dB worse for high bands.

Low transmit power? Not likely. 3GPP specs in link above (see section 4.1.1) dictate that handsets must be within 2dB of target output power under normal conditions (room temp, nominal battery voltage) and 2.5dB under all conditions. All handsets are calibrated on the manufacturing line to meet output power targets, and manufacturers typically calibrate each power level to [target - 0.5dB].

A5 is helpful and should help keep amateurs out when in use (it's upto the network to switch it on), but it's not end to end encryption which would be needed to get around the lawful interception interface specified in GSM networks - the 3GPP spec is here: http://www.3gpp.org/ftp/Specs/latest/R1999/01_seri es/0133-800.zip

Note section 4.2, "Background Technical Requirements":

3) The X3-interface receives "Product" (mobile user's speech and data) from the MSC. It is contained within one or more 64 kbit/s channels.

He recognises that a DRM (protection) system that is transparent to the user would be an advantage to them. After all the DVD's CSS does exactly that, were it not for the unfortunate "region code".

No, Leonardo, the DVD CSS system is *not* transparent to the user, especially if you are using a Free Software operating system. I agree that the region-coding is sucky, and several multi-region settop boxes exist, but you didn't go far enough: the DVD CSS scheme (and the DRM schemes on HD-DVD and on Blu-ray) are NOT transparent to all users out there.

Let's continue...

The way to go is to have a standard system like GSM that anybody can practical [sic] implement

• The basic standards seem to be freely available (although their answer to this question is damn cryptic!): "Does a company implementing..have to pay any royalties..?", Answer: "[3gpp] is not a legal entity but a Partnership...between...standardization organizations in the field of telecommunications."
• The GSM specs seem to include patents which are RAND (Reasonable And Non-Discriminatory) licensed. AFAIK, RAND licensing is incompatible with most Free Software licenses...

So again, no, Leonardo. GSM is *not* an Open Specification that anyone can implement. It is encumbered with patents.

Continuing, we have:

do you think that we would have had the MP3 phenomenon without the MP3 standard or the billions of video files taken by cell phones - and shared - without the MP4 standard?

Yes, I think that the "personal" music and video revolutions could have happened without the specific MP3 and MP4 standards. Having a standard enables people to share audio and video, true. But even if those standards weren't ones that were patent-encumbered (such as MP3 and MP4), the revolution would have taken place once the hardware (iPods, cell phones, digital cameras) were small enough and portable enough for people to take with them everywhere.

It would be really hard to define a "one size fits all" DRM standard.

Actually, I think it would be easy: Let people license their files however they want, but don't encrypt, watermark, or otherwise f*ck with the contents of the files. That is to say, take the "restriction" out of DRM.

Leonardo Chiariglione sounds like a smart guy who is trying to work on creating international standards, and for that I applaud him. But I'd like him to go a bit farther and to make TRULY OPEN standards that anyone can implement, for any reason, on any hardware, without paying anything...that's what a standard should be -- not something locked down with encumbrances that prevent people from using it.

OH DEAR GODS! Word is not desktop publishing software! Please, please, please understand that.

Tell that to standards groups that release their specs in Word format (3GPP, I'm looking at you).

Such a PITA if you only want to print out 1 page, but Word has to paginate the umteen pages to figure out what is the current page.

Can you cite a source for this information? I'm guessing no, since it is inaccurate. In fact you have it backwards, US GSM carriers typically have network time sync, while European carriers do not. Please look up NITZ, it stands for Network Identity and Time Zone and is used on GSM networks. According to the NITZ spec:

"As a network option, it shall be possible to send universal time (UT) by the network. Time information shall include:Year, Month, Day, Hour, Minute, Second, and Timezone and DST. The expected accuracy of the time information is in the order of minutes."

You can also search Howard's Forum to see that both Cingular and T-Mobile support NITZ. Please check your sources next time.

Can someone enlight us with the quality and/or bitrate of 3gp videos? TFA and the wikipedia link are light on details.

The switching is between GSM/UMTS networks and WiFi alright, but not just any WiFi network. It must owned by a (mobile phone) operator with their equipment on it. You get nominally the same service as on their radio network (including data encryption, authentication), albeit faster packet data transfer--and you also get charged appropriately. It's just a different air interface.
See 3GPP TS 22.234, Requirements on 3GPP system to Wireless Local Area Networking (WLAN) interworking.

The reason they have "overhead" is that they use the (limited) control (signaling) channel. I understand SMS was added to the GSM standard late-ish in the design process.

If you're feeling masochistic, have a look at the spec here.

Don't know about the Far East, but in Europe it might have something to do with 3GPP dictating pretty much all the standards and heavy government regulations, there's less time spent letting the market decide something basic like "how do we all talk to each other?" (a question which your average customer is singularly unqualified to answer) and more time spent trying to differentiate your product from everyone elses.

Result: products compete on useful features.

it isn't?

that's news to me and likely hundreds of others that use it daily

Where'd you get that impression?

MPEG-4 is the basis of the 3GPP andstandards for cell phones in japan, and KDDI's ezmovie system (not sure if it's a competing standard, or just something that predates the standard).

In fact, MPEG4 makes less of a difference when compared to MPEG2 on high res content than on low res content.

you know, if you really are up to that, you must think of a SIM card as a small (16-64k) filesystem.

Files are organized into a tree structure in directories and protected (read, write..) by PIN codes. Files can be seen as fixed size arrays of fixed siez strings. The GSM standard specification (GSM 11.11) says that, and what information can be found where. (example, on the directory 'GSM' - which is really a filenumber on the sim instead of a filename), you'll have the last number dialled (LDN file).

the procotol used to open/read files is fairly open.

That's it. So what's so special to write such a program ? You need e.g. serial access to the card interface, the SIM specification, and a small script language, then a few hours later, voila.

(or you could put the SIM card in a phone and check the information)

What you don't have is access to the pin protected information, and good luck to attack those since all european telco industry relies on this.

- a common signal structure for so-called "open" services, and a suitable signal structure for the Galileo Public Regulated Service (PRS).

- a process allowing improvements, either jointly or individually, of the baseline signal structures in order to further improve performances.

- confirmation of inter-operable time and standards to facilitate the joint use of GPS and Galileo.

This sounds like an effort towards standardisation. Something the EU and the rest of the world are pretty good at.

See ITU and 3GPP. And of course IETF. ;)

It is good to see that US is seeing the values and benefits of standardisation.

• ARIB - Japan
• CWTS - China
• ETSI - Europe
• T1 - US
• TTA - Korea
• TTC - Japan

They are interested in using SIP for 3rd generation wireless technologies.

the killer feature that hasn't emerged is a single, high speed, world-wide data standard.

You mean 3G aka 3GPP or UMTS.

Except it has been subverted by business interests and stakes such as W-CDMA, and CDMA2000, and patents held by Qualcomm.

The telecomms industry could do with starting from the ground up (rather than building off the technologically suspect CDMA or GSM systems) with a new, open standard 100% packet based network with IP6 support - then and maybe then the internet (and related services) on a mobile level could become a killer app. Until then they would be best off sticking to voice calls and massivly overcharging for SMS.

Oh boy, flame on.

It might be worth having a rummage on 3GPP to see what's really going on. Yes, there will be support for packet switching, but also for circuit switching - because that's an efficient use of the bearer for voice traffic. There are measures to improve latency. 3G also has to deal with mobility management (moving from cell to cell), roaming, and session maintenance while switching between UMTS and GSM/GPRS. None of it is simple, and IP6 only addresses a tiny fraction of these issues.

Of course, just like in 3G, that doesn't mean that *you* will get that speed, just that it is technically possible to get that much bandwidth in a cell.

Or, as one wag I know put it: those 386kbit/sec (for Euro style 3G) or 150kbit/sec (for Sprint) are the guaranteed not-to-exceed speeds, never seen in the wild...

In Europe, "3G" (third generation) technologies were supposed to transform the economy, turning cell phones into mini-entertainment centers, but reality failed to live up to the hype.

Its difficult to say that '3G' or UMTS to be exact has failed in Europe, as most have not yet launched due to the financial strife in the telecoms sector limiting investment into the new infrastructure. In fact Hutchinson's Three (UK's first UMTS network) will be going live soon

Granted this pressure has resulted in GPRS '2.5G' becoming more widely adopted, and this can provide many of the benefits of UMTS as far as the user is concerned such as reasonable speed mobile data access, whilst being a step upgrade to the GSM netwrok so cheaper to role out and not needing thousands of new masts (UMTS needs masts in different physical locations as it uses a different radio system - see later)

In this respect Europe is in a more fortunate than the US as GSM digital cellular networks have become the standard, so the upgrade to GPRS is a logical one.

The growing interest in EvDO adds to the momentum of Qualcomm's CDMA (Code Division Multiple Access) standard that is now used by some of the largest wireless companies, including Verizon and Sprint Corp

This is a strange tack to take, given the dismisal of '3G' as a failure a few lines before.

In Europe the new standard chosen to replace GSM was UMTS, which is based on a CDMA radio sub system. This is a spread spectrum method which brings many benefits, but means you need new masts as the radio coverage is different.

In the US you have Qualcomm's CDMA 2000 system which will evolve into the W-CDMA standard

In practical aspect these are equivalent systems, at least as far as the radio engineering goes - the differences mainly being in how the networks are run and how data is transfered, the underlying carrier technology is very similar, and infact most of the equipment is the same, differing only in the management systems.

So in Europe the delayed roll out of UMTS can be seen really as a factor of the depressed state of the telecoms market, and the fact that the cheaper to roll out GSM based GPRS system gives you high speed data access.

In the US there is no easy upgrade from an existing network as GSM didn't make much of an inroad and the better range in fringe areas of analogue systems like TACS is more suitable to the larger country.

Realistically the only way for the major equipment providers to realise the return on investment of thier CDMA technology is to go after the one thing the alternatives don't do well, the domain of large scale wireless data access.

In Europe, "3G" (third generation) technologies were supposed to transform the economy, turning cell phones into mini-entertainment centers, but reality failed to live up to the hype.

Its difficult to say that '3G' or UMTS to be exact has failed in Europe, as most have not yet launched due to the financial strife in the telecoms sector limiting investment into the new infrastructure. In fact Hutchinson's Three (UK's first UMTS network) will be going live soon

Granted this pressure has resulted in GPRS '2.5G' becoming more widely adopted, and this can provide many of the benefits of UMTS as far as the user is concerned such as reasonable speed mobile data access, whilst being a step upgrade to the GSM netwrok so cheaper to role out and not needing thousands of new masts (UMTS needs masts in different physical locations as it uses a different radio system - see later)

In this respect Europe is in a more fortunate than the US as GSM digital cellular networks have become the standard, so the upgrade to GPRS is a logical one.

The growing interest in EvDO adds to the momentum of Qualcomm's CDMA (Code Division Multiple Access) standard that is now used by some of the largest wireless companies, including Verizon and Sprint Corp

This is a strange tack to take, given the dismisal of '3G' as a failure a few lines before.

In Europe the new standard chosen to replace GSM was UMTS, which is based on a CDMA radio sub system. This is a spread spectrum method which brings many benefits, but means you need new masts as the radio coverage is different.

In the US you have Qualcomm's CDMA 2000 system which will evolve into the W-CDMA standard

In practical aspect these are equivalent systems, at least as far as the radio engineering goes - the differences mainly being in how the networks are run and how data is transfered, the underlying carrier technology is very similar, and infact most of the equipment is the same, differing only in the management systems.

So in Europe the delayed roll out of UMTS can be seen really as a factor of the depressed state of the telecoms market, and the fact that the cheaper to roll out GSM based GPRS system gives you high speed data access.

In the US there is no easy upgrade from an existing network as GSM didn't make much of an inroad and the better range in fringe areas of analogue systems like TACS is more suitable to the larger country.

Realistically the only way for the major equipment providers to realise the return on investment of thier CDMA technology is to go after the one thing the alternatives don't do well, the domain of large scale wireless data access.

but don't we first need a common voice protocol that is agreed upon and used by all?

That would be the idea, phone companies don't provide services that don't eventually result in mucho dinero. "Analysts" claim MMS (the standard adopted by 3GPP) will out-grow and replace SMS as the dominant mobile messaging tool. Of course SMS was a success by accident, kids / teens / geeks discovered it was a cheap silly way of almost instant messaging on the go. MMS is more expensive both to the user and operator so one could argue the business model is flawed.

Regarding Ogg + MPEG-4 video. The licensing terms for MPEG-4 Video are pretty gnarly. How about Ogg and H.263+ (which, incidently, is what the 3GPP standardized on). That combination nearly works today in Helix DNA Client. We're already committed to making this available in our mainline products like RealOne Player and Helix Universal Server.

Regarding Ogg + MPEG-4 video. The licensing terms for MPEG-4 Video are pretty gnarly. How about Ogg and H.263+ (which, incidently, is what the 3GPP standardized on). That combination nearly works today in Helix DNA Client. We're already committed to making this available in our mainline products like RealOne Player and Helix Universal Server.

The headline should be "3GPP Becoming Mobile-Phone Standard", and it's not all that surprising, but it's very good news for everyone (including RealNetworks, where I'm from). We've been doing a lot of work in the 3GPP, and it's great to see that work paying dividends. If you really want to find out what this stuff is about, look at the spec (and yes, I hate the fact that these are Word docs in zipfiles as much as anyone).

Much of the confusion around this subject comes from a lack of understanding of the difference between .mov, .mp4, and .3gp. DoCoMo's announcement was good news for 3GPP, and given the support throughout the Helix platform for 3GPP formats, codecs, and protocols, we view it as great news for the Helix Community.

As another poster pointed out, only a piece of 3GPP is based on Quicktime is the container file format itself (the bit that says "here's a 3000 byte chunk of data with this 32bit codec identifier"). Another piece (the protocol) is based on work RealNetworks pioneered (RTSP). Moreover, the Helix DNA Client supports the 3GPP specification today.

RealNetworks added MPEG-4 and 3GPP support 10 months ago with the RealSystem Mobile Server (see press release),
and MPEG-4 support will be included in the Helix DNA Server when it is released in the near future.

As for the speculation about Apple releasing 3GPP encoding support, we would welcome them to the party. In early November we announced that a version of our Producer product for creating 3GPP content will ship in Q1 of 03. (see press release) Moreover, we offer our encoding framework as open source (and naturally open APIs) so that you can add support for whatever format you want to. We've given you a head start by implementing Ogg Vorbis support.

Again, the new phones sound great. Lots of new devices for Helix encoders and servers to work with.

The headline should be "3GPP Becoming Mobile-Phone Standard", and it's not all that surprising, but it's very good news for everyone (including RealNetworks, where I'm from). We've been doing a lot of work in the 3GPP, and it's great to see that work paying dividends. If you really want to find out what this stuff is about, look at the spec (and yes, I hate the fact that these are Word docs in zipfiles as much as anyone).

Much of the confusion around this subject comes from a lack of understanding of the difference between .mov, .mp4, and .3gp. DoCoMo's announcement was good news for 3GPP, and given the support throughout the Helix platform for 3GPP formats, codecs, and protocols, we view it as great news for the Helix Community.

As another poster pointed out, only a piece of 3GPP is based on Quicktime is the container file format itself (the bit that says "here's a 3000 byte chunk of data with this 32bit codec identifier"). Another piece (the protocol) is based on work RealNetworks pioneered (RTSP). Moreover, the Helix DNA Client supports the 3GPP specification today.

RealNetworks added MPEG-4 and 3GPP support 10 months ago with the RealSystem Mobile Server (see press release),
and MPEG-4 support will be included in the Helix DNA Server when it is released in the near future.

As for the speculation about Apple releasing 3GPP encoding support, we would welcome them to the party. In early November we announced that a version of our Producer product for creating 3GPP content will ship in Q1 of 03. (see press release) Moreover, we offer our encoding framework as open source (and naturally open APIs) so that you can add support for whatever format you want to. We've given you a head start by implementing Ogg Vorbis support.

Again, the new phones sound great. Lots of new devices for Helix encoders and servers to work with.

The headline should be "3GPP support to your cell phone", and it's not all that surprising, but it's very good news for everyone (including RealNetworks, where I'm from). We've been doing a lot of work in the 3GPP, and it's great to see that work paying dividends. If you really want to find out what this stuff is about, look at the spec (and yes, I hate the fact that these are Word docs in zipfiles as much as anyone).

Much of the confusion around this subject comes from a lack of understanding of the difference between .mov, .mp4, and .3gp. DoCoMo's announcement was good news for 3GPP, and given the support throughout the Helix platform for 3GPP formats, codecs, and protocols, we view it as great news for the Helix Community.

As another poster pointed out, only a piece of 3GPP is based on Quicktime is the container file format itself (the bit that says "here's a 3000 byte chunk of data with this 32bit codec identifier"). Another piece (the protocol) is based on work RealNetworks pioneered (RTSP). Moreover, the Helix DNA Client supports the 3GPP specification today.

RealNetworks added MPEG-4 and 3GPP support 10 months ago with the RealSystem Mobile Server (see press release),
and MPEG-4 support will be included in the Helix DNA Server when it is released in the near future.

As for the speculation about Apple releasing 3GPP encoding support, we would welcome them to the party. In early November we announced that a version of our Producer product for creating 3GPP content will ship in Q1 of 03. (see press release) Moreover, we offer our encoding framework as open source (and naturally open APIs) so that you can add support for whatever format you want to. We've given you a head start by implementing Ogg Vorbis support.

Again, the new phones sound great. Lots of new devices for Helix encoders and servers to work with.

The headline should be "3GPP support to your cell phone", and it's not all that surprising, but it's very good news for everyone (including RealNetworks, where I'm from). We've been doing a lot of work in the 3GPP, and it's great to see that work paying dividends. If you really want to find out what this stuff is about, look at the spec (and yes, I hate the fact that these are Word docs in zipfiles as much as anyone).

Much of the confusion around this subject comes from a lack of understanding of the difference between .mov, .mp4, and .3gp. DoCoMo's announcement was good news for 3GPP, and given the support throughout the Helix platform for 3GPP formats, codecs, and protocols, we view it as great news for the Helix Community.

As another poster pointed out, only a piece of 3GPP is based on Quicktime is the container file format itself (the bit that says "here's a 3000 byte chunk of data with this 32bit codec identifier"). Another piece (the protocol) is based on work RealNetworks pioneered (RTSP). Moreover, the Helix DNA Client supports the 3GPP specification today.

RealNetworks added MPEG-4 and 3GPP support 10 months ago with the RealSystem Mobile Server (see press release),
and MPEG-4 support will be included in the Helix DNA Server when it is released in the near future.

As for the speculation about Apple releasing 3GPP encoding support, we would welcome them to the party. In early November we announced that a version of our Producer product for creating 3GPP content will ship in Q1 of 03. (see press release) Moreover, we offer our encoding framework as open source (and naturally open APIs) so that you can add support for whatever format you want to. We've given you a head start by implementing Ogg Vorbis support.

Again, the new phones sound great. Lots of new devices for Helix encoders and servers to work with.

I am talking about two things (you seem to be the only to have noticed. Bravo):

- accessing my own data
- making my own data accessible to other

In terms of technology versus standards, GUPster is the bastard child (yet to be born) of GUP and Napster. And GUP (Generic User Profile) is an on-going 3GPP standard.

I think the problem (actually the two problems) need to be tackled from both ends: standards and technology.

We all know that "3G" and "4G" are such important, well defined engineering terms.


3G is shorthand for "3rd Generation Partnership Project (3GPP)"

Supposeldy 'true' 3G offers 384 kbit/s downstream...

No, true 3G only requires 144kbit/s, according to the industry body that decides what is and what isn't 3G, 3GPP.

1. It IS true 3G, according to The 3G Partnership Project. If I recall correctly, the System had to offer speeds of 144K minimum to qualify, and the Sprint System does that, at least in theory.

2. Sprint is not the first one. Not even in the U.S. 3G has already been deployed in Japan and in Korea. In the U.S., Verizon has been offering it since the beggining of '02. What Sprint has done is be the first to offer it NATIONWIDE (meaning, wherever Sprint offers service), whereas Verizon offers it only in select markets, and it's slowly being rolled out nationwide.

3. There is no surprise. Even a full year ago, Sprint kept saying that they would roll out 3G in the Fourth Quarter of '01, which we in the industry [full disclosure: yes, I work in the telecom industry, but no, I have no dealings/stock/insider information/business with Sprint other than using them as my mobile phone provider.] thought was bull, and sure enough, they delayed it first to July 4th, when they were supposed to have a big promotional tie in with MIB2, but in June they postponed even that date and just said they'd go live somewhere in the "summer of '02".

Uh... not really. What AT&T rolled out was GPRS, which is 2.5 G, not 3G.

And before the flames arrive about what is 2G and what is 3G, that my granpa heard this columnist say it wasn't really 3G, and all that junk, there is an Industry Partnership that determines what consitutes 3G, and they determined a while back that 1XRTT (What Sprint is deploying) IS 3G.

I would suggest you skip the GSM and go for the next generation, 3G , instead.
Converting to GSM now then the rest of the world is just about to convert to 3G sounds... dumb.

MMS: Multimedia Messaging System -- this allows you to send email with audio/amr attachments, so you can play them with open source code from public 3GPP technical standards TS 26.071, TS 26.073, TS 26.101 and TS 26.074.

AMR is a truly great vocodec technology, which stands for "Adaptive Multi Rate." Accordingly, it takes less bandwidth and battery time because when the microphone isn't picking up sound (from, e.g., your speech) your phone isn't sending as much information. Just the way it ought to be. Why spend 4 kbps to send comfort noise when 20 bps can do just as well? Execellent code!