Apple is a system and user experience company, and has been since the Lisa and first Mac. We people in Slashdot care about implementation details, but most people don't. Apple is better than the average at shielding the users from the implementation details and providing a comfortable and easy user experience.
They're also good at marketing, but their approach there is not recent and was not enough initially to have mass appeal --- although you can say they had a cult following from the early days, just much more limited.
The difference between the early days and now is not so much in the Apple approach, but in the price points they can target and people attitude.
Shielding people for low level tech details used to be a very expensive thing in the early days of the Mac, and few could afford it. Nowadays providing a nice user experience is a multimedia player, then a smartphone or tablet, can be done at a lower price point. Even if Apple is often seen as more expensive, it's still affordable to more and more people. Their computers too are more affordable than in days past. So they can reach more people.
At the same time, technology is more and more pervasive. We (/.) may get a kick out of it and enjoy all those new nice toys and don't care about getting our hands dirty. But most people are mightily confused and frustrated and bored. So they're more and more receptive to easy products, that allows them to get their things down with minimal fuss and understanding of the underlying technology. Nobody likes to feel backward or stupid and be frustrated in front of a high tech product they don't know how to use properly. Apple offer a product they get, and they feel good about it. That creates a lot of loyalty among technophobic people, and even among people who could handle it, but don't want to bother because they have other things to do.
That's IMHO the combination of both that gives the current Apple boom. As I see it these two trends are here to stay, so Apple will stay high until other companies manage to shield people from high tech complications as well as Apple but at a lower price point.
I know. What I meant is that it's not the only choice in Qualcomm offering. If you want to implement a dual radio solution (also called SVLTE, for simultaneous voice and LTE) to offer voice over CDMA at the same time as data over LTE, you will be able do it with the coming Qualcomm MDM9615 in addition to the internal CDMA support of a SnapDragon for example. It's the same next gen 28nm baseband die that you will get in the Gobi 4000, packaged differently.
It's the first chip with LTE integrated into the same chipset as 2G and 3G. You only have to power that one chipset to run all the radios. Right now 4G phones become extremely hot because of having to power two chips.
I guess I wasn't clear enough, so let me rephrase. The choice of whether you need only one or two simultaneous radios is not driven by chipmakers, but by operators. If an operator wants SVLTE before VoLTE is deployed, you must have two radios. Then the Gobi is not a suitable chip, but as I said there are also next gen, more power efficient solutions for SVLTE / dual radio.
Now, for an operator using single radio and CSFB (ATT for example), you don't need anymore two chips but there you can use an integrated chip as the Gobi. That will save space, but not in itself power consumption. Because even if you had two chips in an early implementation, only one was active at a given time and the other was shutdown and not consuming power.
Power consumption is improved first and foremost by more advanced processes used in the baseband (move from 40 to 28nm with the MDM9615 / Gobi 4000), and improved implementation efficiency. Integration in a single package is not a significant factor for power consumption (but is key for board size).
Of course when Verizon turns on VoLTE nationally in 2013 and shuts down 2G and 3G the point will be moot unless you're looking for a global phone.
Yes, we agree on that. As soon as LTE coverage is on par with 2G/3G and VoLTE is there, you can dump the SVLTE approach and its two radios.
You don't necessarily need to sacrifice international roaming if the single radio supports the needed standards. You won't have SVLTE when roaming, but most international operators using W-CDMA/HSPA do not support SVLTE anyway but use CSFB (until VoLTE arrives).
Future chipsets are set to integrate LTE radios capable of using all freqs from 700 - 2600 MHz.
Yes. But there's still the problem of the front-end (FE).
You have the baseband chip (BB), which is by nature band agnostic. Then the RF chip, where new high end offering are now wideband as you say. But in front of the RF chip, you have what's called the analog front-end (or FE) with filters / duplexers / PAs. These filters / duplexers / PAs are band specific, and there's nothing in the pipe for now to make them universal as far as I know. So if you want to support more bands, you will end up with a more complex FE (with a switch connecting to different banks of components). This means more board space and higher cost.
Because of this, don't expect universal phones covering all bands. The phone handset will cost optimize for a few bands only (there are already 41 bands defined for LTE...). This is particularly true in the US where the phone are mostly all subsidized and locked to an operator, with the phone specs also carefully controlled by the operators. The phone is naturally optimized for the operator only (plus some roaming).
No, I know very well what I'm talking about. And you have a lot to learn. You need to understand the difference between single radio and dual radio integration of LTE. I already replied to you elsewhere on this topic, follow the link and read.
In short: if legacy and LTE must be enabled at the same time, the operator has chosen a dual radio integration of LTE. And then you must have two radios, and an integrated single radio chip will not cut it.
As for the gain of integrating the dies in the same package, it's very important in area but not in power. So for a single radio operator (ATT), the integration is nice but won't in itself help the power consumption much.
The big win in the next generation of Qualcomm is the move of the baseband from 45 to 28 nm. The gain will apply to both single and dual radio implementations.
Nope, and maybe a bit more complicated then you think it is;)
There are two main ways to integrate legacy with LTE: single radio and dual radio. When integrating with 3GPP 2G/3G (GSM and W-CDMA/HSPA) the standard way to go is single radio. With single radio you cannot have voice over 2G/3G and data over LTE, it's one or the other. Before voice over LTE is supported, when a voice call is coming you must revert data to 2G/3G too, this is called circuit switched fallback (CSFB). With CDMA you have the choice of single (called optimized eHRPD) or dual radio (non-optimized eHRPD). With dual radio you can support voice over CDMA with data over LTE at the same time. Whether a network uses single or dual radio (or both) is an operator decision, and the handset will adapt to that.
When the operator supports a single radio approach, you can still have separate radio chips on the PCB. But they're never powered at the same time. It does use more board space, but not more power. When a radio is not used it's simply shut down.
If the operator wants a dual radio approach (typically only for a CDMA operator who wants both CDMA voice and LTE data at the same time), then you must have two radios. And they can be used at the same time, that's the whole point. In such a set-up, a chipset with a single radio is just not suitable. But there's plenty of choice and Gobi is not the only way, you can also support dual radio with Qualcomm chips.
In any case, I stand by what I said. Integrating the RF is a win in die space but not significant in power consumption reduction. It's still discrete dies in any case, just in the same package. And the big gain is the move from 40/45 nm to 28 nm on the baseband, which saves power.
"Always on" at the user level doesn't necessarily mean always on at the radio level. For example in LTE the unit of allocation time-wise is called the subframe (SF), and lasts 1 millisecond. For low throughput, the radio will typicall only be used for transmission 1 subframe every N only and be off (or receive only for FDD) the rest of the time.
The topic of UL allocation is actually a very complex one, with trade-offs between power, user throughput and cell throughput. I can't go into all the details, but the frequency used is a very key element, and usually dominates the comparison. The first 4G deployed in the US, WiMAX, is in the 2.6 GHz band. Attenuation there is very high and requires high average transmit power. WiMAX and LTE both have the same maximum transmit power of 23 dBm, and at 2.6 GHz the device will spend most of the time at or very close to 23 dBm, and often being forced to subchannelize (only use a part of the bandwidth, to concentrate its power there and reach a sufficient power density at the base station). Whereas at 700 MHz a device is usually at much lower power level, with a much reduced power consumption. And can use the full band without problem (if practical). So expect 4G transmission to be significantly more power efficient at low frequency.
It turns out that historically, the first generations used the lowest bands. And newest generation had to use what's left, in higher bands. 2G is often at 900 MHz, 3G at 2.1 GHz and 4G started and will often be at 2.6 GHz (YMMV). The digital dividend changes this, and LTE is and will often be deployed in low bands too. Verizon started at 700 MHz for example.
In the end this means that it's nearly impossible for an end user to compare fairly 2G, 3G and 4G. You can only compare a couple (generation, frequency), and the frequency will often be the key factor.
Frequent (and quite inefficient) scanning for 4G is indeed a current problem, but does not invalidate what's discussed above. It's an additional and separate issue. And one that's very carrier dependent. For Verizon, if they meet their very aggressive plans, this coverage issue should be gone by year end.
Yes, radio is an important power drain in practice. But it's not the only one. Taking pictures or shooting videos also eats battery a lot. And the screen is also an important contributor. In my usage pattern where I'm mostly under close WiFi coverage the screen tend to dominate for example. But his varies a lot depending on each person context and usage pattern. Which is why some people say it's ok while others say it's crap: different conditions.
When 3G was improved, the downlink (DL, from base station to device) was improved first. This was HSDPA (D for DL). Then in the following release, the uplink (UL) throughput was improved too, and an improved UL is HSUPA. If you have both improved DL and UL, it's HSPA. And then there's been further improvement in the DL (carrier aggregation, MIMO. Although MIMO is not very popular) to give HSPA+.
In practice, there's no implementation with only the UL upgraded. So HSUPA support means HSPA support. Whether you're HSPA+ is another matter (and purely DL related).
Here's the thing. LTE is a data standard. It doesn't define a voice standard, and there's proposals on how to do voice-over-LTE. And people want to do voice calls. So LTE phones right now hop onto the UMTS (or CDMA) network in order to handle a voice call, while doing LTE for data. The problem is that LTE phones now need two chips - one to do LTE, another to do 3G/voice (ever notice how the LTE versions of phones are always larger? It's not just the larger battery). The iPhone doesn't have enough space for another chip. Plus the extra chip takes power.
You're definitely right that space is very important for skinny smartphones, and integration will help reducing the floor plan size for the 4G subsystem.
But for power consumption, integrating several dies into a single package doesn't change things much (it's not single die integration). The improvement in coming chips will come from moving from 40 nm to 28 nm in most cases. And there's a lot to do to improve implementation efficiency, but the big guys don't seem too concerned by this. As in 3G they make big implementations, and count on new processes better efficiency to reduce the power consumption of the baseband (digital part) over time. For more, see my post above in the thread.
Now the reason LTE phones use more power then HSPA phones is that the LTE transmitter is not integral to the SoC, it is it's own chip. Once the new ARM line is released (mid this year IIRC) we'll see battery life improve significantly as LTE chips will be integrated into the SoC like HSPA chips currently are.
No, that's not a significant factor here. The modem and RF are very unlikely to be integrated into the same die as the AP, as their life-cycle are quite different. At best it's integrated in the same package, but not in the same die (as in the SnapDragon chips). That's a bit more power efficient (shortest connections between AP and BB/RF), but it's negligible compared to the power consumption of a radio access subsystem.
One of the issue with each new WAN technology is that each major generation greatly increases the amount of computations to do. A standard as LTE is made to span years, and it's initially dimensioned to make the most of what's possible. So early implementations are large and power hungry. Then Moore's law (new processes power efficiency increases really) helps you get this down to a reasonable amount, up to a point where the power is dominated by the RF and PA, and no longer by the digital domain. And then the next beefier standard is introduced;)
The current 4G implementations are quite naturally power hogs. 28 nm will help. The thing is, more expensive versions of 4G will arrive soon (LTE Advanced). And that will increase the power consumption again. This time it looks like the power load may increase faster than better process can significantly help, so implementation efficiency will matter. But there's a lot to do there.
It depends. For a given fixed amount of work that scales well over several thread, the multicores CPU will finish the job earlier and go to sleep faster. Even if you had the same implementation efficiency, going to sleep (power gating) earlier is a win as you save the leakage power. But in practice newest CPUs are also made on newer and more power efficient process than older, lower cores implementation. So you win also on that part.
The gotcha in this nice story is that it's only true for a fixed amount of work. If you start to do more, then you can increase the load up to a point where the load increase more than compensates for the limited efficiency gain. And then your power consumption increases.
Bottom line: whether a fancy multi-cores CPU will save or eat battery will really depend on your usage pattern. YMMV.
By the way, the same really apply to 4G vs. 3G vs. 2G (I thought I might touch about this too, as it's the topic of the thread;). Each new generation is MORE power efficient in term of energy per bit transferred. No contest there. But people tend to use the network much more, and more than over compensate for the efficiency gain.
One caveat thought: the statement above applies once you're connected. The issue described here is due to a power inefficient scanning while the device is looking for 4G, and it's a different thing. But this part can be improved too over time. And will cease to be a problem when 4G is more widely deployed (youth problem).
Yes, but be aware that mobile IPv6 is mostly only used in "proxy" mode (PMIPv6). This means that from the device point of view, it looks like a simple "fixed" IPv6 set-up. The device only see it's mobile IP address, and has no notion that MIPv6 is used. PMIPv6 only happens between the LTE packet gateway (P-GW, where the home agent is located) and serving gateway (S-GW), in the network between the core and radio parts of the network, unseen from the device.
Device terminated MIPv6 is specified, but is unlikely to be used in practice. It would allow using MIP over other technologies, but at the cost of adding the MIP tunneling overhead over the radio link as well as more complexity on the device. Even with other radio access technologies, the preferred way is to use PMIP if possible, or then just change the IP on a switch.
So route optimization would only be a gain for the operator in a PMIPv6 set-up. In any case, due to security reasons the traffic will be forced through each mobile device assigned P-GW. Meaning: no route optimization. The P-GW is the box doing policy enforcement, and that's the natural place to support the lawful interception function (required by law in many countries, US among them) as it's a fixed point for a given user (it doesn't change with mobility, that's where the home agent is anchored).
CDMA was the first technology to enable "reuse 1" deployment.
In a GSM network, you need to use several frequencies to deploy one layer of the network, so that a cell doesn't interfere with a close cell. Using 7 frequencies for example allows a cell and all its immediate neighbor cells (using an hexagonal paving) to have different frequencies. Then the the closest cell with the same frequency is not adjacent but one hop further, and its interference is reduced.
In a CDMA network, all cells in a layer can use the same frequency. Now a mobile close to its cell where the signal is high is fine, but a mobile far from its cell and hence close to another neighbor cell will suffer interference. But this can be mitigated. In CDMA the bandwidth is split between codes, and neighbor can share the code space without trampling on each other feet and creating undue interference. There's still interference at the edge, and for a give frequency the cell capacity is lower than in GSM. But now you could use the 7 frequencies of GSM to provide 7 layers instead of a single one. And you gain in total capacity. In other words, reuse 1 reduce the capacity for a single frequency, but allows maximizing the usage of each frequency, and maximizing the network capacity. That's what got every operator so excited.
This being said, CDMA as deployed in CDMA2000/EVDO networks is now pretty backward and expansive. That's why all US CDMA operators are so eager to move to LTE and leave it behind. HSPA+ is much better, and what is amusing is that it kind of move away from the CDMA tenets to introduce back TDM principles (GSM is TDM based). HSPA+ is still CDMA based, but instead of transmitting over a few codes for a long time (as initially done with CDMA), it transmits for a short duration and use most codes. And multiplexing is done over time (as in TDM). Because it turns out that this is most efficient.
Anyway, you can safely ignore fanboys of either GSM or CDMA. It's our past. The future is now and is OFDMA, as used first by WiMAX and now LTE. It also allows for reuse 1 deployments, but instead of handling allocation based on time only (GSM), or on time and codes (CDMA), it handles allocations based on frequency and time. The bandwidth is split in many small carriers (15 kHz spacing in LTE for example). Carriers are groups in bunches (a resource block in LTE is 12 carriers for example). And you allocate several RBs to a device for a subframe of 1 ms. Allocation can change each subframe.
What's the gain of OFDMA? Better handling of multipath. When you're cell phone receive the signal from the base station, it actually receives a "main path" and several echoes due to reflexions on buildings, etc. Also, the higher the bandwidth the shortest the elementary symbol duration. At some point, a symbol becomes mixed with echoes from other symbols and decoding becomes a mess. With OFDMA, become each channel is low bandwitdh (15 kHz, compared to 5 MHz for 3G for example) the symbol duration is very long. There's no problem handling with echoes, become the time delay is very small compared to the OFDM symbol duration. The price to pay for this is doing a FFT over the bandwidth to recover all the basic carriers. That's up to 2k FFT. It's doable and practical now thanks to Moore law.
That should give you a quick overview. And to the experts: please forgive the necessary simplifications to fit in a few paragraphs.
It's cellular level signaling. To save battery the mobile device should spend most of its time in idle mode. In this mode the device mostly sleeps, and wake-up only for a short duration every paging cycle (from 640 ms to 2.56 s typically) to listen for a possible paging from the network telling it to wake-up because there's data to receive. In this idle mode, the device does not transmit, and only receive a few milliseconds every paging cycle. The UE will perform a sort of keep-alive (location tracking really), but only infrequently. So idle is very power efficient.
Also, in idle mode the base stations do not track the mobile at all. It's state is still remembered in the network thought.
Now, when the application level does its polling on top of IP, this will take the mobile our of idle mode and it will have to reconnect.
First, it will have to establish a link to the nearest base stations. Using a contention channel, as the base station doesn't yet know about it. The contention channel is the first signaling resource used.
Then, the BS (NB in 3G or eNB in LTE) will have to fetch the mobile context from the back-end. This lead to further signaling between RAN and core network.
Then, the IP link is operational again, and the stupid couple application IP level polling packets that do nothing but tell "I'm still there" can happen.
Then, the mobile will stay active for a while. Because there's no link between the application and radio layers, the radio layer will only put back the mobile in idle mode after some inactivity timeout. While the mobile is active, some channel maintenance is required that will consume some radio resources.
And, at last, the mobile will go back to sleep.
As you can see, this is inefficient in the extreme. It's really really bad, anyway you take it. Major waste of resource and battery. And it can be done otherwise using a centralized slow polling at least (even better if the back-end uses the radio network status instead of doing its own polling, but that would just be icing on the cake). It's just that application developers need to understand wireless is not wired, and use the proper tools to be efficient. In other words, it's a problem of education (for everyone: broadband data over wireless at scale is still young).
Interesting, and it goes on to show that even inside the telcos the IP network guys do not necessarily know what to do to best use the radio access network (which is the scarce resource to optimize for). So blaming developers or Google as DoCoMo does is not very fair. There's some learning to do all around I'd say.
It doesn't need to add latency: if you replace polling with push notification you will both use the mobile network more efficiently AND reduce latency. So as far as latency goes optimizing for mobile can really be win-win.
The only fundamental con is that you need to optimize the application for mobile. To use a centralized optimized push notification service instead of each application doing its own polling for example. But I don't think there's a way around that: a wireless network is fundamentally different from a wired network, and if you treat mobile as a wired network you will use the network inefficiently (both increasing signaling usage and decreasing useful data capacity, and draining battery).
Broadband wireless data is still pretty new, with a lot to learn on both sides. I'm not sure playing the blaming game as DoCoMo does will help much, but there's still a lot to improve for sure (even inside telcos, where the IP network guys may not do the most efficient things for the radio network part).
Exactly. And increasing control channel capacity is not free, as it reduces resources available for users data. Plus the control channel need robust encoding so are comparatively more expensive than data on average. Plus the standards have some flexibility on dimensioning control channels, but it's not fully flexible either. There's some assumption built in.
So operators may increase the amount of resources allocated to signaling, but this is only possible up to a point and would reduce data capacity (so increase cost per user level data).
So the way to get out of this with everyone wining is to make sure mobile phone applications use the network efficiently, and don't waste signaling capacity just out of ignorance. It seems both Google and Apple provide centralized polling / notification services already, so blaming them may be unfair. But I'm pretty sure there's a lot of developer education still to do. And maybe adding tools in the platform to see what are the wasteful applications would help. Knowledgeable users could spot the offenders, and make some noise so they improve their behavior.
Yes, this centralization of keep-alive / sync / update if very key to operate efficiently on a mobile wireless network. And even though both Google and Apple have some support, I guess not all applications are using it. An application designed for a fixed platform where the network is truly always on and dirt cheap will just do its own polling, and a fast polling it will be compared to what is suitable for a mobile network. This same application on a mobile wireless network will create a lot of signaling and drain batteries for nothing (although users and operators are one different sides for OTT applications, they both win if applications are more mobile savvy and efficient. The operators see less signaling data, the user less battery drain).
So I guess there's some education to do so that developers understand the constraints of a mobile network and do properly use the mobile specific services. And providing visibility on the applications data usage (how frequent does an application initiate connections? etc.) may help too. It would allow knowledgeable end users seeing what are the inefficient apps and put pressure on the developers to improve them.
Please see my reply to ewanm89 just above. It's very small at the TCP/IP level, but it's actually MUCH BIGGER and MUCH MORE FREQUENT;) than the keep-alive done by the telecom network. It's not even very useful, adds inefficient signalling (particularly in 3G vs. 4G) and drains your phone battery for nothing.
That's actually incorrect and quite way off. A normal telephone does NOT report its presence every 3 minutes as the quoted VoIP applications (value coming from TFA). A location update is done only every few hours, or when changing location areas. So it is much less frequent, and will also be much more efficient as the phone returns to low-power / silent mode after the minimum exchange of packets. Whereas the VoIP keep-alive, being data, will lead to a wake-up and the phone will go back to idle after a timeout a few seconds later typically. So you replace a few packets back and forth every few hours by several seconds of active time every 3 minutes. It does make a difference.
I'd rather see operators be more open to OTT services, as frankly they have quite a poor record in providing interesting services. But to run services efficiently on a mobile network some infrastructure still need to be put into place. It's not necessarily rocket science. For example, instead of each application doing its own uncoordinated and fast keep alive polling, they could rely on a platform keep alive service provided by the OS (and it seems both Apple and Google already support that, but I'm no expert on that). Just this centralization would save a lot of needless traffic and grief. And this centralized OS service could be integrated with the network keep alive system, with a connection between the home location register and the Apple or Google keep-alive back-end. Then there would be no additional keep alive polling compared to what the telecom network is already doing.
As you see, it's not super complex. But it requires cooperation between the few platform makers and the many telecom operators. As the cost is born by operators and the effort would be mostly on the platform makers, I don't expect much improvement until the operators start to apply pressure. This is what DoCoMo is starting to do. For once, it's a move that makes sense and that can also benefit the end user with less drain on the phone battery.
What really matters to operators is capacity. The improvements in technology are really to increase cell capacity, to cope with higher data usage (more smartphones, etc.). But capacity is not sexy, so they push peak rates to the public instead. Peak rates are simple and everybody understand. It's the common low-point of marketing in high-tech: show a bigger number, sell... Worked with CPU frequency until it flattened, with camera pixel counts, etc. And it does work, so why change the advertizing method?
As a person with moderate data needs, I'm still very happy to see higher and higher peak rates advertized even if I don't need them. It means more capacity, and that my data usage is more and more negligible compared to people who guzzle videos and use wireless as a fixed line replacement. Soon the lowest data plan will be plenty enough for me.
Yes it does seem incredible. Recently Free in France introduce a plan at 2 Euros per month, but it's for 60 mn voice + 60 SMS and no data. For a 3 GB data plan (no limit, but rate shaped at 3 GB) with unlimited everything else it's 20 Euros a month, which is already quite cheap.
That's called "beam forming" (BF), and that's the trend indeed. It requires active antennas to shape the antenna pattern based on need. To focus the signal toward a given user, but also to steer an antenna "null" (a direction where the antenna gain is null or very low) toward an interferer to not hear it. To give good results you need 4 elementary antennas at the base station at least, and 8 is better.
There is no magic though: to steer the beam you need some feedback, so it's to improve capacity with low speed users. If you're in a car or a train, BF either won't be used or will use a degraded mode (large beam, so less efficient but cover more space and hence can afford being steered less accurately).
I think the carriers are quite realistic about the needs, although they can be off sometimes (all estimations can be wrong). But they're businesses, they try to optimize their revenues and in a lot of places there is not enough competition, so... And most users are also not realistic about what is possible or practical in wireless. Wireless systems nowadays are immensely complex.
For German manufacturing, this is thanks to their focus on high end manufacturing (typical example: fancy machine tools). On the high end you can extract good margins, and sustain decent salaries. And it's not out of a good heart, it's because you need very skilled people and experience matters. So a company has an interest in treating their qualified workers well and have low turn-over. Swiss also has a lot of high end manufacturing (it's not all banks and chocolate;), and is doing well there too. The issue is with low skill / low end manufacturing jobs.
I'm a bit surprised about the Netherlands agricultural exports you quote. The list in Wikipedia seems reasonable to me and the Netherlands is not in the top 10.
I don't understand the GP as demeaning the Chinese people in any mean, just the kind of jobs offshored there. You may object to the wording, but I'm sure we all can agree the assembly jobs discussed here are very low skill jobs indeed.
But the key point in the GP post is that it's not black and white, US workers vs. Chinese workers. It's US workers being more expensive than US robots being more expensive than cheap (for now, but not forever) Chinese labor. People focus on manufacturing jobs being lost to China, and some have dreams that putting trade barriers against China would get these jobs back home. The point of the GP is that in this case, it would be done by robots at home not people, as it would be cheaper. And I tend to agree with him. Of course all this is not black and white, you can't have everything automated (yet?) and setting up the automated plants and making them run still create a few jobs. But mass low-skill employment in Western countries seem more and more difficult for assembly jobs.
And by the way, Foxconn started deploying robots in China too as a hedge against raising salaries in China (mostly on the coast, and the other hedge is to move eastward inside China where salaries are still low, or other countries). So soon it could be Chinese robots vs. Chinese workers and low skill workers may have problems even in China...
The key question is: are there enough low skill jobs providing a decent level of living remaining in Western countries? No everything can be automated, but more and more is. And even what cannot be automated may not attract sufficient salaries for a decent living. This is a Western issue for now, but other countries will have the problem as their development level rises.
Slashdot Mirror
Apple is a system and user experience company, and has been since the Lisa and first Mac. We people in Slashdot care about implementation details, but most people don't. Apple is better than the average at shielding the users from the implementation details and providing a comfortable and easy user experience.
They're also good at marketing, but their approach there is not recent and was not enough initially to have mass appeal --- although you can say they had a cult following from the early days, just much more limited.
The difference between the early days and now is not so much in the Apple approach, but in the price points they can target and people attitude.
Shielding people for low level tech details used to be a very expensive thing in the early days of the Mac, and few could afford it. Nowadays providing a nice user experience is a multimedia player, then a smartphone or tablet, can be done at a lower price point. Even if Apple is often seen as more expensive, it's still affordable to more and more people. Their computers too are more affordable than in days past. So they can reach more people.
At the same time, technology is more and more pervasive. We (/.) may get a kick out of it and enjoy all those new nice toys and don't care about getting our hands dirty. But most people are mightily confused and frustrated and bored. So they're more and more receptive to easy products, that allows them to get their things down with minimal fuss and understanding of the underlying technology. Nobody likes to feel backward or stupid and be frustrated in front of a high tech product they don't know how to use properly. Apple offer a product they get, and they feel good about it. That creates a lot of loyalty among technophobic people, and even among people who could handle it, but don't want to bother because they have other things to do.
That's IMHO the combination of both that gives the current Apple boom. As I see it these two trends are here to stay, so Apple will stay high until other companies manage to shield people from high tech complications as well as Apple but at a lower price point.
Gobi 4000... is from Qualcomm.
I know. What I meant is that it's not the only choice in Qualcomm offering. If you want to implement a dual radio solution (also called SVLTE, for simultaneous voice and LTE) to offer voice over CDMA at the same time as data over LTE, you will be able do it with the coming Qualcomm MDM9615 in addition to the internal CDMA support of a SnapDragon for example. It's the same next gen 28nm baseband die that you will get in the Gobi 4000, packaged differently.
It's the first chip with LTE integrated into the same chipset as 2G and 3G. You only have to power that one chipset to run all the radios. Right now 4G phones become extremely hot because of having to power two chips.
I guess I wasn't clear enough, so let me rephrase. The choice of whether you need only one or two simultaneous radios is not driven by chipmakers, but by operators. If an operator wants SVLTE before VoLTE is deployed, you must have two radios. Then the Gobi is not a suitable chip, but as I said there are also next gen, more power efficient solutions for SVLTE / dual radio.
Now, for an operator using single radio and CSFB (ATT for example), you don't need anymore two chips but there you can use an integrated chip as the Gobi. That will save space, but not in itself power consumption. Because even if you had two chips in an early implementation, only one was active at a given time and the other was shutdown and not consuming power.
Power consumption is improved first and foremost by more advanced processes used in the baseband (move from 40 to 28nm with the MDM9615 / Gobi 4000), and improved implementation efficiency. Integration in a single package is not a significant factor for power consumption (but is key for board size).
Of course when Verizon turns on VoLTE nationally in 2013 and shuts down 2G and 3G the point will be moot unless you're looking for a global phone.
Yes, we agree on that. As soon as LTE coverage is on par with 2G/3G and VoLTE is there, you can dump the SVLTE approach and its two radios.
You don't necessarily need to sacrifice international roaming if the single radio supports the needed standards. You won't have SVLTE when roaming, but most international operators using W-CDMA/HSPA do not support SVLTE anyway but use CSFB (until VoLTE arrives).
Future chipsets are set to integrate LTE radios capable of using all freqs from 700 - 2600 MHz.
Yes. But there's still the problem of the front-end (FE).
You have the baseband chip (BB), which is by nature band agnostic. Then the RF chip, where new high end offering are now wideband as you say. But in front of the RF chip, you have what's called the analog front-end (or FE) with filters / duplexers / PAs. These filters / duplexers / PAs are band specific, and there's nothing in the pipe for now to make them universal as far as I know. So if you want to support more bands, you will end up with a more complex FE (with a switch connecting to different banks of components). This means more board space and higher cost.
Because of this, don't expect universal phones covering all bands. The phone handset will cost optimize for a few bands only (there are already 41 bands defined for LTE...). This is particularly true in the US where the phone are mostly all subsidized and locked to an operator, with the phone specs also carefully controlled by the operators. The phone is naturally optimized for the operator only (plus some roaming).
No, I know very well what I'm talking about. And you have a lot to learn. You need to understand the difference between single radio and dual radio integration of LTE. I already replied to you elsewhere on this topic, follow the link and read.
In short: if legacy and LTE must be enabled at the same time, the operator has chosen a dual radio integration of LTE. And then you must have two radios, and an integrated single radio chip will not cut it.
As for the gain of integrating the dies in the same package, it's very important in area but not in power. So for a single radio operator (ATT), the integration is nice but won't in itself help the power consumption much.
The big win in the next generation of Qualcomm is the move of the baseband from 45 to 28 nm. The gain will apply to both single and dual radio implementations.
Nope, and maybe a bit more complicated then you think it is ;)
There are two main ways to integrate legacy with LTE: single radio and dual radio. When integrating with 3GPP 2G/3G (GSM and W-CDMA/HSPA) the standard way to go is single radio. With single radio you cannot have voice over 2G/3G and data over LTE, it's one or the other. Before voice over LTE is supported, when a voice call is coming you must revert data to 2G/3G too, this is called circuit switched fallback (CSFB). With CDMA you have the choice of single (called optimized eHRPD) or dual radio (non-optimized eHRPD). With dual radio you can support voice over CDMA with data over LTE at the same time. Whether a network uses single or dual radio (or both) is an operator decision, and the handset will adapt to that.
When the operator supports a single radio approach, you can still have separate radio chips on the PCB. But they're never powered at the same time. It does use more board space, but not more power. When a radio is not used it's simply shut down.
If the operator wants a dual radio approach (typically only for a CDMA operator who wants both CDMA voice and LTE data at the same time), then you must have two radios. And they can be used at the same time, that's the whole point. In such a set-up, a chipset with a single radio is just not suitable. But there's plenty of choice and Gobi is not the only way, you can also support dual radio with Qualcomm chips.
In any case, I stand by what I said. Integrating the RF is a win in die space but not significant in power consumption reduction. It's still discrete dies in any case, just in the same package. And the big gain is the move from 40/45 nm to 28 nm on the baseband, which saves power.
"Always on" at the user level doesn't necessarily mean always on at the radio level. For example in LTE the unit of allocation time-wise is called the subframe (SF), and lasts 1 millisecond. For low throughput, the radio will typicall only be used for transmission 1 subframe every N only and be off (or receive only for FDD) the rest of the time.
The topic of UL allocation is actually a very complex one, with trade-offs between power, user throughput and cell throughput. I can't go into all the details, but the frequency used is a very key element, and usually dominates the comparison. The first 4G deployed in the US, WiMAX, is in the 2.6 GHz band. Attenuation there is very high and requires high average transmit power. WiMAX and LTE both have the same maximum transmit power of 23 dBm, and at 2.6 GHz the device will spend most of the time at or very close to 23 dBm, and often being forced to subchannelize (only use a part of the bandwidth, to concentrate its power there and reach a sufficient power density at the base station). Whereas at 700 MHz a device is usually at much lower power level, with a much reduced power consumption. And can use the full band without problem (if practical). So expect 4G transmission to be significantly more power efficient at low frequency.
It turns out that historically, the first generations used the lowest bands. And newest generation had to use what's left, in higher bands. 2G is often at 900 MHz, 3G at 2.1 GHz and 4G started and will often be at 2.6 GHz (YMMV). The digital dividend changes this, and LTE is and will often be deployed in low bands too. Verizon started at 700 MHz for example.
In the end this means that it's nearly impossible for an end user to compare fairly 2G, 3G and 4G. You can only compare a couple (generation, frequency), and the frequency will often be the key factor.
Frequent (and quite inefficient) scanning for 4G is indeed a current problem, but does not invalidate what's discussed above. It's an additional and separate issue. And one that's very carrier dependent. For Verizon, if they meet their very aggressive plans, this coverage issue should be gone by year end.
Yes, radio is an important power drain in practice. But it's not the only one. Taking pictures or shooting videos also eats battery a lot. And the screen is also an important contributor. In my usage pattern where I'm mostly under close WiFi coverage the screen tend to dominate for example. But his varies a lot depending on each person context and usage pattern. Which is why some people say it's ok while others say it's crap: different conditions.
When 3G was improved, the downlink (DL, from base station to device) was improved first. This was HSDPA (D for DL). Then in the following release, the uplink (UL) throughput was improved too, and an improved UL is HSUPA. If you have both improved DL and UL, it's HSPA. And then there's been further improvement in the DL (carrier aggregation, MIMO. Although MIMO is not very popular) to give HSPA+.
In practice, there's no implementation with only the UL upgraded. So HSUPA support means HSPA support. Whether you're HSPA+ is another matter (and purely DL related).
Here's the thing. LTE is a data standard. It doesn't define a voice standard, and there's proposals on how to do voice-over-LTE. And people want to do voice calls. So LTE phones right now hop onto the UMTS (or CDMA) network in order to handle a voice call, while doing LTE for data. The problem is that LTE phones now need two chips - one to do LTE, another to do 3G/voice (ever notice how the LTE versions of phones are always larger? It's not just the larger battery). The iPhone doesn't have enough space for another chip. Plus the extra chip takes power.
You're definitely right that space is very important for skinny smartphones, and integration will help reducing the floor plan size for the 4G subsystem.
But for power consumption, integrating several dies into a single package doesn't change things much (it's not single die integration). The improvement in coming chips will come from moving from 40 nm to 28 nm in most cases. And there's a lot to do to improve implementation efficiency, but the big guys don't seem too concerned by this. As in 3G they make big implementations, and count on new processes better efficiency to reduce the power consumption of the baseband (digital part) over time. For more, see my post above in the thread.
Now the reason LTE phones use more power then HSPA phones is that the LTE transmitter is not integral to the SoC, it is it's own chip. Once the new ARM line is released (mid this year IIRC) we'll see battery life improve significantly as LTE chips will be integrated into the SoC like HSPA chips currently are.
No, that's not a significant factor here. The modem and RF are very unlikely to be integrated into the same die as the AP, as their life-cycle are quite different. At best it's integrated in the same package, but not in the same die (as in the SnapDragon chips). That's a bit more power efficient (shortest connections between AP and BB/RF), but it's negligible compared to the power consumption of a radio access subsystem.
;)
One of the issue with each new WAN technology is that each major generation greatly increases the amount of computations to do. A standard as LTE is made to span years, and it's initially dimensioned to make the most of what's possible. So early implementations are large and power hungry. Then Moore's law (new processes power efficiency increases really) helps you get this down to a reasonable amount, up to a point where the power is dominated by the RF and PA, and no longer by the digital domain. And then the next beefier standard is introduced
The current 4G implementations are quite naturally power hogs. 28 nm will help. The thing is, more expensive versions of 4G will arrive soon (LTE Advanced). And that will increase the power consumption again. This time it looks like the power load may increase faster than better process can significantly help, so implementation efficiency will matter. But there's a lot to do there.
It depends. For a given fixed amount of work that scales well over several thread, the multicores CPU will finish the job earlier and go to sleep faster. Even if you had the same implementation efficiency, going to sleep (power gating) earlier is a win as you save the leakage power. But in practice newest CPUs are also made on newer and more power efficient process than older, lower cores implementation. So you win also on that part.
;). Each new generation is MORE power efficient in term of energy per bit transferred. No contest there. But people tend to use the network much more, and more than over compensate for the efficiency gain.
The gotcha in this nice story is that it's only true for a fixed amount of work. If you start to do more, then you can increase the load up to a point where the load increase more than compensates for the limited efficiency gain. And then your power consumption increases.
Bottom line: whether a fancy multi-cores CPU will save or eat battery will really depend on your usage pattern. YMMV.
By the way, the same really apply to 4G vs. 3G vs. 2G (I thought I might touch about this too, as it's the topic of the thread
One caveat thought: the statement above applies once you're connected. The issue described here is due to a power inefficient scanning while the device is looking for 4G, and it's a different thing. But this part can be improved too over time. And will cease to be a problem when 4G is more widely deployed (youth problem).
Yes, but be aware that mobile IPv6 is mostly only used in "proxy" mode (PMIPv6). This means that from the device point of view, it looks like a simple "fixed" IPv6 set-up. The device only see it's mobile IP address, and has no notion that MIPv6 is used. PMIPv6 only happens between the LTE packet gateway (P-GW, where the home agent is located) and serving gateway (S-GW), in the network between the core and radio parts of the network, unseen from the device.
Device terminated MIPv6 is specified, but is unlikely to be used in practice. It would allow using MIP over other technologies, but at the cost of adding the MIP tunneling overhead over the radio link as well as more complexity on the device. Even with other radio access technologies, the preferred way is to use PMIP if possible, or then just change the IP on a switch.
So route optimization would only be a gain for the operator in a PMIPv6 set-up. In any case, due to security reasons the traffic will be forced through each mobile device assigned P-GW. Meaning: no route optimization. The P-GW is the box doing policy enforcement, and that's the natural place to support the lawful interception function (required by law in many countries, US among them) as it's a fixed point for a given user (it doesn't change with mobility, that's where the home agent is anchored).
CDMA was the first technology to enable "reuse 1" deployment.
In a GSM network, you need to use several frequencies to deploy one layer of the network, so that a cell doesn't interfere with a close cell. Using 7 frequencies for example allows a cell and all its immediate neighbor cells (using an hexagonal paving) to have different frequencies. Then the the closest cell with the same frequency is not adjacent but one hop further, and its interference is reduced.
In a CDMA network, all cells in a layer can use the same frequency. Now a mobile close to its cell where the signal is high is fine, but a mobile far from its cell and hence close to another neighbor cell will suffer interference. But this can be mitigated. In CDMA the bandwidth is split between codes, and neighbor can share the code space without trampling on each other feet and creating undue interference. There's still interference at the edge, and for a give frequency the cell capacity is lower than in GSM. But now you could use the 7 frequencies of GSM to provide 7 layers instead of a single one. And you gain in total capacity. In other words, reuse 1 reduce the capacity for a single frequency, but allows maximizing the usage of each frequency, and maximizing the network capacity. That's what got every operator so excited.
This being said, CDMA as deployed in CDMA2000/EVDO networks is now pretty backward and expansive. That's why all US CDMA operators are so eager to move to LTE and leave it behind. HSPA+ is much better, and what is amusing is that it kind of move away from the CDMA tenets to introduce back TDM principles (GSM is TDM based). HSPA+ is still CDMA based, but instead of transmitting over a few codes for a long time (as initially done with CDMA), it transmits for a short duration and use most codes. And multiplexing is done over time (as in TDM). Because it turns out that this is most efficient.
Anyway, you can safely ignore fanboys of either GSM or CDMA. It's our past. The future is now and is OFDMA, as used first by WiMAX and now LTE. It also allows for reuse 1 deployments, but instead of handling allocation based on time only (GSM), or on time and codes (CDMA), it handles allocations based on frequency and time. The bandwidth is split in many small carriers (15 kHz spacing in LTE for example). Carriers are groups in bunches (a resource block in LTE is 12 carriers for example). And you allocate several RBs to a device for a subframe of 1 ms. Allocation can change each subframe.
What's the gain of OFDMA? Better handling of multipath. When you're cell phone receive the signal from the base station, it actually receives a "main path" and several echoes due to reflexions on buildings, etc. Also, the higher the bandwidth the shortest the elementary symbol duration. At some point, a symbol becomes mixed with echoes from other symbols and decoding becomes a mess. With OFDMA, become each channel is low bandwitdh (15 kHz, compared to 5 MHz for 3G for example) the symbol duration is very long. There's no problem handling with echoes, become the time delay is very small compared to the OFDM symbol duration. The price to pay for this is doing a FFT over the bandwidth to recover all the basic carriers. That's up to 2k FFT. It's doable and practical now thanks to Moore law.
That should give you a quick overview. And to the experts: please forgive the necessary simplifications to fit in a few paragraphs.
It's cellular level signaling. To save battery the mobile device should spend most of its time in idle mode. In this mode the device mostly sleeps, and wake-up only for a short duration every paging cycle (from 640 ms to 2.56 s typically) to listen for a possible paging from the network telling it to wake-up because there's data to receive. In this idle mode, the device does not transmit, and only receive a few milliseconds every paging cycle. The UE will perform a sort of keep-alive (location tracking really), but only infrequently. So idle is very power efficient.
Also, in idle mode the base stations do not track the mobile at all. It's state is still remembered in the network thought.
Now, when the application level does its polling on top of IP, this will take the mobile our of idle mode and it will have to reconnect.
First, it will have to establish a link to the nearest base stations. Using a contention channel, as the base station doesn't yet know about it. The contention channel is the first signaling resource used.
Then, the BS (NB in 3G or eNB in LTE) will have to fetch the mobile context from the back-end. This lead to further signaling between RAN and core network.
Then, the IP link is operational again, and the stupid couple application IP level polling packets that do nothing but tell "I'm still there" can happen.
Then, the mobile will stay active for a while. Because there's no link between the application and radio layers, the radio layer will only put back the mobile in idle mode after some inactivity timeout. While the mobile is active, some channel maintenance is required that will consume some radio resources.
And, at last, the mobile will go back to sleep.
As you can see, this is inefficient in the extreme. It's really really bad, anyway you take it. Major waste of resource and battery. And it can be done otherwise using a centralized slow polling at least (even better if the back-end uses the radio network status instead of doing its own polling, but that would just be icing on the cake). It's just that application developers need to understand wireless is not wired, and use the proper tools to be efficient. In other words, it's a problem of education (for everyone: broadband data over wireless at scale is still young).
Interesting, and it goes on to show that even inside the telcos the IP network guys do not necessarily know what to do to best use the radio access network (which is the scarce resource to optimize for). So blaming developers or Google as DoCoMo does is not very fair. There's some learning to do all around I'd say.
It doesn't need to add latency: if you replace polling with push notification you will both use the mobile network more efficiently AND reduce latency. So as far as latency goes optimizing for mobile can really be win-win.
The only fundamental con is that you need to optimize the application for mobile. To use a centralized optimized push notification service instead of each application doing its own polling for example. But I don't think there's a way around that: a wireless network is fundamentally different from a wired network, and if you treat mobile as a wired network you will use the network inefficiently (both increasing signaling usage and decreasing useful data capacity, and draining battery).
Broadband wireless data is still pretty new, with a lot to learn on both sides. I'm not sure playing the blaming game as DoCoMo does will help much, but there's still a lot to improve for sure (even inside telcos, where the IP network guys may not do the most efficient things for the radio network part).
Exactly. And increasing control channel capacity is not free, as it reduces resources available for users data. Plus the control channel need robust encoding so are comparatively more expensive than data on average. Plus the standards have some flexibility on dimensioning control channels, but it's not fully flexible either. There's some assumption built in.
So operators may increase the amount of resources allocated to signaling, but this is only possible up to a point and would reduce data capacity (so increase cost per user level data).
So the way to get out of this with everyone wining is to make sure mobile phone applications use the network efficiently, and don't waste signaling capacity just out of ignorance. It seems both Google and Apple provide centralized polling / notification services already, so blaming them may be unfair. But I'm pretty sure there's a lot of developer education still to do. And maybe adding tools in the platform to see what are the wasteful applications would help. Knowledgeable users could spot the offenders, and make some noise so they improve their behavior.
Yes, this centralization of keep-alive / sync / update if very key to operate efficiently on a mobile wireless network. And even though both Google and Apple have some support, I guess not all applications are using it. An application designed for a fixed platform where the network is truly always on and dirt cheap will just do its own polling, and a fast polling it will be compared to what is suitable for a mobile network. This same application on a mobile wireless network will create a lot of signaling and drain batteries for nothing (although users and operators are one different sides for OTT applications, they both win if applications are more mobile savvy and efficient. The operators see less signaling data, the user less battery drain).
So I guess there's some education to do so that developers understand the constraints of a mobile network and do properly use the mobile specific services. And providing visibility on the applications data usage (how frequent does an application initiate connections? etc.) may help too. It would allow knowledgeable end users seeing what are the inefficient apps and put pressure on the developers to improve them.
Please see my reply to ewanm89 just above. It's very small at the TCP/IP level, but it's actually MUCH BIGGER and MUCH MORE FREQUENT ;) than the keep-alive done by the telecom network. It's not even very useful, adds inefficient signalling (particularly in 3G vs. 4G) and drains your phone battery for nothing.
That's actually incorrect and quite way off. A normal telephone does NOT report its presence every 3 minutes as the quoted VoIP applications (value coming from TFA). A location update is done only every few hours, or when changing location areas. So it is much less frequent, and will also be much more efficient as the phone returns to low-power / silent mode after the minimum exchange of packets. Whereas the VoIP keep-alive, being data, will lead to a wake-up and the phone will go back to idle after a timeout a few seconds later typically. So you replace a few packets back and forth every few hours by several seconds of active time every 3 minutes. It does make a difference.
I'd rather see operators be more open to OTT services, as frankly they have quite a poor record in providing interesting services. But to run services efficiently on a mobile network some infrastructure still need to be put into place. It's not necessarily rocket science. For example, instead of each application doing its own uncoordinated and fast keep alive polling, they could rely on a platform keep alive service provided by the OS (and it seems both Apple and Google already support that, but I'm no expert on that). Just this centralization would save a lot of needless traffic and grief. And this centralized OS service could be integrated with the network keep alive system, with a connection between the home location register and the Apple or Google keep-alive back-end. Then there would be no additional keep alive polling compared to what the telecom network is already doing.
As you see, it's not super complex. But it requires cooperation between the few platform makers and the many telecom operators. As the cost is born by operators and the effort would be mostly on the platform makers, I don't expect much improvement until the operators start to apply pressure. This is what DoCoMo is starting to do. For once, it's a move that makes sense and that can also benefit the end user with less drain on the phone battery.
What really matters to operators is capacity. The improvements in technology are really to increase cell capacity, to cope with higher data usage (more smartphones, etc.). But capacity is not sexy, so they push peak rates to the public instead. Peak rates are simple and everybody understand. It's the common low-point of marketing in high-tech: show a bigger number, sell... Worked with CPU frequency until it flattened, with camera pixel counts, etc. And it does work, so why change the advertizing method?
As a person with moderate data needs, I'm still very happy to see higher and higher peak rates advertized even if I don't need them. It means more capacity, and that my data usage is more and more negligible compared to people who guzzle videos and use wireless as a fixed line replacement. Soon the lowest data plan will be plenty enough for me.
Yes it does seem incredible. Recently Free in France introduce a plan at 2 Euros per month, but it's for 60 mn voice + 60 SMS and no data. For a 3 GB data plan (no limit, but rate shaped at 3 GB) with unlimited everything else it's 20 Euros a month, which is already quite cheap.
That's called "beam forming" (BF), and that's the trend indeed. It requires active antennas to shape the antenna pattern based on need. To focus the signal toward a given user, but also to steer an antenna "null" (a direction where the antenna gain is null or very low) toward an interferer to not hear it. To give good results you need 4 elementary antennas at the base station at least, and 8 is better.
There is no magic though: to steer the beam you need some feedback, so it's to improve capacity with low speed users. If you're in a car or a train, BF either won't be used or will use a degraded mode (large beam, so less efficient but cover more space and hence can afford being steered less accurately).
I think the carriers are quite realistic about the needs, although they can be off sometimes (all estimations can be wrong). But they're businesses, they try to optimize their revenues and in a lot of places there is not enough competition, so... And most users are also not realistic about what is possible or practical in wireless. Wireless systems nowadays are immensely complex.
For German manufacturing, this is thanks to their focus on high end manufacturing (typical example: fancy machine tools). On the high end you can extract good margins, and sustain decent salaries. And it's not out of a good heart, it's because you need very skilled people and experience matters. So a company has an interest in treating their qualified workers well and have low turn-over. Swiss also has a lot of high end manufacturing (it's not all banks and chocolate ;), and is doing well there too. The issue is with low skill / low end manufacturing jobs.
I'm a bit surprised about the Netherlands agricultural exports you quote. The list in Wikipedia seems reasonable to me and the Netherlands is not in the top 10.
I don't understand the GP as demeaning the Chinese people in any mean, just the kind of jobs offshored there. You may object to the wording, but I'm sure we all can agree the assembly jobs discussed here are very low skill jobs indeed.
But the key point in the GP post is that it's not black and white, US workers vs. Chinese workers. It's US workers being more expensive than US robots being more expensive than cheap (for now, but not forever) Chinese labor. People focus on manufacturing jobs being lost to China, and some have dreams that putting trade barriers against China would get these jobs back home. The point of the GP is that in this case, it would be done by robots at home not people, as it would be cheaper. And I tend to agree with him. Of course all this is not black and white, you can't have everything automated (yet?) and setting up the automated plants and making them run still create a few jobs. But mass low-skill employment in Western countries seem more and more difficult for assembly jobs.
And by the way, Foxconn started deploying robots in China too as a hedge against raising salaries in China (mostly on the coast, and the other hedge is to move eastward inside China where salaries are still low, or other countries). So soon it could be Chinese robots vs. Chinese workers and low skill workers may have problems even in China...
The key question is: are there enough low skill jobs providing a decent level of living remaining in Western countries? No everything can be automated, but more and more is. And even what cannot be automated may not attract sufficient salaries for a decent living. This is a Western issue for now, but other countries will have the problem as their development level rises.