How about including some of us in the drawing board and
testing phase? As mentioned, an NDA is not a problem to
sign.

Just some thoughts off the top of my head,

-On the AP side-

  * 2 Modes (Access Point, PtP)
  * Client status for AP mode, showing the name of the CPE,
    the MAC address, and the RSSI and signal quality.
  * LOVE the adjustable power via software. Keep that!
  * Make routing an option. It can either be set up as a router,
    or a transparent bridge.
  * In PtP mode, it should only be able to connect to another
    SB AP in PtP mode. (for Backhauls)
  * Increase the output power to at least 24db (250mW not counting
    antenna) so that we can adjust our power with the right size
    antenna to reach the FCC legal limit of 36db. With only 17.5db
    coming out of the radio, an AMP is required to get us to the right
    level so we can serve customers. We'd like to get rid of the
    AMPs to cut down on the noise they add and still be able to
    get to 36db.
  * Naturally we would be ethically bound to follow the law and turn
    down the power when we are using the unit in PtP mode with a
    larger antenna. With 24db of power, we could use smaller
    antennas to go the same distance on our backhaul links, and some
    backhaul links would be easier to do at greater distances.

  * For the AP TOTAL, make sure that those of us in FCC land can
    have a setup that allows the full 36db. Options like 60 degree,
    90 degree, 120 degree, and Omni would give us excellent
    flexibility.


-On the CPE side-

  * KEEP IT SIMPLE
  * 1 Mode (Client Bridge) The current design and function
    are good. It's clean and simple. Just need to fix the 
    problems with the current firmware.
  * For the TOTAL, more antenna choices. 9db, 13db, 15db, 19db.
    All flat panels of course. No customer install is the same.
    One guy could need a 13db antenna and the guy next door could
    need the 9db because he has shorter trees in his freznel zone.


I completely agree with Eje. Make the equipment capable of routing
if you want, but don't take away the ability to bridge. If I had to
do a firmware upgrade tomorrow that would make all the APs and CPEs
routed instead of bridged I would have to completely redesign my
entire network and how my customers log in. Let me design my own
network, because as much as we may love the SB equipment, it's only
a small piece of the bigger picture.

I love the way that SmartBridges has designed their stuff. Nobody
else has the clean professional look in their equipment that this
stuff has. Even Motorola Canopy looks kinda like a big Twinkie on
a stick. Most others are just taking oversized panel antennas and
mounting their radios and AMPs inside it. SmartBridges has really
caught our attention by doing a lot of things right. There's still
some polish work to be done on what you've got, and this forum is
a GREAT source for SB to get the input it needs. I'm very glad to
see them using it too.

Thanks.

Kevin Summers
KISTech Internet Services Inc.
www.kistech.com

> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Nish Park
> Sent: Saturday, July 12, 2003 9:13 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [smartBridges] Here I come from ETSI land
> 
> 
> Shawn,
> 
> You are absolutely right. Your suggestions matche with our new direction
> with Nexus. 
> 
> Over past few weeks while responding to specific queries, we keep making
> references to this mysterious platform. And understandably you guys
> would like to know more details. But it is little bit difficult for us
> to share much details at this time. 
> 
> For the fear of competitive reasons. In addition we are not sure if
> certain things we are trying will actually work out. In which case it
> would be like over promising and not deliver. We are in the midst of
> negotiating certain strategic interests with the major component
> suppliers, and it would be pre-mature to announce who the "winners" are.
> 
> Hope this explains why we are tight lipped about this.
> 
> 
> Nish
> 
> 
> 
> 
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Shawn Mitchell
> Sent: Sunday, July 13, 2003 10:16 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: [smartBridges] Here I come from ETSI land
> 
> btw.. one quick rant that's been irritating me (sorry, I've been out in
> the
> sun all this week trying to fix sb stuff... I've got a N I C E sun
> burn...
> I'm trying to stay calm)
> 
> Don't take this the wrong way..   You guys are great with wireless...
> but
> you suck with IP networks.  20 years ago bridging a network was the only
> way
> to do it when you had protocols like DECnet, IPX/SPX, and every other
> type
> of out dated system (by today's standards).
> 
> Cisco has it right.. heck, even Sony has it right...   TCP/IP is a
> ROUTED
> protocol...  IPX/SPX has to be a BRIDGED protocol... NetBEUI, Netbios,
> etc,
> etc, etc have to be a bridged protocol...
> 
> I'm very tired of seeing ARP's from one side of the network end up on
> the
> other side.  80% of the trouble shooting you have to do on wireless
> networks
> will go away, you'll be able to see where the problem is with a simple
> traceroute...
> 
> What I'm getting at... get out of just doing Layer 2.. look at the OSI
> model
> and step up to the next step.  LOOK AT LAYER 3!!!!!  When you give
> something
> an IP address.. it's not the "box", "server", "airbridge", whatever that
> your giving the IP address to.. it's suppose to be the interface that
> you
> give the ip address to.
> 
> So you give the RF interface 192.168.1.24 and the Ethernet interface
> 192.168.0.24.  Ok, you can still have giving the box only one IP
> address,
> but make the interface that doesn't get the IP address an
> alias/clone/whatever of the interface that does get the ip address.
> 
> If you supported routing... you wouldn't have to care how many MAC
> addresses
> are behind the APP, or the AB.  The AP would never see the MAC's from
> behind
> the AB.  Look at the DOCIS standards.
> 
> Remember.... routing = better throughput, better reliability, not having
> to
> worry about bridged "loops", packet storms, etc, etc, etc, etc...
> 
> Bridging = asking for trouble, worrying about loops, not being able to
> see
> anything between you router and CPE.
> 
> Does everyone keep in mind that old rule... remember that your not
> suppose
> to have more than x number of switches between two nodes... otherwise
> you
> scream for trouble...
> 
> You can go ahead and flame me if you want... I'm tired of having
> headache's
> of trying to find out where problems are on a BRIDGED network, and
> trying to
> figure out how to setup some type of routing and not have to worry about
> accidentally creating a bridged loop.
> 
> 
> 
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Kevin Summers
> Sent: Saturday, July 12, 2003 16:05
> To: [EMAIL PROTECTED]
> Subject: RE: [smartBridges] Here I come from ETSI land
> 
> 
> 
> Are there any data sheets or any material to read about some
> of the details that will be in Nexus?
> 
> Kevin Summers
> KISTech Internet Services Inc.
> www.kistech.com
> 
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] Behalf Of Nish Park
> > Sent: Saturday, July 12, 2003 11:06 AM
> > To: [EMAIL PROTECTED]
> > Subject: RE: [smartBridges] Here I come from ETSI land
> >
> >
> > With the current radio the range can not be lowered below 11.5dB.
> > For our new hardware platform Nexus due to be released in Q4 it will
> be
> > possible to do this.
> >
> > Nish
> >
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Leszek Olszewski
> > Sent: Sunday, July 13, 2003 1:44 AM
> > To: '[EMAIL PROTECTED]'
> > Subject: [smartBridges] Here I come from ETSI land
> >
> > Hello,
> >
> > I come from ETSI land and as most of you know we have legal limits of
> > +20dBm EIRP.
> >
> > The question is - is it possible to reduce Smartbridges radio TX power
> > (SB
> > in general, I believe radios used in your devices are equal) down to
> say
> >
> > +3dBm? By doing this I could use higher gain antena, stay within legal
> > EIRP
> > limit and achieve longer link.
> >
> > Now, I do know that there's dial-a-power which allows regulation down
> to
> >
> > 11.5dBm. I am also aware that SB units can be managed via generic
> Atmel
> > SNMP configurator and there you can put hex values for each channel to
> > manipulate TX power. These guys
> > http://www.dcom.cz/docs/wlan/wen2021/vykon2021.htm claim they could
> > drive
> > similiar device down to -8dBm (!).
> >
> > Can someone please confirm or deny this and possibly provide some
> > further
> > explanation why or why not that is possible?
> >
> > I'll appreciate some in-depth technical answer, if possible.
> >
> > Regards,
> > Leszek
> >
> > The PART-15.ORG smartBridges Discussion List
> > To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe
> > smartBridges <yournickname>
> > To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe
> > smartBridges)
> > Archives: http://archives.part-15.org
> >
> >
> > The PART-15.ORG smartBridges Discussion List
> > To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe
> > smartBridges <yournickname>
> > To Remove: mailto:[EMAIL PROTECTED] (in the body type
> > unsubscribe smartBridges)
> > Archives: http://archives.part-15.org
> The PART-15.ORG smartBridges Discussion List
> To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe
> smartBridges <yournickname>
> To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe
> smartBridges)
> Archives: http://archives.part-15.org
> 
> The PART-15.ORG smartBridges Discussion List
> To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe
> smartBridges <yournickname>
> To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe
> smartBridges)
> Archives: http://archives.part-15.org  
> 
> 
> The PART-15.ORG smartBridges Discussion List
> To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe 
> smartBridges <yournickname>
> To Remove: mailto:[EMAIL PROTECTED] (in the body type 
> unsubscribe smartBridges)
> Archives: http://archives.part-15.org  
The PART-15.ORG smartBridges Discussion List
To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe smartBridges 
<yournickname>
To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe smartBridges)
Archives: http://archives.part-15.org  

Reply via email to