Vous êtes sur la page 1sur 4

Minutes from the IP to BTS Working Group - 02/04/00 --------------------------------------------------Attendees: In person: Jagdish Sonti - Cisco Manjuari Aswa - Cisco,

masawa@cisco.com David Lee - Airtouch, david.lee@airtouch.com Jackson Wong -Sun, jackson.wong@sun.com Pat Calhoun - Sun, pat.calhoun@sun.com Gab Montenegro - Sun, gabriel.montenegro@sun.com Michael Speer - Sun, michael.speer@sun.com James Kempf - Sun, james.kempf@sun.com (Chair) Telephonically: Alistair Urie - Alcatel, Alistair.Urie@alcatel.fr Eric Bergeron - Telesystem International Wireless, Inc., bergeron@tiw.ca Tom Towle - Lucent, towle@lucent.com Rick White - Motorola, CEMX92@email.mot.com Rick Phung - Samsung, rphung@sta.samsung.com Nicolas Drevon - Alcatel (also chair of 3GPP working group on IP), Nicolas.Drevon@alcatel.fr Frederic Leroudier - Sprint (also chair of 3GPP2 TSG-A group), FLerou01@sprintspectrum.com Ron Ferguson - Sprint Spectrum, RFergu01@sprintspectrum.com Roger Gustavsson - Ericsson, roger.gustavsson@era.ericsson.se Ian Corden - Lucent, corden@lucent.com Ram Dantu - IP Mobile, rdantu@ipmobile.com Pulin Patel - IP Mobile, ppatel@ipmobile.com Ken Davidson - IP Mobile, kdavidson@ipmobile.com Yoshihiko Taki - Fujitsu, yoshihiko.taki@fnc.fujitsu.com Craig Rhoades - Nokia, craig.rhoades@nokia.com Yousuf Saifullah - Nokia, yousuf.saifullah@nokia.com Michael Ricci - Nokia, michael.ricci@nokia.com Shinichi Baba - Toshiba, sbaba@tari.toshiba.com Alejandro Martinez - Nortel, munozam@nortelnetworks.com Issues: ------1) What is IP to BTS? - Is the BTS IP-aware, has an IP stack and is smarter? - IP is the transport, no IP operations at the BTS? 2) Is there an IP router at the BTS or not? 3) How to handle macrodiversity combiner (selection function) in CDMA with IP? The issue here is that packets coming from separate BTSs to the BSC from the same mobile may not be the same, and the BSC combines them using the macrodiversity combiner. How should this be handled if the transport is IP? 4) How to handle the management of multiple data types on the BTS/BSC connection? Today, ATM, AAL2 are used for voice/data, and AAL5 for signalling. There is also

OA&M data, real time and non-real time user data, and signalling. Data types are O&M, signalling and user data (voice). 5) Current systems require the timing delays between the BTS/BSC/Mobile to be less than 1 ms. How can this be handled? America uses asynchronous timing based on GPS, others use synchronous timing with a mobile/BTS and BSC/BTS feedback loop. David Lee, Vodaphone, thinks this is the key issue to solve. 6) What is the network topology and L1 technology on the BTS/BSC connection? Today it's T1 with point-to-point links. 7) End to end QoS? 8) Interoperability with legacy mobile systems (but not with legacy networks). 9) Is there IP routing at the BSC (there isn't in GPRS for example)? 10) What is the signalling transport layer on BSC/BTS connection? 11) What is the addressing for nodes in the network? Now using e.164, is it IPv2, IPv6 or other? (E.164 needs to be maintained) 12) How do we achieve transport efficiency on low speed T1 lines? Nonissue: -------Not looking at IP over the air, for reasons of spectral efficiency. Discussion: ----------Current system has BSC doing all the scheduling, BTS is dumb. If the BSC to BTS implies an L2 to L3 switch, L3 might cause additional latency. At the BTS currently, there is no protocol overhead cause it is just L1, but if any tagging or channelization or L2 switching is involved, there may be too much delay. Some implementatins have variable length framing and some packetization, so it may be possible to use IP and still retain the same timing requirements. Qualcom has a proprietary transport, for example. Voice is currently unpacketized, just circuit switched, but signalling is packetized. Voice has no header, nothing. 3GPP has standardized on ATM for the A3 interface. 70-80% of cost of a network infrastructure is in the BTS. Moore's law decreases intelligent BTS cost, but the service providers must show a 20% per year decrease

in costs for customers per year. Buffering isn't the problem in the BTS, it's potential protocol stack overhead. Some BTS have minor intelligence. BTS/BSC is orignally channelized. The BSC is directed to channel elements in the BTS, handing off directly to the channel element. The signal is picked up from one medium (wire) and handed off directly to another (radio). Signalling is done out of band. A voice packet coming in over the air is stripped of the header and put into the wired layer packet. Today's BTS have packets on a transmit queue with 1/2 to 1/4 ms dealy, maximum. Can MPS help here? Some existing BSC to BTS systems have proprietary variable length frames. These are very similar to IP. But the frame size must be exactly right to send directly over the air. BTS doesn't need to know about payload downstream. Two BTSs must be able to get packets through an IP network with different delay, then synchronize packets so they can be soft combined at the mobile. An alternative leased line would be link to DSL, much cheaper. Making the BTS more intelligent may have the effect of decreasing the number of suppliers, unintended consequence. L2 should terminate in BSC, not BTS. MAC layer terminates in BSC. There was also considerable discussion about the 3GPP system, in particular, UMTS, and how 3GPP2 and 3GPP can work together. What could be standardized between the two? Perhaps interfaces. Suggested Working Group Charter ------------------------------Major overriding goal: Not duplicate work done by 3GPP or 3GPP2, but rather serve as a vehicle for developing commonality between the two. 1) Define what IP to BTS means - Efficiency of carriage using IP. 2) Short term - rationalizing the transport by looking at using IP to the BTS for transport *only*. The protocols run over the transport would be existing protocols. Note that this will *not* provide for plug compatible BTSs, however. 3) Longer term - a framework for signalling protocol, leveraging from similar features between the different link layers. This breaks the BSC up into separate pieces that can be deployed

as different IP nodes, for example, mobility management, radio resource management. This would provide for plug compatible BTSs. The longer term goal requires agreement on the interfaces between the components as well as the components themselves. Breaking up the BSC will require radio vendor participation. We need guidence from the Technical Committee. Action Items -----------1) Define the advantages of IP for transport only over existing L1 to BTS. Contributions needed. Providers are not convinced that this is enough. 2) Proposals needed for transport between the BTS And BSC involving IP.

Vous aimerez peut-être aussi