|
Vladimir and All,
My comments are inline with [YONG4].
I think that we have one open issue about general
usage of MBS_MAP IE.
Thanks,
Yong Chang.
----- Original Message -----
Sent: Thursday, August 19, 2004 4:18
PM
Subject: RE: [STDS-802-16-MOBILE]
[Harmonization] MBS Harmonization
Yong
and All,
See
my comments below under [VY3]
Vladimir
Vladimir and all,
I think that we can almost compromise each
other.
See my comments inline with [YONG3]
Thanks,
Yong Chang
----- Original Message -----
Sent: Tuesday, August 17, 2004 10:16
PM
Subject: RE: [STDS-802-16-MOBILE]
[Harmonization] MBS Harmonization
Yong,
I see that zone of our disagreement is comparatively small
See my answers below marked as [VY2]
Vladimir
Vladimir,
Thanks for your quick response.
My comments are inlined below under
[YONG2].
I think that we can harmonize
together.
If there is another company to have another
comments on it, please let us know.
Thanks,
Yong
----- Original Message -----
Sent: Tuesday, August 17, 2004 5:55
AM
Subject: RE: [STDS-802-16-MOBILE]
[Harmonization] MBS Harmonization
Yong,
Thanks for your letter.
See my
comments below,marked as [VY].
Vladimir > -----Original
Message----- > From: Yong Chang [ mailto:yongchang@samsung.com]
> Sent: Monday, August 16, 2004 3:17 AM
> To:
Vladimir Yanover; Roger B. Marks
> Cc: stds-802-16@ieee.org
>
Subject: Re: [STDS-802-16-MOBILE] [Harmonization] MBS
Harmonization
>
>
> Dear Vladimir and
all,
>
> First of all, I want to say sorry for not asking
you before.
> But, the authors shown in the initial drafts are
folks who are having
> comments on MBS issue now.
> I had
tried to tell who is involved in making a harmonization
> on MBS
now.
> When we upload the next version, we will strike out your
name from the
> Harmonization Draft.
>
> Second of
all, as I told in Harmonization Conference calls,
> we have
still open issues in MBS now.
>
> Last of all, my
technical comments are inline below with [YONG]
>
> I hope
to understand what we are going to do.
>
>
Thanks,
>
> Yong Chang
>
>
> -----
Original Message -----
> From: "Vladimir Yanover"
<vladimir.yanover@alvarion.com>
> To: "Roger B. Marks"
<r.b.marks@ieee.org>
> Cc:
<stds-802-16@ieee.org>
> Sent: Sunday, August 15, 2004
8:31 PM
> Subject: RE: [STDS-802-16-MOBILE] [Harmonization] MBS
Harmonization
>
>
> > Thanks, I am completely
satisfied
> > Vladimir
> >
> > >
-----Original Message-----
> > > From: Roger B. Marks
[mailto:r.b.marks@ieee.org]
> > > Sent: Friday, August 13, 2004 5:00
PM
> > > To: Vladimir Yanover
> > > Cc:
stds-802-16@ieee.org
> > > Subject: Re:
[STDS-802-16-MOBILE] [Harmonization] MBS
> Harmonization
>
> >
> > >
> > > Vladimir,
> >
>
> > > I've edited the file, striking out your
name.
> > >
> > > I've also noted in the index
that "Vladimir Yanover has
> been deleted
> > > from
the author list at his request."
> > >
> > >
Let me know if you have any problem with this solution.
> >
>
> > > Roger
> > >
> >
>
> > > At 12:54 +0300 2004-08-13, Vladimir Yanover
wrote:
> > > >All,
> > > >
> >
> >I was surprised to find my name in contribution
> >
> H80216e-04_005. It makes
> > > >wrong impression
that I basically agree with its content.
> > > >I never
saw this document before publication and was never
> > >
asked to sign on
> > > >it. So I cannot be
responsible
> > > >for content of the document as well
as for statements
> > > expressed in the
> > >
>document from the name of Alvarion.
> > > >
>
> > >I find this way of actions inappropriate and request
to
> > > remove the document
> > > >from
802.16 WEB site or at least to publish another version
> >
> without my name.
> > > >
> > >
>
> > > >My view on multicast services is the
following.
> > > >1. Requirements
> > >
>- ability to receive MC content while in normal
> operations
[not Idle]
> > > >- ability to employ power saving, at
least while in
> normal operations
> > > >- MC
content will be available only to authorized MSSs
> > >
>
> > > >Ability to receive MC content while in Idle
Mode should be a
> > > separated
> > >
>capability.
> ##################
> [YONG]
> We
don't need to put any limitation that MBS is applicable to
>
only Normal
> operations.
[VY] We are talking on
requirements here. If we drop requirement for ability to receive MC
data in Idle mode, then no additions to MAC are needed,
therefore
no new features in the system to develop. For me it is a strong
motivation to have a separated capability. I believe, many members
have same position.
Now, if we extend requirements to support
Idle mode, we need new features like new DL-MAP IE (you call it
MBS_MAP IE ) to help Sleep control in Idle mode.
As you might see
from my letter, I 1) accepted idea to have such IE 2) suggested
to make such IE general [not related to multicast business].
If we
do it, then we also do not need abovementioned restriction [separated
capability for Idle mode].
Let me know if it is OK for
you.
[YONG2]
That's fine. I do not intend to apply MBS_MAP IE only to MBS business.
This MBS_MAP IE generally can be used for telling when the next frame
associated with the CID is
transmitted from the BS.
[VY2] So we agree to extend
usage of renamed MBS_MAP IE. This also eliminates need in special
capability for Idle mode
Most companies do
not want to have different ways for MBS pending on the mode that
the MSS is currently in.
[YONG3] No issue any more
here.
> As I told several times, our MBS proposal is applicable to
all MSS
> types(e.g., awake, sleep, and idle) with the same
information element.
[VY] I don't understand what is
"MSS of awake type" or 'MSS of sleep type". Any clarification would
help a lot.
[YONG2] They
are MSS in awake mode, MSS in sleep mode.
What I tried
to say is that one unified way is needed for MBS like service
regardless of the mode that the MSS is currently in.
[VY2] Yes. See
previous comment.
[YONG3] No issue any more
here. >
For obtaining power saving, we want to use the same mechanism >
to be applied > to all MSS types. > Explictly, the
MSS can receive the registered MBS content > only when it
is > successfully authenticated and authorized for MBS
application > content that > it has requested. >
There is no technical reason to consider the ability to >
receive MBS content > while in idle mode as a separated
capability. > Technically, we can have much gain when the MSS in
idle mode > can receive the > MBS content seamlessly over
multiple BSs because the MSS can > receive the > MBS
application content on moving multiple BSs without any > network
re-entry > procedure. > Additionally, the MBS does not
limit the current normal > operation scenario. > That is,
the concurrent service(e.g., both unicast service on normal >
operation and MBS simultaneously) is always possible. >
################## > > > > > > > >
>2. To satisfy above requirements actually no additional
MAC > > > features needed. > > > >What we
need is few informative sentences: > > > >- Some of DL
Service Flows are for distributon of > multicast content >
> > >- While the MSS is in normal operations mode [not Idle],
all > > > procedures are > > > >performed
as in 6.3.13 [establishment of connections], usual > > >
>authorization/security stuff > > > >is applicable.
The MSS may go to sleep and be wakened by > > > TRF-IND
with > > > >reference to the CID associated with
multicast service > > ################## >
[YONG] > I told your positions in previous Harmonization
conference > calls on issues > and remedies. > If I
understand your proposal correctly, your proposal for DL SFID >
pre-reserved for MBS usage can be applicable to idle
mode. [VY] I said that there is a problem of CIDs used
for transmission of multicast content. If a an MSS in Idle mode
is
synchronized with a BS, and the BS is using certain CID for multicast
transmission, how the CID becomes known
to those MSSs? Simple
solution: assume that there is a mapping SFID onto CID, same for the
whole network and it is known to both BS and MSS.
We don't need to
specify it in the standard, just to say that such mapping
exists.
We may to do one step further and
to specify that certain set of CIDs is allocated for that [e.g. those
allocated in UL for multcast
polling].
[YONG2] At
least O.K. to me. > However, it seems to me that what you said on
authorization
> and security for
> MBS is very very
complex.
> If I follow your scenario, the MSS shall perform the
current
> network entry
> procedure always whenever the
MSS moves multiple BSs.
[VY] I don't understand sentence "the MSS moves
multiple BSs", so cannot comment on this part.
I don't understand also what is "my scenario".
[YONG2]
Your sentence
"While the MSS is in normal operations mode [not Idle],
all procedures are performed as in 6.3.13 [establishment of
connections], usual authorization/security stuff is
applicable." implied to me that the USUAL
authorization/security, not MBS authorization/security is
applied.
Under your
sentence, the MSS shall be re-authorized and shall change the
multicast security key acrossing multiple BSs.
Based
on what you said in your comment below, you are thinking the same
authorization/security stuff with what we are having.
[VY2] Once the MSS is in normal operations [not Idle mode] ,
it must perform all usual procedures including authentication and
establishment of
connections.
Now, the question is
whether multicast connections must be handled this way also. I
think, it may help. It will allow the BS to know that the
MSS is a consumer of multicast data and to establish bidirectional
communication with the MSS [for example, to provide at upper layer a
security update]
[YONG3] Initially, the MSS
shall perform the usual network entry procedure to obtain the
multicast IP # and port number from the network side. At that time, BS
may know whether or not this MSS is trying to get the MBS content.
However, the BS does not need to establish the traffic CID specific to
this MSS for transmission of MBS content. The MSS tends to get into
the idle mode after receiving the necessary connection and security
information from the BS. If the MSS moves to another BS on receiving
the MBS content, the another target BS does not need to know whether
or not the MSS receiving the MBS content currently comes in and what
mode the MSS in currently in. The encryption key update is
controlled by the network side.
MSS does not trigger updating the MBS
encryption key.
[VY3] This
is correct. This is why I didn't say "the MSS must do DSA for
multicast SFs." I would say "the MSS may do DSA for multicast
SFs."
[YONG4] O.K. I think
that we are on the same page.
> You can not obtain Macro Diversity
since the user-specific security
> mechanism is applied to the
MBS.
[VY] My interpretation of above
is: you're saying that if upper level security mechanism is
applied,
diversity combining cannot be used. If
this interpretation is correct, I'd like to say that I don't
understand
why diversity combining cannot be used.
If several BSs transmit same content and it is encrypted at upper
layer with same key,
then in the air we shall see same
transmissions [MAC PDUs]. Same is correct for encryption
at MAC level:
if two BSs use same key [for
encryption of MAC PDU payload], combining is possible, otherwise
it is not.
[YONG2]
That's what I am
trying to say. I think that your previous sentence might mislead
me misunderstanding what you tried to say.
[VY2} Seems no
disagreement
here?
[YONG3] As I answered in
response to Jeff's comments, the MBS encryption can be performed on
either application layer or MAC layer, not BOTH.
> Accordingly, your proposal using current normal
operation
> does not have any
> performance improvement on
receiving MBS content.
> Moreover, your proposal is very heavy
and overhead to the BS
> and MSS because
> BSs shall know
how many MSSs are currently receiving the specific MBS
>
content,
> how many MSSs are sleep mode currently, and MSS shall
join
> the specific MBS
> content at the network whenever
MSS wants to change his MBS
> application
>
channel.
>
> Conclusively, your scenario following the
current normal
> operation is based
> on current multicast
service using IGMP on IP and above layer.
[VY] Yong, I didn't say a word on
IGMP or IP multicast service.
I would appreciate if you read my
letter more carefully. Thanks
[YONG2] O.K. You
correct my misunderstanding.
> The
current standard can provide what you have in your mind
> at the
sacrifice
> of performance improvement(e.g., Macro Diversity),
simplicity(e.g., BS
> management, MSS join and leave
procedure)
> and generality(e.g., regardless of the MSS's
mode).
> Repeatedly speaking, our simplified MBS proposal does
not
> effect on the
> current normal operation.
>
##################
>
>
> > > >
> >
> >3. Ability of MSS to receive MC content while in Idle
mode
> > > should be a
> > > >separated
capability. In this case authorization should be
> > >
supported by
> > > >upper layers.
> > >
>For example, the content may be encrypted and only
> >
> authorized MSSs will have
> > > >the key. Mapping
of MC SFIDs onto CIDs shall be known to all BSs
> > >
>in the network and to all relevant MSSs [mechanism is out
of
> > > scope of 16e]
>
>
##################
> [YONG]
> As I said earlier, what you
said in the above is fine to me.
> Now, we are waiting for
another company's comment for harmonization.
>
##################
>
> > > >
> > >
>The only issue remains power save while in Idle mode. To
>
> > provide that,
> > > >MBS_MAP Information
Element may be useful, but I would
> make it more
> >
> >general: allow any CID to be encoded including Basic CID
of
> > > some MSS. Then
> > > >such IE
would signal to relevant MSS[s] that there will be
> > >
no DL traffic at
> > > >the CID within certain time
interval [so the MSS may save
> > > power, go for
>
> > >scanning etc.] Accordingly the name should be
changed
> [e.g. to "Idle
> > > >interval
IE"].
> ##################
> [YONG]
> I do not
understand what you are proposing.
> MBS-MAP extended IE is for
the prediction when the next MBS frame is
> transmitted.
>
Why this feature should be bound with MSS's Basic CID?
> MBS_MAP
IE is not relevant to the MSS but relevant to the
> Multicast
CID of
> MBS content.
> This MBS_MAP has already covered
normal operation. Don't need
> to limit to
> the Idle Mode
only.
[VY] Let me spell out my
suggestion.
1. Define IE of same structure as
you suggest
2. Make it not specific to MBS.
It means allow to use it for all CIDs, not only for those
carrying multicast content.
3. Change it's
name
Hope, this helps better
understanding
[YONG2] My
responses are
1. O.K.
2.
O.K.
3. How
about Pre-scheduling IE instead of MBS_MAP IE ?
[VY2} Is it really a prescheduling?
Seems reasonable to define the meaning of the IE as "BS says that for
N frames there
will be no transmission at the
CID". But I don't recommend to make it "BS says that after N frames there will
certainly be
a transmission at the CID". We don't need to
restrict ourselves. MSS receives the IE, goes to sleep,
awakes and starts to listen.
It may listen for several frames before
receives a multicast transmission. Or BS may decide
to send one more
IE of this type etc.
[YONG3] If the MSS miss the
frame detined to be transmitted after N frames, the MSS listen to next
several frames continuously till it receives this IE successfully. The
operation is not diffent each other.
Could you explain
what restriction we have now?
[VY3] My understanding of IE
function is the following
1. The IE may be used for any CID of
any MSS [not necessary in Idle mode]
2. Transmission off the IE means
that during N frames there will be no transmissions at the
connection.
3. If the CID is Basic CID of some
MSS, it means that there will be no transmissions to the
MSS
[certainly MSS in Idle mode
has no Basic CID, so #3 is not appliable to MSS in Idle
mode]
4. If such IE contains CID
related to the MSS, the MSS is supposed after N frames to be
ready to receive something from the BS.
There is no obligation from BS side
to really transmit data.
Now, assuming we agree with above
description, I would rather call it "Idle interval IE" or something
like that.
[YONG4] Let me explain what I
understood. I will appreciate if you correct me when I
misunderstood.
Initial purpose of MBS_MAP is to
provide how long the MBS transmission will be off by telling when the
next transmission is on.
The CID in MBS is not relevant to
specific to the MSS. This is what restriction you try to
say.
You agree to the purpose of MBS_MAP,
but you want re-name the MBS_MAP IE because this IE can be
applicable not only MBS
but also usual normal
operation requiring power saving.
Accordingly, Tx OFF IE, what you called, may
include the Basic CID of the MSS in addition to
multicast transport CID. That implies that the MSS on normal operation
shall read always this Tx OFF IE following DL-MAP even if the MSS does
not receive MBS now. This is what capability you want to extend.
Now, my question for clarification
is,
Case 1)
Do you propose that the
capabilty, Tx OFF IE can be applied to the all transport CID in
addition to Multicast transport CID being assigned to the
MSS with Basic CID? That is, the Tx OFF IE can tell when the
transmission on all transport CID assigned to the MSS
is off. If your proposal is aiming at
this, why doesn't the BS send MOB-SLP-RSP to the
MSS unsolicitly?
And, how can the BS let the MSS know
that it should read Tx OFF IE following
DL-MAP?
Case 2)
Do you propose that the BS can tell
each MSS(e.g., each Basic CID) not to monitor MBS frames
specified in Tx OFF IE?
If I understood correctly, your
proposal for this is redundant because the multicast CID binding with
the MBS
is already in Tx OFF IE.
Another recommendation is to allow CID in the
IE to be a Basic CID of the MSS. Then the IE will
provide yet another way to
allocate to the MSS
a vacation
time [similarly to Sleep Mode].
[YONG4] Is there any gain to use this
method instead of MOB-SLP-RSP sent from the
BS?
[YONG3] I
agreed with Phil's comment on this. In idle mode, Basci CID is not
assigned to the MSS.
[VY3] See above
clarification
> ##################
>
>
> > >
> > > >Other concepts are more less
covered by existing
> > > constructions. For
example
> > > >virtual connection / "MBS Zone"
functions are covered by
> Service Flow
> > >
>concept
> ##################
> [YONG]
> For the
virtual connection concept, I can be willing to harmonize your
>
concept because most of companies
> agreed with the concept that
MBS connection infomation shall
> be the same
> over
multiple BSs.
>
> MBS Zone is applicable to tell the Macro
Diversity Zone and regional
> specific
deployment
[VY] So you do agree to
replace "virtual connection" with Service
Flow?
I would appreciate
that
[YONG2]
We need
explicit text to show how Service Flow works
like virtual connection that I proposed.
[VY2} OK, I am sending to
Yong a small doc with such wording [cannot send it to the
reflector].
Feel free to
use it.
By the way, Service
Flow does not replace the MBS Zone because
MBS Zone is
designed for the MSS to know whether or not
the MBS connection
information previously stored is maintained when it moves into another
BS.
> ##################
>
>
> > >
> > > >Vladimir
> > >
>
> > > >> -----Original
Message-----
> > > >> From: Beomjoon (BJ) Kim
[mailto:beom@LGE.COM]
>
> > >> Sent: Thursday, August 12, 2004 11:31
AM
> > > >> To:
STDS-802-16-MOBILE@listserv.ieee.org
> > > >>
Subject: Re: [STDS-802-16-MOBILE] [Harmonization] MBS
> >
> Harmonization
> > > >>
> > >
>>
> > > >> Dear Yigal
> > >
>>
> > > >> You mean that every BS will
be able to support Macro
> > > >> Diversity in
PHY level.
> > > >> Am I right? If so, we
agree with you in that the negotiation
> > >
>> procedures are not necessary.
> > >
>>
> > > >> Also, if you have another
comment or answer, please give me a
> > > >>
feedback.
> > > >>
> > > >>
Thank you
> > > >>
> > > >>
Regards,
> > > >>
> > > >>
BJ
> > > >>
> > > >> -----
Original Message -----
> > > >> From:
<owner-stds-802-16-mobile@LISTSERV.IEEE.ORG>
> > >
>> To:
<STDS-802-16-MOBILE@LISTSERV.IEEE.ORG>
> > >
>> Sent: Thursday, August 12, 2004 10:40 AM
> >
> >> Subject: Re: [STDS-802-16-MOBILE] [Harmonization]
MBS
> > > Harmonization
> > > >>
>
> > >>
> > > >> > Dear
BJ,
> > > >> >
> > >
>> > I am not aware that there currently exists a
possibility
> > > >> that a BS will
not
> > > >> > support the MBS zone in the
PHY level, and I'm not sure we
> > > >> want
to promote
> > > >> > BS that do not
support this very important capability, so I
> > >
>> don't think a
> > > >> >
negotiation is required.
> > > >> >
>
> > >> > BR,
> > > >>
> Yigal
> > > >> >
> > >
>> > -----Original Message-----
> > >
>> > From:
owner-stds-802-16-mobile@listserv.ieee.org
> > >
>> > [mailto:owner-stds-802-16-mobile@listserv.ieee.org]On
> > > >> Behalf Of
Beomjoon
> > > >> > (BJ) Kim
> >
> >> > Sent: Wednesday, August 11, 2004 2:03
PM
> > > > > > To:
STDS-802-16-MOBILE@listserv.ieee.org
> > > >>
> Subject: Re: [STDS-802-16-MOBILE] [Harmonization] MBS
>
> > Harmonization
> > > >> >
>
> > >> >
> > > >> >
Dear Yong Chang and all involved in MBS
> > >
>> >
> > > >> > I'm BJ from
LG Electronics.
> > > >> > We want to
clarify a few things and our position regarding
> > >
>> the issue in the
> > > >> >
uploaded contribution by Yong Chang.
> > > >>
>
> > > >> > 1) Basically, we agree to
that Pre-Advermisement may not be
> > > >>
necessary under
> > > >> > the assumption
of Macro Diversity.
> > > >> > Therefore,
NBR-ADV message may not include MBS Zone ID of
> > >
>> neighbor BSs (if
> > > >> >
there is no need for an MSS to perform HO under the
>
assumption).
> > > >> >
> > >
>> > 2) However, when an MSS attempts to enter network
at a BS,
> > > >> it is necessary
> >
> >> > for the MSS to negotiate MBS capability with
the BS whether
> > > >> or not the BS
>
> > >> > can support MBS based on Macro
Diversity. It is because all
> > > >> BSs may
not
> > > >> > support MBS with Macro
Diversity. So, we have proposed that
> > > >>
Mode Support
> > > >> > Indication (MBS
support) should be included in
> > > REG-REQ/RSP in
our
> > > >> > contribution
(H80216e-04/01).
> > > >> >
> >
> >> > 3) Also, we have proposed a Backbone message
to manage the
> > > >> BSs included in
>
> > >> > MBS zone.
> > >
>> > We want to hear your opinion about the backbone
message.
> > > >> > (Alvarion people seem
to think it may be out of scope.)
> > > >>
>
> > > >> > Additionally, we have a
question.
> > > >> >
> > >
>> > Under the environment where Macro Diversity is
supported,
> > > >> we understand that
>
> > >> > there is no need for an MSS receiving
only MBS traffic to
> > > >> perform
Handover
> > > >> > procedures.
>
> > >> > However, there may be a case where an
MSS starting to
> > > >> receive MBS
traffic
> > > >> > from BS 1 moves to BS
2.
> > > >> > In this case, BS 2 does not
know the MSS is in its coverage
> > > >>
because the MSS
> > > >> > did not perform
HO procedures.
> > > >> >
> > >
>> > In this situation,
> > >
>> > Q1: If there is DL traffic addressed to the MSS,
how can
> > > >> either BS1 or BS2
>
> > >> > trasmits the traffic to the MSS without
any session
> > > >> information of the
MSS?
> > > >> > If the MSS is in Idle Mode
when the DL traffic arrives (at
> > > >> this
time the DL
> > > >> > traffic will arrive
at BS1), the DL traffic may be
> > > >>
delivered to the MSS
> > > >> > using the
existing procedures of Idle Mode.
> > > >>
> However, if the MSS is in Normal Mode or Sleep Mode, it
is
> > > >> impossible to
> > >
>> > deliver the traffic to the MSS.
> > >
>> >
> > > >> > Q2: If the
MSS has UL traffic to transmit, should the MSS
> > >
>> perform Initial
> > > >> >
Network Entry at BS2?
> > > >> >
>
> > >> > Thank you
> > >
>> >
> > > >> >
Regards,
> > > >> >
> > >
>> > BJ
> > > >> >
>
> > >> > ----- Original Message -----
>
> > >> > From:
<owner-stds-802-16-mobile@listserv.ieee.org>
> > >
>> > To:
<STDS-802-16-MOBILE@listserv.ieee.org>
> > >
>> > Sent: Wednesday, August 11, 2004 4:44 PM
>
> > >> > Subject: [STDS-802-16-MOBILE]
[Harmonization] MBS
> Harmonization
> > >
>> >
> > > >> >
> >
> >> > > All,
> > > >>
> >
> > > >> > > I have uploaded
the initial draft for MBS Harmonization
> > >
>> on the upload
> > > >> >
> server.
> > > >> > > I showed in
this draft how many comments on MBS
> were given.
> >
> >> > >
> > > >> >
> For conference call of MBS only, what I heard from
> >
> the chair of
> > > >> > >
Harmonization is that
> > > >> >
>
> > > >> > > Time: August
5(Thursday), 3:30 PM (PST)
> > > >> > >
Bridge Information: Chair will give information ASAP.
> >
> >> > >
> > > >> >
> If anyone have a contribution with MBS, then please
> >
> >> upload it on the
> > > >>
> server
> > > >> > > before the
meeting.
> > > >> > >
> > >
>> > > Thank,
> > > >> >
>
> > > >> > > Yong
Chang/Ph.D
> > > >> > > Samsung
Electronics, LTD
> > > >> > >
>
> > >> > >
> > > >>
> >
> > > >> >
> > >
>> >
> > > >> >
> >
> >>
> > > >>
> > >
>> This mail passed through mail.alvarion.com
> >
> >>
> > > >>
**************************************************************
>
> > >**********************
> > > >>
This footnote confirms that this email message has
> been
scanned by
> > > >> PineApp Mail-SeCure for
the presence of malicious code,
> > > >>
vandals & computer viruses.
> > > >>
**************************************************************
>
> > >**********************
> > >
>>
> > > >This mail was sent via
mail.alvarion.com
> > > >
> > >
>*************************************************************
>
> ***********************
> > > >This footnote
confirms that this email message has been
> scanned by
>
> > >PineApp Mail-SeCure for the presence of malicious code,
vandals &
> > > >computer viruses.
> >
>
>*************************************************************
>
> ***********************
> > >
> >
>
> > >
> > > This mail passed through
mail.alvarion.com
> > >
> > >
**************************************************************
>
> **********************
> > > This footnote confirms
that this email message has been scanned by
> > > PineApp
Mail-SeCure for the presence of malicious code,
> > >
vandals & computer viruses.
> > >
**************************************************************
>
> **********************
> > >
> > This mail
was sent via mail.alvarion.com
> >
> >
>
**************************************************************
>
**************
> ********
> > This footnote confirms
that this email message has been scanned by
> > PineApp
Mail-SeCure for the presence of malicious code,
> vandals &
computer
> viruses.
> >
>
**************************************************************
>
**************
> ********
>
>
>
>
>
> This mail passed
through mail.alvarion.com
>
>
**************************************************************
>
**********************
> This footnote confirms that this email
message has been scanned by
> PineApp Mail-SeCure for the
presence of malicious code,
> vandals & computer
viruses.
>
**************************************************************
>
**********************
>
This mail was
sent via
mail.alvarion.com
************************************************************************************
This
footnote confirms that this email message has been scanned
by
PineApp Mail-SeCure for the presence of malicious code, vandals
& computer
viruses.
************************************************************************************
This
mail passed through
mail.alvarion.com
************************************************************************************
This
footnote confirms that this email message has been scanned by
PineApp
Mail-SeCure for the presence of malicious code, vandals & computer
viruses.
************************************************************************************
This
mail was sent via
mail.alvarion.com
************************************************************************************
This
footnote confirms that this email message has been scanned by
PineApp
Mail-SeCure for the presence of malicious code, vandals & computer
viruses.
************************************************************************************
This
mail passed through
mail.alvarion.com
************************************************************************************
This
footnote confirms that this email message has been scanned by
PineApp
Mail-SeCure for the presence of malicious code, vandals & computer
viruses.
************************************************************************************
This
mail was sent via
mail.alvarion.com
************************************************************************************
This
footnote confirms that this email message has been scanned by
PineApp
Mail-SeCure for the presence of malicious code, vandals & computer
viruses.
************************************************************************************
|