Subject: [ipcdn] Tone Generation Proposal

From: "Eugene Nechamkin" <[email-masked]>
Date: Tue, 28 Jun 2005 18:25:21 -0700

After looking at the issues associated with the Tone Table definition, here
is the proposal which seems to have a potential to solve the following
outstanding issues:

1. to be able to represent the tones with potentially any number of
frequencies (as opposed to draft-07 with four frequencies limit, and draft-08
with two frequencies limit)

2. to be flexible enough without adding unneccessary complexity to satisify
the MIB doctors requirement (MIB doctors coments for draft-07).

3. to be able to generate twist DB level between two freqs for a tone (as
opposed to draft-08)

Before going into the MIB details, here is the basic idea illustrating the
approach:

1. Define the Frequency Group Table (FreqGroupTable), indexed by FreqGrpIdx
and FreqVal.
This table can be viewed as the "Table of Chords" (using the analogy in one
of the recent e-mails):

FreqGrpIdx     FreqVal    DbLevel       CompMode   
=============================================================================
=======
1               1400       -100            1
1               2060       -100            1
1               2450       -100            1
1               2600       -100            1
2               440        -130            1

COMMENTS:
	- dBLevel - per frequency tone level. Darft-08 was not able to
generate twist DB level between two freqs for a tone. Overall level of all
tones in a frequency group MUST NOT exceed -3dB.
	- CompMode - the following operations on the frequencies in each
group are defined to aggregate them for the tone generation: 
	     - sum of all frequencies in the table (=1),
	     - modulation of the 1st one by the 2nd one (=2)
	- FIVE Freqs per group - MAX.

2. Define Group Sequence Table (GroupSeqTable), indexed by GrpSeqIdx and
GrpNumIdx.
This table can be viewed as the "Table of Musical Themes" (using the analogy
in one of the recent e-mails):

GrpSeqIdx     GrpNumIdx    FreqGrpIdx     DurationON   DurationOFF
RepeatCount
=============================================================================
===
 1                  1          1           100            100              0
(no repeat)
 2                  1          2           100            100              0
(no repeat)
 2                  2          2           300            100              0
(no repeat)
 2                  3          2           100            100              0
(no repeat)

COMMENTS:
	16 Groups per Sequience (Tone) - MAX.

3. Define Tone Table (ToneTable), indexed by ToneType. 
This table can be viewed as the "Table of Musics" (using the analogy in one
of the recent e-mails), with each "Music" corresponding to the particular
Tone being generated:

ToneType    GrpSeqIdx   WholeToneRepeatCnt   ToneSteady
===============================================================
5            1                  5000              2 (no)
12           2                   700              2 (no)

Here is how all these three tables would work together:

1. If EMTA needs to generate "offHookWarning(5)", it looks at the Table-3
(ToneTable), 1st row. This row refers to the Group Sequence '1' (GrpSeqIdx ==
1). The Group Sequence Index is located in the Group Sequence Table (Table-2)
(1st row for GrpSeqIdx==1) which indicates that the Frequencey Group 1
(FreqGrpIdx=1) should be used to generate the tone. The Table-1 described the
composition of this group with various frequencies for FreqGrpIdx==1, which
tells the EMTA to take four frequencies, sum them up (CompMode==1), and play.
Because there is no any more Frequencey Group pointed in the Table-2 for the
Group Sequence '1' (GrpSeqIdx == 1), the "offHookWarning" tone is generated
by repeating this 5000 times (WholeToneRepeatCnt==5000) with the tone being
not steady (ToneSteady==2)

===> Here is how this tone would sound

1) 1400Hz + 2060Hz + 2450Hz + 2600Hz on for 100ms
2) 1400Hz + 2060Hz + 2450Hz + 2600Hz off for 100ms
3) repeat (1) and (2) 5000 times

2. If EMTA needs to generate "callWaiting4(12)", it looks at the Table-3
(ToneTable), 2nd row. This row reffers to the Group Sequence '2' (GrpSeqIdx
== 2). The Group Sequence Index is located in the Group Sequence Table
(Table-2) (2nd, 3rd abd 4th rows for SeqGrpIdx==2) which indicates that the
Frequencey Group 2 (FreqGrpIdx=2) should be used to generate the tone, and
this Group should be played three times. The Table-1 described the
composition of this group with various frequencies for reqGrpIdx==2, which
tells the EMTA to take one frequency (Freq=440) and play it for the 2nd row
of the Table-2. Then 3rd row of the Table-2 is played and finally, 4th row of
the Table-2 is played. The whole "melody" of three repetion of the Group #2
(FreqGrpIdx== 2), plays the required tone by repeating this 700 times
(WholeToneRepeatCnt==700) with the tone being not steady (ToneSteady==2).

===> Here is how this tone would sound

(1) 440Hz on for 100ms
(2) 440Hz off for 100ms
(3) 440Hz on for 300ms
(4) 440Hz off for 100ms
(5) 440Hz on for 100ms
(6) 440Hz off for 100ms
(7) repeat (1) through (6) 700 times

Eugene Nechamkin,
Broadcom Corp.

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "T, Shivakumar" <[email-masked]>
Date: Wed, 29 Jun 2005 11:29:42 +0530

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.

2) There is no way to increase or decrease the number of frequencies
used to play a tone.

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.

4) Why CompMode=2 be restricted to 1st and 2nd frequencies.

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Eugene Nechamkin
Sent: Wednesday, June 29, 2005 6:55 AM
To: Ipcdn (E-mail)
Subject: [ipcdn] Tone Generation Proposal

After looking at the issues associated with the Tone Table definition,
here
is the proposal which seems to have a potential to solve the following
outstanding issues:

1. to be able to represent the tones with potentially any number of
frequencies (as opposed to draft-07 with four frequencies limit, and
draft-08
with two frequencies limit)

2. to be flexible enough without adding unneccessary complexity to
satisify
the MIB doctors requirement (MIB doctors coments for draft-07).

3. to be able to generate twist DB level between two freqs for a tone
(as
opposed to draft-08)

Before going into the MIB details, here is the basic idea illustrating
the
approach:

1. Define the Frequency Group Table (FreqGroupTable), indexed by
FreqGrpIdx
and FreqVal.
This table can be viewed as the "Table of Chords" (using the analogy in
one
of the recent e-mails):

FreqGrpIdx     FreqVal    DbLevel       CompMode   
========================================================================
=====
=======
1               1400       -100            1
1               2060       -100            1
1               2450       -100            1
1               2600       -100            1
2               440        -130            1

COMMENTS:
generate twist DB level between two freqs for a tone. Overall level of
all

2. Define Group Sequence Table (GroupSeqTable), indexed by GrpSeqIdx and
GrpNumIdx.
This table can be viewed as the "Table of Musical Themes" (using the
analogy
in one of the recent e-mails):

GrpSeqIdx     GrpNumIdx    FreqGrpIdx     DurationON   DurationOFF
RepeatCount
========================================================================
=====
===
 1                  1          1           100            100
0
(no repeat)
 2                  1          2           100            100
0
(no repeat)
 2                  2          2           300            100
0
(no repeat)
 2                  3          2           100            100
0
(no repeat)

COMMENTS:

3. Define Tone Table (ToneTable), indexed by ToneType. 
This table can be viewed as the "Table of Musics" (using the analogy in
one
of the recent e-mails), with each "Music" corresponding to the
particular
Tone being generated:

1. If EMTA needs to generate "offHookWarning(5)", it looks at the
Table-3
(ToneTable), 1st row. This row refers to the Group Sequence '1'
(GrpSeqIdx ==
1). The Group Sequence Index is located in the Group Sequence Table
(Table-2)
(1st row for GrpSeqIdx==1) which indicates that the Frequencey Group 1
(FreqGrpIdx=1) should be used to generate the tone. The Table-1
described the
composition of this group with various frequencies for FreqGrpIdx==1,
which
tells the EMTA to take four frequencies, sum them up (CompMode==1), and
play.
Because there is no any more Frequencey Group pointed in the Table-2 for
the
Group Sequence '1' (GrpSeqIdx == 1), the "offHookWarning" tone is
generated
by repeating this 5000 times (WholeToneRepeatCnt==5000) with the tone
being
not steady (ToneSteady==2)

2. If EMTA needs to generate "callWaiting4(12)", it looks at the Table-3
(ToneTable), 2nd row. This row reffers to the Group Sequence '2'
(GrpSeqIdx
== 2). The Group Sequence Index is located in the Group Sequence Table
(Table-2) (2nd, 3rd abd 4th rows for SeqGrpIdx==2) which indicates that
the
Frequencey Group 2 (FreqGrpIdx=2) should be used to generate the tone,
and
this Group should be played three times. The Table-1 described the
composition of this group with various frequencies for reqGrpIdx==2,
which
tells the EMTA to take one frequency (Freq=440) and play it for the 2nd
row
of the Table-2. Then 3rd row of the Table-2 is played and finally, 4th
row of
the Table-2 is played. The whole "melody" of three repetion of the Group
#2
(FreqGrpIdx== 2), plays the required tone by repeating this 700 times
(WholeToneRepeatCnt==700) with the tone being not steady
(ToneSteady==2).

(1) 440Hz on for 100ms
(2) 440Hz off for 100ms
(3) 440Hz on for 300ms
(4) 440Hz off for 100ms
(5) 440Hz on for 100ms
(6) 440Hz off for 100ms

Eugene Nechamkin,
Broadcom Corp.

---

From: "Eugene Nechamkin" <[email-masked]>
Date: Wed, 29 Jun 2005 15:21:48 -0700

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-masked]] 
Sent: Tuesday, June 28, 2005 11:00 PM
To: Eugene Nechamkin; Ipcdn (E-mail)
Subject: RE: [ipcdn] Tone Generation 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":

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>

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

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.

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).

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

Repeat Count = 5000

Shiva