rfc3451.Layered Coding Transport (LCT) Building Block
Network Working Group M. Luby Request for Comments: 3451 Digital Fountain Category: Experimental J. Gemmell Microsoft L. Vicisano Cisco L. Rizzo Univ. Pisa M. Handley ICIR J. Crowcroft Cambridge Univ. December 2002 Layered Coding Transport (LCT) Building Block
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract
Layered Coding Transport (LCT) provides transport level support for
reliable content delivery and stream delivery protocols. LCT is
specifically designed to support protocols using IP multicast, but
also provides support to protocols that use unicast. LCT is
compatible with congestion control that provides multiple rate
delivery to receivers and is also compatible with coding techniques
that provide reliable delivery of content.
Luby, et. al. Experimental [Page 1]
Table of Contents
1. Introduction (2)
2. Rationale (3)
3. Functionality (4)
4. Applicability (7)
4.1 Environmental Requirements and Considerations (8)
4.2 Delivery service models (10)
4.3 Congestion Control (11)
5. Packet Header Fields (12)
5.1 Default LCT header format (12)
5.2 Header-Extension Fields (17)
6. Operations (20)
6.1 Sender Operation (20)
6.2 Receiver Operation (22)
7. Requirements from Other Building Blocks (23)
8. Security Considerations (24)
9. IANA Considerations (25)
10. Acknowledgments (25)
11. References (25)
Authors’ Addresses (28)
Full Copyright Statement (29)
1. Introduction
Layered Coding Transport provides transport level support for
reliable content delivery and stream delivery protocols. Layered
Coding Transport is specifically designed to support protocols using IP multicast, but also provides support to protocols that use
unicast. Layered Coding Transport is compatible with congestion
control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of
content.
This document describes a building block as defined in RFC 3048 [26]. This document is a product of the IETF RMT WG and follows the
general guidelines provided in RFC 3269 [24].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2]. Luby, et. al. Experimental [Page 2]
Statement of Intent
This memo contains part of the definitions necessary to fully
specify a Reliable Multicast Transport protocol in accordance with RFC 2357. As per RFC 2357, the use of any reliable multicast
protocol in the Internet requires an adequate congestion control
scheme.
While waiting for such a scheme to be available, or for an
existing scheme to be proven adequate, the Reliable Multicast
Transport working group (RMT) publishes this Request for Comments in the "Experimental" category.
It is the intent of RMT to re-submit this specification as an IETF Proposed Standard as soon as the above condition is met.
2. Rationale
LCT provides transport level support for massively scalable protocols using the IP multicast network service. The support that LCT
provides is common to a variety of very important applications,
including reliable content delivery and streaming applications.
An LCT session comprises multiple channels originating at a single
sender that are used for some period of time to carry packets
pertaining to the transmission of one or more objects that can be of interest to receivers. The logic behind defining a session as
originating from a single sender is that this is the right
granularity to regulate packet traffic via congestion control. One
rationale for using multiple channels within the same session is that there are massively scalable congestion control protocols that use
multiple channels per session. These congestion control protocols
are considered to be layered because a receiver joins and leaves
channels in a layered order during its participation in the session. The use of layered channels is also useful for streaming
applications.
There are coding techniques that provide massively scalable
reliability and asynchronous delivery which are compatible with both layered congestion control and with LCT. When all are combined the
result is a massively scalable reliable asynchronous content delivery protocol that is network friendly. LCT also provides functionality
that can be used for other applications as well, e.g., layered
streaming applications.
Luby, et. al. Experimental [Page 3]
LCT avoids providing functionality that is not massively scalable.
For example, LCT does not provide any mechanisms for sending
information from receivers to senders, although this does not rule
out protocols that both use LCT and do require sending information
from receivers to senders.
LCT includes general support for congestion control that must be
used. It does not, however, specify which congestion control should be used. The rationale for this is that congestion control must be
provided by any protocol that is network friendly, and yet the
different applications that can use LCT will not have the same
requirements for congestion control. For example, a content delivery protocol may strive to use all available bandwidth between receivers and the sender. It must, therefore, drastically back off its rate
when there is competing traffic. On the other hand, a streaming
delivery protocol may strive to maintain a constant rate instead of
trying to use all available bandwidth, and it may not back off its
rate as fast when there is competing traffic.
Beyond support for congestion control, LCT provides a number of
fields and supports functionality commonly required by many
protocols. For example, LCT provides a Transmission Session ID that can be used to identify which session each received packet belongs
to. This is important because a receiver may be joined to many
sessions concurrently, and thus it is very useful to be able to
demultiplex packets as they arrive according to which session they
belong to. As another example, LCT provides optional support for
identifying which object each packet is carrying information about.
Therefore, LCT provides many of the commonly used fields and support for functionality required by many protocols.
3. Functionality
An LCT session consists of a set of logically grouped LCT channels
associated with a single sender carrying packets with LCT headers for one or more objects. An LCT channel is defined by the combination of a sender and an address associated with the channel by the sender. A receiver joins a channel to start receiving the data packets sent to the channel by the sender, and a receiver leaves a channel to stop
receiving data packets from the channel.
LCT is meant to be combined with other building blocks so that the
resulting overall protocol is massively scalable. Scalability refers to the behavior of the protocol in relation to the number of
receivers and network paths, their heterogeneity, and the ability to accommodate dynamically variable sets of receivers. Scalability
limitations can come from memory or processing requirements, or from the amount of feedback control and redundant data packet traffic Luby, et. al. Experimental [Page 4]
generated by the protocol. In turn, such limitations may be a
consequence of the features that a complete reliable content delivery or stream delivery protocol is expected to provide.
The LCT header provides a number of fields that are useful for
conveying in-band session information to receivers. One of the
required fields is the Transmission Session ID (TSI), which allows
the receiver of a session to uniquely identify received packets as
part of the session. Another required field is the Congestion
Control Information (CCI), which allows the receiver to perform the
required congestion control on the packets received within the
session. Other LCT fields provide optional but often very useful
additional information for the session. For example, the Transport
Object Identifier (TOI) identifies which object the packet contains
data for. As other examples, the Sender Current Time (SCT) conveys
the time when the packet was sent from the sender to the receiver,
the Expected Residual Time (ERT) conveys the amount of time the
session will be continued for, flags for indicating the close of the session and the close of sending packets for an object, and header
extensions for fields that for example can be used for packet
authentication.
LCT provides support for congestion control. Congestion control MUST be used that conforms to RFC 2357 [13] between receivers and the
sender for each LCT session. Congestion control refers to the
ability to adapt throughput to the available bandwidth on the path
from the sender to a receiver, and to share bandwidth fairly with
competing flows such as TCP. Thus, the total flow of packets flowing to each receiver participating in an LCT session MUST NOT compete
unfairly with existing flow adaptive protocols such as TCP.
A multiple rate or a single rate congestion control protocol can be
used with LCT. For multiple rate protocols, a session typically
consists of more than one channel and the sender sends packets to the channels in the session at rates that do not depend on the receivers. Each receiver adjusts its reception rate during its participation in the session by joining and leaving channels dynamically depending on the available bandwidth to the sender independent of all other
receivers. Thus, for multiple rate protocols, the reception rate of each receiver may vary dynamically independent of the other
receivers.
For single rate protocols, a session typically consists of one
channel and the sender sends packets to the channel at variable rates over time depending on feedback from receivers. Each receiver
remains joined to the channel during its participation in the
session. Thus, for single rate protocols, the reception rate of each receiver may vary dynamically but in coordination with all receivers. Luby, et. al. Experimental [Page 5]
Generally, a multiple rate protocol is preferable to a single rate
protocol in a heterogeneous receiver environment, since generally it more easily achieves scalability to many receivers and provides
higher throughput to each individual receiver. Some possible
multiple rate congestion control protocols are described in [22],
[3], and [25]. A possible single rate congestion control protocol is described in [19].
Layered coding refers to the ability to produce a coded stream of
packets that can be partitioned into an ordered set of layers. The
coding is meant to provide some form of reliability, and the layering is meant to allow the receiver experience (in terms of quality of
playout, or overall transfer speed) to vary in a predictable way
depending on how many consecutive layers of packets the receiver is
receiving.
The concept of layered coding was first introduced with reference to audio and video streams. For example, the information associated
with a TV broadcast could be partitioned into three layers,
corresponding to black and white, color, and HDTV quality. Receivers can experience different quality without the need for the sender to
replicate information in the different layers.
The concept of layered coding can be naturally extended to reliable
content delivery protocols when Forward Error Correction (FEC)
techniques are used for coding the data stream. Descriptions of this can be found in [20], [18], [7], [22] and [4]. By using FEC, the
data stream is transformed in such a way that reconstruction of a
data object does not depend on the reception of specific data
packets, but only on the number of different packets received. As a result, by increasing the number of layers a receiver is receiving
from, the receiver can reduce the transfer time accordingly. Using
FEC to provide reliability can increase scalability dramatically in
comparison to other methods for providing reliability. More details on the use of FEC for reliable content delivery can be found in [11]. Reliable protocols aim at giving guarantees on the reliable delivery of data from the sender to the intended recipients. Guarantees vary from simple packet data integrity to reliable delivery of a precise
copy of an object to all intended recipients. Several reliable
content delivery protocols have been built on top of IP multicast
using methods other than FEC, but scalability was not the primary
design goal for many of them.
Two of the key difficulties in scaling reliable content delivery
using IP multicast are dealing with the amount of data that flows
from receivers back to the sender, and the associated response
(generally data retransmissions) from the sender. Protocols that Luby, et. al. Experimental [Page 6]
avoid any such feedback, and minimize the amount of retransmissions, can be massively scalable. LCT can be used in conjunction with FEC
codes or a layered codec to achieve reliability with little or no
feedback.
Protocol instantiations MAY be built by combining the LCT framework
with other components. A complete protocol instantiation that uses
LCT MUST include a congestion control protocol that is compatible
with LCT and that conforms to RFC 2357 [13]. A complete protocol
instantiation that uses LCT MAY include a scalable reliability
protocol that is compatible with LCT, it MAY include an session
control protocol that is compatible with LCT, and it MAY include
other protocols such as security protocols.
4. Applicability
An LCT session comprises a logically related set of one or more LCT
channels originating at a single sender. The channels are used for
some period of time to carry packets containing LCT headers, and
these headers pertain to the transmission of one or more objects that can be of interest to receivers.
LCT is most applicable for delivery of objects or streams in a
session of substantial length, i.e., objects or streams that range in aggregate length from hundreds of kilobytes to many gigabytes, and
where the duration of the session is on the order of tens of seconds or more.
As an example, an LCT session could be used to deliver a TV program
using three LCT channels. Receiving packets from the first LCT
channel could allow black and white reception. Receiving the first
two LCT channels could also permit color reception. Receiving all
three channels could allow HDTV quality reception. Objects in this
example could correspond to individual TV programs being transmitted. As another example, a reliable LCT session could be used to reliably deliver hourly-updated weather maps (objects) using ten LCT channels at different rates, using FEC coding. A receiver may join and
concurrently receive packets from subsets of these channels, until it has enough packets in total to recover the object, then leave the
session (or remain connected listening for session description
information only) until it is time to receive the next object. In
this case, the quality metric is the time required to receive each
object.
Before joining a session, the receivers MUST obtain enough of the
session description to start the session. This MUST include the
relevant session parameters needed by a receiver to participate in Luby, et. al. Experimental [Page 7]
the session, including all information relevant to congestion
control. The session description is determined by the sender, and is typically communicated to the receivers out-of-band. In some cases, as described later, parts of the session description that are not
required to initiate a session MAY be included in the LCT header or
communicated to a receiver out-of-band after the receiver has joined the session.
An encoder MAY be used to generate the data that is placed in the
packet payload in order to provide reliability. A suitable decoder
is used to reproduce the original information from the packet
payload. There MAY be a reliability header that follows the LCT
header if such an encoder and decoder is used. The reliability
header helps to describe the encoding data carried in the payload of the packet. The format of the reliability header depends on the
coding used, and this is negotiated out-of-band. As an example, one of the FEC headers described in [12] could be used.
For LCT, when multiple rate congestion control is used, congestion
control is achieved by sending packets associated with a given
session to several LCT channels. Individual receivers dynamically
join one or more of these channels, according to the network
congestion as seen by the receiver. LCT headers include an opaque
field which MUST be used to convey congestion control information to the receivers. The actual congestion control scheme to use with LCT is negotiated out-of-band. Some examples of congestion control
protocols that may be suitable for content delivery are described in [22], [3], and [25]. Other congestion controls may be suitable when LCT is used for a streaming application.
This document does not specify and restrict the type of exchanges
between LCT (or any PI built on top of LCT) and an upper application. Some upper APIs may use an object-oriented approach, where the only
possible unit of data exchanged between LCT (or any PI built on top
of LCT) and an application, either at a source or at a receiver, is
an object. Other APIs may enable a sending or receiving application to exchange a subset of an object with LCT (or any PI built on top of LCT), or may even follow a streaming model. These considerations are outside the scope of this document.
4.1 Environmental Requirements and Considerations
LCT is intended for congestion controlled delivery of objects and
streams (both reliable content delivery and streaming of multimedia
information).
Luby, et. al. Experimental [Page 8]
LCT can be used with both multicast and unicast delivery. LCT
requires connectivity between a sender and receivers but does not
require connectivity from receivers to a sender. LCT inherently
works with all types of networks, including LANs, WANs, Intranets,
the Internet, asymmetric networks, wireless networks, and satellite
networks. Thus, the inherent raw scalability of LCT is unlimited.
However, when other specific applications are built on top of LCT,
then these applications by their very nature may limit scalability.
For example, if an application requires receivers to retrieve out of band information in order to join a session, or an application allows receivers to send requests back to the sender to report reception
statistics, then the scalability of the application is limited by the ability to send, receive, and process this additional data.
LCT requires receivers to be able to uniquely identify and
demultiplex packets associated with an LCT session. In particular,
there MUST be a Transport Session Identifier (TSI) associated with
each LCT session. The TSI is scoped by the IP address of the sender, and the IP address of the sender together with the TSI MUST uniquely identify the session. If the underlying transport is UDP as
described in RFC 768 [16], then the 16 bit UDP source port number MAY serve as the TSI for the session. The TSI value MUST be the same in all places it occurs within a packet. If there is no underlying TSI provided by the network, transport or any other layer, then the TSI
MUST be included in the LCT header.
LCT is presumed to be used with an underlying network or transport
service that is a "best effort" service that does not guarantee
packet reception or packet reception order, and which does not have
any support for flow or congestion control. For example, the Any-
Source Multicast (ASM) model of IP multicast as defined in RFC 1112
[5] is such a "best effort" network service. While the basic service provided by RFC 1112 is largely scalable, providing congestion
control or reliability should be done carefully to avoid severe
scalability limitations, especially in presence of heterogeneous sets of receivers.
There are currently two models of multicast delivery, the Any-Source Multicast (ASM) model as defined in RFC 1112 [5] and the Source-
Specific Multicast (SSM) model as defined in [10]. LCT works with
both multicast models, but in a slightly different way with somewhat different environmental concerns. When using ASM, a sender S sends
packets to a multicast group G, and the LCT channel address consists of the pair (S,G), where S is the IP address of the sender and G is a multicast group address. When using SSM, a sender S sends packets to an SSM channel (S,G), and the LCT channel address coincides with the SSM channel address.
Luby, et. al. Experimental [Page 9]
A sender can locally allocate unique SSM channel addresses, and this makes allocation of LCT channel addresses easy with SSM. To allocate LCT channel addresses using ASM, the sender must uniquely chose the
ASM multicast group address across the scope of the group, and this
makes allocation of LCT channel addresses more difficult with ASM.
LCT channels and SSM channels coincide, and thus the receiver will
only receive packets sent to the requested LCT channel. With ASM,
the receiver joins an LCT channel by joining a multicast group G, and all packets sent to G, regardless of the sender, may be received by
the receiver. Thus, SSM has compelling security advantages over ASM for prevention of denial of service attacks. In either case,
receivers SHOULD use mechanisms to filter out packets from unwanted
sources.
Some networks are not amenable to some congestion control protocols
that could be used with LCT. In particular, for a satellite or
wireless network, there may be no mechanism for receivers to
effectively reduce their reception rate since there may be a fixed
transmission rate allocated to the session.
4.2 Delivery service models
LCT can support several different delivery service models. Two
examples are briefly described here.
Push service model.
One way a push service model can be used for reliable content
delivery is to deliver a series of objects. For example, a receiver could join the session and dynamically adapt the number of LCT
channels the receiver is joined to until enough packets have been
received to reconstruct an object. After reconstructing the object
the receiver may stay in the session and wait for the transmission of the next object.
The push model is particularly attractive in satellite networks and
wireless networks. In these cases, a session may consist of one
fixed rate LCT channel.
On-demand content delivery model.
For an on-demand content delivery service model, senders typically
transmit for some given time period selected to be long enough to
allow all the intended receivers to join the session and recover the object. For example a popular software update might be transmitted Luby, et. al. Experimental [Page 10]
using LCT for several days, even though a receiver may be able to
complete the download in one hour total of connection time, perhaps
spread over several intervals of time.
In this case the receivers join the session, and dynamically adapt
the number of LCT channels they subscribe to according to the
available bandwidth. Receivers then drop from the session when they have received enough packets to recover the object.
As an example, assume that an object is 50 MB. The sender could send 1 KB packets to the first LCT channel at 50 packets per second, so
that receivers using just this LCT channel could complete reception
of the object in 1,000 seconds in absence of loss, and would be able to complete reception even in presence of some substantial amount of losses with the use of coding for reliability. Furthermore, the
sender could use a number of LCT channels such that the aggregate
rate of 1 KB packets to all LCT channels is 1,000 packets per second, so that a receiver could be able to complete reception of the object in as little 50 seconds (assuming no loss and that the congestion
control mechanism immediately converges to the use of all LCT
channels).
Other service models.
There are many other delivery service models that LCT can be used for that are not covered above. As examples, a live streaming or an on- demand archival content streaming service model. A description of
the many potential applications, the appropriate delivery service
model, and the additional mechanisms to support such functionalities when combined with LCT is beyond the scope of this document. This
document only attempts to describe the minimal common scalable
elements to these diverse applications using LCT as the delivery
transport.
4.3 Congestion Control
The specific congestion control protocol to be used for LCT sessions depends on the type of content to be delivered. While the general
behavior of the congestion control protocol is to reduce the
throughput in presence of congestion and gradually increase it in the absence of congestion, the actual dynamic behavior (e.g. response to single losses) can vary.
Some possible congestion control protocols for reliable content
delivery using LCT are described in [22], [3], and [25]. Different
delivery service models might require different congestion control
protocols.
Luby, et. al. Experimental [Page 11]
5. Packet Header Fields
Packets sent to an LCT session MUST include an "LCT header". The LCT header format described below is the default format, and this is the format that is recommended for use by protocol instantiations to
ensure a uniform format across different protocol instantiations.
Other LCT header formats MAY be used by protocol instantiations, but if the default LCT header format is not used by a protocol
instantiation that uses LCT, then the protocol instantiation MUST
specify the lengths and positions within the LCT header it uses of
all fields described in the default LCT header.
Other building blocks MAY describe some of the same fields as
described for the LCT header. It is RECOMMENDED that protocol
instantiations using multiple building blocks include shared fields
at most once in each packet. Thus, for example, if another building block is used with LCT that includes the optional Expected Residual
Time field, then the Expected Residual Time field SHOULD be carried
in each packet at most once.
The position of the LCT header within a packet MUST be specified by
any protocol instantiation that uses LCT.
5.1 Default LCT header format
The default LCT header is of variable size, which is specified by a
length field in the third byte of the header. In the LCT header, all integer fields are carried in "big-endian" or "network order" format, that is, most significant byte (octet) first. Bits designated as
"padding" or "reserved" (r) MUST by set to 0 by senders and ignored
by receivers. Unless otherwise noted, numeric constants in this
specification are in decimal (base 10).
The format of the default LCT header is depicted in Figure 1.
Luby, et. al. Experimental [Page 12]
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | C | r |S| O |H|T|R|A|B| HDR_LEN | Codepoint (CP)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Control Information (CCI, length = 32*(C+1) bits) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Session Identifier (TSI, length = 32*S+16*H bits) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Object Identifier (TOI, length = 32*O+16*H bits) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Current Time (SCT, if T = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expected Residual Time (ERT, if R = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - Default LCT header format
The function and length of each field in the default LCT header is
the following. Fields marked as "1" mean that the corresponding bits MUST be set to "1" by the sender. Fields marked as "r" or "0" mean
that the corresponding bits MUST be set to "0" by the sender.
LCT version number (V): 4 bits
Indicates the LCT version number. The LCT version number for
this specification is 1.
Congestion control flag (C): 2 bits
C=0 indicates the Congestion Control Information (CCI) field is 32-bits in length. C=1 indicates the CCI field is 64-bits in
length. C=2 indicates the CCI field is 96-bits in length. C=3 indicates the CCI field is 128-bits in length.
Reserved (r): 2 bits
Reserved for future use. A sender MUST set these bits to zero and a receiver MUST ignore these bits.
Luby, et. al. Experimental [Page 13]
Transport Session Identifier flag (S): 1 bit
This is the number of full 32-bit words in the TSI field. The TSI field is 32*S + 16*H bits in length, i.e. the length is
either 0 bits, 16 bits, 32 bits, or 48 bits.
Transport Object Identifier flag (O): 2 bits
This is the number of full 32-bit words in the TOI field. The TOI field is 32*O + 16*H bits in length, i.e., the length is
either 0 bits, 16 bits, 32 bits, 48 bits, 64 bits, 80 bits, 96 bits, or 112 bits.
Half-word flag (H): 1 bit
The TSI and the TOI fields are both multiples of 32-bits plus
16*H bits in length. This allows the TSI and TOI field lengths to be multiples of a half-word (16 bits), while ensuring that
the aggregate length of the TSI and TOI fields is a multiple of 32-bits.
Sender Current Time present flag (T): 1 bit
T = 0 indicates that the Sender Current Time (SCT) field is not present. T = 1 indicates that the SCT field is present. The
SCT is inserted by senders to indicate to receivers how long
the session has been in progress.
Expected Residual Time present flag (R): 1 bit
R = 0 indicates that the Expected Residual Time (ERT) field is not present. R = 1 indicates that the ERT field is present.
The ERT is inserted by senders to indicate to receivers how
much longer the session / object transmission will continue.
Senders MUST NOT set R = 1 when the ERT for the session is more than 2^32-1 time units (approximately 49 days), where time is
measured in units of milliseconds.
Close Session flag (A): 1 bit
Normally, A is set to 0. The sender MAY set A to 1 when
termination of transmission of packets for the session is
imminent. A MAY be set to 1 in just the last packet
transmitted for the session, or A MAY be set to 1 in the last
few seconds of packets transmitted for the session. Once the
sender sets A to 1 in one packet, the sender SHOULD set A to 1 in all subsequent packets until termination of transmission of Luby, et. al. Experimental [Page 14]
packets for the session. A received packet with A set to 1
indicates to a receiver that the sender will immediately stop
sending packets for the session. When a receiver receives a
packet with A set to 1 the receiver SHOULD assume that no more packets will be sent to the session.
Close Object flag (B): 1 bit
Normally, B is set to 0. The sender MAY set B to 1 when
termination of transmission of packets for an object is
imminent. If the TOI field is in use and B is set to 1 then
termination of transmission for the object identified by the
TOI field is imminent. If the TOI field is not in use and B is set to 1 then termination of transmission for the one object in the session identified by out-of-band information is imminent.
B MAY be set to 1 in just the last packet transmitted for the
object, or B MAY be set to 1 in the last few seconds packets
transmitted for the object. Once the sender sets B to 1 in one packet for a particular object, the sender SHOULD set B to 1 in all subsequent packets for the object until termination of
transmission of packets for the object. A received packet with B set to 1 indicates to a receiver that the sender will
immediately stop sending packets for the object. When a
receiver receives a packet with B set to 1 then it SHOULD
assume that no more packets will be sent for the object to the session.
LCT header length (HDR_LEN): 8 bits
Total length of the LCT header in units of 32-bit words. The
length of the LCT header MUST be a multiple of 32-bits. This
field can be used to directly access the portion of the packet beyond the LCT header, i.e., to the first other header if it
exists, or to the packet payload if it exists and there is no
other header, or to the end of the packet if there are no other headers or packet payload.
Codepoint (CP): 8 bits
An opaque identifier which is passed to the packet payload
decoder to convey information on the codec being used for the
packet payload. The mapping between the codepoint and the
actual codec is defined on a per session basis and communicated out-of-band as part of the session description information.
The use of the CP field is similar to the Payload Type (PT)
field in RTP headers as described in RFC 1889 [21].
Luby, et. al. Experimental [Page 15]
Congestion Control Information (CCI): 32, 64, 96 or 128 bits
Used to carry congestion control information. For example, the congestion control information could include layer numbers,
logical channel numbers, and sequence numbers. This field is
opaque for the purpose of this specification.
This field MUST be 32 bits if C=0.
This field MUST be 64 bits if C=1.
This field MUST be 96 bits if C=2.
This field MUST be 128 bits if C=3.
Transport Session Identifier (TSI): 0, 16, 32 or 48 bits
The TSI uniquely identifies a session among all sessions from a particular sender. The TSI is scoped by the IP address of the sender, and thus the IP address of the sender and the TSI
together uniquely identify the session. Although a TSI in
conjunction with the IP address of the sender always uniquely
identifies a session, whether or not the TSI is included in the LCT header depends on what is used as the TSI value. If the
underlying transport is UDP, then the 16 bit UDP source port
number MAY serve as the TSI for the session. If the TSI value appears multiple times in a packet then all occurrences MUST be the same value. If there is no underlying TSI provided by the network, transport or any other layer, then the TSI MUST be
included in the LCT header.
The TSI MUST be unique among all sessions served by the sender during the period when the session is active, and for a large
period of time preceding and following when the session is
active. A primary purpose of the TSI is to prevent receivers
from inadvertently accepting packets from a sender that belong to sessions other than the sessions receivers are subscribed
to. For example, suppose a session is deactivated and then
another session is activated by a sender and the two sessions
use an overlapping set of channels. A receiver that connects
and remains connected to the first session during this sender
activity could possibly accept packets from the second session as belonging to the first session if the TSI for the two
sessions were identical. The mapping of TSI field values to
sessions is outside the scope of this document and is to be
done out-of-band.
The length of the TSI field is 32*S + 16*H bits. Note that the aggregate lengths of the TSI field plus the TOI field is a
multiple of 32 bits.
Luby, et. al. Experimental [Page 16]
Transport Object Identifier (TOI): 0, 16, 32, 48, 64, 80, 96 or 112 bits.
This field indicates which object within the session this
packet pertains to. For example, a sender might send a number of files in the same session, using TOI=0 for the first file,
TOI=1 for the second one, etc. As another example, the TOI may be a unique global identifier of the object that is being
transmitted from several senders concurrently, and the TOI
value may be the output of a hash function applied to the
object. The mapping of TOI field values to objects is outside the scope of this document and is to be done out-of-band. The TOI field MUST be used in all packets if more than one object
is to be transmitted in a session, i.e. the TOI field is either present in all the packets of a session or is never present.
The length of the TOI field is 32*O + 16*H bits. Note that the aggregate lengths of the TSI field plus the TOI field is a
multiple of 32 bits.
Sender Current Time (SCT): 0 or 32 bits
This field represents the current clock at the sender and at
the time this packet was transmitted, measured in units of 1ms and computed modulo 2^32 units from the start of the session.
This field MUST NOT be present if T=0 and MUST be present if
T=1.
Expected Residual Time (ERT): 0 or 32 bits
This field represents the sender expected residual transmission time for the current session or for the transmission of the
current object, measured in units of 1ms. If the packet
containing the ERT field also contains the TOI field, then ERT refers to the object corresponding to the TOI field, otherwise it refers to the session.
This field MUST NOT be present if R=0 and MUST be present if
R=1.
5.2 Header-Extension Fields
Header Extensions are used in LCT to accommodate optional header
fields that are not always used or have variable size. Examples of
the use of Header Extensions include:
o Extended-size versions of already existing header fields.
Luby, et. al. Experimental [Page 17]
o Sender and Receiver authentication information.
The presence of Header Extensions can be inferred by the LCT header
length (HDR_LEN): if HDR_LEN is larger than the length of the
standard header then the remaining header space is taken by Header
Extension fields.
If present, Header Extensions MUST be processed to ensure that they
are recognized before performing any congestion control procedure or otherwise accepting a packet. The default action for unrecognized
header extensions is to ignore them. This allows the future
introduction of backward-compatible enhancements to LCT without
changing the LCT version number. Non backward-compatible header
extensions CANNOT be introduced without changing the LCT version
number.
Protocol instantiation MAY override this default behavior for PI-
specific extensions (see below).
There are two formats for Header Extension fields, as depicted below. The first format is used for variable-length extensions, with Header Extension Type (HET) values between 0 and 127. The second format is used for fixed length (one 32-bit word) extensions, using HET values from 127 to 255.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (<=127) | HEL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Header Extension Content (HEC) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (>=128) | Header Extension Content (HEC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - Format of additional headers
The explanation of each sub-field is the following:
Header Extension Type (HET): 8 bits
The type of the Header Extension. This document defines a
number of possible types. Additional types may be defined in Luby, et. al. Experimental [Page 18]
future versions of this specification. HET values from 0 to
127 are used for variable-length Header Extensions. HET values from 128 to 255 are used for fixed-length 32-bit Header
Extensions.
Header Extension Length (HEL): 8 bits
The length of the whole Header Extension field, expressed in
multiples of 32-bit words. This field MUST be present for
variable-length extensions (HET between 0 and 127) and MUST NOT be present for fixed-length extensions (HET between 128 and
255).
Header Extension Content (HEC): variable length
The content of the Header Extension. The format of this sub-
field depends on the Header Extension type. For fixed-length
Header Extensions, the HEC is 24 bits. For variable-length
Header Extensions, the HEC field has variable size, as
specified by the HEL field. Note that the length of each
Header Extension field MUST be a multiple of 32 bits. Also
note that the total size of the LCT header, including all
Header Extensions and all optional header fields, cannot exceed 255 32-bit words.
Header Extensions are further divided between general LCT extensions and Protocol Instantiation specific extensions (PI-specific).
General LCT extensions have HET in the ranges 0:63 and 128:191
inclusive. PI-specific extensions have HET in the ranges 64:127 and 192:255 inclusive.
General LCT extensions are intended to allow the introduction of
backward-compatible enhancements to LCT without changing the LCT
version number. Non backward-compatible header extensions CANNOT be introduced without changing the LCT version number.
PI-specific extensions are reserved for PI-specific use with semantic and default parsing actions defined by the PI.
The following general LCT Header Extension types are defined:
EXT_NOP=0 No-Operation extension.
The information present in this extension field MUST be ignored by receivers.
EXT_AUTH=1 Packet authentication extension
Information used to authenticate the sender of the
packet. The format of this Header Extension and its Luby, et. al. Experimental [Page 19]
processing is outside the scope of this document and is to be communicated out-of-band as part of the session
description.
It is RECOMMENDED that senders provide some form of
packet authentication. If EXT_AUTH is present,
whatever packet authentication checks that can be
performed immediately upon reception of the packet
SHOULD be performed before accepting the packet and
performing any congestion control-related action on it. Some packet authentication schemes impose a delay of
several seconds between when a packet is received and
when the packet is fully authenticated. Any congestion control related action that is appropriate MUST NOT be postponed by any such full packet authentication.
All senders and receivers implementing LCT MUST support the EXT_NOP
Header Extension and MUST recognize EXT_AUTH, but MAY NOT be able to parse its content.
6. Operations
6.1 Sender Operation
Before joining an LCT session a receiver MUST obtain a session
description. The session description MUST include:
o The sender IP address;
o The number of LCT channels;
o The addresses and port numbers used for each LCT channel;
o The Transport Session ID (TSI) to be used for the session;
o Enough information to determine the congestion control protocol
being used;
o Enough information to determine the packet authentication scheme being used if it is being used.
The session description could also include, but is not limited to:
o The data rates used for each LCT channel;
o The length of the packet payload;
Luby, et. al. Experimental [Page 20]
泰克示波器的使用方法-1
示波器的使用方法 示波器虽然分成好几类，各类又有许多种型号，但是一般的示波器除频带宽度、输入灵敏度等不完全相同外，在使用方法的基本方面都是相同的。本章以SR-8型双踪示波器为例介绍。 （一）面板装置 SR-8型双踪示波器的面板图如图5-12所示。其面板装置按其位置和功能通常可划分为3大部分：显示、垂直（Y轴）、水平（X轴）。现分别介绍这3个部分控制装置的作用。 1．显示部分主要控制件为： （1）电源开关。 （2）电源指示灯。 （3）辉度调整光点亮度。 （4）聚焦调整光点或波形清晰度。 （5）辅助聚焦配合“聚焦”旋钮调节清晰度。 （6）标尺亮度调节坐标片上刻度线亮度。 （7）寻迹当按键向下按时，使偏离荧光屏的光点回到显示区域，而寻到光点位置。 （8）标准信号输出 1kHz、1V方波校准信号由此引出。加到Y轴输入端，用以校准Y 轴输入灵敏度和X轴扫描速度。 2．Y轴插件部分 （1）显示方式选择开关用以转换两个Y轴前置放大器Y A与YB 工作状态的控制件，具有五种不同作用的显示方式：
“交替”：当显示方式开关置于“交替”时，电子开关受扫描信号控制转换，每次扫描都轮流接通Y A或YB 信号。当被测信号的频率越高，扫描信号频率也越高。电 子开关转换速率也越快，不会有闪烁现象。这种工作状态适用于观察两个工作频率较高的信号。 “断续”：当显示方式开关置于“断续”时，电子开关不受扫描信号控制，产生频率固定为200kHz方波信号，使电子开关快速交替接通Y A和YB。由于开关动作频率高于被测信号频率，因此屏幕上显示的两个通道信号波形是断续的。当被测信号频率较高时，断续现象十分明显，甚至无法观测；当被测信号频率较低时，断续现象被掩盖。因此，这种工作状态适合于观察两个工作频率较低的信号。 “Y A”、“YB ”：显示方式开关置于“Y A ”或者“YB ”时，表示示波器处于单通道工作，此时示波器的工作方式相当于单踪示波器，即只能单独显示“Y A”或“YB ”通道的信号波形。 “Y A + YB”：显示方式开关置于“Y A + YB ”时，电子开关不工作，Y A与YB 两路信号均通过放大器和门电路，示波器将显示出两路信号叠加的波形。 （2）“DC-⊥-AC” Y轴输入选择开关，用以选择被测信号接至输入端的耦合方式。置于“DC”是直接耦合，能输入含有直流分量的交流信号；置于“AC”位置，实现交流耦合，只能输入交流分量；置于“⊥”位置时，Y轴输入端接地，这时显示的时基线一般用来作为测试直流电压零电平的参考基准线。 （3）“微调V/div” 灵敏度选择开关及微调装置。灵敏度选择开关系套轴结构，黑色旋钮是Y轴灵敏度粗调装置，自10mv/div～20v/div分11档。红色旋钮为细调装置，顺时针方向增加到满度时为校准位置，可按粗调旋钮所指示的数值，读取被测信号的幅度。当此旋钮反时针转到满度时，其变化范围应大于2.5倍，连续调节“微调”电位器，可实现各档级之间的灵敏度覆盖，在作定量测量时，此旋钮应置于顺时针满度的“校准”位置。 （4）“平衡” 当Y轴放大器输入电路出现不平衡时，显示的光点或波形就会随“V/div”开关的“微调”旋转而出现Y轴方向的位移，调节“平衡”电位器能将这种位移减至最小。 （5）“↑↓ ” Y轴位移电位器，用以调节波形的垂直位置。 （6）“极性、拉Y A” Y A通道的极性转换按拉式开关。拉出时Y A 通道信号倒相显示，即显示方式（Y A+ YB ）时，显示图像为YB - Y A。 （7）“内触发、拉YB ” 触发源选择开关。在按的位置上（常态）扫描触发信号分别
雅思口语Part2常考话题：有趣的地方
雅思口语Part2常考话题：有趣的地方 本文为大家收集整理了雅思口语Part2常考话题：有趣的地方。雅思口语Part2着重考察同学们的英语交流能力，同学们在备考阶段可以注意多积累素材，平时多模仿多练习，这样在考试中才不至于无话可说。 Describe an interesting place to visit Ok, I'd like to tell you about the temple of the Six Banyan Trees. It's located in the city center of Guangzhou and its not far away from Zhongshan 6 Road, near the People's Hospital. It's a good place to go to and climb to see the Flower Pagoda, which has eight sides to it. You can also go there to pray if you are a Buddhist. It is an active temple and is also the head of the Guangzhou Buddhist Association. You can also do a bit of shopping there if you like. Besides the souvenirs you can buy there, it also has a very lively fruit and meat market nearby, so if you just want to shop instead you can. The main feature of this place is the pagoda because it's the tallest in the city. From the outside it looks like it has only nine stories, but actually it has 17 inside. It's quite old, and was built some time in the 10th century. The temple itself is even older than that-I think it goes back to some time
示波器_使用方法_步骤
示波器 摘要：以数据采集卡为硬件基础，采用虚拟仪器技术，完成虚拟数字示波器的设计。能够具有运行停止功能，图形显示设置功能，显示模式设置功能并具有数据存储和查看存储数据等功能。实验结果表明, 该仪器能实现数字示波器的的基本功能，解决了传统测试仪器的成本高、开发周期长、数据人工记录等问题。 1．实验目的 1.理解示波器的工作原理，掌握虚拟示波器的设计方法。 2.理解示波器数据采集的原理，掌握数据采集卡的连接、测试和编程。 3.掌握较复杂的虚拟仪器的设计思想和方法，用LabVIEW实现虚拟示波器。 2. 实验要求 1.数据采集 用ELVIS实验平台，用DAQmx编程，通过数据采集卡对信号进行采集，并进行参数的设置。 2.示波器界面设计 (1)设置运行及停止按钮：按运行时，示波器工作；按停止时，示波器停止工作。 (2)设置图形显示区：可显示两路信号，并可进行图形的上下平移、图形的纵向放大与缩小、图形的横向扩展与压缩。 (3)设置示波器的显示模式：分为单通道模式(只显示一个通道的图形)，多通道模式(可同时显示两个通道)，运算模式(两通道相加、两通道相减等)。
万联芯城https://www.wendangku.net/doc/3f14889412.html,作为国内优秀的电子元器件采购网，一直秉承着以良心做好良芯的服务理念，万联芯城为全国终端生产研发企业提供原装现货电子元器件产品，拥有3000平方米现代化管理仓库，所售电子元器件有IC集成电路，二三极管，电阻电容等多种类别主动及被动类元器件，可申请样片，长久合作可申请账期，万联芯城为客户提供方便快捷的一站式电子元器件配套服务，提交物料清单表，当天即可获得各种元件的优势报价，整单付款当天发货，物料供应全国，欢迎广大客户咨询合作，点击进入万联芯城
2020雅思口语目标7分技巧
2020雅思口语目标7分技巧 雅思考试中，听力和阅读部分拿到高分相对容易些，提高水平，在考试中细心一些即可，但是口语想要拿到7分以上却并不简单。下面就和大家分享雅思口语目标7分，希望能够帮助到大家，来欣赏一下吧。 雅思口语目标7分?口语评分标准告诉你该怎么备考 雅思口语评分标准告诉你“流利度”如何拿7分 很多雅思口语提升攻略里都会提到雅思口语评分标准的四个方面，但对其做细化分析的并不多，比如，为什么你的口语只能拿6分?口语6分与7分的差异究竟表现在哪里?其实这些在评分标准中都有具体的区分。雅思口语7分在“流利度”方面要求大家“讲话时表达详尽，没有明显的不连贯现象，偶尔会有犹豫、重复或者自我纠正，能够灵活使用连词或者有标志性的词汇”，而口语6分的评分标准要求要低很多，具体的要求是“想要讲的详细，但是会因为重复、自我纠正和犹豫失去连贯性，能在口语中使用连词，但并不是所有连词都用的恰当”。 通过对比，我们发现，其实想要在“流利度”方面达到7分并不是特别难，7分有一定的容错度，只要大家不超出界限即可，偶尔犹豫可以，但整体要给考官一种你在自如自信表达的感觉。
针对流利度，建议大家在平时多做实际交流练习，尽可能多找机会与“native speaker”交流，锻炼英式思维的同时，也能提升表达欲望。 雅思口语评分标准告诉你“词汇”如何拿7分 雅思口语评分标准第二项，词汇。口语词汇如何才能达到7分标准呢?口语词汇7分要求大家“灵活使用词汇，能用一些非常见词汇和习语，了解语体和词汇搭配，可偶尔出现使用不当的情况”。具体分析，我们发现7分的词汇要求中，有一个点大家经常忽略，那就是“习语”。其实高端词汇大家在备考中都会用到，但是习语的使用却相对较少，而非常见习语的使用更是少之又少。所以小站君建议大家在备考雅思口语的时候积累一些地道习语，用在口语表达中，不仅仅是Part2，Part1和Part3也可以根据语境使用。如果大家能在口语表达中灵活使用一些让考官大家赞许的习语，分数自然也会有不错地提升。 雅思口语评分标准告诉你“语法”如何拿7分 雅思口语在“语法”方面的要求主要是多样性和准确性，而7分是口语高分的一个分水岭，所以也是语法使用的一个分水岭。“语法”方面想要拿到7分，大家必须“灵活使用复杂结构”，但是容许有一些不影响理解的语法错误。所以口语语法想要拿到7分，必须要掌握复杂句式的使用方法，并能灵活运用。这一点需
示波器的初级使用方法教程
示波器的使用方法教程 ST-16示波器的使用 示波器是有着极其广泛用途的测量仪器之一〃借助示波器能形象地观察波形的瞬变过程，还可以测量电压。电流、周期和相位，检查放大器的失真情况等〃示波器的型号很多，它的基本使用方法是差不多的〃下面以通用ST一16型示波器为例，介绍示波器的使用方法。 面板上旋钮或开关的功能 图1是ST一16型示波器的面板图。 示波器是以数字座标为基础来显示波形的〃通常以X轴表示时间，Y轴表示幅度〃因而在图1中，面板下半部以中线为界，左面的旋钮全用于Y轴，右面的旋钮全用于X 轴。面板上半部分为显示屏。显示屏的右边有三个旋钮是调屏幕用的〃所有的旋钮，开关功能见表1。其中8、10，14，16号旋钮不需经常调，做成内藏式。
显示屏读数方法 在显示屏上，水平方向X轴有10格刻度，垂直方向Y轴有8格刻度〃这里的一格刻度读做一标度，用div表示〃根据被测波形垂直方向(或水平方向)所占有的标度数，乘以垂直输入灵敏度开关所在档位的V／div数(或水平方向t／div)，得出的积便是测量结果。Y轴使用10：1衰减探头的话还需再乘10。 例如图2中测电压峰—峰值时，V／div档用0〃1V／div，输入端用了10 ： l 衰减探头，则Vp－p＝0〃1V／div×3〃6div×10＝3〃6V，t／div档为2ms／div，则波形的周期：T＝2ms／div×4div＝8ms。 使用前的准备 示波器用于旋钮与开关比较多，初次使用往往会感到无从着手。初学者可按表2方式进行调节。表2位置对示波器久藏复用或会使用者也适用。
使用前的校准 示波器的测试精度与电源电压有关，当电网电压偏离时，会产生较大的测量误差〃因此在使用前必须对垂直和水平系统进行校准。校准方法步骤如下： 1〃接通电源，指示灯有红光显示，稍等片刻，逆时针调节辉度旋钮，并适当调准聚焦，屏幕上就显示出不同步的校准信号方波。 2〃将触发电平调离“自动”位置，逆时针方向旋转旋钮使方波波形同步为止。并适当调节水平移位(11)和垂直移位(5)。 3〃分别调节垂直输入部分增益校准旋钮(10)和水平扫描部分的扫描校准旋钮(14)，使屏幕显示的标准方波的垂直幅度为5div，水平宽度为10div，如图3所示，ST一16示波器便可正常工作了。 示波器演示和测量举例 一，用ST一16示波器演示半波整流工作原理： 首先将垂直输入灵敏度选择开关(以下简写V／div)拨到每格0〃5V档，扫描时间转换开关(s／div)拨至每格5ms档，输入耦合开关拨至AC档，将输入探头的两端与电源变压器次级相接，见图4，这时屏幕显示如图5(a)所示的交流电压波形。 如果将探头移到二极管的负端处，这时屏幕上显示图5(b)所示的半波脉冲电压波形〃接上容量较大的电解电容器C进行滤波，调节一下触发电平旋钮(15)，在示波器屏幕上可看到较为平稳的直流电压波形，见图5(c)。电容C的容量越大，脉冲成分越小，电压越平稳。
雅思口语7分词组 180组
雅思口语6-7.5分考前一个月必练词组，句子等180组 1名词词组： a few friends of mine an essential part There’s a great number of traffic accidents happened everyday. a good listener 一个很好的听众 all-round person 全方面人才 bright future 光明的未来 comprehensive skills 综合技能 cultural heritage 文化遗产 fitness center 健身中心 focus of attention 关注的焦点 internet café网吧 low salary/high salary 低薪水/高薪水 many aspects of life 生活的很多方面 modern society 现代社会 movie censorship电影审查制度 on-line shopping 网上购物 people of all ages各年龄段的人们 pleasant atmosphere 令人愉快的环境 pop song 流行歌曲 role model 偶像 scenic spot 景点 serious air pollution 严重的空气污染 the Imperial Palace/the Palace Museum 故宫 traffic jams in rush hours 高峰时期的塞车 valuable experiences 有价值的经历 well-rounded education 全面教育 2动词词组： 把我的思想从课业当中解脱出来：take my mind off my school work It’s located in… 确保某事：It can guarantee sth. to make sure this will not happen 给某人提供某物：provide sb. with sth. acquire a lot of knowledge one can not find in textbooks 学到书本上学不到的知识add to the opportunity/the success 增加机会/增加成功性 avoid health problems 避免亚健康/健康问题 be helpful/beneficial to 对…有利 be under too much pressure of school work 学校课业压力过重 become more aware of the importance of…越来越认识…的重要性 bring sb. up 把某人抚养长大 broaden one’s horizon 开阔眼界 do harm/good to children 对孩子有害/有利 do one’s best/utmost 尽某人最大力量 enforce laws 实施法律
雅思口语7分经验分享
雅思口语7分经验分享 雅思口语7分--既然选择出国，哪还在乎背一本机经,家带来了雅思口语7分经验分享，希望能够帮助到大家，下面就和大家分享，来欣赏一下吧。 雅思口语7分--既然选择出国，哪还在乎背一本机经 20XX-08-17 16:36新东方网整理分享到个人状况：大学勉强过四级，没考6级。工作后突然觉得学历不够，要继续读研，提高英语。于是断然辞职，用了将近半年多的时间复习，备考，战斗。 终于overall : 6.5 speaking:7 首先我想说的是，如果你英语不错，自认随便考考就可以考个7之类的朋友，建议你不要看此贴。因为你能力够好，不需要分享我的经验，我的每一步都是脚踏实地，没有运气，没有天赋，有的只是付出巨大的努力去换回应得的那一点点回报。 听力和阅读我就不多说了，基础不太好的同学，这两项应该都不会好到哪里去，所以我自认自己非常的努力，我的作文和口语从比这两项要考得好很多。
听力：我后来是每天坚持听BBC，并且听写下来，听力的单词一定要会拼写，我很遗憾，考了几次每次都有低级的单词拼写错误，所以一定要拼写下来。 阅读：我阅读一直没很大的提高，剑桥的书做了很多遍，有时做了7，有时6，考试还偶尔考个5.5，问题不知出在哪里，但多看总是没错的，我考完后因为读材料和自己申请，觉得阅读提高很多，现在再去考不知道会不会提高点。 重点我想说说口语和写作，这是我能分享的成功经验。我雅思先后考了4次，但庆幸每一次都有收获，没有浪费一分钱。没有之前的失败，不会有最后的成功，所以不管考几次，一定要自己认真总结。 但4次里面，我的口语都不低于6，之后是6.5，最后是7，稳步提升。我的经验就是我从不怯场，可能和工作有关，我的沟通能力较强，比较胆大，这可能也是我胜算的原因，还有一点就是：我努力。我准备了几乎所有的话题，每天背2——3个小时，也就是说我保持说口语的状态each day,并且说的都是和雅思考试相关的内容。 但这个很难坚持，我告诉很多人，他们都表示去死也不可能坚持每天说3小时口语。但，你如果不坚持，随便准备个十来个话题，我保证你必败，除非你就是运气好，再无其他。
示波器使用方法步骤
示波器是一种用途十分广泛的电子测量仪器。它能把肉眼看不见的电信号变换成看得见的图像，便于人们研究各种电现象的变化过程。示波器的使用方法： 示波器，“人”如其名，就是显示波形的机器，它还被誉为“电子工程师的眼睛”。它的核心功能就是为了把被测信号的实际波形显示在屏幕上，以供工程师查找定位问题或评估系统性能等等。它的发展同样经历了模拟和数字两个时代 数字示波器，更准确的名称是数字存储示波器，即DSO（Digital Storage Oscilloscope）。这个“存储”不是指它可以把波形存储到U盘等介质上，而是针对于模拟示波器的即时显示特性而言的。模拟示波器靠的是阴极射线管（CRT，即俗称的电子枪）发射出电子束，而这束电子在根据被测信号所形成的磁场下发生偏转，从而在荧屏上反映出被测信号的波形，这个过程是即时地，中间没有任何的存储过程的。而数字示波器的原理却是这样的：首先示波器利用前端ADC对被测信号进行快速的采样，这个采样速度通常都可以达到每秒几百M到几G次，是相当快的；而示波器的后端显示部件是液晶屏，液晶屏的刷新速率一般只有几十到一百多Hz；如此，前端采样的数据就不可能实时的反应到屏幕上，于是就诞生了存储这个环节：示波器把前端采样来的数据暂时保存在内部的存储器中，而显示刷新的时候再来这个存储器中读取数据，用这级存储环节解决前端采样和后端显示之间的速度差异。
很多人在第一次见到示波器的时候，可能会被他面板上众多的按钮唬住，再加上示波器一般身价都比较高，所以对使用它就产生了一种畏惧情绪。这是不必要的，因为示波器虽然看起来很复杂，但实际上要使用它的核心功能——显示波形，并不复杂，只要三四个步骤就能搞定了，而现在示波器的复杂都是因为附加了很多辅助功能造成的，这些辅助功能自然都有它们的价值，熟练灵活的应用它们可以起到事半功倍的效果。作为初学者，我们先不管这些，我们只把它最核心的、最基本的功能应用起来即可。
雅思口语Part2参考答案之你去过的城市
雅思口语Part2参考答案之你去过的城市 一、参考范文 Sydney is my most favorite city among the cities I have visited. Sydney is the state capital of New South Wales of Australia. This city is situated in the bank of Tasman Sea and has around 4.6 million people. I have visited this city in 2008, after I finished my graduation and loved my stay there. Sydney had many attractive natural area, botanic garden, parks, and high rising buildings. This city has many heritage listed building that attracts the tourists and visitors. The Sydney Opera House is one of the most recognized landmarks in Australia and is a great place to visit. This city is known for the dynamic cultural hub and it has many famous museum, galleries and art galleries as well. Because of the great architecture, warm weather and hundreds of tourists attraction more than 11 million international and domestic tourists visit this city each year. I had been there for about 15 days and I really enjoyed everything about this city. I stayed at a 20 storied hotel that offered a really amusing sight views. The transportation system of the city is better than many other cities and I could have been maintaining the track and time of my schedules because of that. I loved being at open & wide spaces in the gardens and parks. People are welcoming and friendly there. A tourist can get plenty of helps both from people and the authority and can roam easily without any interruption. I saw 2/3 art museum and some cultural festivals and those were awesome.
雅思口语7分的7个规则和4个要点
雅思口语考试七规则，四要点 雅思口语考试七规则： 1. 心态 无论考什么试，心态都是很重要的。要有信心，不要怕。我见过很多学生，考口语的时候，出来说话都发抖。这有什么好怕?真是奇怪，就是进去说说话嘛。如果要工作也要面视嘛。不做作，给考官一个很好的第1印象。 2.当你进到考场里的时候，你坐下，然后考官说你不要紧张，等等。你不要说：“我一点也不紧张呀。”这个话说出来是很不礼貌的。反而，你说，谢谢，I feel morecomfortable now.也会收到以外的后果。 3. 不要去背一些机警的口语，这回限制你的发挥。看看是可以的，增加一下自己的思路，背的话，分就significantlydropped。希望大家记住这点。很重要。 4. 当考官问的问题，你不是很了解，或者不知道的时候，你要婉转的拒绝。For example, I can talksomething wot u know, and say: that wot i know about..., I have less experiencein these kind of .... . So could we change another one. I think I can talk umore. 等等类似的话。 5. 回答的答案不要大众化，要有自己的特色。外国人喜欢幽默和有个性的人。你如果一味的说谁都知道的事情，大家都会感到SLEEPYAND BORING。 6. 当你考完了以后，也不要去问考官关于自己的不足，等等。这个是违规的。 7. 大胆去说，如果发现不对，即时改更改，用i mean等词。 雅思口语考试四要点： 1. 流利度。这是最首要的，需要大家在雅思考试中说话时不要总是中断，嗯嗯啊啊的。这也是一个语言熟练度和思维的问题。如果你一句话说得很熟，就不会出现打梗;如果你思维开阔，就不会上句接不了下句。这需要大家以句子为单位操练(非单词)，同时看大量的英文材料扩展讲话素材。 2. 语音和语调。很多人发音不好似乎是先天的，且与当地的口音有关系。如果你普通话都讲不好，在雅思口语考试时发音也很难标准。语调方面，注意英语升降调的规律，说话尽量有升有降，抑扬顿挫，不要全部一个调调，听起来像机器人。在雅思口语准备过程中发音的训练靠多听多模仿，这方面的资源很多，不再赘述。 3. 词汇丰富度。这方面不需要过分夸大口语和书面语词汇的区别。但是雅思口语方面的词汇还是应该尽量积累的，尤其是习语和动词短语(不要告诉我你不知道是什么)。见过雅思的三个不同考官的经验告诉我，口语考试中，如果你能时常蹦出一个比较“高档”的词汇(如
示波器的使用方法
示波器的使用 【实验目的】 1.了解示波器的结构和示波器的示波原理； 2.掌握示波器的使用方法，学会用示波器观察各种信号的波形； 3.学会用示波器测量直流、正弦交流信号电压； 4.观察利萨如图，学会测量正弦信号频率的方法。 【实验仪器】 YB4320/20A/40双踪示波器，函数信号发生器，电池、万用电表。 图1实验仪器实物图 【实验原理】 示波器是一种能观察各种电信号波形并可测量其电压、频率等的电子测量仪器。示波器还能对一些能转化成电信号的非电量进行观测，因而它还是一种应用非常广泛的、通用的电子显示器。 1．示波器的基本结构 示波器的型号很多，但其基本结构类似。示波器主要是由示波管、X轴与Y轴衰减器和放大器、锯齿波发生器、整步电路、和电源等几步分组成。其框图如图2所示。
图2示波器原理框图 (1)示波管 示波管由电子枪、偏转板、显示屏组成。 电子枪：由灯丝H、阴极K、控制栅极G、第一阳极A1、第二阳极A2组成。灯丝通电发热，使阴极受热后发射大量电子并经栅极孔出射。这束发散的电子经圆筒状的第一阳极A1和第二阳极A2所产生的电场加速后会聚于荧光屏上一点，称为聚焦。A1与K之间的电压通常为几百伏特，可用电位器W2调节，A1与K 之间的电压除有加速电子的作用外，主要是达到聚焦电子的目的，所以A1称为聚焦阳极。W2即为示波器面板上的聚焦旋钮。A2与K之间的电压为1千多伏以上，可通过电位器W3调节，A2与K之间的电压除了有聚焦电子的作用外，主要是达到加速电子的作用，因其对电子的加速作用比A1大得多，故称A2为加速阳极。在有的示波器面板上设有W3，并称其为辅助聚焦旋钮。 在栅极G与阳极K之间加了一负电压即U K﹥U G，调节电位器W1可改变它们之间的电势差。如果G、K间的负电压的绝对值越小，通过G的电子就越多，电子束打到荧光屏上的光点就越亮，调节W1可调节光点的亮度。W1在示波器面板上为“辉度”旋钮。 偏转板：水平(X轴)偏转板由D1、D2组成，垂直(Y轴)偏转板由D3、、D4组成。偏转板加上电压后可改变电子束的运动方向，从而可改变电子束在荧光屏上产生的亮点的位置。电子束偏转的距离与偏转板两极板间的电势差成正比。 显示屏：显示屏是在示波器底部玻璃内涂上一层荧光物质，高速电子打在上面就会发荧光，单位时间打在上面的电子越多，电子的速度越大光点的辉度就越大。荧光屏上的发光能持续一段时间称为余辉时间。按余辉的长短，示波器分为长、中、短余辉三种。 (2)X轴与Y轴衰减器和放大器 示波管偏转板的灵敏度较低(约为0.1～1mm/V)当输入信号电压不大时，荧光屏上的光点偏移很小而无法观测。因而要对信号电压放大后再加到偏转板上，为此在示波器中设置了X轴与Y轴放大器。当输入信号电压很大时，放大器无法正常工作，使输入信号发生畸变，甚至使仪器损坏，因此在放大器前级设置有衰减器。X轴与Y轴衰减器和放大器配合使用，以满足对各种信号观测的要求。
雅思口语Part2常考话题：在学校里美好的一天
雅思口语Part2常考话题：在学校里美好的一天本文收集整理了雅思口语Part2常考话题：在学校里美好的一天。雅思口语Part2着重考察同学们的英语交流能力，同学们在备考阶段可以注意多积累素材，平时多模仿多练习，这样在考试中才不至于无话可说。 I was trying to think of my best day. You know, my life at school seems so long ago. I can remember an occasion when I won first prize in a singing contest, and I think that had to have been my best day at school. The competition was held outside the school, and we had a stage set up for each of us to sing. The sound quality was not very good since it was an outdoor competition, but I suppose that might have acted in my favour, since I really don't think I am that good of a singer. But anyway, I can remember feeling on stage as nervous as anything, and just closing my eyes and letting myself sort of float in my imagination. I imagined this was my profession, and I thought of myself as a famous person-but I can't remember who it was, it was so long ago. Anyways, after the song was finished I remember people were giving me quite a good applause. When my name was announced as the winner I felt like flying again. You know,' it was something that meant so much to me just to be on stage, but to actually also land first prize was something else. Now that I
雅思口语7分对于part1的要求
雅思口语7分对于part1的要求 如何提高雅思口语成绩?今天给大家带来了雅思口语7分对于part1的要求，希望能够帮助到大家，下面就和大家分享，来欣赏一下。 雅思口语7分对于part1的要求 众所周知，雅思口语考试一共分为3个部分，考试时间为11-14分钟，那么问题来了，如何在如此短的时间内“征服”你们的考官?不论他是面挂迷之微笑，亦或满目苍凉，还是摇头无奈，搞定他们分分钟不在话下。要问我口出狂言的底气在哪里，答案就在这篇*中。当童鞋们一听到口语7，不禁会纷纷惊厥，怎么做到的?其实就是一句话“漂亮的开头，华丽的结尾”。 在口语的三个部分中，part1无疑是大家留给考官们的first impression。虽说不能一语定乾坤，但是从印象分来说不得不引起大家的注意。从口语评判的四个维度分析来看，若想拿到7分，就得做到表达详尽，无明显困难，或不失连贯，具有一定灵活性地使用一系列连接词。灵活地使用词汇讨论各种话题，使用一些非常见的词汇及习语，对语体及词汇搭配有所认识，能够有效地进行改述;较灵活地使用一系列复杂的语法结构，虽然反复出现一些语法错误，但语句通常正确无误;发音表现出6分水平中所
有积极表现，但也表现出8分水平中部分积极表现。概括成一句话，就是“低错误率，高产出值”。在part1中，大家通常会被问到五大类题型：个人信息类、个人喜好类、休闲类、技能类、抽象类。若想一举将它们拿下，就要学会使用功能型结构词及万能语料。这就要求大家“先打扫干净屋子再请客人”，将脑海中固有的一些“口水话”全部摒弃，再给大脑注入新鲜的氧气和血液。譬如，当大家想表达因果关系时，不应一张嘴就是because，so，我们可以适当的使用for this reason，accordingly，as a consequence，on this account等诸如此类的口语表达;当想表达喜爱时，不能想当然就是I like，而应该多用用I’m fairly keen on、I’m really into、I simply adore、I am pretty fond of……，让表达不落入俗套。对于part1的问题，大多数还是关乎大家的个人信息以及个人喜好，所以回答起来也是驾轻就熟，相信答案的key words 大部分的鸭鸭们都是可以想到的，关键是如何将这些idea用两三句话完美无误的表达出来。需要注意几点：一是注意时态。明明问的是上周的活动，就不要再用一般现在时啦;二是注意句式的变化。不要一味依赖靠谱的简单句，认为祸从口出，就不敢多说，其实考官期待的是你主动与他们交流，尽可能多的描述事件的细节或者是给出相应的实例，增强答案的信服度，同时也可以增加答案的长度。譬如，in 20XX就可以变为in the year of 20XX;三是注意用词，避免cliché。尽可能使用一些高端大气上档次的词汇及词组，譬如，将nice替换成fabulous，terrific，marvelous
雅思口语part2文稿
Street that you like to visit_where, how often, what do you like to do, why you like there I’d like to talk about a street ,a gathering place of non government organizations.,which is located in the function of zhongnan road and zhongshan road in wuhan city in china .There are more than 50 ngo established and ran on this street so you can always see many energetic college volunteers passing out leaflets about caring aids children here or some street performance which are aim to hencing public’s environmental awareness.i often go to this street, about once a week to take part in some voluntary activities or visit my friends who works in a foundation there, besides, some education salons also attract me a lot, it feel so free to sit in the coffee bar on the street with a group of persons who all pays more attention to chinese basic organization. I thinks , this is a place that reflect my dream because i do really want to be a professional person work on public service to help children in remote areas to receive basic education for my strong belief that........ What sport you would like to try for the first time What, how, equipment, why you want to learn this I’d like to talk about GAONAO, a kind of Chinese traditional sport i’d like to learn. I want to learn this because more than 80percent of students in my university can play it well and i do really admire them. Besides, my boyfriend is a crazy player of gaonao so in order to create our common interest and play it with him, i plan to learn it. At last, i think this sport is so interesting which probably could attract many foriners to play, so i want to recommend and teach this chinese traditional sports to others when i study abroad which is beneficial for me to make friends. The only equipment used is a small foot bag and the playing method is very easy, you have to throw foot bag very high and run to receive it with another person by leg within 1mins. And two other persons would try to stop both of you. If your competitor receive the foot bag first rather than you , you would fail.i will learn it form my patient and professional boyfriend. A photo of yourself Where you took it When you took How,\ How you felt about it I’d like to talk a photo of myself by a selfie stick in a special spot, bathroom in my dorm, recording my most frustrating but bravest moment in my university. My most
黄瀚生雅思口语Part2话题
人物 —A good student A good student that I have studied with was Tom. Tom was my high school classmate and he was our class monitor. He always got top marks in our class. For example when most people scored a 60 on the test. Tom would always get 80 or 90. So his scores were always better than others. We studied together during the weekend at the library and during weekdays we studied together in the classroom. We were really good friends and we always help each other. I remember Tom would always help me with my English because it was my weakest subject. Through his help my English improved a lot. Besides studying, we also had many common interests such as doing sports and playing games. I think he was a good student because he was hardworking and diligent. In high school many students studied to 6pm and went home to play, but Tom would always study until 9 or 10. He puts in a lot more work than others so that’s why I think he is also a motivated person. Most importantly. I feel that he sets high standards fo r himself and that’s the reason for his success. --A good parent Someone I know who I think is a good parent is my mother. My mother is the matriarch of my family, she is a kind and understanding person. She has so much love in her that makes all the kids in my family love her. Although she is not the bread winner of the family, she makes many important decisions in my family. My father will often ask my mother’s opinion before he does something. To me my mom is like my friend, I can talk to her about everything, whether it’s about my relationship, my studies or my social circle. No one knows me better than my mom. My mother will always be there to give me encouragement and gives me constructive feedback. My mother is also a knowledgeable person, when I was young, whenever I had about my homework, she would always help me. She really sets a good example for me, I received lots of influences from her. I think she is the perfect example of a good parent. --A famous person A famous person who has impressed me was Steve Jobs. Steve jobs is the founder of Apple. I remembered the first time I knew about him was when I got my first apple product which was the Ipad. At that time I only knew him as the founder of Apple. As I started to use more and more apple products, I felt Jobs became closer to life. When he died, I read his biography and I started to admire him. He started as a college dropout with a dream and passion for greatness. He was an innovative genius who made products that would change our lives. His pursuit of perfection made Apple become a leader in the IT industry. What impresses me the most is that Jobs is a bold person. He is willing to do and try things that most people can only imagine. I think I learned a lot from Jobs and as a young person, I think we need to be like him. We often times only think but never take the initiative. So this is a famous person that has really impressed me. 地点