GPRS has standardised a means of supporting simultaneous speech and data calls, but there is no device available today which implements this protocol enhancement (it's called Dual Transfer Mode, for those who are interested)
Since DTM has only just finished being standardised, it's a bit unfair to complain that no devices (or, indeed, networks) support this as yet.
For the moment, most GPRS networks operate in so-called Network Mode of Operation 2 (NMO 2). This means that you can receive voice call paging only when an active transfer is not in progress, but that you mac make calls at any time, and can receive calls when there is no TBF present (which basically equates to no IP packets flowing).
NMO 1, which will likely come to some commercial networks by year end, allows you to receive voice calls in both transfer and idle mode.
I believe that no network has deployed NMO 1 commercially as yet. If anyone knows differently, I'd love to know (and to know where!)
It depends on what you mean by security. All of the cellular data standards have standardised some form of encryption for over-the-air data.
While not as secure as 1024 bit PGP, they are sufficient to prevent unencrypted data (e.g. POP3 login info) from being captured easily by sniffing packets over the air, and are generally rather better designed from a security standpoint than WEP (GSM uses public key challenge-response mechanisms to exchange sipher keys, and encrypts all GPRS data packets and most signalling; CDMA2000 doubtless does likewise, but I'm less expert in the details).
However, all cellular technologies end up putting your IP packets on the Internet. If they are not encrypted end-to-end, then they are indeed vulnerable to attack from within the Internet itself, but there's really nothing your phone provide can do about this. You can run end-to-end encrypted VPN solutions on all of the cellular technologies (if your provider chooses to open the appropriate ports to let you do so, of course, but that's a commercial issue). I can happily run end-to-end encrypted VPN to my employer over GPRS, and others at work do so over CDMA 2000.
As a summary, for normal, reasonable purposes, the over-the-air encryption on all current cellular technologies is sufficient to protect packets from being sniffed by RF means - in this respect they are rather more secure than WiFi. If you're really concerned about security, you should be running end-to-end encryption anyway.
A thought provoking and intelligent post, which I'd moderate up if I wasn't already a contributor in the thread. Think you've misunderstood how cellular phones operate somewhat, however. No mobile phone carries a 'transponder' as such, but a mobile phone needs to have some means of telling the network where it is, so that the network knows where to look if there is a call for the mobile.
This is normally done by having the mobile 'tell' the network when it moves from the coverage of one cell to another (in GSM it's called Location Update - see 24.008 specification (www.3gpp.org) for gruesome details. UMTS works similarly, CDMA2000 doubtless a little different, but the principle will be the same).
The consequence is that the network will have a log of which cell you are in at any given time that your phone is turned on. Now, this doesn't accurately locate you (although in many cities, where cell sizes are 300 meters, it could be pretty close), which could establish a pattern of behaviour (or invalidate a false alibi, for example). Forthcoming US legislation (E911, IIRC) requires closer location fixes ( 100 meters) to be possible in the US, and this will inevitably be deployed everywhere as it allows for many useful services (think "give me directions to the nearest bar/restaurant/train station etc"). Point is that your phone already does this, has for many years, and there's no need for an 'always on' connection to allow for this.
As it happens, I have absolutely nothing against the use of these technologies - indeed, I've even been involved with their design. I *do* think it's important to ensure that the authorities use them according to the law. Of course they normally will, because a conviction could be impossible if the evidence was gathered illegally, but you've correctly pointed out how this can be abused at times.
My point is really that concerned citizens of any nation should scruitinize the actions of their governments and ensure that they remain within what the majority find acceptable, and ensure that firm action is taken against those responsible when the accepted legal boundaries are overstepped.
Unfortunately, at this time, governments all over the world are using the current 'security' crisis as a means to extend the extent to which our actions are monitored. This may well be necessary, but an informed and intelligent is required about the balance between the need to protect citizens and the right to reasonable privacy when you are going about your lawful business.
In my opinion, at least here in the UK, we had that balance about right 5 years ago, and are moving somewhat in the wrong direction. If the majority feel I'm wrong, and after due consideration, that's fine with me.
Indeed so. While 'uncool', lawful interception tends to be a prerequisite to deploying many types of technology - for example the GSM mobile system has had a detailed specification for what information can be intercepted, and how this must be achieved, for many years (you can start from GSM 01.33 specification and work your way out...)
This type of technology can, self-evidently, generate vast quantities of data, and each network equipment vendor currently generates in a different format. It's simply a way to ensure that data which would have been logged anyway is provided to law enforcement agencies in a standardised way.
Probably true to argue that this will be used for ISP logs etc. but the key point is this: "lawful interception". In the UK, and doubtless most of the 'Western' world, this requires a court order, but in these 'terrorist' domainated days, the criteria which are sufficient to get such an order are becoming ever less stringent "...well, he was a commie as a student, and anyone with a beard like that must be an international terrorist, your honour..."
The job of the concerned citizen is not to fight the enabling technology, but to ensure, through the democratic process, lobbying and protest as required, that the use by government agencies of these technologies stays within reasonable (whatever that means) grounds.
Obvious first point: you're a fool if you don't have a contract. UK law is sufficiently similar to US law that you should not have any great difficulty in understanding it (and if it's so legalese that you don't understand it, beware!). If you're not confident that you understand what your obligations and rights are, engage a solicitor (UK version of a lawyer).
The contract should cover at least: - What you need to deliver, and when - What you will be paid, and when - What happens if you fail to deliver for
some reason - Who owns the work before you have been paid - What happens in the event of dispute - Who is responsible for failings in the
software, and to what extent - Who is responsible for ensuring that all
relevant taxes are paid. - Jurisdiction of the contract (usually the
state/country of the client)
There are basically two types of contract work. In one case, you turn up at the company for whom you are doing the work every day, and get paid an hourly (daily, weekly or whatever) rate. In such a case, the contact will stipulate your holiday rights, what happens if you go sick, and will probably have a fixed duration (renewable, with trial period). This is low risk for you, but you'd obviously need to be in the UK woth valid work permit (or be an EU citizen, ancestral visa holder or whatever). If not, it's probably not an option for you.
The second type is work on a defined project (e.g. "you will deliver the foomatic e-commerce enabled profit maximiser website").
The issue with such a project is to get the scope of the work you will do tied down from the start. Issues to think about: who pays if the customer changes the requirements, what consitiutes a "change" anyway. Please be *very* careful here - probably the #1 cause of problems for people doing this kind of work is that the two sides have different expectations.
If you're not 100% clear about what is being asked for, I'd suggest splitting the contract into two parts: a specification and implementation. Idea is that you get paid for writing a specification, which the customer can change, but once this is agreed, you have a fixed price for delivering what was requested.
In such a contract, payments are usually phased on demonstrating milestones. One possibility would be (assuming a website):
1) Milestone payment for agreed specification (~10% of total) - accompanied by an annexe specifying your following milestones and payments. 2) Milestone payment for delivering interface mock-up (~20%) 3) Milestone payment for prototype fully functional site on small server (~20%) 4) Milstone payment for "beta" delivery on production server (~20%) 5) Final payment on acceptance (~10%) 6) Bonus (10%) for early completion (maybe a penalty for late completion as well)
I hope you're good at estimating how long you will take to do this: many software engineers are natural optimists, and will say that they can do something in 3 months which actually takes 6 (and which would kill your profit from this work), and remember that the customer will want 'finished' - i.e. documented, reliable, commercially acceptable - software. If you're not certain that you know how to do this, better work on an hourly basis.
You would be well advised to work via a limited liability company (these can be purchased off the shelf, for around UKP100), and to have professional indemnity insurance (another UKP160 or so).
Please bear in mind that if you are on a time and materials basis in the UK, you may see some odd contractual clauses which are concerned with ensuring that your customer cannot be liable for your tax (the so called IR35 rule).
You may wish to try the Professional Contractors Group (http://www.pcg.org.uk) - they certainly offer a fairly inexpensive Professional Indemnity package (although I'm not sure if you need to be UK resident or not).
Current GSM net data rate is 9.6 kbit/sec, but this figure includes a hefty overhead for error detection/correction in the channel coder. The GSM full rate end EFR voice codecs are both 13 kbit/sec, while there is a (newish) standardised 14.4 kbit/s data rate which works by choosing a different channel coding scheme. Also, there are 8 timeslots on a GSM carrier, not 10.
The gross data rate of a GSM carrier is 270.833 kbit/s divided between 8 timeslots of equal length (156.25 bits each). Of these, 148 bits can carry useful data whilst the remaining bits are guard bits etc. to cope with differing delays between mobiles which are at different distances to the base station. Of these 148 bits, in the normal switched GSM data scheme of things, 114 bits carry real data, 2 bits are used for frame 'stealing' indications and 56 bits are used for a channel training sequence. This gives (if I did my maths properly) a raw bit rate before channel coding of 24700 bits/sec on a GSM timeslot. There is a further loss of capacity due to the coding techniques used by the channel coder which leads to the 13 kbit/s available for a voice channel. 14.4k data uses a different channel coder to get around the problem (at the expense of performance in poor signal areas)
The actual performance which can be delivered by GPRS depends on three main factors: the number of slots on the carrier which are configured to support GPRS traffic (this can be from 1 to 8 in theory, but in rollout it is likely to be between 2 and 4 in most networks (there is the possibility in some networks to vary this according to the relative switched/packet load); the number of slots supported by the mobile - estimates are that the first generation of GPRS mobiles will support only 1 or 2 slot operation; and the number of users of the shared packet channel.
Thus, and assuming an otherwise unoccupied packet channel, the first generation GPRS mobiles are likely to give data rates in the range of 16 kbit/s (one slot) to 33 kbit/s (two slot). If you had a second generation GPRS mobile capable of doing 8 slot GPRS, the theoretical maximum performance is around 115 kbit/s (NB: not a precise figure - I don't have the GPRS coder details to hand) which ought, in practice, to give performance similar to a 64 kbit/s ISDN line.
In summary, I wouldn't throw away the trusty analogue modem just yet...
Slashdot Mirror
GPRS has standardised a means of supporting simultaneous speech and data calls, but there is no device available today which implements this protocol enhancement (it's called Dual Transfer Mode, for those who are interested)
Since DTM has only just finished being standardised, it's a bit unfair to complain that no devices (or, indeed, networks) support this as yet.
For the moment, most GPRS networks operate in so-called Network Mode of Operation 2 (NMO 2). This means that you can receive voice call paging only when an active transfer is not in progress, but that you mac make calls at any time, and can receive calls when there is no TBF present (which basically equates to no IP packets flowing).
NMO 1, which will likely come to some commercial networks by year end, allows you to receive voice calls in both transfer and idle mode.
I believe that no network has deployed NMO 1 commercially as yet. If anyone knows differently, I'd love to know (and to know where!)
It depends on what you mean by security. All of the cellular data standards have standardised some form of encryption for over-the-air data. While not as secure as 1024 bit PGP, they are sufficient to prevent unencrypted data (e.g. POP3 login info) from being captured easily by sniffing packets over the air, and are generally rather better designed from a security standpoint than WEP (GSM uses public key challenge-response mechanisms to exchange sipher keys, and encrypts all GPRS data packets and most signalling; CDMA2000 doubtless does likewise, but I'm less expert in the details). However, all cellular technologies end up putting your IP packets on the Internet. If they are not encrypted end-to-end, then they are indeed vulnerable to attack from within the Internet itself, but there's really nothing your phone provide can do about this. You can run end-to-end encrypted VPN solutions on all of the cellular technologies (if your provider chooses to open the appropriate ports to let you do so, of course, but that's a commercial issue). I can happily run end-to-end encrypted VPN to my employer over GPRS, and others at work do so over CDMA 2000. As a summary, for normal, reasonable purposes, the over-the-air encryption on all current cellular technologies is sufficient to protect packets from being sniffed by RF means - in this respect they are rather more secure than WiFi. If you're really concerned about security, you should be running end-to-end encryption anyway.
A thought provoking and intelligent post, which I'd moderate up if I wasn't already a contributor in the thread. Think you've misunderstood how cellular phones operate somewhat, however. No mobile phone carries a 'transponder' as such, but a mobile phone needs to have some means of telling the network where it is, so that the network knows where to look if there is a call for the mobile.
This is normally done by having the mobile 'tell' the network when it moves from the coverage of one cell to another (in GSM it's called Location Update - see 24.008 specification (www.3gpp.org) for gruesome details. UMTS works similarly, CDMA2000 doubtless a little different, but the principle will be the same).
The consequence is that the network will have a log of which cell you are in at any given time that your phone is turned on. Now, this doesn't accurately locate you (although in many cities, where cell sizes are 300 meters, it could be pretty close), which could establish a pattern of behaviour (or invalidate a false alibi, for example). Forthcoming US legislation (E911, IIRC) requires closer location fixes ( 100 meters) to be possible in the US, and this will inevitably be deployed everywhere as it allows for many useful services (think "give me directions to the nearest bar/restaurant/train station etc"). Point is that your phone already does this, has for many years, and there's no need for an 'always on' connection to allow for this.
As it happens, I have absolutely nothing against the use of these technologies - indeed, I've even been involved with their design. I *do* think it's important to ensure that the authorities use them according to the law. Of course they normally will, because a conviction could be impossible if the evidence was gathered illegally, but you've correctly pointed out how this can be abused at times.
My point is really that concerned citizens of any nation should scruitinize the actions of their governments and ensure that they remain within what the majority find acceptable, and ensure that firm action is taken against those responsible when the accepted legal boundaries are overstepped.
Unfortunately, at this time, governments all over the world are using the current 'security' crisis as a means to extend the extent to which our actions are monitored. This may well be necessary, but an informed and intelligent is required about the balance between the need to protect citizens and the right to reasonable privacy when you are going about your lawful business.
In my opinion, at least here in the UK, we had that balance about right 5 years ago, and are moving somewhat in the wrong direction. If the majority feel I'm wrong, and after due consideration, that's fine with me.
Indeed so. While 'uncool', lawful interception tends to be a prerequisite to deploying many types of technology - for example the GSM mobile system has had a detailed specification for what information can be intercepted, and how this must be achieved, for many years (you can start from GSM 01.33 specification and work your way out...)
This type of technology can, self-evidently, generate vast quantities of data, and each network equipment vendor currently generates in a different format. It's simply a way to ensure that data which would have been logged anyway is provided to law enforcement agencies in a standardised way.
Probably true to argue that this will be used for ISP logs etc. but the key point is this: "lawful interception". In the UK, and doubtless most of the 'Western' world, this requires a court order, but in these 'terrorist' domainated days, the criteria which are sufficient to get such an order are becoming ever less stringent "...well, he was a commie as a student, and anyone with a beard like that must be an international terrorist, your honour..."
The job of the concerned citizen is not to fight the enabling technology, but to ensure, through the democratic process, lobbying and protest as required, that the use by government agencies of these technologies stays within reasonable (whatever that means) grounds.
Obvious first point: you're a fool if you don't have a contract. UK law is sufficiently similar to US law that you should not have any great difficulty in understanding it (and if it's so legalese that you don't understand it, beware!). If you're not confident that you understand what your obligations and rights are, engage a solicitor (UK version of a lawyer).
The contract should cover at least:
- What you need to deliver, and when
- What you will be paid, and when
- What happens if you fail to deliver for
some reason
- Who owns the work before you have been paid
- What happens in the event of dispute
- Who is responsible for failings in the
software, and to what extent
- Who is responsible for ensuring that all
relevant taxes are paid.
- Jurisdiction of the contract (usually the
state/country of the client)
There are basically two types of contract work. In one case, you turn up at the company for whom you are doing the work every day, and get paid an hourly (daily, weekly or whatever) rate. In such a case, the contact will stipulate your holiday rights, what happens if you go sick, and will probably have a fixed duration (renewable, with trial period). This is low risk for you, but you'd obviously need to be in the UK woth valid work permit (or be an EU citizen, ancestral visa holder or whatever). If not, it's probably not an option for you.
The second type is work on a defined project (e.g. "you will deliver the foomatic e-commerce enabled profit maximiser website").
The issue with such a project is to get the scope of the work you will do tied down from the start. Issues to think about: who pays if the customer changes the requirements, what consitiutes a "change" anyway. Please be *very* careful here - probably the #1 cause of problems for people doing this kind of work is that the two sides have different expectations.
If you're not 100% clear about what is being asked for, I'd suggest splitting the contract into two parts: a specification and implementation. Idea is that you get paid for writing a specification, which the customer can change, but once this is agreed, you have a fixed price for delivering what was requested.
In such a contract, payments are usually phased on demonstrating milestones. One possibility would be (assuming a website):
1) Milestone payment for agreed specification (~10% of total) - accompanied by an annexe specifying your following milestones and payments.
2) Milestone payment for delivering interface mock-up (~20%)
3) Milestone payment for prototype fully functional site on small server (~20%)
4) Milstone payment for "beta" delivery on production server (~20%)
5) Final payment on acceptance (~10%)
6) Bonus (10%) for early completion (maybe a penalty for late completion as well)
I hope you're good at estimating how long you will take to do this: many software engineers are natural optimists, and will say that they can do something in 3 months which actually takes 6 (and which would kill your profit from this work), and remember that the customer will want 'finished' - i.e. documented, reliable, commercially acceptable - software. If you're not certain that you know how to do this, better work on an hourly basis.
You would be well advised to work via a limited liability company (these can be purchased off the shelf, for around UKP100), and to have professional indemnity insurance (another UKP160 or so).
Please bear in mind that if you are on a time and materials basis in the UK, you may see some odd contractual clauses which are concerned with ensuring that your customer cannot be liable for your tax (the so called IR35 rule).
Good luck, but take care...
You may wish to try the Professional Contractors Group (http://www.pcg.org.uk) - they certainly offer a fairly inexpensive Professional Indemnity package (although I'm not sure if you need to be UK resident or not).
Current GSM net data rate is 9.6 kbit/sec, but this figure includes a hefty overhead for error detection/correction in the channel coder. The GSM full rate end EFR voice codecs are both 13 kbit/sec, while there is a (newish) standardised 14.4 kbit/s data rate which works by choosing a different channel coding scheme. Also, there are 8 timeslots on a GSM carrier, not 10.
The gross data rate of a GSM carrier is 270.833 kbit/s divided between 8 timeslots of equal length (156.25 bits each). Of these, 148 bits can carry useful data whilst the remaining bits are guard bits etc. to cope with differing delays between mobiles which are at different distances to the base station. Of these 148 bits, in the normal switched GSM data scheme of things, 114 bits carry real data, 2 bits are used for frame 'stealing' indications and 56 bits are used for a channel training sequence. This gives (if I did my maths properly) a raw bit rate before channel coding of 24700 bits/sec on a GSM timeslot. There is a further loss of capacity due to the coding techniques used by the channel coder which leads to the 13 kbit/s available for a voice channel. 14.4k data uses a different channel coder to get around the problem (at the expense of performance in poor signal areas)
The actual performance which can be delivered by GPRS depends on three main factors: the number of slots on the carrier which are configured to support GPRS traffic (this can be from 1 to 8 in theory, but in rollout it is likely to be between 2 and 4 in most networks (there is the possibility in some networks to vary this according to the relative switched/packet load); the number of slots supported by the mobile - estimates are that the first generation of GPRS mobiles will support only 1 or 2 slot operation; and the number of users of the shared packet channel.
Thus, and assuming an otherwise unoccupied packet channel, the first generation GPRS mobiles are likely to give data rates in the range of 16 kbit/s (one slot) to 33 kbit/s (two slot). If you had a second generation GPRS mobile capable of doing 8 slot GPRS, the theoretical maximum performance is around 115 kbit/s (NB: not a precise figure - I don't have the GPRS coder details to hand) which ought, in practice, to give performance similar to a 64 kbit/s ISDN line.
In summary, I wouldn't throw away the trusty analogue modem just yet...