Destructive Break Signal Process in MoIP

advertisement
Telecommunications Industry Association
TR30.1/02-09-119
(TIA)
McLean, VA, September 9th – 12th, 2002
COMMITTEE CONTRIBUTION
Technical Committee TR-30 Meetings
SOURCE:
Conexant Systems
CONTACT:
Frank Chen
Phone:
+1 (949) 579-3296
Fax:
+1 (949) 579-3667
Email: frank.chen@mindspeed.com
TITLE:
Destructive Break Signals Process in MoIP
PROJECT:
PN-0012
DISTRIBUTION:
Members of TR-30.1
____________________
ABSTRACT
This contribution discusses destructive break signals treatment in V.MoIP.
COPYRIGHT STATEMENT:
The contributor grants a free, irrevocable license to the Telecommunications Industry Association (TIA) to incorporate text or
other copyrightable material contained in this contribution and any modifications thereof in the creation of a TIA Publication; to
copyright and sell in TIA's name any TIA Publication even though it may include all or portions of this contribution; and at
TIA's sole discretion to permit others to reproduce in whole or in part such contributions or the resulting TIA Publication. This
contributor will also be willing to grant licenses under such copyrights to third parties on reasonable, non-discriminatory terms
and conditions for purpose of practicing a TIA Publication incorporates this contribution.
This document has been prepared by the Source Company(s) to assist the TIA Engineering Committee. It is proposed to the
Committee as a basis for discussion and is not to be construed as a binding proposal on the Source Company(s). The Source
Company(s) specifically reserves the right to amend or modify the material contained herein and nothing herein shall be
construed as conferring or offering licenses or rights with respect to any intellectual property of the Source Company(s) other
than provided in the copyright statement above.
-2-
1.
Introduction
This contribution discusses two ways to treat destructive break signal in MoIP. It addresses how
to handle incoming break signal as well as the break acknowledgement signal from PSTN link.
Both methods clarify the issue associated with document “TR30.1-10208094”. This
contribution provides simple and reliable solutions without increasing the data channel
bandwidth.
2.
Limited Expediting of Destructive Break Signal over IP Link
With limited expediting, a gateway will discard any data not yet transmitted, complete the
transmission of outstanding data packets and expect to receive acknowledgements of them. This
method is simple and has a smooth transition. However, it may introduce a small latency.
Two messages will be required to carry the destructive break and its acknowledgement signal
across IP link. A definition of these proposed messages are defined below.
The message BRKMSG is used to relay an incoming destructive break signal over the IP link.
BRKMSG is sent once there are no further outstanding data packets to be transmitted or retransmitted over the IP link. This implies that all of data packets transmitted over the IP link
have been acknowledged. The message is to be sent over a reliable expedited IP channel.
The message BRKACKMSG is used to relay an incoming break acknowledgement signal over
IP link. The BRKACKMSG is sent using the same transport channel as the data transmit
channel. This allows the data before BRKACKMSG to be discarded and data after
BRKACKMSG can be sent to modem.
By extending the break operation defined in V.42, destructive break signalling can be properly
handled in MoIP. The following table is an extension of Table 4/V.42 and Table 5/V.42.
DESTRUCTIVE BREAK SIGNAL PROCESS IN MOIP
10209-119
-3-
Table 1 Limited Expediting - Gateway Action on Destructive Break Signal and Acknowledgement
Break handling
option
Destructive break
signal from
PSTN(3)
With respect of data and break messages
Going to remote
gateway
Going to local
modem
Coming from
remote gateway
Coming from
local modem
- Complete data
transmission in
progress (1), then
transmit
BRKMSG
- Discard data
not yet
delivered
- Discard data
until receive
BRKACKMSG
- Hold and flow
off data until
receive
BRKACKMSG
- Complete
data
transmission in
progress (2),
then transmit
break
- There is no
incoming data
before
BRKACKMSG is
sent
- Discard data
until receive
break
acknowledgement
signal
- Reset transcompression
engine and
resume data
transmission
- Reset transcompression
engine and
resume data
reception
- Reset transcompression
engine and
resume data
reception
- Reset transcompression
engine and
resume data
transmission
- Reset transcompression
engine and
resume data
reception
- Reset transcompression
engine and
resume data
reception
- Discard data
not yet
transmitted
Destructive break
message from IP
- Complete data
transmission in
progress (1),
- Discard data
not yet
transmitted
- Discard data
not yet
transmitted
Destructive break
acknowledgement
signal from
PSTN
- Reset transcompression
engine
BRKACKMSG
from IP link
- Reset transcompression
engine and
resume data
transmission
- Send
BRKACKMSG
followed by data
(1) After complete data transmission, there is no outstanding data packet over IP link. All
transmit data packets are acknowledged.
(2) This means the completion of current data transmit frame.
(3) Break acknowledgement signal may be sent upon receiving break signal from PSTN or
upon receiving BRKACKMSG from IP link.
DESTRUCTIVE BREAK SIGNAL PROCESS IN MOIP
10209-119
-4-
M1
G1
G2
M2
brk
(brkack)
BRKMSG
data
data
brk
data
data
k
brkac
ta
da
MSG
BRKACK
data
data
(brkack)
data
data
Figure 1 Destructive Break over IP
brk
BRKMSG
brkack
brk
data
RNR
data
C
D
D
data
data
brkack
reset
compression
engine
data
D
C
data
Figure 2 Destructive Break over STCX MoIP
DESTRUCTIVE BREAK SIGNAL PROCESS IN MOIP
10209-119
data
data
BRKACKMSG
C
C
data
reset
compression
engine
RR
data
D
-5-
3.
Full Expediting of Destructive Break Signal over IP Link
With full expediting, a gateway will complete the transmission of the current data packet, flush
any outstanding data packets and discard any data not yet transmitted. Re-initiation of data
channel over IP Link is required to synchronize the two gateways’ transport protocol. The
advantage of this method is that it has no latency end to end. It does require an additional
information exchange between the two gateways.
BRKMSG is sent over a reliable expedited transport channel. Message BRKACKMSG may
either be sent using the same transport channel as used by the data transmit channel, or be sent
over a reliable expedited transport channel. Note the data transmission on the reverse direction
after channel re-initiation also implies the reception of break acknowledgement signal.
The following table show how a break signal is handled with this method.
Table 2 Full Expediting - Gateway Action on Destructive Break Signal and Acknowledgement
Break handling
option
Destructive break
signal from
PSTN
With respect of data and break messages
Going to remote
gateway
Going to local
modem
Coming from
remote gateway
Coming from
local modem
- Complete
current data
packet
transmission,
then transmit
BRKMSG
- Discard data
not yet
delivered
- Discard data
until receive
BRKACKMSG
- Hold and flow
off data until
receive
BRKACKMSG
- Complete
current data
frame
transmission,
then transmit
break
- Discard data
packets
- Discard data
until receive
break
acknowledgement
signal
- Flush
outstanding data
packets
- Discard data
not yet
transmitted
Destructive Break - Complete
message from IP current data
packet
transmission,
- Flush
outstanding data
packets
- Discard data
not yet
- Discard data
not yet
transmitted
DESTRUCTIVE BREAK SIGNAL PROCESS IN MOIP
10209-119
-6-
transmitted
Destructive break
acknowledgement
signal from
PSTN
- Reset transcompression
engine
- Reinitialise
data transmit
channel with
new base
sequence
number
- Reset transcompression
engine and
resume data
transmission
- Reset transcompression
engine
- Reinitialise data
reception channel
with new base
sequence number
- Reset transcompression
engine and
resume data
reception
- Resume data
Reception
- Send
BRKACKMSG
followed by data
transmission
Destructive break
acknowledgement
message from IP
link
- Reset transcompression
engine
- Reinitialise
data transmit
channel with
new base
sequence
number
- Reset transcompression
engine and
resume data
transmission
- Reset transcompression
engine
- Reinitialise data
reception channel
with new base
sequence number
- Reset
compression
engine and
resume data
reception
- Resume data
Reception
- Resume data
transmission
Note: Break acknowledgement signal may be sent upon receiving break signal from PSTN or
upon receiving BRKACKMSG from IP link.
4.
BRKMSG and BRKACKMSG
The following information is identified as necessary for BRKMSG:
1. Break type – this comes from PSTN link.
2. Break length (optional) – this comes from PSTN link.
3. Break sequence number (BRK_SEQ_NUM) – this is the counter in case multiple
breaks are issued from PSTN link.
4. New base sequence number of data packet on data transmit channel
(BRK_TX_BASE) – this apply only on full expediting method. It will be used by
the remote gateway to initialise transport data transmit channel.
DESTRUCTIVE BREAK SIGNAL PROCESS IN MOIP
10209-119
-7-
5. New base sequence number of data packet on data receiving channel
(BRK_RX_BASE) – this apply only on full expediting method. It will be used by
the remote gateway to initialise transport data receive channel.
The following information is identified as necessary for BRKACKMSG:
Break acknowledgement sequence number – this is the counter to indicate the break
acknowledgement signal
5.
Multiple Break Signals from Both Client Modems
If multiple distinguished break signals are sent from either one or both client modems, the break
signals and break acknowledgement signals shall be relayed over IP network. For a gateway
that receives a break signal from PSTN, it may resume data transmission and reception only
after same number of break signals from PSTN and break acknowledgement messages from IP
network are received. For a gateway that receives a break message from the IP, it may resume
data transmission and reception only after the same number of break messages from IP network
and break acknowledgement signals from PSTN have been received.
6.
Summary
This contribution describes two methods for supporting the transmission of destructive breaks
and its acknowledgement. The first method Limited Expediting is simpler to implement but
adds a small amount of latency, whereas the second method Full Expediting, removes the delay
at the cost of a small amount of complexity. Both methods support multiple and bi-direction
break sourcing and sinking. The advantage of the mechanisms is that no overhead in terms of
bandwidth and processing is required. The SSID field defined in SPRT header is removed.
The proposed two methods are implemented. A variety of client modems from major brands is
tested. The results show both methods are simple and reliable.
It is proposed that the committee agrees to the following:
A
Agreed
Destructive break process procedure defined in this
document shall be included in V.MoIP standard.
DESTRUCTIVE BREAK SIGNAL PROCESS IN MOIP
10209-119
-8-
__________________
DESTRUCTIVE BREAK SIGNAL PROCESS IN MOIP
10209-119
Download