EDGE Voice & Data Simultaneously, Possible Solution For Carriers

[Geniusdog254]

OK, if you're like me then the iPhone sending calls to voicemail while browsing the web is unacceptable. I have a solution that if carriers would take the time to implement would allow simultaneous voice and data on EDGE. Now, bear in mind I don't know about the code they use, or how they could implement it, but it WOULD WORK. OK, now if you pause the data packet while the voice call comes in the phone would ring. If you were really creative you could implement it to where it sends one data packet, pauses data, and then sends a voice, and then repeat = simultaneous voice and data. But I know it can be implemented quite easily in VB 2008 (Yes I know they don't use that but I don't know C++ or Assembly or anything but .NET) For instance;

// Sets up variables for call detection
Private bool InComingCall = false
Private string curPacket
Private bool CallDeclined = false
// Checks for incoming calls and pauses if detected
If InComingCall = true Then PauseDataPacket
Private Sub PauseDataPacket()
{
        // Saves the current packet to curPacket string and stops sending data
        SndPacket.CurrentPacket.ToString(curPacket)
        SndPacket.Stop()
}
// If the user declines the call then restart sending data
If CallDeclined = true Then ResumeDataPacket()
Private Sub ResumeDataPacket()
{
        // Start sending prom the previous packet
        SndPacket.Start(curPacket)
        // Clean up variables
        InComingCall = false
        CallDecline = false
}

And there we go, that, in the right language whatever it may be, implemented on the tower and the phone, then it will pause the data and let the user choose to accept the call or not, and if not resume it, I know it's a little rough, but I wrote that in 5 minutes outta my head. Correct me if I'm wrong, I don't know much about cell systems, but would this not be pretty easy for Apple and the carriers to implement.

 

[diamond.g]

OK, if you're like me then the iPhone sending calls to voicemail while browsing the web is unacceptable. I have a solution that if carriers would take the time to implement would allow simultaneous voice and data on EDGE. Now, bear in mind I don't know about the code they use, or how they could implement it, but it WOULD WORK. OK, now if you pause the data packet while the voice call comes in the phone would ring. If you were really creative you could implement it to where it sends one data packet, pauses data, and then sends a voice, and then repeat = simultaneous voice and data. But I know it can be implemented quite easily in VB 2008 (Yes I know they don't use that but I don't know C++ or Assembly or anything but .NET) For instance;

And there we go, that, in the right language whatever it may be, implemented on the tower and the phone, then it will pause the data and let the user choose to accept the call or not, and if not resume it, I know it's a little rough, but I wrote that in 5 minutes outta my head. Correct me if I'm wrong, I don't know much about cell systems, but would this not be pretty easy for Apple and the carriers to implement.

Sounds cool, too bad it wouldn't work. GSM/EDGE has a spec to use voice/sms and data at the same time, but it looks like it would require two radios to work. As it is data connections are like phone calls that have call waiting disabled. I don't know if you can enable call waiting while using the data connection. I guess the best thing they could do is reserve the SMS channel and transmit call requests over it.

 

[macduke]

Congrats. You took a class on VB 2008? You know how to do if/then statements! Yay. But let me assure you, its way more complicated than you think. The way I understand it is that when downloading data on EDGE, there is no way for the phone to even tell if a call is coming in because the access to the radio is being blocked by the data connection. Its kind of like how you used to not be able to get phone calls while using your modem back in the 90s. Perhaps if the phone had two radios then you could. I'm pretty sure AT&T has some pretty good programmers that would have thought of this already.

Sorry if I came off as rude, it just reminded me of the sample programs we had to do in class back when I was learning VB6 in high school. Those were the days, waiting for programs to compile on the Pentium II's and then getting stuck in infinite loops.

*sigh*

 

[Geniusdog254]

OK, I understand the concept of how it's blocked like a modem on dialup, believe me i'm stuck on it. But if it is implemented on the tower end, to where it would stop sending data if it needed to send a call, in other words, nothing added on the phone, all tower side, once the phone finished downloading the data then the radio would be open, correct? Then it can send the phone call, and if the user declines it or once its finished then the tower goes back to the data call. I just wish Apple had thought of using 2 radios, yes it would add to cost, but if cost is an issue either save your money or don't buy the phone, don't sacrifice quality so cheap people can get it.

And I didnt take a class on VB 2008, I taught myself

 

[feelthefire]

OK, I understand the concept of how it's blocked like a modem on dialup, believe me i'm stuck on it. But if it is implemented on the tower end, to where it would stop sending data if it needed to send a call, in other words, nothing added on the phone, all tower side, once the phone finished downloading the data then the radio would be open, correct? Then it can send the phone call, and if the user declines it or once its finished then the tower goes back to the data call. I just wish Apple had thought of using 2 radios, yes it would add to cost, but if cost is an issue either save your money or don't buy the phone, don't sacrifice quality so cheap people can get it.

And I didnt take a class on VB 2008, I taught myself

The towers have no "smart" abilities. They deal exclusively with receiving and relaying signal. There's no place to IMPLEMENT any code, it's hardware.

the only way to do it is with 2 radios, and even then, it requires a hell of a lot of code in the phone to give it specific instructions on which radio to use when, which is why it's not been done before.

It wouldn't just add to cost, it would suck the battery down to pieces twice as fast.

 

[jettoblack]

Sure, you could do it if you made a ton of non-standard changes to the GSM spec and to the towers' hardware and software and to every phone. While you were at it, you could bump up the data speed as well. You'd have to give it a new name though, since it wouldn't be compatible with any of the GSM equipment out there. I guess you could call your new standard UMTS (aka 3G).

 

[rogersmj]

Congrats. You took a class on VB 2008? You know how to do if/then statements! Yay. But let me assure you, its way more complicated than you think. ... I'm pretty sure AT&T has some pretty good programmers that would have thought of this already.

My thoughts exactly.

Sorry if I came off as rude, it just reminded me of the sample programs we had to do in class back when I was learning VB6 in high school. Those were the days, waiting for programs to compile on the Pentium II's and then getting stuck in infinite loops.

*sigh*

I don't think you came off very rude...I saw this thread when it was posted yesterday and I was trying to think of a way to say what you said, but I think it would have come out way worse. I have a computer science degree, and one of my pet peeves is non-programming experts saying "Couldn't you just...?" As in, "Couldn't you just make it do this? It's so simple." No, it's pretty much never that simple.

I'm not saying this isn't worth having a discussion about...but anyone who learned one tiny little facet of programming and then comes on the 'net saying they have "found" a solution for a problem that (undoubtedly) thousands of professionals haven't...well, it reeks of ignorance and arrogance.

If we just want to talk about why it wouldn't be that simple...well, my completely uneducated guess is that it has to do with both the infrastructure of GSM/EDGE networks and the realty of radio technology. As someone else mentioned, it's probably not possible to be running programs sophisticated enough to examine packet headers (and determine if a packet is a call or data) on the tower transmitters themselves. Those things on the towers are just like giant walkie-talkie radios (subdivided into thousands of channels) -- they just broadcast and receive, and send everything back to the mothership. Once a signal is already going out on a channel, that's it -- only one at a time. And they're not going to want the incoming call to keep polling again and again until there's an opening in the radio transmission -- that would cause delays and use more bandwidth, and possibly clog some things up with collisions (although it's just as likely they have an efficient way to deal with those, like I said I'm guessing based on my limited knowledge of cell networks).

 

[kdarling]

EDGE radios can only do one thing at a time: voice or data.

But as has been pointed out before, there is a way to receive calls during EDGE data transfer... if the cell is using NOM-1 (Network Operating Mode type One) and if the phone itself is prepared to handle it.

Paging signals (incoming calls and SMS) are sent via voice channels. (In this case, channel refers to a mode and type of packets.)

Data is sent using data channels. While transceiving data, it can see only data packets, so there is no normal way for the phone to get the voice paging signal.

With NOM-1, a paging flag is piggybacked on a data signaling channel, so the phone can see the incoming call while doing data transfers. It can then pause and ask the user what to do.

I realize this is not what you're looking for, but it's what is supported right now.