Subject: Re: [seamoby] micro, schmicro

From: James Kempf <[email-masked]>
Date: Tue, 16 Jan 2001 07:55:35 -0800 (PST)

>> 
>> "Do what you can locally before going globally" ?
>> 
>> br,
>> John
>
>Right on John!
>
>Think globally, act locally...  Charity begins at home....
>The end-to-end argument...  All apply John.  I for one
>would love to see us dump the macro/micro distinction
>since I think the original basis for this distinction
>i.e. (no COA change) is a flawed distinction.  The real
>IMPORTANT distinction is that of edge devices/routers
>versus core routers and how they relate to mobility, NOT
>what subnet you are on!
>

Um, actually what subnet you are on has an intimate relationship to
what edge router you are using or what core router. The whole point
of having a router is to bridge two subnets, in subnet based routing.

		jak

---

From: "Chitrapu, Prabhakar R" <[email-masked]>
Date: Tue, 16 Jan 2001 12:31:30 -0500

I agree that 'micro/macro' are relative terms and can be mis-understood. 

Terms such as 'Edge vs. Core devices/routers' are good.  

However, I have a question: Do issues that SeaMoby wants to address HAVE to
belong to an EDGE domain/subnet/access-network ? Can they not be applied to
ANY subnet or a LOCAL-domain, even though it may not be at the edge ? If
that is indeed the case, then terms  such as 'intra-domain vs. inter-domain'
devices/routers might be useful. 

Prabhakar Chitrapu.

----------------------------------------------------------------------------
----------------
Prabhakar Chitrapu, Ph.D.					Tel:
610-878-5730	
Manager, Algorithm Development				Fax: 610-878-7841

InterDigital Communications Corp.				Email:
[email-masked]
781 Third Avenue, King of Prussia, PA 19406-1409.
http://www.interdigital.com

> -----Original Message-----
> From:	Phil Neumiller [SMTP:[email-masked]]
> Sent:	Tuesday, January 16, 2001 9:31 AM
> To:	[email-masked]
> Cc:	[email-masked]; [email-masked]
> Subject:	Re: [seamoby] micro, schmicro
> 
> 
> > 
> =pdn

---

From: [email-masked]
Date: Tue, 16 Jan 2001 11:48:12 -0600

James,

I understand this.  However, it may be the case that useable routes exist
between
an edge router pair that are unknown to the mobility agents being used.  If this
is
the case the path between the mobile and the new ER is shorter when the mobility
agents are bypassed.  This will not always be the case, but the worse case is
that
you have to route back through the mobility agents right?  Ideally wireless
networks
that handover to each other frequently will become mesh networked at the edge of
the big I overtime.  That is we follow the simple principle of allowing the
physical
network to adapt overtime to the logical traffic patterns.

-Phil

---

From: [email-masked]
Date: Tue, 16 Jan 2001 18:08:00 -0600

I think I disagree.  Why would the FAs necessarily find these routes?
You could have situations like the following:

 FA1                    FA2
  |                      |
(net 1)---------------(net 2)
  |                      |
(net 3)---------------(net 4)
  |                      |
(AP 1)                (AP 2)
  |
 MN  --> handing over to ^

Here net 1 is a subnet of FA1, and net 3 is a subnet of
net 1.  The OSPF or RIP path between AP 2 and FA 1, may
be different that that between AP 1 and AP 2. which may
have a mesh link between net 3 and net 4 that is unknown
to FA1 and FA2 right?

Kulwinder Atwal <[email-masked]> on 01/16/2001 05:46:42 PM

Sent by:  Kulwinder Atwal <[email-masked]>

To:   Phil Neumiller/MW/US/3Com, [email-masked]
cc:
Subject:  RE: [seamoby] micro, schmicro

> an edge router pair that are unknown to the mobility agents
> being used.

If the routes are IP routes then the IP mobility agents will be
aware of them, and will find the shortest path.  Otherwise, there is an
error in the implementation.

If the routes are L2 routes then this is an L2 issue.

Unless you are getting at something else.

---

From: Kulwinder Atwal <[email-masked]>
Date: Tue, 16 Jan 2001 18:46:42 -0500

- Kulwinder.

>  If this

---

From: [email-masked]
Date: Wed, 17 Jan 2001 15:57:53 +0200

Hi Phil,

> Also, I believe edge mobility is active ALL the time, and 
> core mobility (mobile IP) is active WHEN subnet boundaries 
> change.  Also, I believe that edge mobility must compensate 
> for the latency of adjustments in core routing updates made 
> by mobile IP.

As I understand the problem space, I don't think SeaMoby will
be tackling routing issues - after all we are in the
TRANSPORT AREA.  Anyhow, if you feel that routing issues
are something that we must solve, then I imagine that we
will need to re-charter and be in the Routing Area.

I hope to avoid getting into the routing area myself,
as I think it will unduly complicate matters.

br,
John

---

From: "Gary Kenward" <[email-masked]>
Date: Wed, 17 Jan 2001 10:09:30 -0500

"encouraging bad real time design"? 

A valid point Kulwinder, but I have two observations:

 1. The imposition of topology restrictions over a wide area greatly
     changes the philosophy of the internet.

  2. In the limit, applying real time design rules yields ATM/ISDN/
      Telco type networks.

Somewhere is the balance, to be sure, for every interceding router
adds one "unit" of incremental delay (internet rule-of-thumb). One
answer is to put all handoff management at the link layer. This leads
to link layer subnets that are bigger then many autonomous systems.

Another answer is to distribute the mobility functionality to all routers,
and hope for route optimization.

The wrong answer, I think we all agree, is a mobility agent somewhere
at the far edge of the domain.

Gary

> From: Kulwinder Atwal [mailto:[email-masked]]
> Sent: Tuesday, January 16, 2001 8:12 PM
> To: [email-masked]'; Kulwinder Atwal
> Cc: [email-masked]
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Tuesday, January 16, 2001 7:08 PM
> > To: Kulwinder Atwal
> > Cc: [email-masked]
> Making your diagram technology neutral:
>  
>   Big I			Big I
>    |                      |
>  (CR 3)------CRL1----- (CR 2)
>    |                      |
>  (OAR)-------ARL1-----  (NAR)
>    |                      |
>  (OAP)                  (NAP)
>    |
>   MN  --> handing over to ^> 
>  
> 
> CR = Core Router
> 
> AR = Access Router 
> 
> OAR = Old Access Router
> 
> NAR = New Access Router
> 
> I think your model in encouraging bad real-time network 
> design.  The ARs
> should have the functionality to resolve MN moves through one 
> link.  If ARs
> agree on one link for passing all MN handover related 
> messages in advance,
> this will cut down on the amount of messaging needed for a 
> handover as well.
> 
> 
> Either staticly, or dynamically the Access Routers (OAR/NAR) 
> need to agree
> on one single path for MN moves in advance of the move.  This 
> path may even
> be set once by the Network Administor during network setup.
> 
> Further, placing the functionality required for the move that 
> many layers
> away from the MN will most likely not result in the real-time 
> behaviour we
> are looking for.
> 
> This is why I believe the better solution is to place the primary
> functionality for the move in the ARs nearest the MN.   
> 
> Unlike the general Internet, Real-Time network design must consider
> deterministic behaviour as a primary design objective.  
> 
> If the Network Designer wishes Real-Time behaviour to be a 
> primary design
> goal, then deterministic behaviour must be a primary design 
> objective. 
> 
> If we want Real-Time hand-overs then at least:
> 
>  - we must place Real-time bounds on "Routed Clouds"
>  - move decision making closer to the MN
>  - limit handover messaging to one pre-determined path
> 
> Also, since the problem space encompasses mobile wireless we 
> must provide
> positive confirmation of every message between the MN and an AR.
> 
> - Kulwinder.
> 
> > 
> >

---

From: "Gary Kenward" <[email-masked]>
Date: Wed, 17 Jan 2001 10:13:49 -0500

I agree with Michael.

And I would like to add an observation: it has been
suggested by someone that the FA belongs at the AP.
This would imply many things, not the least of which is
changes to the definition of what an FA does - assuming
the purpose of the FA being at the AP is to support
SeaMoby.

The alternative, which is what this discussion implicitly
includes, is a third mobility agent at the AP. This has
been somewhat hidden by referring to the SeaMoby
functions indirectly as AP functions.

Now we have at least 4 mobility agents: the HA, FA, AP
and at least one mobility functional entity within the link
layer.

Gary

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Tuesday, January 16, 2001 8:54 PM
> To: Kulwinder Atwal
> Cc: [email-masked]'; [email-masked]
> I think you are misunderstanding Phil's point
> which I took to mean that the placement of the
> foreign agent is not necessarily the same as the
> placement of the AR. While I wonder whether that's
> an especially wise idea from the standpoint of
> needing to have a security relationship with both
> the AR (aka NAS) and the FA (for BU's, say), I
> think I probably disagree with your premise too.
> I don't think that we can or should make any
> assumption that the AR's will always know a priori
> about one another. I think it's useful in many
> cases to allow such topology knowledge to be used
> for network based moves, but this is not
> sufficient: it's a local optimization. The more
> general case where the old AR doesn't know squat
> about the new AR is also a perfectly valid case
> that needs to be accounted for.
> 
> 	   Mike
> 
> 
> Kulwinder Atwal writes:
>  > should have the functionality to resolve MN moves through 
> one link.  If ARs
>  > Either staticly, or dynamically the Access Routers 
> (OAR/NAR) need to agree
>  > on one single path for MN moves in advance of the move.  
> This path may even
>  > Further, placing the functionality required for the move 
> that many layers
>  > away from the MN will most likely not result in the 
> real-time behaviour we
>  > are looking for.
>  > 
>  > goal, then deterministic behaviour must be a primary 
> design objective. 
>  > 
>  > Also, since the problem space encompasses mobile wireless 
> we must provide

---

From: [email-masked]
Date: Wed, 17 Jan 2001 10:07:35 -0600

Sent by:  "Gary Kenward" <[email-masked]>

pdn>This has been "formerly" suggested by the MIPv4 fast
pdn>handoff team in the form of drafts.

pdn>No, this was not the purpose.  Several of "us" on
pdn>the list believe there are many problems with an
pdn>FA chicken in every AP pot.

pdn>Yeeas!  However, a peer-to-peer model is even NICER,
pdn>where a MN can be a Mobility agent (if it wants to
pdn>(IIWT), an AP can be an MA IIWT, an AR can be and MA
pdn>IIWT, etc.  This would be the most flexible.  Each MA
pdn>reflecting its own self interest while happily exchanging
pdn>context with a friendly neighborhood of MAs.  Can you
pdn>say moblity utopia?

pdn>You Nortel guys just can't shake the hierarchy can you...
pdn>(:-)) <<< - Real big sh*t eatin grin (sorry Gary).
pdn>Now we have a plethora of MAs all speaking CNP to each
pdn>other in Phil's utopian mobility enabled globe.

pdn>Try being flippant once and a while, it releases the
pdn>creative juices.  May be try being flipper since this
pdn>is SeaMoby.

Bye,

-pdn

---

From: "Gary Kenward" <[email-masked]>
Date: Wed, 17 Jan 2001 13:36:11 -0500

Actually, I like the idea. Phil's proposal certainly encapsulates
more of what I envision Seamoby to be about then  any of the
other definitions.

Sorry Phil, please continue the mantra.

Gary

> From: Phil Neumiller [mailto:[email-masked]]
> Sent: Wednesday, January 17, 2001 8:40 AM
> To: [email-masked]
> Cc: [email-masked]
> [email-masked] wrote:
> > 
> > Hi all,
> > 
> > I don't know, if this helps at all, but I thought I might 
> share some of my
> > (not too distant) earlier experiences in mobility work on 
> H.323 systems.
> > First of all, I have never seen a good definition for micro 
> and macro
> > mobility. Yet people use these as if they were clearly and similarly
> > understood by everyone. If you ask me, micro mobility in 
> the context of IP
> > networks is something that happens behind an access point 
> or a base station,
> > i.e. no change of the CoA is involved and thus there isn't 
> much (anything?)
> > that needs to be done in the IP layer. However, as I said, 
> I'm sure there
> > are other definitions for micro mobility as well.
> 
> You are correct.  This seems to be the running definition or 
> what I have
> called the "classic" definition of micro-mobility.  Now I have
> questioned
> whether this distinction is a useful one.  My feeling is that edge
> versus
> core mobility is a far more important distinction than a change in
> subnet.
> 
> core mobility 
> (mobile IP) is active WHEN subnet boundaries change.  Also, I believe
> that edge mobility must compensate for the latency of adjustments in
> core
> routing updates made by mobile IP.
> 
> So, as I have stated in every design team message list, I hope we can 
> convince the list to abandon this terminology and recognize the real 
> problem which is edge versus core.  Complex behavior enabling seamless
> mobility will be best implemented in edge devices of the global
> Internet.
> This is the ONLY way that it will scale globally.  As Tom Petty said,
> "No, I won't back down.." on this one.
> 
> > What we did in the H.323 Mobility work was not to use these 
> terms, but
> > instead refer to the scope of the mobility in terms that 
> were already
> > defined for H.323. Thus we ended up talking about 
> intra-zone, inter-zone,
> > intra-domain and inter-domain mobility. In a similar 
> manner, I would imagine
> > that terms, such as "intra/inter-link mobility", "intra/inter-subnet
> > mobility", "intra/inter domain mobility" or something 
> similar could be used
> > with regards to Mobile IP and Seamoby. An alternative for 
> this would, of
> > course, be to define unambigiously the terms "micro 
> mobility" and "macro
> > mobility", but since these are already in use and mean 
> various different
> > things depending on the context, I would imagine that the 
> use of them would
> > lead to misunderstandings.
> > 
> Here I would prefer we use the terminology of edge versus 
> core mobility.
> Can somebody shoot me down so I can get off this mantra??? :-)
> 
> TNX,
> 
> Phil (N9FCW, PSK/QPSK mbox = 10.140.700 MHz)
>

---

From: "Gary Kenward" <[email-masked]>
Date: Wed, 17 Jan 2001 13:38:47 -0500

Dana:

   You do not seem to have a concrete objection to "edge
mobility". I tend to agree concerning "core mobility", although
there is already a problem with the difference in denotation
between the Internet use of "core" versus the cellular use of 
"core".

   What not be clear and use "MIP" and "edge mobility"?

Gary

> From: Dana L. Blair [mailto:[email-masked]]
> Sent: Wednesday, January 17, 2001 8:54 AM
> To: Phil Neumiller; [email-masked]
> Cc: [email-masked]; [email-masked]
> Let's take this discussion back to the micro-mobility alias, 
> since it is a mobility
> discussion.
> 
> At 07:39 AM 1/17/01 -0600, Phil Neumiller wrote:
> >> First of all, I have never seen a good definition for 
> micro and macro
> Edge and Core are too abstract terms to discuss detailed 
> mobility solutions.
> Cellular folks use the term Core to reference an MSC, HLR, 
> other other systems.
> IP folks use the term Core to referece a high speed backbone 
> IP network.
> Since we are within the IP context let's use specific IP 
> terms.  That is
> why I defined micro-mobility in terms of IP addressing an 
> Access Links.
> 
> >
> I think you need to define subnet more specifically.  For 
> example, an ethernet
> is an IP subnet which is part of a larger IP subnet for a 
> department which
> is part of a company IP subnet which is part of an ISP IP 
> subnet which is
> part of the internet.  Which subnet boundary are you referencing ?
> 
> I tried to avoid the subnet ambiguity by saying there are 
> some boundaries where
> the routable IP address assigned to the MN must change.  Then 
> there are others
> where it does not change.  micromobility applies to those 
> cases where the
> address does not change.
> 
> I don't think we disagree.  This design team is focussing on 
> mobility solutions
> that can be implemented at the edge of an IP network where 
> the IP address
> does not change.
> 
> Let's discuss on the call today.
> 
> thanks,
> Dana
> 
> >
> >> What we did in the H.323 Mobility work was not to use 
> these terms, but

---

From: "Gary Kenward" <[email-masked]>
Date: Wed, 17 Jan 2001 14:20:40 -0500

> Sent: Wednesday, January 17, 2001 11:08 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: [email-masked]

I didn't say I supported the proposal, I was simply echoing
the distilled version.

> pdn>context with a friendly neighborhood of MAs.  Can you

The old Mobile Data International packet data system used
mobile control handover. Worked extremely well, except that
10 - 20% of the bandwidth could easily be consumed by the
handover signalling (yeah, I know Phil, bandwidth isn't really 
scarce). And there wasn't much pretense of security.

> pdn>other in Phil's utopian mobility enabled globe.

Excuuuuuuse me! I didn't create the hierarchy. The MIP people
did. Indeed, I think I missed a level of MIP hierarch, FH/HMIP,
which has introduced yet another mobility agent: the GFA.
Frankly, I actually believe that you only need one mobility
solution (and that doesn't mean MIP nor soft handoff). However, I 
do believe that for scalability reasons, there are local and global
components.

> pdn>creative juices.  May be try being flipper since this

Don't get me started, the outside world may not be ready for Gary
Kenward's flippancy...

But, since you ask, I was originally going to propose that we use the
term "C-mobility" instead of "micromobility".

> -pdn

A bientot.
Gary

---

From: Kulwinder Atwal <[email-masked]>
Date: Thu, 18 Jan 2001 00:19:23 -0500

I agree, it is much better than "domain", "sub-net", "coverage area", or
"service area".
 
- Kulwinder.

---

From: Kulwinder Atwal <[email-masked]>
Date: Thu, 18 Jan 2001 00:37:08 -0500

Why not be technology neutral and NOT use MIP vs edge terminology?
 
MIP maybe replaced in the future for reasons known, or unknown to us.
I know it is very, very hard for a Nortel guy to even imagine the
possibility of a Universe with no MIP, 
but stranger things have happened.
 
I fully and completely support Phil's suggestion.
 
Let's be protocol neutral and go with " edge vs core".  Let's at least start
with:
 
 - a clean slate
 - figure out what we need SeaMoby to be first
 - Learn about the requirements of all of the different network types that
need SeaMoby. 
- Learn about the protocols that can offer some functionality to SeaMoby:
ie. SLP.
 
- Kulwinder.

---

From: [email-masked]
Date: Thu, 18 Jan 2001 10:25:33 +0200

Hi Gary,

[<JAL> ]  FA is a Mobile IPv4 term (if I am not 
mistaken).  I think we should avoid using this
term - as I do believe we are considering IPv6
usage.
 
br,
John

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 18 Jan 2001 12:07:20 -0500

This issue is not edge vs MIP nor Seamoby vs MIP. It is in our charter to
interwork
with other IETF technology solutions, including, specifically MIP. Thus, we
have to
define the boundary, and consider how the two would interwork.
 
In addition, until we have the "edge" problem resolved, we really have no
business touching
on MIP issues, never mind talking about MIP being replaced.
 
Having said this, I would re-emphasize an earlier point made that I
supported: SeaMoby
does need to interoperate with MIP, but it should also be able to work
without MIP (implying that the services provided by MIP are either not
required or provided by another, possibly proprietary solution).
 
Gary

-----Original Message-----
From: Kulwinder Atwal [mailto:[email-masked]]
Sent: Thursday, January 18, 2001 12:37 AM
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Dana L. Blair'; Phil Neumiller;
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [seamoby] micro, schmicro

 
 
 - a clean slate
 
- Kulwinder.

---

From: "Guilhem Tardy" <[email-masked]>
Date: Thu, 18 Jan 2001 13:24:54 -0500

Gary,

I totally agree with your last message. :)

So, when those boundaries are defined in a neutral wording (i.e. not
specific to MIP), I strongly support interworking with MIP *and* whatever
else IETF technology solutions outside of those boundaries. I certainly did
NOT intend to have Seamoby replace any IETF technology solutions *outside of
the boundaries of Seamoby* (even MIP, believe me!), and I feel overjoyed by
reading your last paragraph which emphasizes the neutrality of Seamoby
regarding to those IETF (or proprietary, as you noted) technology solutions.

Guilhem.

> From: Kenward, Gary [WDLN2:AN10:EXCH] 
> Sent: Thursday, January 18, 2001 12:07 PM
> To: 'seamoby'

---

From: [email-masked]
Date: Fri, 19 Jan 2001 09:03:50 +0200

Hi Gary,

> required or provided by another, possibly proprietary solution).

I think more importantly, as I said at the IETF in San Diego, I 
don't think any of us want to attend a BOF called 'Interworking
between SeaMoby & Mobile IP' ...

br,
John

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 19 Jan 2001 12:33:24 -0500

I'm not sure that you intended your comment to be humorous, but it 
brought a smile to my face.

I definitely agree.
Gary

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, January 19, 2001 2:04 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked]

---

From: [email-masked]
Date: Mon, 22 Jan 2001 10:15:50 +0200

Hi Pat,

> Using statements like complexity is a red-herring. I've 
> implemented Mobile IP,
> and it really isn't that complex. Any piece of code is 
> complex, so I would
> argue that it will be very hard to justify another protocol 
> to solve non edge routing.

I agree and do think that when all is said and done, 
the solution developed in SeaMoby will be fairly 
complex as well.

John

---

From: Kulwinder Atwal <[email-masked]>
Date: Sun, 28 Jan 2001 01:02:26 -0500

> Why are you so attached to telling everyone how to design a 
> network?  I can
> guarantee I can design a network with 5 hops to the decision 
> making body that
> still makes the same window, and is more efficient.  Frankly, 
> you are limiting
> yourself by keeping this TOO CLOSE to the MN...you're not 
> giving it enough
> choices...see more on this below.

The key phrase here is "primary functionality".  I knew the moment that I 
typed it someone would mis-understand.  I fully recognize the 
need for there to be functionality further away.  Such as changing the CoA.
What I was referring to were "shades of gray", not "black and white"
solutions.
I have previously made statements supporting your views (If memory serves).

Choice is my number two concern, after real-time performance.  

> Wrong, we must use intelligent packet switched clouds (a LOT 
> faster than
> routing)

I was trying to limit the solution space to something smaller than the "Oort
Cloud".
The problem I have with drawing a cloud is that I don't know if the new path
is 
significantly shorter, or longer than the old path.  If it is much longer
(ie. geo-synchro satillite)
then seamless hand-off of real-time streams is not possible due to time lag,
and we may opt for reactive handoff.

> Bzzzt.  We want the MN to be able to choose from the APs 
> around it...to do
> this efficiently (and cost effectively), we want to move this 
> a few hops from the
> AP, so the network can experience some natural aggregation, 
> thus eliminating
> the need for every AP to be linked to every possible 
> neighbor, and allowing a
> link to die without impeding CT.

I agree that efficiency is possible by aggregating some functionality.  I
wish you could see the draft.  My concern was over the terminology.  

Also, I think you are assuming that a user with a private Bluetooth or
802.11 network will actually have, or want five hops.  This the Commericial
Cellular, or ISP business model.  If I don't want to pay for ISP bandwidth
to connect with a co-worker in the next room should I be forced to do five
hops for "efficiency" ?  Can I not choose less hops and save some money?  I
suppose it depends if you primary concern is efficient use of ISP resources,
or efficient use of end-user resources (saving money). 

> Ouch...again, painful.  This is an over-generalization.  See 
> SCTP.  SCTP is
> the perfect protocol for this stuff, since that's what it was 
> designed for.  Why
> confirm every single message and waste bandwidth and battery, 
> when there's a
> better method?

I am NOT saying send a seperate confirmation message for message sent.
Messages in Bluetooth are confirmed using a "piggyback" scheme.  A single
bit (ARQN) is set to one in the header to indicate postive confirmation of
the reception, of the last message during the last Master/Slave time.  It is
set to zero to indicate negative confirmation.  There is no significant
"extra"  bandwidth, or battery life being wasted.  This is done at the L2
level.  

Further, I fully support SCTP. 

Referring to section 6.2 of RFC2960 (SCTP):

"The SCTP endpoint MUST always acknowledge the reception of each valid DATA
chunk." 

Sounds like positive confirmation.  My point is that in mobile wireless
communications it is not unreasonable to lose one packet every one hundred.
Further, if we want successful seamless transfer, some type of confirmation
+ timeout scheme must be considered for the very reasons that you have
stated for the wired side in addition to the wireless reasons.  This is what
I mean by transaction-based mode changes. 

- Kulwinder.
Bluetooth Firmware Design
Zucotto Wireless Inc.