PCT
`
`WORLD INTELLECTUAL PROPERTY ORGANIZATION
`International Bureau
`
`INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT)
`
`(51) International Patent Classification 7 :
`H04M 11/00
`
`A2
`
`(11) Internationa!Publication Number;
`
`WO 00/45581
`
`(43) International Publication Date;
`
`3 August 2000 (03.08.00)
`
`(21) International Application Number:
`
`PCT/US00/02266
`
`(81) Designated States: JP, European patent (AT. BE, CH, CY, DE,
`DK, ES, FI, FR, GB, GR, IE, IT, LU, MC, NL, PT, SE).
`
`(22) International J<'iling Date:
`
`28 January 2000 (28.01.00)
`
`Published
`Without international search report and to be republished
`upon receipt of that report.
`
`(30) Priority Data:
`60/117,916
`09/318,785
`
`29 January 1999 (29.01.99)
`25 May 1999 (25.05.99)
`
`us
`us
`
`(71) Applicant: DATA RACE, INC. [US/US]; 12400 Network
`Boulevard, San Antonio, TX 78249 (US).
`
`(72) Inventor: OLIVER, David, C.; 8721 Mountain Top, San
`Antonio, TX 78255-3528 (US).
`
`(74) Agent: CONLEY, ROSE & TAYON, P.C.; P.O. Box 398.
`Austin. TX 78767-0398 (US).
`
`(54) Title: MODEM TRANSFER MECHANISM WHICH PRIORITIZES REAL-TIME DATA TRANSFER OVER REGULAR DATA
`TRANSFERS
`
`(57) Abstract
`
`A modem transfer mechanism which provides
`for multiplexed transfer of real-time data and regular
`data across a communication medium (e.g. a dialup
`modem link) where real-time data is prioritized over
`regular data. Real-time latency is minimized. When
`the modem receives and parses a data stream compris(cid:173)
`ing real-time data and regular data from a computer (or
`other DTE), data confonning to a real-time protocol
`is stored in a real-time buffer and transmitted expe(cid:173)
`ditiously using a special protocol which is described
`herein. Optionally, real-time data is compressed be(cid:173)
`fore transmission onto a communication medium (e.g.
`an analog phone line). Data not conforming to a
`real-time protocol may be buffered for transmission in
`due course. The modern is also configured to receive a
`data stream including multiplexed real-time data and
`regular data from the communication medium. The
`modem demultiplexes the real-time data and the reg(cid:173)
`ular data. The real-time data is stored into a second
`real-time buffer and the regular data is stored into a
`second regular buffer. Voice frames are delivered to
`the computer (or other DTE) with priority over regular
`data frames. Using a pair of such modems to establish
`a modem link across a switching network (e.g.
`the
`PSTN) allows real-time data to be transmitted with
`a minimum of real-time delay while simultaneously
`transmitting regular data.
`
`Internet
`Protocol Stack
`137
`
`PPP Stream
`I 136
`
`-------· DTE Interface 138 ··-·-· -·-·-------·-········---·---·---
`
`140
`
`142
`
`11111 I 1--~
`
`I I
`
`MODEM ill
`
`To
`Switching Network
`SC#1
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1013
`Page 1 of 38
`
`

`

`FOR THE PURPOSES OF INFORMATION ONLY
`
`Codes used to identify States party to the PCT on the front pages of pamphlets publishing international applications under the PCT.
`
`AL
`AM
`AT
`AU
`AZ
`BA
`RR
`RE
`BF
`BG
`BJ
`BR
`BY
`CA
`CF
`CG
`CH
`CI
`CM
`CN
`cu
`CZ
`DE
`DK
`EE
`
`Albania
`Armenia
`Austria
`Australia
`Azerbaijan
`Bosnia and Herzegovina
`Barbados
`Belgium
`Burkina Faso
`Bulgaria
`Benin
`Brazil
`Belarus
`Canada
`Central African Republic
`Congo
`Switzerland
`COte d'Ivoire
`Cameroon
`China
`Cuba
`Czech Republic
`Germany
`Denmark
`Bstonia
`
`ES
`FI
`FR
`GA
`GB
`GE
`Gil
`GN
`GR
`HU
`IE
`IL
`IS
`IT
`JP
`KE
`KG
`KP
`
`KR
`KZ
`LC
`LI
`LK
`LR
`
`Spain
`Finland
`France
`Gabon
`United Kingdom
`Georgia
`Ghana
`Guinea
`Greece
`Hungary
`Ireland
`Israel
`Iceland
`Italy
`Japan
`Kenya
`Kyrgyzstan
`Democratic People's
`Republic of Korea
`Republic of Korea
`Kazakstan
`Saint Lucia
`Liechtenstein
`Sri Lanka
`Liberia
`
`LS
`LT
`LU
`LV
`MC
`MD
`MG
`MK
`
`ML
`MN
`MR
`MW
`MX
`NE
`NL
`NO
`NZ
`PL
`PT
`RO
`RU
`SD
`SE
`SG
`
`Lesotho
`Lithuania
`Luxembourg
`Latvia
`Monaco
`Republic of Moldova
`Madagascar
`The former Yugoslav
`Republic of Macedonia
`Mali
`Mongolia
`Mauritania
`Malawi
`Mexico
`Niger
`Netherlands
`Norway
`New Zealand
`Poland
`Portugal
`Romania
`Russian Federation
`Sudan
`Sweden
`Singapore
`
`SI
`SK
`SN
`sz
`TD
`TG
`TJ
`TM
`TR
`TT
`UA
`UG
`us
`uz
`VN
`YU
`zw
`
`Slovenia
`Slovakia
`Senegal
`Swaziland
`Chad
`Togo
`Tajikistan
`Turkmenistan
`Turkey
`Trinidad and Tobago
`Ukraine
`Uganda
`United States of America
`Uzbekistan
`Viet Nam
`Yugoslavia
`Zimbabwe
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1013
`Page 2 of 38
`
`

`

`WO 00/45581
`
`PCT /US00/02266
`
`Title:
`
`Modem Transfer Mechanism which Prioritizes Real-Time Data Transfer over Regular Data Transfers
`
`Field of the Invention
`
`The present invention relates to the transmission of real-time data (such as voice data) and non-real-time
`
`5
`
`data. and more particularly to a system and method for minimizing the delay of a real-time data transfer while
`
`simultaneously performing a non-real-time data transfer over a communication link (such as a dialup modem
`
`link).
`
`Description of the Related Art
`
`10
`
`In the prior art, a modem link, such as that depicted in Fig. 1, may have been used to transfer real-time
`
`data or non-real-time data between two digital devices. Any device capable of sourcing and/or sinking digital
`
`data will be referred to herein as a data terminal equipment (DTE). In the modem link of Fig.I, a first DTE, i.e.
`
`DTE#l, provides a data stream to modem #1. Modem #1 transmits the data stream to modem #2 across a
`
`switching network, such as the Public Switched Telephone Network (PSTN) or the Integrated Services Digital
`
`15
`
`Network (ISDN). Modem #2 receives the data stream from the switching network and forwards the data stream to
`
`a second DTE, i.e. DTE#2. Similarly, DTE#2 may provide a second data stream to modem #2 for transmission to
`
`modem #1 across the switching network. Modem #1 forwards the second data stream to DTE#l. Modem #1
`
`couples to the switching network through a first subscriber connection SC#l, and modem #2 coupled to the
`
`switching network through a second subscriber connection SC#2. For example, subscriber connection SC#l may
`
`20
`
`be an analog telephone line, i.e. a Plain Old Telephone Service (POTS) line, and subscriber line SC#2 may be an
`
`ISDN line.
`
`DTE#! and DTE#2 may be computers, in which case Figs. 2A&2B illustrate a typical arrangement for
`
`the software organization of the first computer DTE#!. Fig.2A depicts the transmission of data originating from
`
`software applications running on the first computer DTE#l. Fig. 2B depicts the reception of data by the same
`
`25
`
`software applications. The software applications transfer data to/from an Internet Protocol Stack which may be
`
`part of an operating system. The Internet Protocols Stack comprises a multi-layered system of software protocol
`
`modules. The Internet Protocol Stack communicates with modem #1 through a DTE interface. The DTE inter(cid:173)
`
`face typically has a much higher bandwidth than the bandwidth attainable through the switching network.
`
`As shown in Fig. 2A, software applications running on the first computer DTE#l submit data to "sock-
`
`30
`
`ets" S 1-S3. Each socket passes the application data to a corresponding transport protocol module. The transport
`
`protocol modules implement transport protocols such as Transmission Control Protocol (TCP) or User Datagram
`
`Protocol (UDP). TCP is a reliable protocol, and thus, is well suited for applications such as file transfer or email
`
`which require reliable transfer. UDP makes no provision for reliability, and thus, it executes with lower latency
`
`(delivers the data more quickly) than TCP. Therefore, UDP is typically the choice for real-time applications.
`
`35
`
`The first computer DTE#l includes a central processing unit and memory for executing software appli-
`
`cations. For example, a real-time application may generate a stream of Real Time Protocol (RTP) packets of
`
`which a representative packet RTPl is shown. The real-time application is shown supplying the packet RTPl to
`
`socket Sl. Internet Telephony, slow scan TV and telemetry are examples ofreal-time applications.
`
`In addition to the real-time application, the first computer DTE#l may execute other UDP applications or
`
`40
`
`TCP applications: one of each is shown in Fig. 2A. The UDP application is shown providing a data packet Dl to
`
`socket S2. The TCP application provides a bit stream D2 to the socket S3.
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1013
`Page 3 of 38
`
`

`

`WO 00/45581
`
`PCT /US00/02266
`
`A first UDP module receives packet RTPl from socket Sl and encapsulates this packet in a UDP packet.
`
`The resulting UDP packet is denoted as UDP[RTPl]. A second UDP module receives the data packet Dl from
`
`the second socket S2 and encapsulates the data packet D 1 in a UDP packet. The resulting UDP packet is denoted
`
`as UDP[Dl]. A TCP module encapsulates the bit stream D2 (or a portion thereof) in a TCP segment denoted
`
`~
`
`TCP[D2]. The UDP and TCP packets are multiplexed and presented to an Internet Protocol (IP) module. The IP
`
`module encapsulates the UDP and TCP packets according to the Internet Protocol. The resulting IP packets are
`
`presented to a Point-to-Point Protocol (PPP) module. The PPP module encodes the stream of IP packets into a
`
`stream of PPP frames. Each PPP frame is separated by a tilde character. A portion of the PPP stream is shown.
`
`For example, the PPP stream includes (a) a first frame which encapsulates a packet denoted IP/TCP/D2 whose
`
`10
`
`payload D2 originated from the TCP application, (b) a second frame which encapsulates a packet IP/UDP/DI
`
`whose payload Dl originated from the UDP application, and (c) a third frame which encapsulates a packet
`
`IP/UDP/RTPl whose payload RTPl originated from the real-time application. The PPP stream is supplied to
`
`modem #1 through the DTE interface. Modem #1 transmits the PPP stream to modem #2 (not shown) through the
`
`switching network.
`
`15
`
`It is noted that the PPP module may perform header compression on the IP/UDP/RTP encapsulated
`
`packets. For example, the Compressed Real Time Protocol (CRTP) specifies a scheme for performing such
`
`header compression. In addition, the PPP module may perform TCP/IP header compression as well as TCP/IP
`
`data compression.
`
`As shown in Fig.2B, modem #1 receives from modem #2 (not shown) a second PPP stream. The second
`
`20
`
`PPP stream is supplied to a PPP module in the Internet Protocol Stack. A portion of the second PPP stream is
`
`shown at the input of the PPP module. The second PPP stream may include (a) a first frame which encapsulates a
`
`packet IP/TCP/D4 whose payload 04 is targeted for the TCP application, (b) a second frame which encapsulates a
`
`packet IP/UDP/D3 whose payload D3 is targeted for the UDP application, and (c) a third frame which encapsu(cid:173)
`
`lates a packet IP/UDP/RTP2 whose payload RTP2 is targeted for the real-time application. The PPP module re-
`
`25
`
`covers a stream of IP packets from the second PPP stream. The IP module recovers UDP and TCP packets from
`
`the IP packets. The UDP and TCP packets are demultiplexed according to their destination port numbers. Each
`
`socket is associated with a unique port number. UDP packets which encapsulate RTP, e.g. UDP[RTP2], are sent
`
`to a first UDP module which recovers the RTP packet RTP2. The RTP packet RTP2 is supplied to the real-time
`
`application through socket S4. Another UDP encapsulated data packet UDP[D2] is supplied to a second UDP
`
`30
`
`module. The second UDP module recovers the embedded data D2 and passes this data to the UDP application
`
`through socket S5. TCP encapsulated data TCP[D4] is sent to a TCP module. The TCP module recovers the em(cid:173)
`
`bedded data D4 and passes this data to the TCP application through socket S6.
`
`While it is desirable to be able to execute a real-time application and a non-real-time application simulta(cid:173)
`
`neously, the non-real-time data communicated by the non-real-time applications may compromise the perform-
`
`35
`
`ance of the real-time data transfer, especially in the situations where subscriber connection SC#l is a low(cid:173)
`
`bandwidth connection such as an analog telephone line. Fig. 3 illustrates how real-time performance may be
`
`compromised by the presence of non-real-time data transfers. Subgraph (A) depicts a PPP data stream compris(cid:173)
`
`ing real-time frames and non-real-time frames in transit across the DTE interface from the Internet Protocol Stack
`
`to modem #1. In particular, a first non-real-time data frame DI is followed by a first real-time frame Vl. The
`
`40
`
`first real-time frame VI is followed by a second non-real-time data frame D2. The second non-real-time data
`
`frame D2 is followed by a second real-time frame V2. The first non-real-time frame is transmitted across the
`
`2
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1013
`Page 4 of 38
`
`

`

`WO 00/45581
`
`PCT /US00/02266
`
`DTE interface at time to. The real-time data frames VI and V2 are transmitted at times t 1 and t2 respectively.
`Quite often, real-time applications generate real-time frames with a predetermined periodicity. For example, the
`
`G.729 speech compression standard prescribes that frames be generated periodically with a 10 millisecond period.
`
`Subgraph (B) depicts the same real-time frames and non-real-time frames as they are being transmitted
`
`onto the subscriber connection SC# I by modem # 1. It is noted that the time duration of the frames is significantly
`
`lengthened due to the low bandwidth of the subscnber connection SC#l as compared to the bandwidth of the DTE
`
`interface. A large non-real-time data frame such as DI may significantly delay succeeding real-time frames. For
`
`example, real-time frame VI is delayed from time t 1 to time 4 because non-real-time frame DI is elongated in
`transmission onto the subscriber connection SC#l. Furthermore, the real-time delay may accumulate when a sue-
`
`! 0
`
`cession of large non-real-time frames occurs in the transmitted stream. Observe that the second non-real-time
`
`packet D2 adds to the delay already developed by non-real-time data frame Dl, and thus, time delay t5-t2 is larger
`than delay t4-t1• In other words, real-time frame V2 is delayed more than real-time frame VI. Such accumulating
`delays typically compromise the quality of the reconstructed real-time signal at the real-time destination. For ex(cid:173)
`
`ample, a human auditor at the real-time destination may find the reconstructed voice signal to contain annoying
`
`15
`
`pauses. When these pauses occur with sufficient frequency and/or duration, the human auditor may not be able to
`
`make sense of the reconstructed voice signal. It is noted that DTE#2 may not necessarily be the real-time desti(cid:173)
`
`nation. For example, DTE#2 may serve as a gateway to the Internet in which case the real-time destination may
`
`be yet another computer coupled to the Internet.
`
`Furthermore, the time interval between successive real-time frames may be greatly increased due to in-
`
`20
`
`tervening non-real-time frames. For example, non-real-time frame D2 is large enough to stretch the time interval
`
`between frames VI and V2 to the significantly larger value t5-t4 during transmission onto the subscriber connec(cid:173)
`tion SC# 1. This lengthening of the time interval between successive real-time frames due to the low bandwidth
`
`subscriber connection SC#! compromises the quality of the reconstructed real-time signal at DTE#2. For exam(cid:173)
`
`ple, a real-time voice stream may manifest a broken (i.e. discontinuous) sound to the human ear when non-real-
`
`25
`
`time data is simultaneously transmitted.
`
`It is noted that buffering within modem #1 induces a time delay on the PPP stream. For example, the
`time difference t3-to may be attributed to buffering delay within modem #1. For example, the v.42 protocol typi(cid:173)
`cally involves buffering data in packets of size 128 bytes.
`
`Subgraph (C) depicts the same real-time frames and non-real-time frames as they are being received
`
`30
`
`from subscriber connection SC#2 by modem #2. It is noted that the frames of subgraph (C) are delayed in time as
`
`compared to the corresponding frames of subgraph (B) due to propagation through the switching network. Sub(cid:173)
`
`graph (D) depicts the same real-time frames and non-real-time frames as they are delivered to DTE#2 from mo(cid:173)
`
`dem #2.
`
`It is noted that modem #2 performs data buffering before transmitting data to DTE#2. This induces an
`
`35
`
`additional time-delay in the PPP stream. For example, the time difference t7-I'(; may be attributed to buffering de(cid:173)
`lay.
`
`The deleterious effects discussed above are so pronounced that non-real-time data streams must typically
`
`be disabled as, e.g., by closing the non-real-time applications in order to obtain an acceptable level of performance
`
`in the real-time data transmission. For example, an Internet Telephony correspondent who accesses an Internet
`
`40
`
`Service Provider (ISP) through the switching network with an analog phone line SC#l must typically
`
`3
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1013
`Page 5 of 38
`
`

`

`WO 00/45581
`
`PCT /US00/02266
`
`close/suspend other software applications which might transmit and/or receive data across the modem link in or(cid:173)
`
`der to obtain acceptable voice quality.
`
`Conventional modems contribute to the problem of real-time frame delay because they naively transmit
`
`data frames in the order they are presented by DTE#l. Thus, a substantial need exists for a modem which could
`
`5
`
`concurrently transfer real-time data and non-real-time data over a low-bandwidth subscriber connection such as an
`
`analog telephone line without compromising the performance of the real-ume data transmission. In particular, it
`
`would be very desirable to have a modem which could transmit voice data with minimum latency (i.e. time delay)
`
`while concurrently transferring non-real-time data.
`
`Internet Telephony is a popular example of a real-time application.
`
`Internet Telephony applications
`
`10
`
`(such as NetPhone®) use Voice over Internet Protocols (VoIP) with RTP to make telephone connections between
`
`computer users. A standardized Voice over Internet Protocol is described in ITU Recommendation H.323 (02/98)
`
`- Packet-Based Multimedia Communications Systems. RTP is elaborately described in ITU Recommendation
`
`H.225.0 (02/98) - Call Signaling Protocols and Media Stream Packetization for Packet-Based Multimedia Com(cid:173)
`
`munication Systems. Internet Telephony applications work well on direct local area network (LAN) connections,
`
`15
`
`or over a segment of the Internet which is able to ensure an acceptable Quality of Service (QoS) level. In other
`
`words, the LAN or Internet segment needs to be able to provide a minimum bandwidth and maximum latency for
`
`packet transmissions between Internet Telephony correspondents. Bandwidth reservation protocols such as the
`
`Resource Reservation Setup Protocol (RSVP) have been developed to allow applications to reserve resources
`
`along the path from data source to data destination.
`
`20
`
`However, over a low-speed dial-up (modem) connection to the Internet, which normally uses the Point-
`
`to-Point Protocol (PPP), there are a number of problems with Internet Telephony (IT) as follows.
`
`( 1) The typically small voice packets generated by the IT application are triply encapsulated:
`
`first in RTP, then UDP, then IP. This RTP/UDP/IP protocol stack adds a large overhead to
`
`the small voice packets.
`
`25
`
`(2) As alluded to above in conjunction with Fig. 3, modem buffering can delay voice packets.
`
`(3) Some modems perform data retransmission upon error. However, this facility is not suitable
`
`for the voice packet transmissions. Voice packets which are transmitted with error should
`
`be dropped (i.e. ignored). Therefore, modems which perform data retransmission upon er(cid:173)
`
`ror needlessly consume transmission bandwidth and induce added voice delay.
`
`30
`
`(4) As alluded to above, voice packets may be delayed by concurrent data transmission, as
`
`packets are sent in the order they are received.
`
`(5) Digital Simultaneous Voice & Data (DSVD) Modems address the problem of data packets
`
`delaying voice packets, but only handle special-purpose voice sources, such as a locally
`
`terminated analog voice circuitry.
`
`35
`
`If a user desires to transfer both real-time data and non-real-time data simultaneously, one solution is
`
`simply to use two connections (such as analog telephone connections) to the switching network, one reserved for
`
`voice traffic and the other reserved for data traffic. However, this solution suffers because of its expense and be(cid:173)
`
`cause of its inefficiency - the user may not always be performing real-time and non-real-time transfers concur-
`
`40
`
`rently. There is also the expense ofrequiring two modems to handle the two connections.
`
`4
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1013
`Page 6 of 38
`
`

`

`WO 00/45581
`
`PCT /US00/02266
`
`Conventional modem protocols for transmitting voice and regular data together ( e.g., DSVD and the
`
`V.70 suite) provide a way to transport locally originated (e.g. from a connected telephone handset) voice packets
`
`across a modem with some level of latency control, depending upon the protocol. However, they do not provide a
`
`mechanism to accept and deliver general purpose real-time data packets, such as Voice over IP. To modify the
`
`~
`
`conventional methods would requite significant change in the software running on the host (user and server) com(cid:173)
`
`puters to direct voice packets to a high pnonty port on the modem. I',;o standardized way of directing the data
`
`exists, and such changes would require access to multiple sources of software (IP protocol stacks, Windows sock(cid:173)
`
`ets, etc.), which may be proprietary and often unavailable.
`
`It is noted that there exist a class of modems called Digital Simultaneous Voice and Data (DSVD) mo-
`
`10
`
`dems which are configured for transferring voice and non-voice data across analog telephone lines. Fig. 4 illus(cid:173)
`
`trates a DSVD modem link. A first DSVD modem. i.e. DSVD 1, couples to the PSTN through a first analog tele(cid:173)
`
`phone line Ll, to DTE#l through a DTE interface, and local telephone TEL1. A first user situated at DTE#l
`
`speaks into the handset of local telephone TEL 1. The first user's voice is digitized and compressed by circuitry in
`
`the first DSVD modem DSVDl. The first DSVD modem DSVDl receives non-voice data from DTE#l, multi-
`
`15
`
`plexes the compressed-voice data with the non-voice data, and transmits the multiplexed stream to a second
`
`DSVD modem, i.e. DSVD2, through the PSTN. The second DSVD modem DSVD2 demultiplexes the multi(cid:173)
`
`plexed stream. The recovered voice data is decompressed and then converted to analog form for presentation to
`
`the handset of local telephone TEL2. The non-real-time data recovered from the multiplexed stream is transmit(cid:173)
`
`ted to DTE#2. The same process occurs in the opposite direction, thus enabling the two subscribers to concur-
`
`20
`
`rently engage in voice and data communication over analog telephone lines L 1 and L2.
`
`The multiplexed voice/data stream includes separate voice frames and data frames. A frame typically
`
`includes markers which define the start and end of the frame. A frame may additionally contain information
`
`about the data format, etc., in a frame header. The separate frames are multiplexed so that bandwidth is statisti(cid:173)
`
`cally divided between voice frames and data frames. For example, a 28.8 Kbps DSVD modem may transmit non-
`
`25
`
`voice frames at 19.2 Kbps and voice frames at 9.6 Kbps. However, DSVD modems have several disadvantages.
`
`By inserting a substantial amount of regular data between voice frames, the latency (i.e. time delay) between
`
`voice frames is increased. This increase in voice latency may cause the reconstructed voice signal to appear
`
`"jerky" (i.e. discontinuous).
`
`The increase in voice latency may be avoided by transmitting voice frames as often as they are generated
`
`30
`
`by the voice compression circuitry, and transmitting non-voice data in the time intervals between voice frames.
`
`The size of data frames must be controlled so as to fit between successive voice frames. Segments of non-voice
`
`data which are larger than a critical size may be fragmented into two or more frames. The critical size is deter(cid:173)
`
`mined by the time interval between voice frames and the signaling rate across the analog phone line L 1. While
`
`this multiplexing scheme may control voice latency, it increases overhead in the non-voice transfer due to the
`
`35
`
`overall increase in the number of non-voice frames. Each frame includes a header. Increasing the number of
`
`voice frames to transmit a given segment of non-voice data implies a loss of available transmission bandwidth.
`
`Therefore, controlling the non-voice frame size to improve voice latency has the effect of decreasing overall data
`
`throughput. Several ad hoc DSVD implementations have been advanced by telecommunication vendors. How(cid:173)
`
`ever all of these implementations suffer from the above noted disadvantages.
`
`40
`
`Another disadvantage of DSVD is that a more complicated modem is required having at least two ports
`
`or interfaces, one for the DTE and another for the phone.
`
`5
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1013
`Page 7 of 38
`
`

`

`WO 00/45581
`
`PCT /US00/02266
`
`One technique for transferring simultaneous voice and non-real-time data is displayed in the Integrated
`
`Services Digital Network (ISDN). ISDN is an international standard which defines a digital interface between
`
`subscribers and the PSTN. The digital interface provides increased transmission rates as compared to the rates
`
`attainable over analog telephone lines. A subscriber must be equipped with a special ISDN modem which per-
`
`5
`
`forms low-level time-division multiplexing of voice and regular data. The ISDN modem allocates a fixed portion
`
`of the transmission bandwidth to the voice data. Cnforrunately this allocation scheme implies that the regular(cid:173)
`
`data bandwidth cannot expand during those time when the full voice bandwidth is not being used, and vice versa.
`
`ISDN service must be subscribed to from the phone company and may not be available in all areas. ISDN service
`
`is typically more expensive than analog telephone service.
`
`In addition, ISDN modems are typically more expen-
`
`10
`
`sive than conventional modems. Thus, users desirous of performing simultaneous real-time and non-real-time
`
`data transfers are often discouraged from considering ISDN.
`
`DSVD is addressed in the International Telecommunication Union (ITU) v.70 standard. This uses a
`
`technique for implementing simultaneous real-time and non-real-time data transmission by interrupting regular
`
`data frames in a modem connection using non-standard "abort" tokens in order to introduce real-time data. The
`
`15
`
`suspend/resume tokens of the ITU v.76 recommendation is such an approach. However, using "abort" tokens has
`
`the disadvantage of requiring special hardware to create and detect the abort tokens. Furthermore, overhead is
`
`increased by the use of the tokens and additional frame information.
`
`As described above, all the existing solutions for providing simultaneous real-time and non-real-time
`
`communication suffer from one or more of the following limitations:
`
`20
`
`(a) they require special hardware;
`
`(b) they involve increased complexity and/or expense;
`
`( c) they can only be applied to special-purpose voice sources; or
`
`( d) they negatively impact voice latency.
`
`It is therefore desirable to provide a low latency technique for communicating real-time and non-real-time data
`
`25
`
`over a conventional modem connection with minimal impact on performance.
`
`Summary of the Invention
`
`The problems described above are largely solved by a communication system and method according to
`
`the present invention which provides for multiplexed transfer of real-time data and regular ( e.g. non-real-time)
`
`30
`
`data across a communication medium (e.g. a dialup modem link). The multiplexing scheme employed by the
`
`communication system prioritizes real-time data over regular data, and thereby minimizes transmission latency for
`
`the real-time data stream.
`
`The present invention contemplates a modem which is configured for coupling to a host computer across
`
`a DTE interface. The modem is configurably aware ofreal-time protocols such as CRTP or RTP. When the mo-
`
`35
`
`dem receives a data stream comprising real-time data and regular data from a high-speed computer port, it parses
`
`the data stream for real-time data. Data which conforms to a real-time protocol is stored in a real-time buffer and
`
`transmitted expeditiously using a special protocol which is described herein. Optionally, real-time data is com(cid:173)
`
`pressed before transmission onto a communication medium (e.g. an analog phone line). For example, compres(cid:173)
`
`sion may involve throwing away framing information which may be easily reconstructed by a complementary
`
`40
`
`receiving modem. Data which does not conform to a real-time protocol may be buffered for transmission in due
`
`6
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1013
`Page 8 of 38
`
`

`

`WO 00/45581
`
`PCT /US00/02266
`
`course. If the regular data buffer fills up, the DTE port is not "flow controlled", but instead packets of data are
`
`discarded. Thus, the real-time data is unimpeded.
`
`The modem described above is also configured to receive a data stream including multiplexed real-time
`
`data and regular data from the communication medium. The modem demultiplexes the real-time data and the
`
`5
`
`regular data. The real-time data is stored into a second real-time buffer and the regular data is stored into a second
`
`regular buffer. Voice frames are delivered to the DTE with priority over regular data frames. If the DTE port is
`
`not flow-controller by the host computer, the modem may implement a data discard procedure when the second
`
`regular buffer and/or second real-time buffer are full. The modem may discard newly arriving regular data frames
`
`and retain the regular data frames already stored in the second regular buffer. In contrast, the modem may discard
`
`10
`
`old real-time frames stored in the second real-time buffer and overwrite these old real-time frames with newly
`
`arriving real-time frames.
`
`Using a pair of such modems to establish a modem link across a switching network (e.g. the PSTN) al(cid:173)
`
`lows real-time data to be transmitted with a minimum of real-time delay while simultaneously transmitting regular
`
`data. One of the modems may connected to a user computer while the other may be situated at an ISP's Point-of-
`
`15
`
`Presence. Alternatively, the pair of modems may serve as a bridge between two data networks. For example, the
`
`pair modems may bridge a corporate office network to a branch office LAN.
`
`The present invention also contemplates a software modem client which executes on the host processor.
`
`The software client transfers data to/from a conventional modem. The software client implements the forwarding
`
`of real-time data over regular data according to the principles of the present invention in both transmit and receive
`
`20
`
`directions.
`
`Brief Description of the Drawings
`
`A better understanding of the present invention can be obtained when the various embodiments of the
`
`following detailed description is considered in conjunction with the following drawings, in which:
`
`25
`
`Fig. 1 illustrates a modem-based communication link according to the prior art;
`
`Fig. 2A&2B illustrate a software architecture for transmission and reception of data respectively according to
`
`the prior art;
`
`Fig. 3 illustrates real-time frames and non-real-time frames in various stage of delivery across a modem
`
`link;
`
`30
`
`Fig. 4 illustrates a Digital Simultaneous Voice and Data (DSVD) modem link;
`
`Fig. 5 illustrates modem-based communication according to present invention;
`
`Fig. 6A illustrates the transmission architecture of a modem according to the present;
`
`Fig. 6B illustrates a state diagram for transmission logic 146 of modem 113;
`
`Fig. 6C illustrates an escape sequence protocol for real-time data injection into an output data stream;
`
`35
`
`Fig. 6D illustrates further features of the escape sequence protocol;
`
`Fig. 6E illustrate the initiation of transmission in response to the availability of real-time data;
`
`Fig. 7 A illustrates the reception architecture of modem 113;
`
`Fig. 7B illustrates a state diagram for tran