I am looking for some guidance from the list. We will soon be deploying
wireless payment devices (CDMA/GSM). We are looking at options on where to
locate the servers that will run the backend payment gateways; we would like
the least amount of latency between the servers and the wireless networks as
possible. The wireless networks we will be deploying the devices on are:
AT&T Wireless
Verizon Wireless
Sprint PCS
Rogers Wireless
Bell Mobility
Telus Mobility
Vodafone
I was thinking we have a few options, to try and peer with the wireless
networks directly, buy bandwidth from networks that are directly peered with
the wireless operators or the Global Roaming Exchange Peering service that
Equinix runs but I have not been able to find out much more then what is on
Equinix’s public web site. We also have a need to peer with PayPal and
Amazon. I welcome the lists comments and recommendations.
With the assumption that you will have a wired backhaul to your HQ over
which the retail access-layer devices connect to commerce servers, make
sure that the wireless carrier's gateways to their wired network (where
the wired backhaul is connected to) are geographically well-dispersed
such that wireless access traffic from (for example) suburban Los
Angeles destined for a Los Angeles HQ data center, does not traverse the
US back to the east coast before it enters the carrier's wired backbone.
Surprisingly, some large wireless carriers appear to think that 2
continental traversals for each packet is an acceptable network design.
I have experienced round trip latency between sites 50 miles apart
measured at 750-1500 milliseconds when using GSM/CDMA wireless as the
access layer method.
The key is to ask the wireless carrier where the network-to-network
interfaces between the wireless and wired backbone networks are located,
and moreover, how many interfaces are there. Some large wireless
carriers have a single wireless/wired gateway for the entire US!
For Sprint you can get a circuit to AS1239 and just take customer
routes. Their PCS network is AS10507, but as far as I know the closest
you can get to it is 1239.
Some large telcos with wireless and wireline operations in the US
maintain 2 separate backbones: one that I call "wired", that corresponds
to traditional wired access where commerce servers are usually located;
and one that I call a "wireless" backbone, where GSM/CDMA wireless
devices are used to aggregate access-layer traffic. Both backbones
consist of national fiber-optic, BGP-based networks. Surprisingly, some
large telcos have a presence of both wireline and wireless backbones in
the same colos, but the 2 backbone networks are interconnected, not in
that colo, but at a single geographic location (with perhaps a single
hot standby interconnection site), located, for example in northern
Virginia.
So, the worst case is that if the servers and GSM/CDMA devices are
located in Southern California, even though the telco has a wireline and
wireless presence in the local LA colo, GSM/CDMA access-layer traffic
must traverse the continental US to northern Virginia and back to get to
the server.
I would suggest getting on the GRX network. As an enterprise you
should be able to get IPX service from any number of providers.
Belgacom, Syniverse, and Sybase365 all offer IP data service onto the
GRX. Then you aren't limited to just the US carriers, you'll be able
to reach most all carriers globally.
Folks, GRX is for data roaming between mobile providers, not for
connecting eye balls and content. Only mobile operators are members
of the GRX, not customers of mobile operators or content of any sort.
Here's an example, I am a T-Mobile USA subscriber. I travel to Canada
and roam on to Rogers's network. When i start a data session on my
mobile phone, Rogers passes all the data traffic back to T-Mobile via
the GRX peering exchange. When in Canada, my HTTP traffic does not
exit in Canada, it is tunneled back via GRX peering to T-Mobile in the
USA and exit's in the USA. The roamed into network (Roger's in my
example) is just an access network to reach the network that i
subscriber to (T-Mobile USA).
As someone else may have noted, your best best is to figure out where
the mobile providers peer out on the Internet and purchase access in
the same region and ISP as the mobile provider. Also, as someone else
noted, some mobile providers do a lot of aggregation that adds
latency, other mobile providers are more distributed and punt to the
ISP closer to the user.
I have been working on a similar project and I am finding it very hard
to get the mobile operators to understand why we want as little latency
as possible and they are not very open to people peering with their
"wireless" backbone. I hope this will change with more and more
eyeballs going wireless.
I have been working on a similar project and I am finding it very hard
to get the mobile operators to understand why we want as little latency
as possible and they are not very open to people peering with their
"wireless" backbone.
Possibly because the way that they tunnel GTP to the GGSN and the
locations of GGSN devices relative to the handsets served preclude as
little latency as possible.
I hope this will change with more and more
eyeballs going wireless.
LTE provides an opportunity to move the bottleneck.
I have been working on a similar project and I am finding it very hard
to get the mobile operators to understand why we want as little latency
as possible and they are not very open to people peering with their
"wireless" backbone.
Possibly because the way that they tunnel GTP to the GGSN and the
locations of GGSN devices relative to the handsets served preclude as
little latency as possible.
Yes. Some mobile providers are more heavily aggregated than others.
I have been pushing for decreasing the architectural latency in the
mobile architecture with IPv6
But there are a lot of roadblocks, some more technical than others.
Also, the wireless providers generally don't have a point of presence
in the peering NAPs. I have run this business case a few times for
my company and it generally is a financial wash, and therefore not
worth the effort to deploy and support additional transport and nodes
at the peering locations. It's simpler and cheaper to just punt the
Internet traffic out of the wireless networks as soon as possible to
an ISP, and those ISP frequently own the fiber transport as well.
But, like anything, you can always ask your B2B account manager for a
special setup. There are special setups that i know for corporate
customers.
I hope this will change with more and more
eyeballs going wireless.
LTE provides an opportunity to move the bottleneck.
LTE provides some latency benefits on the wireless interface, but the
actual packet core architecture is very similar to GSM / UMTS.
For those concerned about latency, the key is working with the
wireless operator to find where the mobility aggregation points are
and how they are connected to the Internet. More advanced
applications at large scale can justify direct peering, but i don't
imagine that achieves much real latency benefits over just being
properly coordinated with the locations and ISPs.
LTE provides an opportunity to move the bottleneck.
LTE provides some latency benefits on the wireless interface, but the
actual packet core architecture is very similar to GSM / UMTS.
right, renaming the the GPRS Core Network to SAE doesn't really impart
much magic to it. the air interface is certainly better. If the PDN
gateways in an LTE deployment are located solely in the same locations
as the former GGSNS then yeah your topoly is going to look almost identical.
