Considering the measurement parameters, the IETF IPPM working group hasn’t give
any recommendations about multiparty communication. All of their defined
parameters and relevant metrics are original for unicast traffic environment. In
another words, those parameters are defined to evaluate one-to-one traffic but not
one-to-many and many-to-many. In the view of a multiparty communication group,
whether they use unicast or multicast, there is more than one user receiving the same
information from the group but, very possibly, with different QoS in terms of the
packet delay, jitter and packet lost rate, especially when the satellite links are
introduced in real-time applications. Consider the following case (I): three users are in
a conference where user A and user B locate very closely and user C is very far from
them and communicate with them via a satellite. When user A violently discusses
with user B, user C may not have chance to speak in because he could be more than a
second later to hear what user A and user B are talking about. It could be worse if this
conference is using push-to-talk technique, in which if a user want to talk he should
wait until no one speaks in a conference. Another case is the Internet gaming. All of
the players in a game demand similar QoS. Imagine that three players, A, B and C, are
competing in a game on the Internet, in which A and B locate closely and C is one
satellite hop away. If C receives game data seconds later than A and B, he can never
win the game. So we are hoping that all users in a multiparty communication group
can have less different relative QoS in terms of the delay, jitter and packet loss.
Therefore, we need a rule to judge if the difference of QoS at each multiparty
communication group user is tolerable or not, which cannot be achieved from the oneto-one parameters described in IPPM. In this section, we will define a group of
parameters, named one-to-group parameters, which can be measured as the evidence
of judging the multicast QoS.
There is another consideration. In the view of one multiparty communication group
member, he is receiving data from the group. In other words, he is receiving data from
a group of people instead of from one. It implies that the QoS of the traffic received,
in terms of delay, jitter and packet loss, will be verified from time to time when the
source changed. This situation often happens in a real-time conference when the
active speaker changed. Let us consider the three-user conference case (I) mentioned
in previous paragraph: when user A talking with user B, user B can hear user A with
very small delay. Then, user B begins to talk with user C. User B will find now the
communication is suffering much larger delay. Thus, the QoS changed sharply in the
view of user B when the person to whom he talked with changed between user A and
user C. if this change happens very often, user B may clearly feel the conference is
“unstable”. We need a rule to measure how unstable the QoS of a conference is. So
after defining the one-to-group parameters, we will define another set of parameter:
group-to-one parameters.
All of the parameter defined below based on one assumption that the multiparty
communication is using multicast technologies. We suppose that all multiparty
communication in the future will use multicast instead of unicast.
1.1.1. One-to-group parameters
One-to-group parameters are defined to measure the QoS in the view of a group
multicast users. Two subset parameters are introduced:
1. Group (algorithm) mean
a. Group mean delay
b. Group mean jitter
c. Group packet lost rate
2. Group variation
a. Group delay variation
b. Group jitter variation
c. Group packet lost rate variation
The one-to-group parameters are measured based on only one source in a multicast
group. Whenever we say one-to-group parameter, we should associate it with a
source. The Figure 1 shows this concept.
User D
M-CAST
M-CAST
LAN
Sat. Net
IP Net
User A
M-CAST
User B
M-CAST
User E
IP Net
M-CAST
User C
Figure 1 One-to-group measurement scenario example
In Figure 1, user A, B, C, D and E belong to the same multicast group. User D is the
only active source in the multicast group when measuring the one-to-group
parameters. User B and C are connected with user D through terrestrial IP network,
user E are in the same LAN with user D, and user A are connected with user D using a
satellite network. The one-to-group parameters measured in this scenario should be
associated with user D.
1.1.1.1. Group (arithmetic) mean
Group mean parameters are trying to measure the overall QoS for a multicast group.
The definition of the group mean is the mean of a mean one-way parameter, such as
one-way delay, one-way jitter and packet loss, measured simultaneously on all of the
multicast group members except of the active source. The word “simultaneously”
implies the mean one-way parameter should be calculated based on the same packet
sample at each user. For example, let us still consider the case (I). When user A
speaking, we capture a set of packets from P1 to Pn at both user B and user C
respectively. Then, the mean one-way delay of these packets is calculated for user B
and user C. Finally, we calculate the mean of these two mean one-way delays as the
group mean delay for this conference. The calculation definition should be the sum of
a list of numbers, the two mean one-way delays of user B and user C in this case,
divided by the total number of numbers in the list, which is two in this case. Thus, the
group mean delay in the case (I) is:
Group Mean Delay 
Mean Oneway Delay of User A  Mean Oneway Delay of User B
2
So the procedures to obtain group mean parameters are:
1. Simultaneously measure the one-way parameters, one-way delay, one-way
jitter and packet loss, on all of the receivers in a multicast group when there is
only one source active.
2. Calculate the mean one-way parameters, end-to-end delay, jitter and packet
loss rate, for each of the receiver.
3. Calculate the group mean parameters, group mean delay, group mean jitter
and group mean packet loss rate.
4. Change the active source and repeat the step 1,2 and 3 until all of the group
members have talked.
So for each multicast member acting as a source, we can have one value for a certain
group mean parameter. The metric of the group mean parameters could be:
Metric
name
<ICEBERGS
Group
Mean
(parameter
name)
–
beginning
time/date/duration >

Measurement parameters:

The source IP address

The multicast group address

Value of the group mean parameter

Packet type (audio, video and data)
1.1.1.2. Group variation
Group variation parameters are trying to measure how the QoS varies among all of the
users in a multicast group. The word “variation” in this document is the population
standard deviation. The definition of the group variation is the population standard
deviation of a mean one-way parameter, such as one-way delay, one-way jitter and
packet loss, measured simultaneously at all of the multicast group members except of
the active source. The word “simultaneously” means the mean one-way parameter
should be calculated based on the same packet sample at each users. Considering the
case (I) as an example, when user A speaking, we simultaneously capture a set of
packets from P1 to Pn at both user B and user C respectively. Then, the mean one-way
delay of these packets is calculated for user B and user C respectively. Finally, we
calculate the variation of these two mean one-way delays as the group delay variation
for this conference. The group variation parameter can be denoted by  para , where the
symbol “para” means the one-way parameter’s name such as delay, jitter and packet
loss rate, and calculation should be:
 para 
(x  )
2
N
(E 1)
where x should be the mean one-way parameter value (delay, jitter and packet loss
rate) and  is the corresponding group mean parameter value. N is the number of the
receivers.
So the procedures to obtain group variation parameters are:
1. Find out the group mean delay;
2. Calculate the group variation parameters
So each of the group variation parameter is only one value. The metric of the group
variation parameter could be:


Metric name <ICEBERGS Group Variation (parameter name) – beginning
time/date/duration >
Measurement parameters:
 The source IP address
 The multicast group address
 Value of the group variation parameter
 Packet type (audio, video and data)
If trying to provide all group members the best QoS with respect to lowest variation in
terms of delay, jitter and packet loss, the group mean and group variation metrics can
be used to decide the best source location. I.e., for a single source multicast group, we
can decide which member could be the data relay or proxy by comparing the group
mean and group variation. The source that provides both the lowest group mean and
the group variation would be chosen as the best source location. Another example is
the Internet gaming. Normally there is more than one server for one game. The choice
of the best server could be based on the group mean and group variation metrics.
1.1.2. Group-to-one parameters
Group-to-one parameters are defined to measure the QoS in the view of one multicast
user with respect to the fact that this user is receiving from more than one source in
the group. Three subset parameters are introduced:
1. Group member parameters
a. Group member delay
b. Group member jitter
c. Group member packet loss
2. Group member (arithmetic) mean
a. Group member mean delay
b. Group member mean jitter
3. Group member variation
a. Group member delay variation
b. Group member jitter variation
The group-to-one parameters are measured based on only one receiver in a multicast
group. Whenever we say group-to-one parameter, we should associate it with the
receiver. The Figure 2 shows this concept.
User D
M-CAST
M-CAST
LAN
Sat. Net
IP Net
User A
M-CAST
User B
M-CAST
User E
IP Net
M-CAST
User C
Figure 2 Group-to-one measurement scenario example
Figure 2 shows almost the same information as Figure 1. The difference is, in Figure
2, user D is the receiver who received data from all of the rest group members
simultaneously or consequently. The group-to-one parameters measured in this
scenario should be measured and associated with user D.
1.1.2.1. Group member parameters
Group member parameters are trying to measure the average multicast QoS for one
multicast member. The definition of one multicast user’s group member parameters is
the parameters, such as delay, jitter and number of packet lost, which measured at this
user when it is receiving data from all of the rest multicast group members. For
example, let’s still consider the case (I). We are going to measure the group member
parameters of user B. When user A speaking, we capture a set of packets (Set A) from
P1 to Pn at user B. Then, user C takes the conference floor and begin to talk. We can
capture another set of packets (Set B) from P1’ to Pn’ at user B. Obviously, the one-toone parameters for Set A and Set B are different because of the various network
environment between user A and user B and between user C and user B. However, if
we consider Set A and Set B as a big packet set (Set C), we can have the group
member parameters of user B by calculating the delay, mean jitter and number of
packet lost of the Set C.
So the procedures to obtain group member parameters are:
1. Keep the measured user X silent and all of the rest group members talk one by
one.
2. Monitor the data stream received from the multicast group and measure the delay
and jitter for each packet and the number of packet lost using similar methods
described for one-way delay, one-way jitter and one-way number of packet lost.
The difference is the source in this case is the multicast group. The source IP
address is the multicast group address. The measured results are the group
member delay and jitter for user X.
3. Repeat the step 1 and 2 to measure the group member parameters at all of the rest
multicast members.
The metric of the group member parameters could be:


Metric name <ICEBERGS Group member (parameter name: delay, jitter or
number of packet lost) – beginning time/date/duration >
Measurement parameters:
 The multicast group address
 The address of the measured node
 Value of the group member parameter


Packet length
Packet type (audio, video and data)
1.1.2.2. Group member (arithmetic) mean
The Group member mean parameters are the mean of the group member parameters.
I.e.:

Group member mean delay: the arithmetic mean of the group member delay

Group member mean jitter: the arithmetic mean of the group member jitter.
The group member mean parameters are for measuring the average QoS of all
multicast group members.
The metric of the group member parameters could be:


Metric name <ICEBERGS Group member mean (parameter name: delay or
jitter) – beginning time/date/duration >
Measurement parameters:
 The multicast group address
 The address of the measured node
 Value of the group member mean parameter
 Packet type (audio, video and data)
1.1.2.3. Group member variation
Group member variation parameters are trying to measure how the QoS varies when a
user receiving data from all of the rest members in a multicast group. The definition
of the group member variation of a user X is the variation of its group member
parameters, such as group member delay, group member jitter and group member
packet loss. I.e.:

Group member delay variation: the variation of the group member delay

Group member jitter variation: the variation of the group member jitter.