Subject: [Sigtran] A question about TEI management for BRI over V5UA

From: Zhao Bo <[email-masked]>
Date: Wed, 24 Mar 2004 09:54:40 +0800

Dear authors:
    According to V5UA draft, Section 1.4, "Dynamic TEI Management for BRI over V5 shall be located on the MGC". 
    Could you tell me the reason for this? This function can also be implemented in SG, as in IUA. Why shall we use a different from IUA?
    Best regards

Zhao Bo

*****************************************************************
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
*****************************************************************

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

---

From: "Berthold Jaekle" <[email-masked]>
Date: Thu, 25 Mar 2004 16:30:17 -0000

Hi Zhao,

When TEI Management procedure is located on MGC, I think that parts of ISDN
BRI Layer 2 can be located on the MG. An example is the Data Link Monitor
Function (exchange of RR, RNR commands).
Reason: The RR commands/responses will busy the MGC.

With assumption that TEI Management procedure is located on MGC (MG has no
knowledge about TEI state), the following message flows may work: 

Layer 2 activation by MGC:
--------------------------

TE1               MG                          MGC
  <---SABME-------  <-Establish Request ------- 
  ------UA ------>  --Establish Confirm ------>
  <-----RR -------
  ------RR ------>

Layer 2 activation by ISDN Terminal (TE1):
------------------------------------------

TE1               MG                          MGC
  ----SABME------>  --Establish Indication ---> 
  <-----UA -------

Exception:
If the TEI is not assigned on MGC, the MGC shall release Layer 2 and invoke
TEI Removal Procedure for the non-assigned TEI(Q.921 5.3.4) 

TE1               MG                          MGC
  <---DISC-------  <-Release Request ----------  /* release Layer 2 */
  ------UA ----->  --Release Confirm --------->

The V5UA UNIT-DATA-Request message contains Protocol Data parameter contains
'Identity remove message' (Q.921 5.3.6.1)

TE1               MG                          MGC
  <-----UI-------  <-UNIT-DATA-Request---------  /* Remove TEI */
                      Protocol Data

Layer 2 break:
--------------
When switching to MG-2, ISDN Layer 2 goes down. 
The Terminal re-establishes Layer 2 over MG-2, if Data Link Monitor Function
is implemented on user side, or when a Layer 3 message is transmitted.
The MGC shall re-establishes Layer 2 over MG-2 for all active calls, when
switch-over to the protection ISDN Communication channel has occurred. 

Note: Messaging flow above are based on own deliberations and not on
existing implementation.

Regards,
Berthold
Berthold Jaekle
CS2K Development / Specification
NNR05 - Nortel Networks Germany
e-mail: [email-masked]
phone : +49-7545-968020 (ESN 565-8020)
fax: +49-7545-968160 (ESN 565-8160)

-----Ursprüngliche Nachricht-----
Von: Zhao Bo [mailto:[email-masked]] 
Gesendet: Donnerstag, 25. März 2004 06:45
An: [email-masked]
Cc: [email-masked]; Khanchandani, Neeraj [NC1:JF15:EXCH]; Rao, Sanjay
[NC1:JC30:EXCH]; Weilandt, Eva [FRIED:NR5:EXCH]; Jaekle, Berthold
[FRIED:NR5:EXCH]
Betreff: Re: [Sigtran] A question about TEI management for BRI over V5UA

Hi Eva:
    Thanks for the reply. It's a very good idea for C channel protection.
    But I have another question: Shall the ISDN BRI layer 2 entity be also
located in MGC?  If a V5 ISDN subscriber sends a SABME message via it's D
channel, this message will be aggregated to a V5 C channel and sent to MG.
Shall MG answer this message with UA, or let MGC to do this? MG will not
know the TEI assignment state(because TEI is assigned by MGC). Besides, if
the layer 2 entity is located in MG, when we switch MG, the layer 2 link
will be cut, too.
    Best regards.    

----- Original Message ----- 
From: [email-masked] 
To: [email-masked] 
Cc: [email-masked] ; [email-masked] ;
[email-masked] ; [email-masked] ;
[email-masked] 
Sent: Wednesday, March 24, 2004 10:16 PM
Subject: Re: [Sigtran] A question about TEI management for BRI over V5UA

Hi Zhao,

that's the difference between ISDN (for IUA) and V5 (for V5UA): ISDN does
not have this redundancy mechanism as V5 has. Either the d-channel is up, or
it is down (for ISDN).

For V5, we can take advantage of the protection mechanism to protect the
(ISDN)-c-channel (what is equivalent to the d-channel) by splitting the V5
interface with more than one link over two (or more) GWs. And this does only
work if the TEI management is located where the V5 system management is: at
the MGC.

Otherwise, at c-channel switch-over from one GW to the other, the new GW
would not know about the TEIs negotiated by the other GW, and had to take
down all the calls to make sure.

Hope this is clear enough.

Eva Weilandt

--- original Nachricht Ende ----

Dear authors:
According to V5UA draft, Section 1.4, "Dynamic TEI Management for BRI over
V5 shall be located on the MGC". 
Could you tell me the reason for this? This function can also be implemented
in SG, as in IUA. Why shall we use a different from IUA? Best regards

Zhao Bo

*****************************************************************
This e-mail and its attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure, reproduction,
or dissemination) by persons other than the intended recipient(s) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
*****************************************************************

--