1
MULTIMEDIA TRANSPORT PROTOCOL AND
MULTICAST COMMUNICATION
Serge Fdida Laboratoire MASI-CNRS, Université Pierre et Marie Curie
4 place Jussieu, 7500
5 Paris, France
Tel. +33-1-44-27-30-58, Fax. +33-1-44-27-62-86
E-mail: Serge.Fdida@masi.ibp.fr
ABSTRACT
The emerging of high speed networks provides the infrastructure for handling a wide set of new applications, covering distributed multimedia cooperative features. In this framework, multipeer communication is a major service/protocol issue because most of these applications exhibit the need for such a functionality. Besides many functions and mechanisms, the semantics of transport layer multicast conversation has to be defined. We show that a new service semantic called statistical-reliable, in which the reliability is enforced when desired by applications, is of major interest for the high-performance networking paradigm. This new reliability semantic can be implemented using a protocol akin to the XTP bucket algorithm. The interest of the developed protocol is that 1) it can perform efficiently on top of wide area (for instance ATM-based) networks as well as LANs, 2) it provides a continuous reliability service from best-effort to all-reliable as a function of the application requirements, 3) it is able to handle group size from small to very large with only a slight increase of overhead, 4) it works for unicast communication. These functionalities provide an interesting and efficient protocol for covering the need of distributed multimedia applications.
1. INTRODUCTION
Multipeer communication defines the transfer of information units between several users, organized within a group structure. Multicasting or peer-to-multipeer exchange is designed for transferring information from a single source to a set of receivers known as the group. The multicast service is undoubtedly useful for distributed systems of the future. This service is currently under study in many standard protocols (ATM, Internet, Transport, Application). Multicasting offers significant performance advantages over multiple sequential unicastings in terms of efficient use of the network bandwidth, decreasing the elapsed time and increasing concurrency. It will thus rapidly become a preferred paradigm for many applications [Ngo91] such as resource finding [Aha88], replicated file system [Che85], distributed games [Ber85], distributed databases [Sto79], email distribution list [Sak85], routing table dissemination [Qui80] and computer conferencing [Agu86], etc.
The concept of multicast communications has received much recent attention. One can cite work carried out in standardization committees (ANSI, ISO, etc. [Coh91, Coc92, Mou92, ISO93, MPC95] and projects CIO [Mat93, Mil93], Berkom [Del93] for the definition of a multicast taxonomy, service and protocol. Although, most of the existing multicast algorithms are focused on the MAC or IP [Dee89], [Top90] layer. Some work already started on point-to-multipoint communications in ATM-based systems [Rob95]. Little attention was devoted to the development of multicast protocols at the transport layer [ISO88, Che88, PEI92, San92].
A transport layer multicast shall provide a simultaneous transfer of the same TPDU to a number of peer transport layer entities. In providing such a multicast service, the transport layer relies on the multicast capabilities provided by the underlying network. Multicasting can be achieved at different levels. It is natural at the MAC layer, also provided at the AAL layer (without error recovery), and can be made available at the network layer [Dee89] if required mechanisms are provided (connection set up, routing, resource management, etc.). When applied at the transport layer, functionalities to be used rely on the multicasting facilities provided at the lower layers, namely, either MAC, AAL or IP layer. Transport layer multicasting will be more easy to design if the underlying service provide an efficient multicasting facility; otherwise, some problems have to be solved such as packet replication, error recovery and routing. Other aspects needs definitely to be studied such as addressing and group management.
We focus in this paper on the design issues of a multicast transport protocol able to perform efficiently on top of networks with various characteristics. This study is based on the XTP3.6 multicast approach [PEI92] and some other protocols [Cla87, Che88, Min89, Wat89]. See [Doe90] for a survey of lightweight transport protocols.
In a modern transport protocol there are at least six procedures: connection management, data transfer, state/time synchronization, flow
control, rate control, and error control. Incorporating such procedures in a multicast transport layer imposes significant challenges and a new multicast protocol must be designed and integrated into the transport layer. One of the central issues associated with the development of the multicast transport protocol is error detection and recovery. The reliability semantic has a significant impact on the protocol complexity as well as the group size that increases overhead. We introduce a statistical-reliable multicast semantic that is able to cope with a wide set of application requirements and group size with a limited overhead. We then describe the basic design features of the associated protocol.
The paper is structured as follows. Section 2 introduces briefly the transport layer multicast taxonomy, semantic and model. The motivation for a Statistical-reliable semantic is presented in section 3, as well as the salient features of the proposed protocol for ensuring efficient reliable communication. Other important issues related to multicasting are discussed in section 4. The concluding remarks and future work is contained in section 5.
2. TRANSPORT LAYER MULTICAST
In this section, we briefly introduced some important issues of the multipeer/multicast environment that will be used in the remainder of the paper. Some key elements of the on-going multicast taxonomy definition are introduced. Then, we present the associated multicast service semantics that are used today as well as a model for the transport layer multicast.
2.1 Taxonomy
The taxonomy is of most importance because it defines a common vocabulary and framework to name and address multipeer communication. Works on that topic started a few years ago and are mainly discussed within the OSI standardization body [Mou92, ISO93, Mat93, MPC95]. We briefly introduce in the sequel some important elements of the taxonomy.
The group concept allows to define a set of entities as a single entity identified by a single group-name and group-address and whose membership in the group is defined by a rule, a set of rules or a list. A (N)-Multicast group is a set of (N)-entities that abide by the rule(s) for belonging to a group able to utilize multicast services. An (N)-enrolled-group is a set of entities, called members, which have completed the registration and activation procedures and therefore are in the position to be rached by the means of at least one (N)-group-name and (N)-group-address. A group can be static or dynamic depending on the fact that the criteria defining the group membership can evolve. A group has a known population when it is possible to identify the individual name or address
of every other member of the group. There are two sub-categories of known population: complete known population where every member of the group is able to determine the identity of every other member of the group and partial-known population where only a subset of the group is able to do so. A group has an unknown population where it is not possible to determine the identity of every member of the group. A (N)-group-association is an association established between members of an (N)-enrolled-group, and possibly (N)-entities not belonging to the enrolled-group, for the purpose of transfering data. The establishement of a (N)-group-association leads to the creation of a (N-1)-group-connection (connection-oriented-mode) or exists only during the instance of communication (connectionless mode). Within the (N)-enrolled-group membership, the members that have accepted to participate in a group-association are called participants and this set is called the Active-group. The Active-Group-Integrity (AGI) specifies the set of conditions concerning the active group which must be true in order for the group connection to be in the data transfer phase. When the AGI is no more satisfied, the group-association is either released or suspended until all conditions are satisfied again. For instance, a Quorum specifies that a minimum number of participants is required to consider that the AGI is satisfied.
2.2 Semantic
Within the transport layer, multicast association needs to support a wide variety of Transport Service (TS) user requirements. Thus, the semantics of transport layer multicast association needs to be defined. We present four categories for this purpose.
Best Effort Multicast provides a "best effort" sequential transport of a single variable length TSDU to a set of TS users. The service is best effort in that missing or corrupted TSDUs are not delivered or recovered. All-reliable Multicast ensures that the lost or damaged T P D U is retransmitted until the transmitter knows with absolute certainty that all receivers have correctly received it. k-Reliable Multicast defines that a successful transmission is achieved if at least a number of k (k We propose another reliable semantic stronger than best-effort multicast but weaker than all-reliable multicast called statistical-reliable in which the reliability is enforced when desired by applications. The point at which the reliability becomes unacceptable would be application dependent. The Statistical-reliable Multicast does not enforce absolute reliability and the multicast sender does eliminate the need for maintaining state of individual multicast receivers. Using this semantic, the multicast transmission is considered successful if none, some or all TS users receive the multicast data. As the transmitter is relieved of any concern with the states of receivers, there is no way to know whether or not all receivers have successfully received the multicast TPDU s. However, if a more stringent requirements on the reliability is needed, it can be implemented on top of this statistical-reliable multicast transport protocol, i.e. protocol that deals with reliability in an application dependent manner. Note also that this concept can be efficiently used in other environments with different requirements and objectives (for instance multipoint ABR). 2.3 Model of the Transport Layer Multicast Transport layer multicast is defined as the transfer of a transport service data unit (TSDU) which is received from the sending transport service user (TS-user) to a set of receiving TS-users. The data transfer is simplex and begins after the establishment of the transport layer multicast connection. The sender's transport layer entity prepares only a single copy of the transport protocol data unit (TPDU) that is designated as a multicast TPDU. This TPDU is then transferred to the sender network/link layer entity which is responsible for sending the incoming TPDU to the receivers of the group. Associated with a multicast association, the S-TSAP identifier is utilized to identify the sending TS-user and the G-TSAP is used to identify a set of destination TSAP s. The pair of S-TSAP/G-TSAP is mapped into a list of addresses at the network/link layer. We note that this mapping procedure is not however part of the transport layer functionality. According to this addressing scheme, a multicast connection is set up and maintained between a sender and a group of receivers such that the transfer of any data-bearing or status-request TPDU is multicast from the sender to the group. On the other hand, the transfer of any response TPDU is unicast back to the sender along an established connection between the individual receiver and the sender. The receivers should only generate response TPDU s when either: -specifically requested by the sender transport entity via status-request or data-bearing TPDU, or -explicitly announcing the request for retransmission. Clearly, the response TPDU contains only the announcement of the correctly received TPDU or the lost TPDU, and should not in any case contains the data-bearing TPDU. Figure 1 illustrates the model of the multicast transport layer connection described above. For the purpose of this paper, we assume that there is no transport connections established between any two receivers. It is worth noting that any design of a transport layer multicast should take as much advantage as possible of the facilities provided by the underlying network. The distribution of multicast services over point-to-point networks can be potentially costly if the participants must establish connections to any other participants, thus there is no coordination amongst receivers. Sender Receiver 1Receiver N 3. STATISTICAL RELIABLE MULTICAST 3.1 Motivation for a statistical-reliable service Applications have different reliability requirements that varies from all-reliable to best-effort type. On the other hand, they also exhibit other constraints or needs such as group communication in cooperative work. In multicast communication, reliability has a cost that depends heavily on the group size and dynamic. It is quite straightforward to design an efficient all-reliable multicast protocol as long as the group size remains manageable; otherwise, the overhead will increase dramatically as a function of the group size. The main reason is the need to monitor each single receiver to collect the state information of the multicast association. The purpose of the statistical-reliable semantic is to provide a continuous reliability service and to scale with group size (Figure 2). The statistical-reliable multicast does not enforce absolute reliability and the multicast sender does eliminate the need for maintaining state of individual multicast receivers. Using this semantic, the multicast transmission is considered successful if none, some or all TS users receive the multicast data. An important issue of such a service is to be able to assess the quality-of-service that it provides depending on the networking environment and protocol parameters. The idea for supporting this solution is not to provide to the service user a reliability of say x%, but to provide him with the highest reliability available. Performance studies of the designed algorithm [Fdi93], [Bra95], show that the quality-of-service provided by the protocol is either very good, or so poor that it can not work (due to buffer overflow). Statistical-reliable protocol appears in fact to be either unreliable (this should not appear!) or all-reliable with the benefit of a much lower cost and overhead than an all-reliable protocol. This behavior is due to the fact that there exists some communication situations where the application requirements (in throughput for instance)can not be sustained with the amount of available resources (mainly buffer and processing resources). A careful design and selection of protocol mechanisms will contribute to alleviate the communication overhead and increase the reliability level. Also, for some multimedia type of traffic, reliability is not required and the protocol can provide a best-effort service while disabling the heuristic. Reliability Figure 2: Reliability Semantic for Multicasting As a conclusion of this section, we claim that a well-designed multicast protocol with the statistical-reliable semantic can be efficiently used for multimedia cooperative applications and scale properly with group size. For this purpose, we design new mechanisms for error control in the next section. 3.2. Error Control in Statistical Reliable Multicast In an earlier paper [San92], the authors presented the problem of design of error control protocol for X T P -based reliable multicast communication. This paper describes a more efficient multicast transport protocol designed for tackling issues such as reliability, scalability and AGI management. Other consideration in this study were to operate the protocol over non natural broadcast networks. The basic control framework of the protocol is akin the bucket heuristic proposed in XTP3.6. The main features of the bucket protocol are summarized below [PEI92], [San92]. Figure 3 shows that a sender multicasts the data-bearing and control packets (in XTP parlance, DATA or CNTL packets) to a set of M receivers using a single group address . XTP assumes that the multicast sender has neither knowledge of all the receivers nor the individual addresses of all receivers. RECEIVERS M Network Figure 3: Multicast Operation in XTP The XTP 's multicast error control is based upon the concept that the sender periodically multicasts a CNTL [sync=k ] packet to the receiver set to which each receiver immediately responds by multicasting a CNTL [echo=k ] packet to all member of the group. Each receiver must copy the sync value from incoming CNTL [sync=k ] packet into the echo field of outgoing CNTL [echo=k ] packet returned to the sender. Sync-echo pair is used to correlate a request CNTL [sync=k ] and its associated response CNTL [echo=k ], this procedure is known as synchronizing handshake . Of course, in order to uniquely identify the buckets, the sync value must be incremented by one for each (re)transmission of DATA or CNTL [sync ] packet. This will keep sender and receivers synchronized with respect to state information. The CNTL [sync ] is used to solicit the status of the receivers and CNTL [echo ] is used to transfer "status information"about the receiver. Each "status information" may contain reception status, flow control, rate control, and round-trip time estimate , etc . Here,we focus only on the reception status which is represented by two variables rseq (received sequence number) and dseq (delivered sequence number). The dseq and rseq represent two kinds of acknowledgement in XTP3.6. The dseq value is used by the receiver to indicate one larger than the sequence number of the received DATA packet last delivered to the XTP user. The dseq value is the only information required to release the sender's input buffers. The rseq contains a value one larger than the largest monotonic sequence number of the received D A T A packet received without error. The rseq provides the retransmission information to the sender which is necessary to trigger retransmission, starting with the byte identified by rseq . Note that dseq is not a mandatory parameter and has been removed in XTP4.0. Since the sender is not aware of the individual addresses of the receiver set, it can not know from which receivers a burst of CNTL[echo] packet is received. A mechanism is required to efficiently interpret this burst of CNTL[echo] packets and to determine the time period that the sender should wait for collecting CNTL[echo] packets before updating its state. To accomplish these objectives, XTP specifies a heuristic known as the Bucket Algorithm kept at the sender. The buckets can effectively accumulate the CNTL[echo] packets coming from multiple receivers and then forward the summary of CNTL[echo] packets to the sender's state machine. In other word, a multicast sender that executes a bucket algorithm considers all the receivers as a single entity thus many receiver's retransmission requests are transformed into a single retransmission. We give in this section a specification of XTP's bucket error control mechanism. Once a multicast transfer is initiated, a sender is imposed to maintain a bucket list consisting of a series of buckets which correspond to a finite time period T p(T p might be assigned with the worst case estimate of network-roundtrip-time or greater as suggested in [9]). A bucket may correspond to a time window T w where its length will determine the interval between the generation of two consecutive CNTL[sync] packets initiated by the sender. The bucket k is created when the sender submits a CNTL[sync=k] packet. The bucket k will be used to store all response CNTL[echo=k] packets associated with CNTL[sync=k]. For a given sender, the total number of buckets n should be (T p/T w) buckets. It is clear that T p and T w are two design parameters to be tuned. At the moment when a new bucket is created and if all the bucket list is full, the oldest bucket (i.e. the one labeled with the lowest value of sync) must be released in order to create a new one. Note that at this point in time, the sender's state should also be updated by applying the minimum values of dseq and rseq over all the buckets in the bucket list. Then the sender begins retransmitting with the byte identified by rseq and releases all input buffers containing data whose sequence numbers are less than the dseq value. The same action will take place each time the bucket is recycled. A performance analysis of the bucket algorithm was done in [Fdi93], [Bra95] and discusses the influence of the above parameters on the protocol efficiency and reliability. In the following, we extend the basic features of the error control protocol in the following directions: i) scalability issues, ii) protection against slow receivers and AGI management, iii) efficient processing of the bucket list. Other aspects such as filtering are also briefly addressed. https://www.doczj.com/doc/2115031484.html,e of NACK Strategy In Negative A CK nowledgement (NACK) protocol, it is the receivers' responsibility to detect data packet losses and recover from them. This scheme is more appropriate for a high performance with low error rate broadband environment, therefore for multicast communications. The main reasons for this: (i) the NACK protocol detects faulty/lost packets and performs retransmission requests as quickly as possible thereby keeping the average packet delay low, (ii) the NACK strategy reduces the amount of control packet exchanged between systems, only data that is lost need to be acknowledged, and (iii) due to the fewer packet exchanges, the NACK based approach should result in lower processing overhead. There are, however, some inherent drawbacks of this scheme: (i) lack of efficient buffer management. The sender cannot release the packets from its buffers even if they have been received correctly by all receivers, (ii) it cannot detect receivers' failures, (iii) the receivers may have to wait for an unbounded time to detect the loss of the last data packet(s), and (iv) it works well only if the environment does not reorder packets. The first three issues can be overcome by introducing the sender based acknowledgement strategy discussed in the next subsection. The last issue will not appear in an ATM-based environment [Onv94] that is our target underlying network. At any receivers, a gap in sequence number implies a missing packet. Then, the corrupted receivers should immediately generate the NACK messages. The NACK messages need not be repeatedly transmitted by these corrupted receivers. If the NACK messages are lost, this will not violate the protocol. The succeeding sender based acknowledgement messages (described in the next subsection) will eventually update the record correctly. Note that in this study the number of receivers simultaneously missing their data is assumed to be very rare, thus the arrival of the back-to-back NACK messages at the source would be negligible. If this assumption is not verified, then the application requirements can not be met according to the network resources availability. It is worth to mention that the utilization of Forward-Error-Correction (FEC) techniques is very attractive in high-bandwidth networking environment because it avoids retransmissions while increasing bandwidth requirements. However, the main cause for errors is buffer overflow that might render FEC inefficient, especially if successive packets from the same connection get lost. 2.Sender based Acknowledgement Policy In conjunction with the N A C K scheme, the sender based acknowledgement strategy may be used to efficiently signal the sender to release the buffers and to probe the status of the group when the protocol operates under normal conditions. The sender periodically issues status-request packets to the receiver group to solicit receivers' state information. Upon receipt of the status-request packets, the receivers generate the acknowledgement reply-messages returned to the original sender. The multicast sender uses these reply-messages to release its buffers. Generally speaking, multicast by its very nature is self synchronizing. This means that all multicast receivers get the status-request packets at roughly the same time, and thus respond at almost the same time. This can lead to congestion at the multicast source (implosion problem), with many of the replies being lost. It is very important to note that the replies that are dropped may be from the receivers who are missing the data. In this case the multicast sender will not be aware, and therefore source congestion can make the statistical reliable multicast unreliable. To avoid this, a multicast transport protocol should have some sort of mechanism for minimizing the number of receiver responses and distributing such responses in time to cope with scalability issues. Damping and slotting where proposed in XTP but are not adapted to non-broadcast networks. One method for reducing the reply messages requires that the recipients only respond intermittently if they do not detect any packet loss. The common method for increasing the minimum spacing between replies is simply to have each response be returned at some random time by recipients using an exponential back-off algorithm. Hence, a receiver will only reply to a control packet every n requests, n following the exponential back-off value, which is bounded by a maximum value and reset on an error condition (NACK transmission). It is expected that the intermittent response and back-off schemes would effectively eliminate the source congestion and the peak processing demand at the multicast sender. 3.Protection against slow receivers In unicast, the association is useless if the packets cannot be delivered to the receiver, thus sender buffers should not be released until the receiver acknowledges the packets. However in multicast, the slowly responding receivers that miss data may not keep requesting retransmissions according to the AGI. If some protection is not built into the protocol, this can degrade the performance of all other recipients. Thus after a certain number of retries that allows the slow receivers to ensure reliable delivery, the sender buffers should be released. This scenario of a slow receiver within a group association is the one that is most likely to occur due to different receiver capabilities and resources. In this situation, the decision to drop the misbehaving user depends on the AGI that can lead either to disconnect this receiver or to release or suspend the association if this receiver is a key element of the application. In dealing with the problem of slow receiver(s), a method should be provided to inform receivers that the missing data is no longer available and thus can not be recovered. The slow receiver(s) may then leave the multicast association when it get too far behind. The proposed method consist in monitoring the connection throughput at the sender site. If the throughput gets under some QoS thresholds, a specific control packet (Monitoring packet) with the minimum accepted rseq value is sent to the multicast group. Each receiver reacts to the Monitoring packet according to their status as defined in the AGI condition. If a receiver can not sustain the minimum rate then it will disconnect itself from the connection if it is compliant with the AGI condition, otherwise, if the minimum rate can not be achieved then a disconnection request will be issued by the sender because the QoS requirements can not be guaranteed. Other scenarios might be envisaged to manage the AGI. 4.Bucket Algorithm The provision of a statistical reliable multicast facility involves the following functionalities at the sender: (i) to collect the incoming CNTL packets into a single representative record, and (ii) to determine the time period that the multicast sender should wait for collecting the incoming CNTL packets before updating its state. Buckets age over time; when the bucket structure is full, the oldest bucket will be replaced by the newest bucket and the sender's state will be updated accordingly. Method of coalescing the replies described in this paper differs from the one presented in [PEI92, San92], in that the retransmission information is stored in each bucket. With a significant number of buckets, the approach proposed in [PEI92, San92] could be time consuming since the multicast sender has to merge the bucket information into a single record before each retransmission. Based on a global record, retransmission conditions can be set up. The proposed protocol also employs a more elaborate retransmission rules to ensure that the premature or delayed retransmission(s) will not occur. Some implementation details for our error control protocol discussed above are presented in the annex. 4. OTHER MULTICAST ISSUES 4.1. Filtering The scalability issue can also be addressed while adding some functionalities within the intermediate nodes [Car94]. The principle is to design a Group Communication Server (GCS) that is responsible for performing error control, scalability and filtering. The GCS is located in an intermediate node of the multicast tree and is managing a sub-tree. Retransmissions are originating from the GCS avoiding unnecessary retransmissions over common branches of a multicast tree and reducing delays introduced by retransmissions from the source. A sender deals only with the GCS instead of communicating simultaneously with the set of receivers. Finally, the GCS can be seen as a way to provide different quality of service to outgoing data streams, providing filtering capabilities. Although targeting other problems, a similar approach was developed in the network layer while introducing gathering/filtering functions [Raj92, Zha93]. An important parameter is the cost of such functions that might be more efficient to provide at the network layer than at upper layers. They have to be combined with other approaches such as the one we proposed at the transport layer. Another important issue is the one related to the impact of the multicast tree topology. The cumulative loss probability seen by a source may be significant even if the buffer overflow seen at the switches and receivers is quite low [Bha94]. The cumulative loss probability is also very sensitive to the tree topology. 4.2. Multimedia multicasting We defined a Multimedia connection (Figure 4) as a bundle of monomedia connections, each requesting a given quality of service. Thus,a multicast monomedia transport connection will operate as described above for a transport connection, using the statistical reliable semantic according to the application needs. If the application does not have any reliability requirement, then the bucket algorithm is simply disabled. A multimedia stream is composed of a set of monomedia transport connections, each with its own quality of service. The bundle of connections is managed to provide other services such as synchronization or partial order service [Diaz95] that enable to coordinate the different streams within a given bundle according to the application for play-out purposes. Out-of-sequence delivery of packets results in a significant improvement in throughput. Partial order service provides the ability to deliver the packets of a given bundle in an ordering which is not a total ordering, allowing thus for out-of-sequence delivery and resulting in higher performance. Other ordering issues [Bir91] , [Gar91], are of importance but are not covered in this paper. Monomedia Connection Multimedia Connection Figure 4: Multicast Multimedia Transport Connection This protocol will be implemented in the French join CNET-CNRS Project named CESAME [Ann94]. 5. CONCLUSION Multicast or peer-to-multipeer transmission is becoming a major issue for supporting distributed multimedia applications. Today, this problem is tackled within both international bodies and projects because it appears to be a mandatory task to define multicast/multipeer service and protocols at different layers. In this paper, we introduce the service semantic called "statistical reliable" to cope with scalabilty issues while keeping a high level of reliability (related to error recovery issues). A protocol is designed to support the statistical reliable semantic, specifically addressing ATM based networks as well as other important features such as AGI management. The protocol emphasized a high degree of reliability in multicast data delivery with fast and efficient error recovery procedures. If the parameters are correctly sized, we can expect to get an all reliable quality-of-service while using the statistical reliable protocol with the benefit of low processing and bandwidth overhead. We conclude with a discussion on related issues such as filtering, impact of topology and multicast multimedia transport connection. 6. REFERENCES [Agu86]Aguilar L. et. al., "Architecture of a Multimedia Teleconferencing System", Proc. of ACM SIGCOMM, pp. 126-135, 1986. [Aha88]Ahamad M. et. al., "Using Multicast Communication to Locate Resources in a LAN-Based Distributed System", Proc. of IEEE 13th. Conference on Local Computer Networks, pp. 193-202, October 1988. [Ann94]Annals of Telecommunications, The Cesame Project, Tome 49, N°5-6, pp. 217-356, May-June 1994. [Ber85]Berglund E.J., Cheriton D., "Amaze: a Multiplayer Computer Games", IEEE Software, vol. 2, no. 3, 1985. [Bha94]Bhagwat P., Mishra P., Tripathi S.K., "Effect of Topology on Performance of Reliable Multicast Communication", Infocom94, pp.602-609, 1994. [Bir91]Birman K. , Schiper A. and Stephenson P., "Lightweight Causal and Atomic Group Multicast", ACM Transactions on Computer Systems, vol. 9, no. 3, pp. 272-314, August 1991. [Bra95]Brandwajn A., Fdida S., "Modeling and Analysis of a Transport Multicast Protocol", Laboratoire MASI, France, September 1995. [Car94]Carle G., "Adaptation Layer and Group Communication Server for Reliable Multipoint Services in ATM Networks", in Steinmetz (Ed), Multimedia: Advanced Teleservices and High-Speed Communication Architectures, Springer, pp. 124-138, 1994. [Che85]Cheriton D., Zwaenepoel W., "Distributed Process Groups in the V Kernel", ACM Transactions on Computer Systems, vol. 3, no. 2, pp. 77-107, May 1985. [Che88]Cheriton D. , "VMTP: Versatile Message Transaction Protocol", RFC 1045, June 1988. [Cla87]Clark D. , Lambert M., Zhang L., "NETBLT: A Bulk Data Transfer Protocol", Request For Comments, RFC 998, March 1987. [Coc92]Cocquet P., Diot C., "Enhanced Transport Service", Proposed Contribution to ISO/IEC JTC1 SC6/WG4, June 1992. [Coh91]Cohn M., "High Speed Transport Protocol (HSTP) Specification", Contribution to ISO/IEC JTC1 SC6/WG4 on the High Speed Transport Protocol, September 1991. [Dee89]Deering S., "Host Extension for IP Multicasting", RFC 1112, August 1989. [Del93]Delgrossi L., Sandvoss J. (ed.), "The BERKOM-II Multimedia Transport System (MMT), Version 3.0", August 1993. [Dia95]Diaz M., Drira K., Lozes A., Chassot C., "Definition and Representation of the Quality-of-Service for Multimedia Systems", IFIP International Conference on High Performance Networking (HPN'96). Palma (Spain), September 1995. [Doe90]Doeringer W.A. et. al., "A Survey of Light-Weight Transport Protocols for High-Speed Networks", IEEE Transactions on Commmunications, vol. 38, no. 11, pp. 2025-2039, November 1990. [Fdi93]Fdida S., Santoso H., "XTP Bucket Error Control: Enhancement and Performance Analysis", TriCom' 93, Raleigh, USA, October 1993. [Gar91]Garcia-Molina H. and Spauster A., "Ordered and Reliable Multicast Communication", ACM Transactions on Computer Systems, vol. 9, no. 3, pp. 242-272, August 1991. [ISO88] ISO-8072, Information Processing Systems, Open Systems Interconnection, Transport Service Definition, 1988. [ISO93]ISO/IEC, JTC1/SC6/WG4, Draft Multicast Taxonomy of Multicast Operation, 10.31.1993. [Mat93]Mathy L., Leduc G., Bonaventure O., Danthine A., "A Group Communication Framework", CIO RACE Project 2060, R2060/ULg/CIO/IN/P/005, December 1993. [Mil93]Miloucheva I., "Specification of Enhanced Protocol Facilities for Multicast and Broadcast", CIO RACE Project 2060, R2060/TUB/CIO/DS/P/003/b1, October 1993. [Min89]Minet P., "Performance Evaluation of GAM-T-103 Real Time Transfer Protocols", Proc. of IEEE Infocom 1989, Ottawa, April 1989. [Mou92]Moulton J. , Proposed USA Contribution to SC6 on Multicast Transport Protocol, July 1992. [MPC95]Multi-Peer Communication Architecture, ISO/IEC Draft 7498-5, SG7-SC21, 1995. [Ngo91]Ngoh L.H., "Multicast Support for Group Communications", Computer Networks and ISDN Systems, vol. 22, pp. 165-178, 1991. [Onv94]Onvural R.O., "Asynchronous Transfer Mode Networks: performance Issues", Artech House, 1994. [PEI92]Protocol Engines Inc., "XTP Protocol Definition", Version 3.6, 11 January 1992. [Qui80]Quillan Mc. et. al., "The New Routing Algorithm for the Arpanet", IEEE Transactions on Commmunications, vol. 28, no. 5, May 1980. [Raj92]Rajagopalan B., "Reliability and Scaling Issues in Multicast Communications", Sigcomm'92, pp188-198, 1992. [Rob95]Roberts L.G., "Point-to-Multipoint ABR Operation", ATM Forum /95-0834, August 1995. [Sak85]Sakata S., Ueda T., "A Distributed Interoffice Mail System", IEEE Computer, vol. 13, no. 10, pp. 106-116, October 1985. [San92] Santoso H., Fdida S., "Transport Layer Multicast:An Enhancement for XTP bucket algorithm", 4th IFIP High Performance Networking (hpn'92), Liège, Belgique, décembre 1992. [San94]Santoso H., Fdida S., "Transport Layer Statistical Multicast based on XTP Bucket Algorithm", Annals of Telecommunications, The Cesame Project, , Tome 49, N°5-6, pp. 257-269, May-June 1994. [Sto79]Stonebreaker M., "Concurency Control and Consistency of Multiple Copies of Data in Distributed INGRESS", IEEE Transactions on Software Engineering, pp. 188-194, May 1979. [Top90]Topolcic C., "Experimenal Internet Stream Protocol, Version 2, ST-II", RFC 1190, October 1990. [Wat89]Watson R.W., "The Delta-t Transport Protocol: Features and Experience", Proc. of IFIP Workshop on Protocols for High Speed Networks, pp. 3-18, Zurich, 1989. [Zha93]Zhang L., Deering S., Estrin D., Shenker S., Zappala D., "RSVP: A New Resource ReServation Protocol", IEEE Networks. September 1993. ANNEX Implementation Details Rather than designing a new packet structure for implementing our multicast error control algorithm, we intentionally use the existing XTP packet format without any change. Below we present some procedures at the sender/receivers relevant to the implementation of a statistical reliable transport layer multicast. 1. Multicasting sender packets and Unicasting receiver response packets A sender multicasts the data-bearing and control packets (in XTP parlance, DATA or CNTL packets) to a set of M receivers using a single group address G-TSAP. The response CNTL packets are unicast from the receivers to the sender. This necessarily needs that every receiver knows the transport address of the sender. The sender is therefore identified by S-TSAP. 2. Generation of Status REQuest (SREQ) packets at the sender Periodically, the multicast sender makes the acknowledgement requests by use of the SREQ bit in the header; for this purpose the sender may issue either DATA[sync=k] or CNTL[sync=k] packet with the SREQ bit set. However unlike in XTP, the CNTL packet should never be transmitted if there is an unsent DATA packet available at the sender data queue. It almost seems counter-productive to interrupt the transmission of DATA for sending CNTL packets; a DATA packet with SREQ bit set may serve the same purpose. This will greatly reduce: (i) the number of packets transmitted, and (ii) the source CPU processing demand. 3. Generation of response CNTL packets at the receivers Receivers may issue two types of CNTL packets for acknowledgement: CNTL[echo=k, FASTNAK=1] or CNTL[echo=k, FASTNAK=0]. The FASTNAK bit is used to distinguish between unsolicited (FASTNAK=1) or solicited (FASTNAK=0) response CNTL packets. The multicast receiver generates a CNTL[echo=k, FASTNAK=1] packet whenever a gap exists; the receiver must copy the sync value of the last in sequence DATA packet correctly received into the echo field of outgoing CNTL[echo=k, FASTNAK=1]. The receiver issues the CNTL[echo=k, F A S T N A K=0] packet in response to any DATA[s y n c=k] or CNTL[sync=k] packet with SREQ bit set; the echo value of response packet should be set with the sync value of the corresponding control request message. Both solicited and unsolicited responses are unicast to the original multicast sender, and all two are used to transfer "status information" about the receivers. Each "status information" may contain reception status, flow control, rate control, etc. In this paper, we focus only on the reception status which is represented by two variables rseq (received sequence number) and dseq (delivered sequence number). 4. Sync Adjustment The sync and echo are two variables used to synchronize both the sender and receiver protocol state machines. A value sent in the sync field by sender is returned via the echo field by the receiver. This way, the sender can make certain assumptions about the state of the receiver. The values sent in the sync field must be unique and incremented on DATA packets as well as CNTL packets. The sync will also be used for bucket labeling described later in this section. Note that the XTP definition makes it clear that sync is not intended to be incremented for CNTL packets in either unicast or multicast cases. The way how the sync field is interpreted in XTP is rather different from the one used in this paper. 5. Collecting acknowledgement CNTL packets at the sender For every time a SREQ DATA[sync] or SREQ CNTL[sync] packet is submitted, the multicast sender creates a new bucket. This newly created bucket is labeled using the value of sync contained in its corresponding SREQ DATA[sync] or SREQ CNTL[sync] packet. Therefore, a range of sync values sent out in SREQ DATA[sync] or SREQ CNTL[sync] packets will identify a series of buckets. At the moment when a new bucket is created and if all the buckets are full, the sender's state is updated, then the oldest bucket (i.e. the one labeled with the lowest value of sync) must be emptied and replaced by the newest one. Each bucket contains the following variables: 1. label, it holds the sync value carried in the SREQ DATA[sync] or SREQ CNTL[sync] packets. 2. lseq, this variable contains a value one larger than the largest sequence number of DATA packet ever (re)transmitted as known at the beginning of a bucket creation. 3. send_time, this variable saves the current value of time when the SREQ DATA[sync] or SREQ CNTL[sync] packet is sent. This variable is used to calculate the Round Trip Time (rtt) which is estimated by subtracting "send_time" from the arrival time of a solicited response CNTL packet at the sender. By including "time" variable into a bucket, a multicast sender is not needed to send "time" (as in XTP [9], "time" variable can only be transported via CNTL packet) to get an accurate estimate of RTT. This will therefore increase the protocol efficiency. For every time, a solicited NON-FASTNAK CNTL[echo] packet is received from receiver, the echo value of this packet will be associated with the bucket label and if they are match, then the status information (i.e. rseq and dseq) carried in this packet will be used to update the retransmission variables contained in the global record. In order to prevent any unnecessary retransmissions, the state information used to update the sender state must not be out-of-date [26]. Note that any received solicited response CNTL[echo] packet with a echo value that cannot be associated with any bucket label must be ignored. On receipt of an unsolicited FASTNAK CNTL[echo] packet, the state information (i.e. rseq and dseq) carried in this packet should be used to update the variables of the global record, provided that this state information is still up-to-date [26]. It is important to note that upon receiving a FASTNAK response the data will not be retransmitted immediately. The retransmission is delayed until the next bucket expiration time somewhat to filter the duplicates. 6. Procedure for updating the global retransmission record In specifying the updating rules, we make use the following variables maintained in a global record as illustrated in Figure 5: 1. min_rseq is a variable containing the minimum value of rseq selected from the incoming solicited or unsolicited CNTL[echo] packets assuming that these packets are not obsolete. 2. min_dseq is a variable containing the minimum value of dseq selected from the incoming solicited or unsolicited CNTL[echo] packets assuming that these packets are not obsolete. 3. uncover_rseq is a variable containing the value of uncovered sequence number rseq. 4. max_rtt is a variable containing the maximum value of the estimated rtt. 5. saved_min_rseq, saved_min_dseq and saved_max_rtt are three variables, respectively used to store the current values of min_rseq, min_dseq, and max_rtt. 6. saved_sync is a variable used to store the current value of sync. 7. rt_flag is a boolean variable (retransmission flag) used to indicate that the retransmission is necessary and not redundant. 8. recovery_impossible is a boolean variable used to indicate whether the recovery is still possible. 9. start_to_collect_rseq, start_to_collect_dseq start_to_calculate_rtt, and start_to_collect_uncover_rseq are four dummy boolean variables, respectively used to initialize the values of min_rseq, min_dseq max_rtt, and uncover_rseq. Let us now apply the global variables defined above to the updating procedures. At each arrival of a CNTL[echo] from the receivers the following sequences of checks are performed: Sender's input buffers Saved_min_dseq Saved_min_rseq increasing sequence numbers T w T p Figure 5: Bucket Error Control ? If FASTNAK reply (i.e. CNTL[echo ] with FASTNAK bit set) do the following checks: * If (rseq > saved_min_dseq) then Begin If (echo>saved_sync) then Begin rt_flag=yes;If start_to_collect_rseq=no then Begin start_to_collect_rseq=yes;min_rseq=rseq:End Else Begin If rseq * If (rseq 高压蒸汽灭菌锅操作规程 一、操作步骤 1、开盖：向左转动手轮数圈，直至转动到顶，使锅盖充分提起，拉起左立柱上的保险销，向右推开横梁移开锅盖。 2、通电：接通电源，此时欠压蜂鸣器响，显示本机锅内无压力（当锅内压力升至约0.03Mpa 时蜂鸣器自动关闭），控制面板上的低水位灯亮，锅内属断水状态。 3、加水：将纯水或生活用水直接注入蒸发锅内约8升，同时观察控制面板上的水位灯，当加水至低水位灯灭，高水位灯亮时停止加水。当加水过多发现内胆有存水，开启下排汽阀放去内胆中的多余水量。 4、放样：将灭菌物品仪器堆放在灭菌筐内，各包之间留有间隙，有利于蒸气的穿透，提高灭菌效果。密封：把横梁推向左立柱内，横梁必须全部推入立柱槽内，手动保险销自动下落锁住横梁，旋紧锅盖。 5、设定温度和时间：按一下确认键，进入温度设定状态，按上下键可以调节温度值，再次按下确认键，进入时间设定状态，按左键或上下键设置需要的时间，再次按动确认键，设定完成，仪器进入工作状态，开始加热升温。 6、灭菌结束后，关闭电源，待压力表指针回落零位后，开启安全阀或排汽排水总阀，放净灭菌室内余气。若灭菌后需迅速干燥，须打开安全阀或排汽排水总阀，让灭菌器内的蒸汽迅速排出，使物品上残留水蒸气快速挥发。灭菌液体时严禁使用干燥方法。 7、启盖：同第一步。 二、注意事项 1、堆放灭菌包时应注意安全阀放汽孔位置必须留出空气，保障其畅通，否则易造成锅体爆裂事故。 2、灭菌液体时，应将液体灌装在耐热玻璃瓶中，以不超过3/4体积为好，瓶口选用棉花纱塞。 3、本器尽量使用纯水，以防产生水垢。 动物微生物生实训室 生物显微镜操作规程 一、操作步骤 1、将所需观察的标本放在工作台上卡夹住。 2、将各倍率物镜顺序装于物镜转换器上，目镜插入目镜筒中。 3、操作时将标本移动到工作台中间，先用10×物镜观察，打开电源开关把亮度调节钮移至适当位置，转动粗调手轮将工作台上升到能见到标本的影形，转动微调手轮即可得到清晰的物象。光亮的选择可转动聚光镜架手轮使聚光镜上升或下降，再调节可变光栏，使改变交栏孔径以便获得适合各类细节标本的照明亮度。（为光源和观察需要备有滤色片供使用，滤色片装于可变光栏下部的托架上，可得到选择的色泽。如用低倍物镜观察液体及用高位物镜时感到光源太强时，可将毛玻片装于可变光栏下部托架上使用，可得到暗淡光线）转动工作台上纵向手轮，使工作台同标本作前后方向移动，转动横向手轮使标本作左右方向移动。将所需观察的物体移至中心观察，然后转至高倍物镜或油浸物镜进行观察（用油镜时需加注香切片物体）仍能看见物体的影象，需再转动微调手轮即可达到清晰的物象。例用完毕只要转动粗调手轮将工作台下降到底，再将亮度调节钮移到最小亮度处最后关上电源开关。 4、调节亮度调节钮可以改变灯泡发光亮度以获得最佳亮度。 5、更换灯泡方法：把钨卤素灯插入灯座，然后将它插入底座下方插口处即可。 标 准 操 作 规 程 (Standard Operating Procedure) 实验动物隔离检疫 标准操作规程 Standard Operating Procedure for ethical review system of Laboratory Animal 制定者 Author 兽医办公室/兽医师 Veterinary office 审查者 Reviewer 肖春兰 动物质量办公室/技术员 Technican of Animal Quality Lab 审查者 Reviewer 王婧 办公室主任 Office Director 机构负责人批准Facility Manager Approver 周正宇 中心最高领导者 Top Manager of the Center 修订记录（Revision History） 发放记录（Revision History） 1、目的(Purpose) 规范苏州大学实验动物中心实验动物隔离检疫标准操作规程。 2、适用范围 (Scope) 此文件适合苏州大学实验动物中心所有动物隔离检疫。 3、职责(Responsibility) 3.1 文件编写、批准人员对该文件编写和修改的有效性负责。 3.2 文件编写人员负责根据此文件，对担任实验动物隔离检疫的工作人进行 培训和指导。 3.3 担任实验动物隔离检疫的工作人，负责执行本标准操作规程，并负责反馈 相关信息。 4、操作规程(Procedures) 凡自主采购且来源为不是免检单位（见附表1）的SPF级实验动物，均需在进入我中心SPF动物房前，接受隔离检疫。 4.1 提交自购申请 凡自主采购实验动物的个人及单位，均需向我中心提交自购实验动物申请。 4.1.1 登陆动物管理系统 科研计划人以科研计划用户身份登陆苏州大学实验动物管理系统。 4.1.2 提交动物订购申请 科研计划人点击动物订购项，添加动物订购申报。 4.1.3 注意事项 动物实验标准操作规程 一、人流线路工作人员进入第一更衣室→脱去个人外衣（饰品）放入衣柜→脱去蓝色拖鞋后(→淋浴室)进入第二更衣室→穿上红色拖鞋→手消毒（0.1%新洁尔灭）→按操作规范穿上无菌连体衣，戴上一次性无菌口罩、手套→进入缓冲间→风淋→进入清洁走廊→进入洁净区域工作→进入饲养室或检疫室→所有工作结束后→进入污物走廊、脱掉红色拖鞋→进入缓冲间→穿上蓝色拖鞋，进入洗刷、消毒区域，取掉手套、口罩、连体衣，分别放入指定的回收桶中→进入第一更衣室，穿上个人衣（饰）→出屏障系统。 二、物流线路物品→高压蒸汽灭菌器或传递窗或渡槽→消毒传递间→清洁准备室→清洁走廊→饲养室或动物实验室→污物经包装处理→（后室缓冲间）→次清洁走廊→气闸（缓冲间）→清洗消毒室→外部区域。 三、动物流线路外来SPF级实验动物→传递窗→消毒传递间→清洁准备室→清洁走廊→饲养室或动物实验室→生产繁殖或实验处理后→（后室缓冲间）→次清洁走廊→气闸（缓冲间）→清洗消毒室→外部区域。 四、空气（压力）流程新风口→空气初效过滤器→空气中效过滤器→空气高效过滤器→屏障系统内各区域并产生压力梯度: ①清洁走廊→饲养室或动物实验室→（后室缓冲间）→次清洁走廊→气闸（缓冲间）→室外。②(进入屏障系统内)气闸(缓冲间)→第2更衣室→淋浴室→第1更衣室→室外。③(离开屏障系统内)气闸(缓冲间)→清洗准备间 (消毒室)→外部区域。④消毒传递间→传递窗→清洗消毒室→外部区域。 五、注意事项为了防止空气倒流，必须调节并保持4.4中各区域间的压力梯度，同时，必须时刻保证2更衣室、消毒传递间、气闸（缓冲间）至少20Pa的正压。 六、质量记录动物/物品传递管理记录表、动物饲养环境参数与异常情况记录表。 抗肿瘤药物体内筛选标准操作规程概述： 抗肿瘤药物是指能够直接杀伤或抑制肿瘤细胞生长或增殖的一类药物，作用机制包括抑制肿瘤细胞核酸或蛋白质的合成、干扰大分子物质代谢、干扰微管系统、抑制拓扑异构酶等。 本操作规程包括与抗肿瘤药物申请临床试验和申请上市有关的非临床有效性和安全性研究的内容，其中着力强调非临床有效性和安全性之间的关联性，以及非临床研究和临床试验之间的关联性。旨在一方面为抗肿瘤药物的非临床研究提供技术参考；另一方面，通过技术要求引导科学有序的研发过程，使国内此类药物的研发更趋规范和合理。 本操作规程仅代表目前对抗肿瘤药物非临床研究的一般性认识。具体药物的非临床研究应在本指导原则的基础上，根据药物的自身特点制订研究方案。 研究目的： 建立一套包括抗肿瘤药物体内作用的药效学研究和评价体系及相应的标准操作规程以 及抗肿瘤药物安全性和作用新机制的研究。 ①有效性研究 抗肿瘤药物有效性研究的目的主要在于探索受试物的作用机制、作用强度、抗瘤谱等，为之后的安全性评价以及临床试验中适应症、给药方案的选择提参考信息。 ②安全性评价 安全性评价的目的主要包括：（1）估算 I 期临床试验的起始剂量；（2）预测药物的毒性靶器官或靶组织；（3）预测药物毒性的性质、程度和可逆性；（4）为临床试验方案的制订提供参考。 研究计划： (a)小鼠急性毒性测试 按照急性毒性测试的常规方法，选用昆明种小鼠，通过腹腔注射方式给药，测定体外抗肿瘤活性突出的化合物的半数致死量（LD50），参考给药小鼠体重变化情况，评价化合物的急性毒性，并确定小鼠体内抗肿瘤活性测试的给药剂量。 (b)小鼠体内抗肿瘤活性测试 根据动物体内抗肿瘤活性测试的标准方法，选用昆明种小鼠，皮下接种肉瘤S180或肺癌H22瘤株，选择体外活性突出且急性毒性较低的化合物，设定合适的剂量通过腹腔注射方式给药，以临床常用抗肿瘤药物环磷酰胺作为阳性对照药物，测定肿瘤生长抑制作为体内活性评价指标。 (c)专利保护范围内的化合物的继续合成 申请保护范围较大的专利，合成部分可能具有良好活性的新的化合物，拓展研究范围，发现活性更强的化合物，并申请新的发明专利。并可针对具体化合物申请从属专利，延长高活性化合物的保护期限。 （d）体外抗肿瘤活性的广泛筛选 采用MTT法或台盼蓝染色法，测定化合物对多种人肿瘤细胞株的增殖抑制活性，确定化合物在不同瘤株间抗肿瘤活性的选择性，为裸鼠模型实验提供依据。 （e）抗肿瘤作用机理的深入研究 根据抗肿瘤（f）人癌裸鼠移植瘤模型实验活性化合物作用机理特征，选用微管蛋白聚合等实验从分子水平确认化合物的作用机理；利用人脐静脉血管内皮细胞探讨化合物对内皮细胞骨架的影响及诱导凋亡的途经，从细胞水平上阐明化合物的作用机理。 根据抗肿瘤新药审批办法的要求，采用裸小鼠皮下接种模型和/或原位移植瘤模型，以相对肿瘤增值率和生存时间为指标，确定化合物的抗肿瘤活性。 （g）动物体内药物代谢动力学实验 动物实验室管理规定 为加强对动物实验室的规范化管理，保证实验动物质量，确保实验研究和检测结果准确可靠以及安全评价符合标准，同时为了防止人畜共患病的发生及蔓延，根据我动物实验室实际情况规定如下： 1.实验动物的管理及使用必须严格按照《实验动物管理条例》和《广东省实验动物管理条例》的有关条款执行。 2.国家对实验动物生产和使用实行许可证制度。本动物实验室（屏障环境）已获得《广东省实验动物使用许可证》，面向广大科研工作者开放。需要开展动物实验的单位和个人，可向动物实验室提出申请，经审批通过并按规定办理相关手续后，即可进入实验室进行实验动物的饲养和实验操作。 3.本办法所称实验动物，是指经人工饲养培育，遗传背景明确或者来源清楚，对其质量实行控制，用于科学研究、教学、医药、生产和检定以及其他科学实验的动物。 4.在动物实验室进行动物实验活动的人员必须严格遵守动物实验实验室各项规章制度，服从工作人员的管理和安排。 5.深圳第三人民医院实验动物管理委员会负责指导和监督实验动物工作，动物实验室具体负责动物实验的管理、监督和检查工作。 6.动物实验室的工作人员（包括管理人员、实验动物技术人员和饲养人员）必须经过正规的实验动物培训，并持有“广东省实验动物学会”颁发的《实验动物技术培训班结业证书》或相关实验动物从业人员资格证书。实验动物从业人员实行定期健康体检制度，确认无传染病（含微生物和寄生虫）和其他影响实验动物工作疾病的人员方可上岗。 7.凡申请进入动物实验室进行动物实验操作的人员（包括研究生）必须提交相关实验动物从业人员资格证书，无证人员必须参加本动物实验室举办的岗前培训，经考核合格并取得深圳第三人民医院动物实验室颁发的《实验动物上岗培训合格证》后，方可申请进入动物实验室从事动物实验操作。 8.购买实验动物必须选择有资质的实验动物生产单位，在动物进入动物实验室的同时提交《实验动物生产许可证》复印件和《实验动物质量合格证》原件。 实验室生物安全实施标准操作规程 1、目的：预防与控制院感管理工作达到预期目标，防止医务人员发生职业暴露。 2、适用范围：检验部门工作人员。 3、定义：无 4、管理要求： 4.1进入规定 4.1.1在实验室入口处应贴生物危害警告标志。注明病原微生物、实验室生物安全等级和负责人电话。 4.1.2未经许可，非授权人员不应进入实验室。 4.1.3. 实验室门应保持关闭状态。 4.1.4. 与实验室工作无关的动物、个人衣物不应带入实验室。 4.2.个人防护 4.2.1.工作服 4.2.1.1. 在实验室工作时，应穿着工作服。 4.2.1.2. 不应穿着实验室工作服离开实验室。 4.2.1.3. 实验室工作服不应与日常服装放在一起。 4.2.2.手套 在进行可能直接或意外接触到血液、体液以及其他具有潜在感染性材料的操作时，应戴上合适的手套。脱手套后应洗手。用过的一次性手套应丢入感染性医疗废物袋内。 4.2.3.洗手 脱手套后以及离开实验室前，都应洗手。 4.2.4.其他防护 4.2.4.1. 当有可能受到喷溅物污染、碰撞或人工紫外线辐射伤害时，应戴合适的护目镜。 4.2.4.2. 不应再实验室内穿露脚趾的鞋子。 4.2.4.3. 不应在实验室工作区域进食、饮水、吸烟、化妆和处理接触镜（隐形眼镜）。 4.2.4.4. 不应在实验室工作区域内储存食品和饮料。 4.3.实验室工作区 4.3.1. 实验室应保持清洁整齐，严禁摆放和实验无关的物品。 4.3.2. 每天工作结束后，应消毒工作台面和生物安全柜台面。活性物质溅出后要随时消毒。 4.3.3. 所有受到污染的材料、标本和培养物应废弃于医疗废物容器内，不得与普通垃圾混放。需要清洁再利用的材料，应先压力蒸汽灭菌处理。 4.3.4. 需要带出实验室的手写文件应保证在实验室内没有受到污染。 参考文献：[1] WHO. 实验室生物安全手册,第3版.2004. 5、标准无 6、流程（无） 7、表单（无） 8、相关文件 8.1参考文献：[1] 中华人民共和国卫生部. 公共场所集中空调通风系统卫生规范[S].2006. [2] 中华人民共和国卫生部.医院空气净化管理规范[WS/T 368-2012]. 微生物检验实验室沙门菌属标准操作规程 1.概述 沙门菌属是一大群寄生于人和动物肠道中的形态、培养特性、生化反应和抗原构造相似的革兰阴性杆菌，其血清型别繁多、抗原复杂的肠道病原菌，分为6个亚属、2200种以上的血清型。伤寒沙门菌属亚属I，多价O抗血清D群，是临床上最为重要的沙门菌。 2.标本类型 粪便、血液等额标本。 3.鉴定 3.1 形态与染色：革兰阴性杆菌，菌体细长，大小为（0.7~1.5um）×（2~5um）。有周鞭毛，无芽胞，无荚膜。 3.2 培养特性：在麦康凯琼脂平板上形成无色、透明的菌落；SS琼脂平板上呈无色、透明，但大部分菌落中央呈黑色（产H2S）；在XLD琼脂平板上也产生中央黑色的菌落（产H2S）；HE琼脂平板上菌落呈蓝绿色。CHROMagar显色培养基上呈紫色菌落。半固体琼脂中均匀混浊生长，无穿刺线。 3.3 生化反应：氧化酶试验阴性，TSI为K/A；发酵葡萄糖，不发酵乳糖；IMViC-+--或-+-+，H2S试验阳性或阴性，动力、赖氨酸脱羧酶和硝酸盐还原试验阳性，鸟氨酸脱羧酶、尿素酶试验阴性，氰化钾（KCN）培养基不生长。 3.4 鉴别要点： 3.4.1 本菌特征：鉴别平板上无色透胆或半透明的菌落，TSI为K/A，H2S阳性或阴性，有动力，IMViC-+--或-+-+，尿素酶试验阴性。符合上述特性者，可通过血清凝集试验）作出诊断。 3.4.2 与志贺菌属的鉴别：少数伤寒沙门菌在TSI上H2S阴性，动力不明显，易与志贺菌属混淆，可用血清凝集反应相鉴别。 3.5 操作步骤 3.5.1 观察菌落特征，挑取可疑菌落，做TSI试验。参见细菌鉴定标准操作构规程。 3.5.2 血清学鉴定参见沙门菌血清学检测标准操作规程。 3.5.3 鉴定从SS琼脂平板上挑取可疑菌落，用微生物鉴定仪或传统生化法进行细菌鉴定。 4. 药敏 参见药物敏感性试验标准操作规程及CLSI M100-S20最新版本文件。 5. 质量控制 参见质量管理程序。 6.检验结果解释与分析 沙门菌的鉴定依赖于传统或商品化系统生化反应和血清学两种方法。若生化反应符合沙门菌，但A-F多价血清不 实验动物尿液采集的标准操作规程(SOP) 关键词：尿液采集操作规程 目的：采集各种实验动物的尿液,以用于实验 主体内容： 常用的采集方法较多，一般在实验前需给动物灌服一定量的水。 (一)代谢笼法：此法较常用，适用于大、小鼠。将动物放在特制的笼内。动物排便时，可以通过笼子底部的大小便分离漏斗将尿液与粪便分开，达到采集尿液的目的。 由于大、小鼠尿量较少，操作中的损失和蒸发，各鼠膀胱排空不一致等原因，都可造成较大的误差，因此一般需收集5小时以上的尿液，最后取平均值。 (二)导尿法：常用于雄性兔、狗。动物轻度麻醉后，固定于手术台上。由尿道插入导尿管(顶端应用液体石蜡涂抹)，可以采到没有受到污染的尿液。 (三)压迫膀胱法：在实验研究中，有时为了某种实验目的，要求间隔一定的时间，收集一次尿液，以观察药物的排泄情况。动物轻度麻醉后，实验人员用手在动物下腹部加压，手要轻柔而有力。当加的压力足以使动物膀胱括约肌松驰时，尿液会自动由尿道排出。此法适用于兔、狗等较大动物。 (四)输尿管插管法：动物麻醉后，固定于手术台上。剪毛、消毒，于耻骨联合上缘之上在正中线做皮肤切口(长约3～4cm),沿腹中线切开腹壁及腹膜,找到膀胱翻出腹外。辨认清楚输尿管进入膀胱背侧的部位(膀胱三角)后，细心地分离出两侧输尿管，分别在*近膀胱处穿线结扎。在离此结扎点约2cm 处的输尿管近肾段下方穿一根丝线。用眼科剪在管壁上剪一斜向肾侧的小切口，分别插入充满生理盐水的细塑料管( 插入端剪成斜面)，用留置的线结扎固定。可见到尿滴从插管中流出( 头几滴是生理盐水)，塑料管的另一端与带刻度的容器相连或接在记滴器上，以便记录尿量。在适用过程中应经常活动一下输尿管插管，以防阻塞。在切口和膀胱处应盖上温湿的生理盐水纱布。 (五)膀胱插管法：腹部手术同输尿管插管。将膀胱翻出腹外后，用丝线结扎膀胱颈部，阻断它同尿道的通路。然后在膀胱顶部避开血管剪一小口，插入膀胱漏斗，用丝线做以荷包缝合固定。漏斗最好正对着输尿管的入口处。注意不要紧贴膀胱后壁而堵塞输尿管。下端接橡皮管插入带刻度的容器内以收集尿液。 (六)穿刺膀胱法：动物麻醉后固定于手术台上，在耻骨联合之上腹正中线剪毛，消毒后进行穿刺，入皮后针头应稍改变一下角度，以避免穿刺后漏尿。 (七)剖腹采尿法：同穿刺法做术前准备，皮肤准备范围应大一点。剖腹暴露膀胱，操作者的左手用无齿小平镊夹住一小部分膀胱，右手持针在小镊夹住的膀胱部位直视穿刺抽取尿液。可避免针头贴在膀胱壁上而抽不出尿液。 (八)反射排尿法：适用于小鼠，因小鼠被人抓住尾巴提起时排便反射比较明显。故需采取少量尿液时，可提起小鼠，将排出的尿液接到带刻度的容器内。 动物实验中心屏障环境设施物品进出标准操作规程 一、各类物品进入清洁区之前的准备 1.1 准备的原则 各类饲养管理用物品由管理人员负责准备。平时应根据实验数量、动物种类和数量，对相应所需的各种物料如：饲料、垫料、各种用具等进行必要的储备，确保实验工作的顺利进行。 各类实验用物品则由实验人员根据实验需求进行准备。 所用灭菌物品在高压灭菌前应加外包装。 将完成工作记入工作记录表(见附表)。 1.2 无菌服的准备 管理人员将穿出清洁区的无菌服及时进行清洗、烘干或凉晒。具体要求是：一般每半月应清洗1次，个别过脏者，应随时清洗；随时烘干潮湿的无菌服；每次传入清洁区之前均需进行成套包装并标明大、中、小号，然后由设备使用人员进行高压灭菌并传入清洁区。 1.3 工作鞋的准备 洗刷人员每天下午下班前将所有已穿过的工作鞋进行清洗、药物浸泡消毒；洁净区内将已晾干的工作鞋码放在洁净走廊入口处备用。 1.4 口罩、手套的准备 对不耐高温的一次性用品，应整批包装，并经CO60照射或环氧乙烷灭菌后，由传递窗/间传入清洁区；对反复使用者，应经高压灭菌后，传入清洁区。 1.5 饲料的准备 经CO60照射灭菌后的饲料，非洁净区人员剥去外包装并对塑料袋表面全方位药物喷雾消毒后，码放在传递仓搁架上；紫外线消毒半h后，洁净区人员剥去塑料袋后，再将其传入清洁区（塑料袋不得进入洁净区）。可高压灭菌的饲料，可经过高压灭菌器,直接进入清洁区。 1.6 笼具和各种工具的洗刷 由洗刷人员负责。洗刷应及时、够量，确保满足清洁区的需要。 先把由清洁区传出的笼具和各种工具中的污物分类倒入相应污物容器中，再用自来水冲洗笼具和各种工具。 对于尿碱等附着物，可用稀酸浸泡后再冲洗，确保冲洗干净，不留污垢。 洗刷完毕，将它们有序地码放在凉干架上。 1.7 垫料、笼具和各种工具的消毒 应使用吸湿性好、尘埃少、无异味、无毒性、无油脂的材料作为垫料。 根据清洁区内不同笼具的需求量（注意留有余量），将适量的垫料分装至洗刷并凉干的笼具内（亦可用其它容器包装 动物实验中心高压蒸汽灭菌器标准操作规程 1、操作程序 1.1 由管理人员负责。该同志应熟悉本设备的工作原理和维护注意事项，作好日常性的使用和维护工作。 1.2 设备由蒸汽发生器、太阳能热水器和双扉灭菌器组成。 1.3 清洁区操作员打开蒸发器进水阀门（由太阳能提供热水）， 1.4 打开外门（平时外门应关闭但不压紧），放入待消毒的物品（注意：待消毒物品的有效占用空间应不小于内室空间的80%，否则，容易产生“小装量效应”而使灭菌效果不确实；另外，消毒垫料时应使用外包装袋，以免垫料进入排气管道），关闭外门。 1.5 开启灭菌器柜门，须在确定另一侧门关闭的情况下，方可打开，清洁区操作员取出物品后马上关闭柜门。 1.6 关闭灭菌器双门后，打开电源开关，将蒸汽管道中的冷凝水排放后再打开通向高压锅的蒸汽阀门。 1.7 当蒸发器的压力达到0、3～0、4Mpa时，打开送气阀门。开启夹层进气阀（预热夹层，看住压力表，压力不要超过0、15Mpa） 1.8 打开真空阀，开启真空泵。当压力达到-0、075Mpa 时，关闭真空泵。打开内室进气阀，内室进气，内室压力 达到0、06Mpa时，关闭内室进气阀，开启真空泵（反复三次），第三次抽真空结束时，关闭真空泵、真空阀。 1.9 开启内室进气阀，升温灭菌。 1.10灭菌结束时，将内室压力排出，接近于0Mpa市，打开真空阀门，开启真空泵。大约8分钟后关闭真空泵、真空阀。打开回空气阀，当室内压力为0时，打开柜门。灭菌结束。 1.11 灭菌结束后，关闭水电及各个阀门。 1.12 清洁区操作员打开内门，取出消毒好的物品（避免烫伤），关闭内门。 1.13 作业完毕，两侧操作员将物品码放整齐，彻底清理环境卫生。非清洁区操作员将灭菌器电源开关、蒸汽和供水阀门关闭。灭菌饲料后要用清水清洗灭菌器内胆。 1.14操作人员必须做好灭菌记录。 2、设备使用注意事项及维护 2.1 每班作业前，应检查各仪表和水、电、汽源和气泵是否正常；作业时，每周打印灭菌记录1次；作业后要保持设备内外的卫生清洁。 2.2 平时应注意观察设备运转是否正常，发现问题应及时解决。维护时应严格按照维护方法（详见设备操作说明）进行规范作业；必要时，要请专业人员进行检修。 . 实验室生物安全标准操作规程HYEY-PGC-2016 （第三版） 目录 HYEY-PGC01-2016 实验室人员进出实验室 HYEY-PGC02-2016 实验室检测样品采集 HYEY-PGC03-2016 实验室检测样品包装和运送HYEY-PGC04-2016 实验室检测样品接收 HYEY-PGC05-2016 样品检测操作规程 HYEY-PGC06-2016 电气设备操作规程 HYEY-PGC07-2016 实验室消毒剂配制标准操作规程HYEY-PGC08-2016 无菌间使用标准操作规程HYEY-PGC09-2016 实验室废弃物处理标准操作规程HYEY-PGC10-2016 实验室消毒标准操作程序HYEY-PGC11-2016 实验室意外事故处理 1 目的 制定检验科实验室人员进出的标准操作程序，保障实验室生物安全。 2 适用围 适用于检验科实验室人员进出程序。 3 职责 实验室工作人员执行本程序的规定。实验室负责人负责监督执行。 4 规程要求 4.1进入程序 实验室人员需将外衣挂入（避免将外衣与工作服混放），穿上工作服，按要求戴手套、口罩等防护用品方可进入实验室。 4.2 退出程序 工作结束后，实验室人员在实验室将一次性口罩、手套、鞋套等放入指定容器。先用0.5%新洁尔灭对手进行消毒，再用消毒肥皂洗手。在指定区域脱下工作服，必要时进行紫外消毒。实验室人员退出实验室后，必须将实验室入口门关好，方可离开实验 室。 1 目的 为保障检测实验的顺利进行，规采样程序，防止病原微生物在实验室采样过程中产生污染。 2 适用围 适用于实验室采集、处理动物样品。 3 职责 3.1 采集检测样品的工作人员在采集过程中应当防止病原扩散，并对样本的来源、采集过程和处理方法等作详细记录。 3.2 检验人员必须严格按照本操作规程操作，不可擅自做出超出本规程的操作，所有 XXXX药业有限公司 标准操作规程(S O P) 页号2－1 题目：实验动物尸体及废弃物处理标准操作规程起草：日期：审核：日期： 文件编号：批准：日期： 编订部门：化验室执行日期：年月日 分发部门：化验室、档案室 1.目的 规范实验动物室废弃物的处理过程 2.范围 实验动物室废弃物的处理 3.责任 质量保证科、化验室、实验动物室负责人及相关人员 4. 制定依据： 国家《实验动物条例》、《实验动物环境及设施》及 《河南省实验动物管理办法》 《河南省实验动物使用许可证验收实施细则》、等相关文件要求。 5.规程 5.1 动物饲养及动物实验废弃物的处理 5.1.1 有专用废弃物盛装袋（箱），及时将废弃物装入袋内，封口 文件编号：SP-DW-SOP-09-005-01 页号2－2 严密，倒入规定地点。 5.1.2 感染性实验废弃物需先高压灭菌后再处理。 5.2.动物尸体 5.2.1因不明原因而死亡的动物，必须向管理人员汇报，查明原因后再作处 理。有潜在危害的动物尸体和废弃物，消毒灭菌后用专用塑料袋严格包装，暂存于冰柜中。 5.2.2 设有专用尸体盛装器或袋。淘汰的实验动物被安乐死后，用塑料袋密封包装及时将尸体装入袋内，封口严密，存入冰柜中，并登录在登记簿上。 5.2.3动物尸体集中收集，与医疗垃圾处理部门签定协议，其负责接收动物尸体并无害化处理。实验动物尸体严禁食用和出售。 5.2.4 感染性实验的动物尸体需先高压灭菌后再处理。 5.2.5 动物尸体处理后，需填写处理记录，注明处理方法和时间，经办人签名。动物尸体或废弃物处理后对相关设施、设备、器具进行消毒. 5.2.6实验动物室的所有废弃物均应放入专用的容器内。一般废弃物当日处理。过期的饲料、过期的试剂等需上报动物实验负责人批准后，按作报废处理，过期的饲料按普通废弃物处理，过期试剂需按不合格试剂销毁， 6.变更历史 序号 文件版本编号变更原因变更日期变更前变更后 实验室标准操作规程 目的：严格控制动物实验环境不受病源微生物的危害,保护动物的福利,维持环境的生物洁净度。 适用范围：适用于所有在屏障设施内工作的人员。 职责： 1.设施负责人负责监督、管理； 2.工作人员严格按规程行事。 规程： 1.辅助人员进入洁净走廊后,穿上洁净走廊的拖鞋,到洁净储物间配制当天使用的各种消毒剂,备用。 2.辅助人员在洁净储物间的把当天使用的笼具、饮水瓶、饲料等物品用运输车运到洁净走廊,备用。 3.饲养员在二更出来的缓冲间,在手消毒器前要注意手套的彻底消毒,经风淋后进入清洁走廊,穿上洁净走廊的拖鞋,每一动物房外门口的位置放置一瓶75%的酒精喷壶,进入动物房前,用酒精喷手、喷门把后,把已准备好的物品放入动物房。 4 .饲养员进入动物房后,关紧通向洁净走廊的门,换上动物房内的专用拖鞋,然后巡视房间内的所有设施和动物,按每周的工作计划安排工作,并做好温度、湿度、工作日记等记录,对当天完成的工作在工作安排表上打勾并签名确认,如出现问题及时汇报并进行处理。 5 .饲养人员应该在当天工作完成前把第二天需要换的水瓶、大概的饲料添加量及其他需要的物品记录在纸上带出交给辅助人员准备。把有关的记录数据写在纸上带出来交给第一负责人。 6.饲养人员的拖鞋在工作完成后,用酒精喷雾消毒后,放回动物房靠洁净走廊门口,然后把物品带出次清洁走廊,在物品出口处签名,次清洁走廊的清洁消毒工作由最后出来的人员完成。 注意事项 1.严禁动物房内的逆向走动,以及动物房之间的互相串联。 2.在有辅助人员的情况下,饲养人只负责自已管辖的房间,房间外的工作由辅助人员完成。 3.在周六日或其他节假日轮值没有辅助人员的时候,轮值人员进动物房前,须先到储物间准备当天要用的物品,尽量减少动物房、清洁走廊、储物间之间的来回走动。 知识改变命运 1 / 1 关键词：尿液采集操作规程 目的：采集各种实验动物的尿液,以用于实验 主体内容： 常用的采集方法较多，一般在实验前需给动物灌服一定量的水。 (一)代谢笼法：此法较常用，适用于大、小鼠。将动物放在特制的笼内。动物排便时，可以通过笼子底部的大小便分离漏斗将尿液与粪便分开，达到采集尿液的目的。 由于大、小鼠尿量较少，操作中的损失和蒸发，各鼠膀胱排空不一致等原因，都可造成较大的误差，因此一般需收集5小时以上的尿液，最后取平均值。 (二)导尿法：常用于雄性兔、狗。动物轻度麻醉后，固定于手术台上。由尿道插入导尿管(顶端应用液体石蜡涂抹)，可以采到没有受到污染的尿液。 (三)压迫膀胱法：在实验研究中，有时为了某种实验目的，要求间隔一定的时间，收集一次尿液，以观察药物的排泄情况。动物轻度麻醉后，实验人员用手在动物下腹部加压，手要轻柔而有力。当加的压力足以使动物膀胱括约肌松驰时，尿液会自动由尿道排出。此法适用于兔、狗等较大动物。 (四)输尿管插管法：动物麻醉后，固定于手术台上。剪毛、消毒，于耻骨联合上缘之上在正中线做皮肤切口(长约3～4cm),沿腹中线切开腹壁及腹膜,找到膀胱翻出腹外。辨认清楚输尿管进入膀胱背侧的部位(膀胱三角)后，细心地分离出两侧输尿管，分别在*近膀胱处穿线结扎。在离此结扎点约2cm 处的输尿管近肾段下方穿一根丝线。用眼科剪在管壁上剪一斜向肾侧的小切口，分别插入充满生理盐水的细塑料管( 插入端剪成斜面)，用留置的线结扎固定。可见到尿滴从插管中流出( 头几滴是生理盐水)，塑料管的另一端与带刻度的容器相连或接在记滴器上，以便记录尿量。在适用过程中应经常活动一下输尿管插管，以防阻塞。在切口和膀胱处应盖上温湿的生理盐水纱布。 实验室生物安全标准操作规程 HYEY-PGC-2016 （第三版） 2016年1月11日发布 2016年1月20日实施 怀远县第二人民医院 目 录 HYEY -PGC01-2016 实验室人员进出实验室 HYEY -PGC02-2016 实验室检测样品采集 HYEY -PGC03-2016 实验室检测样品包装和运送 HYEY -PGC04-2016 实验室检测样品接收 HYEY -PGC05-2016 样品检测操作规程 HYEY -PGC06-2016 电气设备操作规程 HYEY -PGC07-2016 实验室消毒剂配制标准操作规程 HYEY -PGC08-2016 无菌间使用标准操作规程 HYEY -PGC09-2016 实验室废弃物处理标准操作规程 HYEY -PGC10-2016 实验室消毒标准操作程序 HYEY -PGC11-2016 实验室意外事故处理 1 目的 制定检验科实验室人员进出的标准操作程序，保障实验室生物安全。 2 适用范围 适用于检验科实验室人员进出程序。 3 职责 实验室工作人员执行本程序的规定。实验室负责人负责监督执行。 4 规程要求 进入程序 实验室人员需将外衣挂入（避免将外衣与工作服混放），穿上工作服，按要求戴手套、 口罩等防护用品方可进入实验室。 退出程序 工作结束后，实验室人员在实验室将一次性口罩、手套、鞋套等放入指定容器。先用%新洁尔灭对手进行消毒，再用消毒肥皂洗手。在指定区域脱下工作服，必要时进行紫外消毒。实验室人员退出实验室后，必须将实验室入口门关好，方可离开实验室。 1 目的 为保障检测实验的顺利进行，规范采样程序，防止病原微生物在实验室采样过程中产生污染。 2 适用范围 适用于实验室内采集、处理动物样品。 3 职责 采集检测样品的工作人员在采集过程中应当防止病原扩散，并对样本的来源、采集过程和处理方法等作详细记录。 检验人员必须严格按照本操作规程操作，不可擅自做出超出本规程的操作，所有实验人员对所从事的工作负相应的责任。 4 过程要求 工作条件 具有采集、处理样品所需要的生物安全防护设备； 具有掌握相关专业知识和操作技能的工作人员； 具有有效的防止病原扩散的措施； 具有保证检测样品质量的技术方法和手段。 实验材料 准备灭菌的解剖器械（剪刀、镊子、手术刀、大刀、斧头等）、灭菌试管、平皿或自封袋、载玻片、棉签、营养肉汤、30%、50%甘油盐水缓冲液、加抗生素的PBS（病毒保存液）、50％甘油磷酸盐缓冲液、酒精灯、灭菌注射器、15mL的离心管、管、记号笔、签字笔、防护服、无粉乳胶手套、防护口罩、铅笔、空白标签纸、胶布、75%酒精棉球、碘酒棉球、冰袋、冷藏容器、消毒药品、采样单等。 XXXX^业有限公司 标准操作规程（SOP） 页号2-2 1. 目的 规范实验动物验收与检疫操作，预防、控制实验动物疫病，保证实验动物质量。 2. 范围 实验动物家兔、小鼠、豚鼠 3. 责任 质量保证科、化验室、实验动物室负责人及相关人员 4. 制定依据： 国家《实验动物条例》、《实验动物环境设施标准》、《河南省实验动物管理办法》、《河南省实验动物使用许可证验收实施细则》等相关文件。 5. 规程 5.1. 实验动物的检疫由动物实验人员或动物饲养人员负责。 5.2. 外来实验动物均需要进行检疫观察，对来源丁有生产许可证单位的合格动物只须进行常规检查。 5.3. 根据实验动物的微生物等级和品种、品系不同，进行3-21天的检疫观 察。活洁级以上小鼠一般检疫观察2-3天；普通级动物兔、豚鼠的检疫时间为1 文件编号：SP-DW-SOP-09-014-01 页号2 -2 周。符合要求的实验动物才能进入实验程序。 5.4. 实验动物到达后，首先检查包装情况，完好无损的才可接收。 5.5. 对照订货条件与到达的实验动物----- 进行核实。 5.6. 将运输盒的所有外表面用75%洒精等消蠹液进行彻底的擦拭消蠹，将实验动物传入检疫室。 5.7. 在实验动物转入饲养盒时，认真检查动物的健康状况，主要有： 5.7.1精神状态和营养状况； 5.7.2皮毛：有无光泽、出血、干燥； 5.7.3有无眼屎、流泪、白内障、角膜损伤等； 5.7.4耳：有无损伤、耳壳有无曲折、有无中耳炎等； 5.7.5四肢：有无弯曲、脱臼、外伤、关节炎等； 5.7.6肛门：有无下痢，便血，脱肛等。 5.8. 在检疫过程中发现有异常现象时，应判明异常的原因，并适当延长检疫 5.9. 每天做好检疫观察记录。 6. 变更历史 实验动物接收标准操作规程 确保接收实验动物的健康和质量，制定本程序。 2 适用范围 适用于实验动物接收的操作活动。 3 职责 3.1实验动物中心管理人员负责监督、管理； 3.2严格遵守相应级别实验动物检疫操作流程。 4. 流程 4.1 购入动物时，应向有实验动物生产许可证、信誉好、动物质量佳、有严格管理和一定规模的单位购入； 4.2 当动物抵达后，首先检查带空气过滤装置的运输箱密封情况，对照运输箱上的标签，核对动物的信息与要求是否相符； 4.3 运输箱表面用消毒液喷雾消毒，放入传递窗，关门，打开紫外灯照射30分钟； 4.4 打开动物运输箱，转移至动物笼具内，放入检疫室检疫，观察是否有任何异常行为或疾病的迹象； 4.5 在检疫室饲养5-7天以后，检疫合格方可转入饲养室。 编写/修订记录 1 目的 确保短期动物实验进度顺利完成，给予微生物要求低的实验动物简易检疫程序，制定本程序。 2 适用范围 实验周期为2个月以内，实验动物微生物系对实验结果影响较小的实验项目。 3 职责 3.1实验动物中心管理人员负责监督、管理； 3.2严格遵守相应级别实验动物检疫操作流程。 4. 流程 4.1 新进动物必须隔离饲养于检疫室5-7天，确认无异常后，移入饲养间。 4.2 动物观察内容： 4.2.1皮毛：有无光泽、竖毛、出血、污物、脱毛等 4.2.2眼：有无眼屎、流泪、角膜损伤等 4.2.3口腔：有无流涎、出血等 4.2.4耳：有无外伤、耳壳曲折等 4.2.5四肢：有无外伤、弯曲脱臼、肿胀等 4.2.6肛门：有无腹泻、血便、脱肛等 4.2.7精神和食欲：有无沉默、倦怠、不活跃、食欲不振、拒食等 4.2.8营养状况：有无消瘦、过度肥胖、成长异常等 4.2.9姿势和步态：有无姿势异常、行走和站立困难、运动失调、跛行等 4.2.10触觉：弹性、硬度、肿胀、疼痛等 5.检疫结果 隔离观察一周，如观察内容无异常则转入动物中心饲养间，如有异常由动物检疫员进一步检疫相关微生物指标，查明原因。如果为国标要求阴性项目感染则整批淘汰，其他情况根据设施内实际微生物情况提出合理化建议，最终处理决定由实验团队、动物中心工作人员和分管领导讨论决定。 委托动物实验协议书 受托方（甲方）全称：_______________________________________________ 委托方（乙方）全称：_______________________________________________ 根据国家科技部等七部局《实验动物许可证管理办法（试行）》 和XX省科技厅等六厅局《XX省<实验动物许可证管理办法（试行）>实施细则》的规定，为尚未领取许可证的单位和个人提供合格的动物实验条件，合理利用取得行政许可的实验动物设施资源，明确委托和受托双方应履行的责任和义务，双方协议如下： 第一条甲方已具备的法律地位和实验条件： 一、已取得XX省实验动物使用许可证。证号： 二、能按乙方要求购进质量合格、遗传背景明确或来源清楚的实验动物和专用饲料、垫料及其他相关物品。 三、有符合国家标准相应净化级别的动物实验室，公布了人员进出实验室应遵守的规章制度和标准操作规程（SOP）。 四、从事动物饲养、兽医、实验、设施和设备维护等人员经过了专业技术和动物福利培训，获得了政府主管部门颁发的岗位资格证书。 第二条委托动物实验的方式（选用√表示） 方式一：甲方向乙方提供动物实验设施和设备，乙方人员到甲方实验室进行实验（）。 方式二：乙方设定动物实验方案交给甲方，甲方按照设定方案承担实验任务（）。 第三条甲乙双方约定： 一、选用第二条第一款方式的，（1）乙方实验人员经过了培训，有岗位资格证书，附名册；甲方有权禁止无证书人员进入实验室。（2）乙方实验人员严格遵守甲方公布的实验室管理制度和标准操作规程（SOP）；甲方有权拒绝违规人员进入实验室或停止实验至改正为止。（3）乙方实验人员不随意搬动、不丢失实验设备。如造 附件1 实验动物饲养管理的SOP 1、目的 为规SPF级动物房大小鼠、仔猴的饲养规，保证试验质量，特制定本制度。 2、围 适用于本公司SPF级动物房的工作人员。 3、容 3.1准备工作 3.1.1操作人员按SPF区人员进出标准操作规程要求进入动物饲养区。 3.1.2推门时应感觉到正压存在，如有异常及时通知相关人员。 3.1.3观察看温、湿度计，并记录读数。温度湿度变化围超过规定围时，要及时向实验人员和实验室负责人汇报，以便尽快采取措施。 3.1.4观察水瓶有无漏水，有无动物逃逸，动物健康情况，若有异常情况，应及时向实验人员和实验室负责人汇报并记录情况。 3.1.5检查每盒动物的饮水及摄食状况，若饮水及摄食不正常的动物笼，先检查是否饮水瓶阻塞，再观察动物是否有疾病征兆。若有，立即上报。 3.1.6发现动物死亡，要调查死亡原因，判断事故死亡还是异常死亡，并报告，不能确定原因的要将整盒动物送出屏障待查。 3.2 SPF大、小鼠的饲养管理SOP 3.2.1鼠喜阴暗、安静的环境，对环境温度、湿度很敏感，经不起温度的骤变和过高的温度。最大温差小于等于4℃，温度在20～26℃，相对湿度40～70％，一般鼠饲养盒温度比环境高1～2℃，湿度高5～10％。噪音60分贝以下，氨浓度14/（mg/m3）以下．通风换气大于等于15次/小时。光照循环条件是是12小时明/12小时暗，如果光照条件与上述不符，且没有实验方案支持，必须通知实 验动物管理部的管理人员。 3.2.2鼠饲养在聚碳酸酯的实底的笼盒里，笼子底部放高压灭菌的玉米芯做垫料。除非实验方案有特殊的要求，和/或有动物管理委员会的批准，方可以进行改动。鼠是群居性动物，可能时尽量成群饲养，但每笼不得超过5只。 3.2.3饲料和饮水：鼠通过实验室等级颗粒料或等同的其它饲料自由采食，或者由实验动物管理部管理层或专题负责人提出建议。加饲料时，观察动物采食量，若尚有剩余饲料，则与新鲜饲料混合后喂。根据笼鼠的多少参考如下饲料量饲喂,不宜太多。工作日每天检查一次料盒，周末一次。在更换笼具时，根据需要添加饲料。鼠采食量一般为5g（100g体重24小时），请根据动物的实际体重计算并投喂。鼠通过水瓶自由饮水。工作日每天检查1次水瓶，周末一次，每周至少更换一次水瓶。鼠饮水量一般为8～11ml（100g体重24小时）如果要求进行饲料/饮水的消耗量计算，则要根据实验方案进行记录。某些实验需要对饲料/饮水进行限制，或者给予特殊的饲料/饮水。 3.2.4鼠笼具的更换 鼠笼具（包括垫料）每周更换两次，通常为周二和周四。更换时，将鼠笼从笼架上取下放在工作车或工作台上，鼠取出放在干净的笼具中，加上盖子，放好标签，将笼架用75%酒精擦洗干净后放回笼架。换笼具时同时观察动物健康情况。换下的笼具和盖子放在推车上推到饲养室靠污物走廊的门口后开门将鼠盒放在污物走廊地上，然后关闭该门。工作车不准推入污物走廊。换出脏垫料做无害化处理。 3.2.5清洁卫生：饲养室保持整洁，门窗，墙壁，地面，鼠盒，笼架每天擦试。 3.2.6记录保存：动物管理记录表（附表4）中，记录着饲养室日常管理和卫生清洁的情况，这些文件在记录阶段保存在饲养室。 3.3 SPF仔猴饲养的SOP 标准操作规程（SOP）—— 一、目的 该文件用以说明实验动物麻醉的具体操作以及操作规范，以保证麻醉剂量准确，使实验动物处于麻醉状态，实验顺利进行。同时保证操作人员的安全。二、范围 适用于中国国家流感中心的所有技术人员对实验动物进行麻醉。 三、程序 （一）生物安全要求 动物实验涉及到H5、H7亚型高致病性禽流感病毒，H2N2亚型流感病毒的时候，动物麻醉操作需要在ABSL-3级实验室进行操作。操作其他病毒的时候，动物麻醉操作需要在ABSL-2级实验室中进行。 （二）材料 1．实验动物：中小型实验动物，如：小鼠、大鼠、豚鼠、兔及雪貂等。 2．动物实验中常用的麻醉剂分为三类，即挥发性麻醉剂、非挥发性麻醉剂和中药麻醉剂。 （1）挥发性麻醉剂 这类麻药包括乙醚、氯仿等。乙醚吸入麻醉适用于各种动物，其麻醉量和致死量差距大，所发安全度亦大，动物麻醉深度容易掌握，而且 麻后苏醒较快。其缺点是对局部刺激作用大，可引起上呼吸道粘膜液体 分泌增多，再通过神经反射可影响呼吸、血压和心跳活动，并且容易引 起窒息，故在乙醚吸入麻醚时必须有人照看，以防麻醉过深而出现上情 况。 （2）非挥发性麻醉剂 这类麻醉剂种类较多，包括苯巴比妥钠、戊巴比妥钠、硫喷妥钠等巴比妥类的衍生物，氨基甲酸乙脂和水合氯醛。这些麻醉剂使用方便， 一次给药可维持较长的麻醉时间，麻醉过程较平衡，动物无明显挣扎现 象。但缺点是苏醒较慢。 （3）中药麻醉剂 动物实验时有时也用到象洋金花和氢溴酸东莨菪碱等中药麻醉剂，但由于其作用不够稳定，而且常需加佐剂麻醉效果才能理想，故在使用 过程中不能得到普及，因而，多数实验室不选用这类麻醉剂进行麻醉。（三）实验步骤 1．吸入法 用一块圆玻璃板和一个钟罩或一个密闭的玻璃箱作为挥发性麻醉剂的容器，多选用乙醚作麻醉药。麻醉时用几个棉球，将乙醚倒可其中，迅速转入钟罩或箱内，让其挥发，然后把待麻醉动物投入，约隔4-6min即可麻醉，麻醉后应立即取出，并准备一个蘸有乙醚的棉球小烧杯，在动物麻醚变浅时给套在鼻上使其补吸麻醉药。本法最适于大、小鼠的短期操作性实验的麻醉，当然也可用于较大的动物只是要求有麻醉口罩或较大的玻璃箱。由于乙醚燃点很低，遇火极易燃烧，所以在使用时，一定要远离火源。 2．腹腔和静脉给药麻醉法 非挥发性和中药麻醉剂均可用作腹腔和静脉注射麻醉，操作简便，是实验室最常采用的方法之一。腹腔给药麻醉多用于大小鼠和豚鼠，较大的动物如兔、狗等则多用静脉给药进行麻醉。由于各麻醉剂的作用长短以及毒性的差别。所以在腹腔和静脉麻醉时，一定控制药物的浓度和注射量。 （如下表）动物微生物实验仪器操作规程汇总(DOC)
标准操作规程实验动物隔离检疫标准操作规程【模板】
动物实验标准操作规程
抗肿瘤药物体内筛选试验标准操作规程(SOP)
动物实验室管理规定
实验室相关标准操作规程完整
微生物检验实验室沙门菌属标准操作规程
实验动物尿液采集的标准操作规程
动物实验中心屏障环境设施物品进出标准操作规程
动物实验中心高压蒸汽灭菌器标准操作规程
实验室生物安全标准操作规程
实验动物尸体及废弃物处理标准操作规程
实验室标准操作规程.doc
实验动物尿液采集的标准操作规程
实验室生物安全标准操作规程精选
实验动物验收与检疫操作规程
试验动物接收标准操作规程
委托动物实验协议书(完整版)
动物大小鼠、实验猴饲养的操作规程
标准操作规程(SOP)——实验动物的麻醉
相关主题
文本预览