Subject: [NEXTEL-1] Define System Channel Capacity

From: [email-masked]
Date: Wed, 11 Jun 2003 10:54:44 -0400

------- Original Message --------
From: Bill McLain <[email-masked]>
Subject:Define System Channel Capacity

	I have been reviewing the PSWN Operational Best Practices report on
trunked LMR systems.  They recommend to maintain 20% excess system channel
capacity.  My question is what does this mean?  How do you really determine
"system capacity"?  By the FCC determinations, you need from 80 or 100
terminal units per channel.  Somehow this doesn't really fit properly
either.  This seems correct if it were conventional operations as I can see
100 users all on a single channel, all of the same organization.  But when
you bring in 100 units comprised of 15 units of 8 different organizations,
you have a major communications problem.  
	So back to the basic premise, how do you really define system
channel capacity?  If I look at 10 channel site data, and for example, and
see that only 8 of the channels are every busy at a time, does this mean
that I have 20% excess capacity?  Like wise, can I consider the same for
only having 4 channels of a 5 channel site busy for the majority of the
time?  
	Additionally, do you consider queuing?  Do queues that average less
than .5 --(one-half) of a second factor into the picture.  In fact does a
queue ever enter the picture?  Consider our network--some 80+ sites,
approximately 350 channels in operation, some 27M PTT's per month with over
8M data calls going on.  Some sites never see a queue, others may have
queuing levels of 1% for brief periods of time.  

thanks

bill  

Bill McLain
Network Engineer
RACOM Corp
888.752.1044    phone
888.751.1070        fax
[email-masked]

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get A Free Psychic Reading! Your Online Answer To Life's Important Questions.
http://us.click.yahoo.com/Lj3uPC/Me7FAA/ySSFAA/61FxlB/TM
---------------------------------------------------------------------~->

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

---

From: "Madden, Roger" <[email-masked]>
Date: Wed, 11 Jun 2003 17:30:31 -0400

Bill,
You bring up some really good questions.  Wish I had some good answers.

I don't know what PSWN meant by 20% excess capacity, but with their
endorsement of P25 trunked systems, I gotta believe that, essentially,
PSWN means no queuing on the service channels during "normal busy hour"
operations, and less than 80% peak occupancy on any channel, including
the trunking control channel, during a 24 hour period.  When your system
controller begins showing occupancy significantly greater than that, you
apply for additional channels.   
 
With regard to the FCC channel criteria, those criteria are more than 25
years old, and were developed in the early days of trunking, based on
manufacturer and public input to rulemakings on FCC Docket 18262.  I
would guess that few persons at the FCC foresaw statewide area
multi-site trunked systems in public safety applications, or large scale
adoption of trunking technology for small cities.  Otherwise, I'm sure
the per-channel loading would have been somewhat different, but probably
still a fixed number, because ultimately the FCC had to have a way to
manually process the applications.  Numbers work; formulas don't, when
you are an applications examiner processing 50 or so applications per
day.

When the numbers were created, a public safety conventional channel was
considered "fully loaded" at 50 mobiles. Message length statistics had
been gathered by SRI for the various radio services and Public Safety in
general had m90th percentile message lengths of about 8 sec.  Erlang
curves indicated at least 2 X additional capacity from trunking 5
channels, hence the 100 mobile number.

Sounds simplistic, and it was.  If anything, it was overly conservative
for single user single-site trunked systems.  Multi-user, multi-site
systems like yours weren't on the radar.

I'll give you more of my perceptions about the evolution of trunking in
the FCC rules later, if anyone is interested.  Most of the people who
wrote that history are gone, so I'm safe(grin).

Roger Madden
_____________
  
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, June 11, 2003 10:55 AM
To: [email-masked]
Subject: [NEXTEL-1] Define System Channel Capacity

------- Original Message --------

	I have been reviewing the PSWN Operational Best Practices report
on
trunked LMR systems.  They recommend to maintain 20% excess system
channel
capacity.  My question is what does this mean?  How do you really
determine
"system capacity"?  By the FCC determinations, you need from 80 or 100
terminal units per channel.  Somehow this doesn't really fit properly
either.  This seems correct if it were conventional operations as I can
see
100 users all on a single channel, all of the same organization.  But
when
you bring in 100 units comprised of 15 units of 8 different
organizations,
you have a major communications problem.  
	So back to the basic premise, how do you really define system
channel capacity?  If I look at 10 channel site data, and for example,
and
see that only 8 of the channels are every busy at a time, does this mean
that I have 20% excess capacity?  Like wise, can I consider the same for
only having 4 channels of a 5 channel site busy for the majority of the
time?  
	Additionally, do you consider queuing?  Do queues that average
less
than .5 --(one-half) of a second factor into the picture.  In fact does
a
queue ever enter the picture?  Consider our network--some 80+ sites,
approximately 350 channels in operation, some 27M PTT's per month with
over
8M data calls going on.  Some sites never see a queue, others may have
queuing levels of 1% for brief periods of time.  

thanks

bill  

Bill McLain
Network Engineer
RACOM Corp
888.752.1044    phone
888.751.1070        fax
[email-masked]

Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/

---

From: [email-masked]
Date: Thu, 12 Jun 2003 08:53:50 -0400

-------- Original Message --------
   From: Sean O'Hara  [email-masked]
Subject: Re: Define System Channel Capacity

All, Although Erlang-C and other theoretical models are often applied as a first
estimate, you almost always need to resort to simulation to get better accuracy.
All of the previously mentioned parameters need to be known in order to do this,
but they will often be different for different talk groups. There are also some
additional factors to consider. For each talk group the loading may come from a
different type of distribution, which may or may not have large components that
are periodic in time (shift times, rush hours, etc).  For example, certain talk
groups have larger percentages of cyclical loading levels, and some are almost
purely random and impulse (incident-driven).  The cross-correlation/covariance of
the entire set of talk groups must also be determined, as they will have highly
correlated loading characteristics.  Also, the talk groups structures themselves
become the dominant factor for GOS, as a talk group of even 1000 members can still
only generate about 0.6 Erlangs of traffic.  Therefore if you model a certain
amount of "Erlangs/user", the total loading within a talk group cannot exceed ~0.6
Erlangs - even though the total loading may add up to more than 10 times than on
paper.  Because of this, talk group size should be kept to the minimum number
necessary. The types of calls per users base must also be known. What percentage
are unit to unit?  Off-system?  Group to Group? Unit to Group? Interconnect?  What
is the correlation of these to incident-driven and periodic patterns? System
design also has a lot to do with this.  Wide area loading will affect a number of
sites, and require channel resources at all sites that light up (particularly
stressing to a multicast system, where the total spectrum requires goes through
the roof).  Also, multiple talkgroup quasi-membership or scan groups can also
carry a lot of unnecessary traffic around the system, so it is important to
characterize these effects in the simulation.  The logic structure of the master
database and system controller drives affects a lot of these factors. It is only
by considering these types of issues that a accurate answer be found.  Note that
many of these parameters can be found through measurements, and many are system
dependent.  You can see that voice capacity and traffic modeling can get quite
involved.  Data is a whole different story.... Sean

---

From: [email-masked]
Date: Thu, 12 Jun 2003 10:12:57 -0400

------- Original Message --------
   From: "Sean O'Hara" <[email-masked]>
Subject: Re: Define System Channel Capacity

Thanks Dave and Good Points, Control channel access must be modeled to estimate
collision probability as well as reentry delay times.   Call processing will also
have an effect, although I do not know what the typical values would be (probably
depends on the centralization or decentralization of control functionality).
These will affect directly affect GOS. I also forgot the protocols for late
entry.  If the call is not set up until a channel resource is clear at all sites
where members are registered, than the talk group GOS will increase roughly as
1-(1-GOS)^N,  where GOS is the single site GOS and N is the sites involved.  For
six sites a 1% GOS increases to almost 6%.  This is simplistic, as the site
loading correlation will be a large factor in the actual degradation.  Something
like this can only be modeled through simulation. As far as the talk group numbers
go, larger talkgroups clearly offer lower SYSTEM GOS.  However the result to the
end user is an apparent lower talk group GOS, as the Erlangs/user within the talk
group will be limited by the size.  For example, if all active officers in Group A
need to use the radio 30 seconds an hour for their own outbound messages, then a
talkgroup GOS of 0.05 would only support 6 active members (what PSWAC appeared to
use in their estimates).  In reality, membership is larger, and members reduce and
coordinate their communications internally.  Still, if you have a talk group with
60 members, you could never support more than 45 sec/hour of individual traffic -
not considering system overheads.  This amounts to about 3 messages per user per
hour at almost complete blocking levels - pretty low, and possibly pretty
dangerous. In order for PS to be able to use their radios more, talk group
membership should be as low as possible while supporting operational requirements,
and also reduce unnecessary cross group communications.  That said, situational
awareness factors usually drive a lot of outside group scanning. Sean