RE: Tone Generation Proposal

Given the subject and the reflector's restrictions, I'll try to make my
response as short as possible. Please, first see my answers to your questions
on our proposal in-line with your questions (marked with <EN>, </EN>). Then -
please see the part which analyses your proposal immediately below
(COMMENTS).

First - general comment related to all tables participating in tone
generation: the reasonable level of flexibility in changing the tone
generation parameters (e.g. frequencies values, compositions of the tones,
and duration of the frequencies and their dB levels) is defined by the
practical needs of the Operators in changing these parameters "on-the-fly".
The tone generation parameters, once established for the particular Operator
(e.g. geographical zone), are not changed until the EMTA is used in the realm
of this Operator. Hence - the real need for modifying these parameters
"on-the-fly" is quite limited. 

COMMENTS:
=========

1. Having "ToneType" to be an index in ALL tables creates unneccessary
interdependecies in the tables making processing logic unneccessary more
complicated. For example, having the ToneTable Index in "FreqTable" prohibits
the re-use of the same Frequency Group (the same frequency composition) for
different tones. This results in the waste of resources of the MTA.
Your example seems to demonstrate that the ToneType is not required when
transitioning from multi-freq-tone table with ToneType=5 to the FreqTable
with PriGrp=1. Our approach demonstrates how this can be accomlished simpler,
without "ToneType" being an index in all tables.

***** If ToneType is eliminated from the "FreqTable", then this table becomes
almost identical to the "FreqGroupTable" of our proposal.

2. pktcSigDevMultiFreqToneTable: 
   - The number of groups for each tone is unneccessary restructed by two.
What if the tone requires more than two groups?
   - "CompMode" is not clearly defined: if it reffers to the Composition of
the Groups (as an example seems to state) then the control over frequencies
composition is  not possible. If it reffers to the composition of the
frequencises, then Groups composition is not defined. Also CompMode has to
have the Modulation option in which case it's not clear what's modulating
what - group over group or frequency over frequency. In both cases, it's not
defined how the modulation's done.
   - "FreqNum" is not neccessary as it's not being used in the tone
generation (based on the example).

***** If "FreqNum" and "SecGrp" are eliminated from the
pktcSigDevMultiFreqToneTable, then this table becomes almost identical to the
"GroupSeqTable" of our proposal with the index "ToneType" essentially used
the same way as "GrpSeqIdx" in our proposal.

3. pktcSigDevToneTable:
   - "NumOnOff" is not clearly defined, hence the restriction related to it
is not clear: "FreqNum in the multi freq tone table MUST not exceed its
corresponding value specified in pktcSigDevToneNumOnOffCount". If it's "the
number of on-off sequence(pktcSigDevToneNumOnOffCount) required for each tone
type"  (as stated by your description), then the numbers in the example do
not correspond to it: for ToneType=12, NumOnOff should be '5', not '3'. If
"NumOnOff" is the number of occurances of the particular ToneType in the
pktcSigDevMultiFreqToneTable (but NOT the number of frequencies as the name 
"FreqNum" seems to suggest!), then this number equals to the number of rows
with same ToneType in  pktcSigDevMultiFreqToneTable. In both cases "NumOnOff"
is not needed.
   - "NumFreq" is not needed as this number equals to the number of the rows
for the corresponding group in pktcSigDevToneFreqTable.

***** If "NumOnOff" and "NumFreq" are eliminated from the
pktcSigDevToneTable, then this table becomes almost identical to the
"ToneTable" of our proposal.


Eugene Nechamkin,
Broadcom Corp.

-----Original Message-----
From: T, Shivakumar [mailto:[email protected]] 
Sent: Tuesday, June 28, 2005 11:00 PM
To: Eugene Nechamkin; Ipcdn (E-mail)
Subject: RE: [ipcdn] Tone Generation Proposal

The following issues are not addressed in this proposal. 

1) Since the FreqVal is index to the FreqGroupTable, the frequencies used for
playing a tone cannot be modified.
<EN>
Respectfully disagree. If changing the frequency for the same group is the
requirement, it can be simply arranged by choosing a different index in the
MIB table (when we come to the MIB issues) or by just creating a new group in
the "FreqGroupTable" and, possibly, deleting the previous one (if necessary).

</EN>

2) There is no way to increase or decrease the number of frequencies used to
play a tone.
<EN>
Respectfully disagree for two reasons. Firstly - if necessary, this can be
easily done by just incuding an additional row in the "FreqGroupTable" or
deleting the row from the table. For example: say you want to introduce
additional freq of 600 Hz to the "callWaiting4(12)" tone. This can be easily
done by just creating an additional row in the "FreqGroupTable":

FreqGrpIdx     FreqVal    DbLevel       CompMode   
========================================================================
2               600        -100            1

Secondly - there is no need to modify the frequency composition 'on the fly'.
The table should be setup ahead of time to meet the tone requirements.
</EN>

3) The entry with FreqGrpIdx=2 and FreqVal=440 in the FreqGroupTable can be
used for playing multiple tone types(callwaiting 1,2,3,4) and modifying any
value in this row would affect the other tone type.
<EN>
Respectfully disagree for two reasons. 
Firstly - it can be done by by introducing a new Frequency Group for each
tone (if neccesssary). Secondly - there is no need to modify the frequency
composition 'on the fly'. The table should be setup ahead of time to meet the
tone requirements.
</EN>

4) Why CompMode=2 be restricted to 1st and 2nd frequencies.
<EN>
I cannot think of any other real example of the tone when more than two
frequencies are participating in the modulation when generarting a particular
tone. I would appreciate any reference on such example. If this is realy
required then we need to clearly define how to modulate more than 2
frequencies.
</EN>


All these issues are addressed in the following proposal:

1) Define a freq table(pktcSigDevToneFreqTable) indexed by
pktcSigDevToneType,pktcSigDevToneFreqGrpNumber,pktcSigDevToneFreqIndex.

pktcSigDevToneFreqGrpNumber: This MIB Object along with pktcSigDevToneType
groups multiple frequency entries that has to be added to form a tone.

ToneType FreqGrpNumber FreqIndex FreqValue DbLevel
===================================================
   5           1           1        1400     -130
   5           1           2        2060     -130
   5           1           3        2450     -130
   5           1           4        2600     -130
  12           1           1         440     -130


2) Define a Multi Freq Tone table(pktcSigDevMultiFreqToneTable) indexed by
pktcSigDevToneType, pktcSigDevToneFrequencyNumber.

This Table is same as the one defined in draft-8 except that instead of
specifying the frequency values in the PriCompValue and SecCompValue we'll
specify the Freq Group Number(pktcSigDevToneFreqGrpNumber) for a specific
tone type. Also CompMode can contain either ignoreSecondary(1) or
primaryModulatedBySecondary(2).

ToneType FreqNum PriGrp SecGrp CompMode CompPrtg OnDur OffDur RepeatCount
========================================================================
==
   5        1      1       1       1       0      100    100      1
  12        1      1       1       1       0      100    100      1
  12        2      1       1       1       0      300    100      1
  12        3      1       1       1       0      100    100      1


3) Define a tone table(pktcSigDevToneTable) indexed by pktcSigDevToneType.
This table is same as the one defined in draft-8 except for the DbLevel is
removed and two new columns are added to specify the number of
frequencies(pktcSigDevToneNumFrequencies) and to specify the number of on-off
sequence(pktcSigDevToneNumOnOffCount) required for each tone type.

For any tone type the FreqIndex in the FreqTable MUST not exceed its
corresponding value specified in pktcSigDevToneNumFrequencies and the FreqNum
in the multi freq tone table MUST not exceed its corresponding value
specified in pktcSigDevToneNumOnOffCount.

ToneType RepeatCount Steady NumFreq NumOnOff
=============================================
   5        5000        2      4       1
  12         700        2      1       3


In order to play the offhookwarning tone(tone type=5), iterate over all
entries in the multi freq tone table with index 5. For each row in the multi
freq tone table with index=5 select the corresponding PriGrp and SecGrp.

PriGrp = 1
SecGrp = 1

The PriGrp specifies the group number of the primary component of the tone.
This is specified in the FreqTable. This tone is generated by adding all
frequencies specified in the freq table for that particular tone type and
FreqGrpNumber(value specified in PriGrp).

Primary Component of the Tone = 1400 + 2060 + 2450 + 2600

Since compMode is set to 1(ignoreSecondary) the secondary component is
ignored. The resulting tone is played for 100msec ON(on dur) and 100msec
OFF(off dur) once(repeat count).

This entire sequence is repeated for the value specified in RepeatCount of
the Tone Table.

Repeat Count = 5000
------------------------------------------------------------------------
-

Shiva