Protocol in Infra-Structured Mobile Networks

The Reimplementation of theRRDP Transport ProtocolC.McAvaney, J.Rough, G.Wickham,D.De Paoli{chrismc,ruffy,gjw,ddp}@.auSchool of Computing and MathematicsDeakin UniversityGeelong, Victoria, 3217AbstractThe RHODOS Reliable Datagram Protocol (RRDP) is an integral part of the RHODOS distributed operating system. The existing implementation of RRDP, after years of development, has begun to show inadequacies that are hindering the whole RHODOS system. This document describes what was the existing implementation of RRDP, the problems that existed, and reports on the reimplementation of the RRDP protocol. Minor modifications made to the actual protocol and the supporting infrastructure in the operating system are also described within.The Reimplementation of the RRDP Transport Protocol1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 Overview of RHODOS Interprocess Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12.1 Message Delivery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12.2 The RHODOS System Name (SName) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22.3 Berkeley Memory Buffers (MBufs). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22.4 Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32.4.1 The send() primitive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32.4.2 The recv() primitive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32.4.3 The call() primitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42.5 Remote Interprocess Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42.6 The Roles of RHODOS Components in Remote Interprocess Communication . . . .62.6.1 The Microkernel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62.6.2 IPCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62.6.3 RRDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82.6.4 IP/Eth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83 The RRDP Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83.1 RRDP Packet Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83.2 Packet Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103.3 Sending Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113.4 Receiving Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123.5 Resolution of Network Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133.6 Unreliable RRDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133.7 Protocol Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134 Implementation Aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144.1 Message Structures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144.2 Optimum Timeout Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144.3 Removal of RRDP/IP header dependency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155 Performance Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156 Conclusions and Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167 Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17Page iiThe Reimplementation of the RRDP Transport Protocol 1 IntroductionDistributed operating systems aim to provide a transparent interface to a cluster of workstations connected together by a local area network. Crucial to this objective is the provision of a high-performance interprocess communications facility. The two components of this facility are the interprocess communication primitives and the supporting transport protocol for remote communication [Goscinski1991]. The reimplementation of the supporting transport protocol (RRDP) is the subject of this report.The previous implementation of RRDP lacked timeouts and hence full reliability. The delivery of messages would fail if the last packet of a group (Section 3.2) was lost or corrupted. Additionally, the resources used by the message would not be freed due to an impasse where the sender was waiting for an acknowledgement (where it would free the resources), and the receiver was waiting for the final packet to arrive before it would send the acknowledgement. Although implementing timeouts in RRDP should have been a trivial exercise, several race conditions existed that complicated the task somewhat. These race conditions had caused modifications to RRDP to be abandoned in the past, thus one of the objectives of this project was to eliminate these race conditions.The goals of this project were to introduce timeouts reliably to the protocol, minimising any changes to servers that interact with the RRDP server. Once completed, all race conditions were to have been eliminated in the RRDP server, allowing future improvements and fixes to be applied to the protocol without unnecessary complication.Section2 provides an overview of interprocess communication in RHODOS including the roles of RHODOS components in providing the interprocess communication service. Section3 describes the RRDP protocol including packet structures, the procedures used for transmitting and receiving messages, and handling of network failures. Important issues that were raised during the implementation of this project are presented in Section4. A comparison of the performance of the old and new implementations of RRDP is in Section5. Finally Section6 concludes this report and indicates future work to be done on RHODOS interprocess communication.2 Overview of RHODOS Interprocess CommunicationThis section describes the implementation of interprocess communication in the RHODOS operating system. The roles and responsibilities of the Microkernel, IPCM, RRDP and IP/Eth servers are discussed. Additionally, the structure and semantics of communication between these components is described.2.1 Message DeliveryAll messages in RHODOS are sent to a “port”, with any process allowed to have any number of ports to receive messages on. A port is a logical entity maintained by the Microkernel and has associated with it an “operation queue”. Messages are delivered to a port by being referenced by an operation structure (oper), which is stored in the operation queue. The oper contains the details about the message, such as the return port, a pointer to the message (stored in MBufs), and pointers to the Process Control Blocks (PCBs) of any processes with blocked operations on that port.Page 1The Reimplementation of the RRDP Transport Protocol Page 2Two models are used for message delivery. In the first model, the message is copiedinto buffers maintained by the Microkernel, in this case Berkeley MBufs [Leffler et al 1989].The message is then added to the destination port’s operation queue for retrieval by a matchingreceive. When a matching receive is invoked the message is copied from the MBufs into thedestination process’ memory, and the MBufs are freed. In cases where a matching receive hasalready been invoked on the destination port, a second model is used where the message iscopied directly from the sending process’ buffer to the destination process’ buffer, thuseliminating a copy operation. These mechanisms are discussed extensively in[Goscinski et al 1994a].2.2 The RHODOS System Name (SName)In order to differentiate between the different active ports across the whole distributedsystem, some form of identification (naming) is necessary. RHODOS’ naming structureconsists of three levels: user level, system level, and low level (physical) naming[Goscinski et al 1994b]. System names (SNames) are used to identify objects used at thesystem level, hence ports are identified by an SName. The structure of the SName is shown inBlock 1. The fields that uniquely describe a port are the origin (sn_origin), which identifies theworkstation where the port was created; and the object number (sn_object ) which differentiatesbetween ports created on the same workstation.2.3 Berkeley Memory Buffers (MBufs)The demands placed on memory management for interprocess communication arevery different to the demands from other parts of an operating system. The MBuf data structure(shown in Block 2) was designed to provide an efficient allocation and reclamation scheme forinterprocess communication systems [Leffler et al 1989].The advantage of MBufs is that data can be inserted or removed at the beginning of anMBuf by manipulating the value of the m_off variable, and can be appended or removed at theend of an MBuf by manipulating the value of the m_len variable. This is extremely usefulwhen used in network protocols, where manipulation of packet headers (and trailers) occursfrequently. MBufs are shared in RHODOS, used for the storage and passing of messagesbetween: the Microkernel; IPCM; RRDP; and IP/Eth.If the data structure that is to be stored in MBufs is larger than the data region in asingle MBuf, then several MBufs can be linked via the m_next field to hold the data structure.Block 1: The RHODOS System Name (SName)The Reimplementation of the RRDP Transport Protocol Page 3This is known as a “chain” of MBufs. Several chains can also be linked together using them_act field, form a linked list.The implementation of MBufs in RHODOS is not identical to that of Berkeley. Themost obvious change is the addition of the m_flags field, which used to indicate to the IP/Ethserver (Section 2.6.4) whether the MBufs holding a packet can be deleted once the packet istransmitted.2.4 PrimitivesThe first point of contact for all interprocess communication primitives in RHODOSis the Microkernel (Section 2.6.1), invoked by using the primitives described in this section.RHODOS provides two models of interprocess communication: message passing (send() andrecv()); and remote procedure calls (call(),recv(), and send()).2.4.1 The send() primitiveThe send() primitive (Block 3) is used to send a message from one process to another.It requires four arguments:•dest_port - the SName of the receiving (destination) port for the message;•return_port - the SName of a port where return messages can be sent;•send_args - a data structure holding the parameters of the send operation, such as thelocation of the user’s buffer, the length of that buffer, etc. Several of these structures can belinked together to issue a send operation using several buffers (termed a multibufferedsend);•send_results - a data structure that is populated with the results of the send operation such asthe total amount of data transmitted.2.4.2 The recv() primitiveThe recv() primitive (Block 4) is used to receive a message that has been delivered.The recv() primitive waits for a matching message to be delivered if necessary. It requires fourarguments:•dest_port- the SName of the destination port where the message is attached or will arrive;Block 2: The MBuf Data StructureThe Reimplementation of the RRDP Transport ProtocolBlock 3: The RHODOS send() Primitive•return_port - an SName structure that can optionally be used to place restrictions on the return port;•recv_args - a data structure holding the parameters of the receive operation, such as the location of the user’s buffer, the length of that buffer, etc. Several of these structures can be linked together to issue a receive operation using several buffers (termed a multibuffered receive);•recv_results - a data structure that is populated with the result of the receive operation such as the total amount of data received.Block 4: The RHODOS recv() Primitive2.4.3 The call() primitiveThe call() primitive (Block 5) is used to provide remote procedure calls. Although the call() primitive is an atomic system call, it is logically composed of a call to the send() primitive, followed by a call to the recv() primitive. The call() primitive requires four arguments:•dest_port - the SName of the destination port for the RPC (the process providing the service);•call_args - a data structure holding the parameters of the call operation, such as the location of the user’s buffers for both the request and response, the length of each of those buffers, etc. Several of these structures can be linked together to issue a multi-buffer request;•call_results - a data structure that is populated with the results of the call operation such as the total amount of data transmitted and received.2.5 Remote Interprocess CommunicationTwo paths are used for remote interprocess communication in RHODOS. In the default path, messages are transmitted reliably using the RRDP protocol. RRDP also provides an unreliable service (see Section 3.6) if the use of a reliable protocol is deemed to be too expensive. The second delivery mechanism involves the use of the “Fast Eth” protocol. Fast Page 4The Reimplementation of the RRDP Transport ProtocolBlock 5: The RHODOS call() PrimitiveEth is an extremely light weight (unreliable) protocol, located directly over the Ethernet layer. Due to its placement, the Fast Eth protocol can only be used for communications within a subnet. The Fast Eth protocol is not relevant to this report and will not be discussed any further.A process sends a message in RHODOS by invoking the send() primitive (Section2.4.1). If the destination port for a message is local, the message is delivered as described in Section 2.1. If the destination port is not local, then the message is forwarded to the IPCM for resolution. The IPCM first determines the destination for the message (see Section2.6.2), and then forwards the message to the RRDP server, along with the address of the workstation for the message to be sent to. The RRDP server transmits the message by splitting the message into packets, and forwarding the MBufs (Section2.3) holding the packets to the IP/Eth server. Finally the IP/Eth server transmits the packets on the network.Any RRDP packets arriving from the network (received by IP/Eth), are passed up to the RRDP server, which reconstructs the incoming message and forwards it to the local IPCM for delivery to the destination port. These mechanisms are depicted in Figure1. It is important to realise that the message is only copied once, either from the user’s buffer into MBufs during a send operation, or from MBufs into the user’s buffer during a receive operation. A message or packet is forwarded between servers by passing a pointer to the MBufs that hold the message/packet.Figure 1: Structure of Remote Interprocess Communication in RHODOSPage 5The Reimplementation of the RRDP Transport Protocol2.6 The Roles of RHODOS Components in Remote Interprocess CommunicationThe servers involved in providing remote IPC are described in this section. In particular, the roles of the Microkernel, IPCM and IP/Eth servers are presented. Communication between the RRDP server and other servers are also described. An overview of interactions with the RRDP server can be seen in Figure 2.2.6.1 The MicrokernelThe first point of contact for all RHODOS interprocess communication is the Microkernel (Section 2.4). When a new message is received, the Microkernel checks that the return port is valid (checks that it exists locally), and then determines whether or not the destination port exists locally. If the destination port is local, then the message is attached using the oper structure described in Section 2.1. If the destination port it is not local, the message is packed into MBufs (Section 2.3) and forwarded to the IPCM for resolution.Messages are packed into MBufs by the Microkernel in sequences such that they can be easily divided into separate chains equal to the length of the data part of an RRDP packet. This means that the Ethernet, IP, and RRDP packet headers (see Section 3.1) can be attached to the data without needing to move any data between MBufs to fully utilise a packet.When a message arrives at a destination workstation, the IPCM delivers the message by using the send() primitive. The IPCM’s call to send() is different to usual, in that the return port is not checked to see if it exists locally, and the message is stored in MBufs. This allows the IPCM to deliver messages from remote hosts, specifying a remote SName as the return port if necessary. The message is attached to the destination port using the oper structure described in Section 2.1. The Microkernel then attempts to pair the new message with any blocked receive operations.2.6.2 IPCMThe IPCM is responsible for the delivery of messages destined for ports that do not exist locally. The IPCM always receives messages in MBufs, either from the Microkernel for outgoing messages, or from the RRDP server for incoming messages. When a message arrives for remote delivery, the IPCM first sends the message to the workstation where the destination port was created (the port’s origin). If the port has not been migrated, then the port will exist on that workstation and the message is delivered.If the port has been migrated, the remote IPCM returns the message to the source IPCM, along with the workstation where the port currently exists. The source IPCM stores a mapping for the port for future messages, and the message is sent to the new workstation [De Paoli1996].To transmit an outgoing message, the IPCM forwards the message to the RRDP server, along with additional information identifying the source workstation of the message, the return (source) port and destination port origin and object numbers, and the quality of service required for delivery of the message. The RRDP server later returns an acknowledgement to the IPCM to indicate the success or failure of delivery of the message to the remote workstation.Page 6The Reimplementation of the RRDP Transport ProtocolPage 7The sending process invokes send() for a message destined to a remote port. The message is forwarded to the IPCM for resolution.The IPCM forwards the message to RRDP with the address where the message is to be sent.The RRDP server splits the message into packets and forwards the packets to IP/Eth for resolution.The IP/Eth server on the sending workstation sends the packets to the remote workstation, received by the remote IP/Eth server .The first group is forwarded to the remote RRDP , which returns an acknowledgement to the sending RRDP server.The second (and last) group of packets is sent to the remote workstation.The last group is forwarded to the remote RRDP server.The RRDP server returns an acknowledgement to the sending RRDP server and then forwards the reconstructed message to the IPCM.The message is forwarded to the receiving process.Sender IPCM RRDP IP/Eth IP/Eth RRDP IPCM Receiver Figure 2: Overview of Remote Interprocess Communication with RRDP in RHODOSThe Reimplementation of the RRDP Transport ProtocolPage 8The IPCM receives incoming messages from the RRDP server, along with theadditional information provided to RRDP by the source IPCM. The IPCM checks for the existence of the destination port on the local workstation, and if the port exists it forwards the message to the destination process using the send() primitive as discussed in Section 2.6.1. If the port does not exist locally, and has not existed locally and then been migrated to another workstation, the IPCM notifies the source IPCM that the destination port was invalid.2.6.3 RRDPThe RRDP server is responsible for delivering messages between workstations. This includes the division of messages into packets (although this is helped by the Microkernel as discussed in Section 2.6.1), reliable delivery of the packets to the remote workstation, and reconstruction of the original message on the remote workstation. RRDP is discussed in depth in Section 3.2.6.4 IP/EthThe IP/Eth server receives packets for transmission from the RRDP server, stored in chains of MBufs. The data in the first MBuf of each chain begins with the IP header for the outgoing packet, with the protocol number and destination address fields filled in by the RRDP server. The IP/Eth server populates the remaining fields of the IP address, attaches an Ethernet header, and queues the packet for transmission by the Ethernet device driver.Any RRDP packets that arrive from the network are packed into MBufs and forwarded to the RRDP server. The RRDP packets are identified by the protocol number field in the IP header (see Figure 3). The ICMP [Postel1981] and IGMP [Deering1989] protocols are also partially supported. All other packets addressed to the workstation are ignored.3 The RRDP ProtocolThe RRDP Protocol is a reliable datagram based transport protocol developed using the concept of a multidatagram protocol. RRDP was initially built upon UDP [Goscinski et al1990], but UDP has since been removed from the model. A datagram based, connectionless protocol was selected for its high performance and low setup overheads. This section presents a description of the implementation of the RRDP protocol.3.1 RRDP Packet StructureThe structure of RRDP packets, as with other network protocols, involves a header part and a data part. The header is shown in Figure 3. The Ethernet and IP protocols are well documented by other literature and will not be addressed here. The value of the protocol field in the IP header is given a value that is recognised by RHODOS workstations as the RRDP protocol. The value used in this field is unimportant, except it cannot be a protocol number used by any other workstations on the network.The RRDP header is composed of 13 fields (see Figure 3). The message number, source location,destination origin,destination object,source origin, and source object fields are supplied by the RHODOS Interprocess Communications Manager (IPCM). The DCM Message Number and DCM Origin fields are set by the Data Collection Manager [Wickham1997].The message number field uniquely identifies every outgoing message from a particular workstation. The message number is generated by a simple counter mechanism maintained by the IPCM. The source location field identifies the workstation that is currently transmitting a message. The destination origin and object fields are used to identify the destination port SName. The source origin andobject fields are used to identify the SName of the return port provided by the sending process.1The group number field is initially given the value of 0 and incremented before the transmission of a new group, hence the first group transmitted is group 1. The sequence bit field is initially set at the least significant bit, and left shifted once to identify each packet in the group. Each of these identifiers are then combined to form a “bitmap” of the packets that have arrived at the destination workstation. This bitmap is returned in the sequence bit field as part of the acknowledgement. The version field is reserved for future use. The quality of service field indicates whether a message is being transmitted reliably or not (see Section 3.6). The1.the format used for representing the IP header in this diagram was adapted from [T anenbaum 1996].Figure 3: RRDP Packet Header 1type of packetfield indicates whether a packet is a data packet, or acknowledgement packet. Finally, the padding field is used to align the data section to a 32-bit boundary.3.2 Packet GroupsThe original proposal for the RRDP protocol [Goscinski et al1989] was a stop-and-wait protocol where an acknowledgement was required for each packet transmitted. In an effort to reduce the number of acknowledgments in RRDP, a multidatagram approach was introduced, where several packets are transmitted before an acknowledgement is required (Figure 4).Figure 4: Multidatagram protocol with group size 4The number of packets transmitted in a group can be any value between 1 (which causes RRDP to revert to a stop-and-wait protocol) and 32. These limits are imposed by size of the sequence bit field of the RRDP header which is 32-bits. Figure 5 demonstrates the relation between group size and message turnaround time for message sizes varying from 10k to 100k, increasing by 10k increments.It can be seen that as group sizes are increased, minimal turn around times are reached for larger messages. Once the optimal value for a message size is reached, it remains much the same for the remaining group sizes. For example, a message size of 10k reaches an optimal reading at a group size of 9, whereas a message of 100k reaches its minimum value at a group size of approximately 29 packets.However, it was also found that the larger the group size, the higher the number of buffer overruns (missed packets) in the Ethernet handler. This problem can be attributed to the network congestion that is caused by releasing such a large number of packets in quick succession, and a lack of support for flow control to prevent this problem. There are two alternatives that can be used to reduce this problem: the size of the Ethernet handler’s receive buffer can be increased, or the group size can be reduced. However these alternatives do not resolve the lack of flow control that causes this problem, thus they are not solutions. Support for flow control is the subject of future research in RRDP.An arbitrary group size of 29 has been selected for its optimal time values up to a 100k message size, but no true optimal value will be able to be found until flow control is introduced to the protocol.3.3 Sending MessagesNew messages are received by the RRDP server from the IPCM in a single chain of MBufs. This chain is immediately separated into several smaller chains, each no longer than the maximum data payload length of an RRDP packet. This procedure is assisted by the way that the Microkernel packs a message into MBufs (discussed in Section 2.6.1).An entry is added into RRDP’s internal state tables, and the first group of packets is transmitted by passing chains of MBufs containing the packets to IP/Eth (see Section 2.6.4). The send state table entry (STE) is marked as waiting for an acknowledgement and RRDP continues to accept messages. If no acknowledgement arrives within a specified period, a timeout occurs and the packets of that group are retransmitted. The value of the timeout is currently set to an arbitrary value of 200ms, and is the subject of future research.Whenever a timeout occurs and packets are retransmitted, the timeout is reset to twice the value of previous setting, and after five timeouts it is decided that the message is undeliverable. If an acknowledgement does arrive, the timeout value is reset to the initial 200ms, and the process repeats.When an acknowledgement arrives and there are packets that haven’t been acknowledged as having arrived safely, those missing packets are immediately retransmitted。

pLKOshRNA病毒质粒载体构建protocol⽅法详解Search for Plasmids:Home Deposit Plasmids Request PlasmidsInformationBrowseSearchPricingFAQProtocols > pLKO.1 ProtocolpLKO.1 - TRC Cloning VectorAddgene Plasmid 10878. Protocol Version 1.0. December 2006.Copyright Addgene 2006, All Rights Reserved. This protocol is provided for yourconvenience. See warranty information in appendix.Click here for a printable copy.Table of ContentsA. pLKO.1-TRC Cloning Vectoro A.1 The RNAi Consortiumo A.2 Map of pLKO.1o A.3 Related plasmidsB. Designing shRNA Oligos for pLKO.1o B.1 Determine the optimal 21-mer targets in your geneo B.2 Order oligos compatible with pLKO.1C. Cloning shRNA oligos into pLKO.1o C.1 Recommended materialso C.2 Annealing oligoso C.3 Digesting pLKO.1 TRC-Cloning Vectoro C.4 Ligating and transforming into bacteriaD. Screening for Insertso D.1 Recommended materialsPlasmid CartYour cart is empty.Recently ViewedpLKO.1 - TRC clo...Plasmid 10878pLVTHMPlasmid 12247Mammalian RNAi T...Collectiono D.2 Screening for insertsE. Producing Lentiviral Particleso E.1 Recommended materialso E.2 Protocol for producing lentiviral particles ? F. Infecting Target Cellso F.1 Recommended materialso F.2 Determining the optimal puromycin concentrationo F.3 Protocol for lentiviral infection and selection ?G. SafetyH. Referenceso H.1 Published articleso H.2 Web resourcesI. Appendixo I.1 Sequence of pLKO.1 TRC-Cloning Vectoro I.2 Recipeso I.3 Warranty informationBack to TopA. pLKO.1-TRC Cloning VectorA.1 The RNA i ConsortiumThe pLKO.1 cloning vector is the backbone upon which The RNAi Consortium (TRC) has built a library of shRNAs directed against 15,000 human and 15,000 mouse genes. Addgene is working with the TRC to make this shRNA cloning vector available to the scientific community. Please cite Moffat et al., Cell 2006 Mar; 124(6):1283-98 (PubMed) in all publications arising from the use of this vector.A.2 Map of pLKO.1pLKO.1 is a replication-incompetent lentiviral vector chosen by the TRC for expression of shRNAs. pLKO.1 can be introduced into cells via direct transfection, or can be converted into lentiviral particles for subsequent infection of a target cell line. Once introduced, the puromycin resistance marker encoded in pLKO.1 allows for convenient stable selection.A.3 Related ProductsThe following plasmids available from Addgene are recommended for use in conjunction with the pLKO.1 TRC-cloning vector.Note: pLKO.1 can also be used with packaging plasmid pCMV-dR8.2 dvpr (Addgene #8455) and envelope plasmid pCMV-VSVG (Addgene#8454) from Robert Weinberg's lab. For more information, visit Addgene's Mammalian RNAi Tools page.Several other laboratories have deposited pLKO derived vectors that may also be useful for your experiment. To see these vectors, visit Addgene's website and search for "pLKO".Back to TopB. Designing shRNA Oligos for pLKO.1B.1 Determining the Optimal 21-mer Targets in your GeneSelection of suitable 21-mer targets in your gene is the first step toward efficient gene silencing. Methods for target selection are continuously being improved. Below are suggestions for target selection.1. Use an siRNA selection tool to determine a set of top-scoring targets for your gene. For example, the Whitehead Institute for Biomedical Research hosts an siRNA Selection Program that can be accessed after a free registration(/doc/c66f21e6f8c75fbfc77db279.html /bioc/siRNAext/). If you have MacOS X, another excellent program is iRNAi, which is provided free by the company Mekentosj(/doc/c66f21e6f8c75fbfc77db279.html /irnai/).A summary of guidelines for designing siRNAs with effective gene silencing is included here:Starting at 25nt downstream of the start codon (ATG), search for 21nt sequences that match the pattern AA(N19). If no suitablematch is found, search for NAR(N17)YNN, where N is anynucleotide, R is a purine (A,G), and Y is a pyrimidine (C,U).G-C content should be 36-52%.Sense 3' end should have low stability – at least one A or T between position 15-19.Avoid targeting introns.Avoid stretches of 4 or more nucleotide repeats, especially repeated Ts because polyT is a termination signal for RNA polymerase III.2. To minimize degradation of off-target mRNAs, use NCBI's BLAST program. Select sequences that have at least 3 nucleotide mismatches to all unrelated genes.Addgene recommends that you select multiple targetsequences for each gene. Some sequences will be more effectivethan others. In addition, demonstrating that two different shRNAsthat target the same gene can produce the same phenotype willalleviate concerns about off-target effects.B.2 Ordering Oligos Compatible with pLKO.1To generate oligos for cloning into pLKO.1, insert your sense and antisense sequences from step B.1 into the oligos below. Do not change the ends; these bases are important for cloning the oligos into the pLKO.1 TRC-cloning vector.Forward oligo:5' CCGG—21bp sense—CTCGAG—21bp antisense—TTTTTG 3'Reverse oligo:5' AATTCAAAAA—21bp sense—CTCGAG—21bp antisense 3'For example, if the target sequence is (AA)TGCCTACGTTAAGCTATAC, the oligos would be:Forward oligo:5'CCGG AATGCCTACGTTAAGCTATAC CTCGAG GTATAGCTTAACGTA GGCATT TTTTTG 3'Reverse oligo:5'AATTCAAAAA AATGCCTACGTTAAGCTATAC CTCGAG GTATAGCTTA ACGTAGGCATT 3'Back to TopC. Cloning Oligos into pLKO.1The pLKO.1-TRC cloning vector contains a 1.9kb stuffer that is releasedupon digestion with EcoRI and AgeI.The oligos from section B contain the shRNA sequence flanked by sequences that are compatible with the sticky ends of EcoRI and AgeI. Forward and reverse oligos are annealed and ligated into the pLKO.1 vector, producing a final plasmid that expresses the shRNA of interest.C.1 Recommended MaterialsC.2 A nnealing Oligos1. Resuspend oligos in ddH2O to a concentration of 20 µM, then mix:5 µL Forward oligo5 µL Reverse oligo5 µL10x NEB buffer 235 µL ddH2O2. Incubate for 4 minutes at 95o C in a PCR machine or in a beaker of boiling water.3. If using a PCR machine, incubate the sample at 70o C for 10 minutes then slowly cool to room temperature over the period of several hours. If using a beaker of water, remove the beaker from the flame, and allow the water to cool to room temperature. This will take a few hours, but it is important for the cooling to occur slowly for the oligos to anneal.C.3 Digesting pLKO.1 TRC Cloning Vector1. Digest pLKO.1 TRC-cloning vector with AgeI. Mix:6 µg pLKO.1 TRC-cloning vector (maxiprep or miniprep DNA)5 µL10x NEB buffer 11 µL AgeIto 50 µL ddH2O> Incubate at 37o C for 2 hours.2. Purify with Qiaquick gel extraction kit. Elute in 30 µL of ddH2O.3. Digest eluate with EcoRI. Mix:30 µL pLKO.1 TRC-cloning vector digested with AgeI5 µL10x NEB buffer for EcoRI1 µL EcoRI14 µL ddH2O> Incubate at 37o C for 2 hours.4. Run digested DNA on 0.8% low melting point agarose gel until you can distinctly see 2 bands, one 7kb and one 1.9kb. Cut out the 7kb band and place in a sterile microcentrifuge tube.When visualizing DNA fragments to be used for ligation, useonly long-wavelength UV light. Short wavelength UV light willincrease the chance of damaging the DNA.5. Purify the DNA using a Qiaquick gel extraction kit. Elute in 30 µL of ddH2O.6. Measure the DNA concentration.C.4 Ligating and Transforming into Bacteria1. Use your ligation method of choice. For a standard T4 ligation, mix:2 µL annealed oligo from step C.2.20 ng digested pLKO.1 TRC-cloning vector from step C.3. (If you were unable to measure the DNA concentration, use 1 µL) 2 µL10x NEB T4 DNA ligase buffer 1 µL NEB T4 DNA ligaseto 20 µL ddH2O> Incubate at 16o C for 4-20 hours.2. Transfo rm 2 µL of ligation mix into 25 µL competent DH5 alpha cells, following manufacturer's protocol. Plate on LB agar plates containing 100 µg/mL ampicillin or carbenicillin (an ampicillin analog).Back to TopD. Screening for InsertsYou may screen for plasmids that were successfully ligated by restriction enzyme digestion. However, once you have identified the positive clones, it is important to verify the insert by conducting a sequencing reaction.D.1 Recommended MaterialsD.2 Screening for InsertsDay 1:1. Innoculate 5 colonies from each ligation into LB + 100 µg/mLampicillin or carbenicillin.Day 2:2. Spin down the cultures and use a miniprep kit to obtain DNA.3. Conduct a restriction digest with EcoRI and NcoI:1 µg miniprep DNA2 µL10x NEB buffer for EcoRI0.8 µL EcoRI0.8 µL NcoIto 20 µL ddH2O> Incubate at 37o C for 1-2 hours.4. Run the digestion products on a 1% agarose gel. You shouldsee two fragments, a 2kb fragment and a 5kb fragment.5. Sequence positive clones with pLKO.1 sequencing primer (5'CAA GGC TGT TAG AGA GAT AAT TGG A 3').You may need to adjust the sequencing conditions if theDNA polymerase has difficulty reading through thesecondary structure of the hairpin sequence.Back to TopE. Producing Lentiviral ParticlesBefore this step, you must contact your institution's Bio-Safety office to receive permission and institution-specific instructions. You must follow safety procedure s and work in an environment (e.g. BL2+) suitable for handling HIV-derivative viruse s.For transient knockdown of protein expression, you may transfect plasmid DNA directly into the target cells. The shRNA will be expressed, but the DNA is unlikely to be integrated into the host genome.For stable loss-of-function experiments, Addgene recommends that you generate lentiviral particles and infect the target cells. Addition of puromycin will allow you to select for cells that stably express your shRNA of interest.E.1 Recommended MaterialsNote: pLKO.1 could also be packaged using pCMV-dR8.2 dvpr and pCMV-VSVG from the Robert Weinberg lab. For more information, visit Addgene's Mammalian RNAi Tools page.E.2 Protocol for Producing Lentiviral ParticlesThis protocol is for transfection in a 6 cm plate. The protocol can be scaled to produce different amounts of virus as needed. Day 1:a. For each plasmid to be transfected, plate 7x105 HEK-293T cellsin 5 mL of media in a 6 cm tissue culture plate. Incubate cells at37o C, 5% CO2 overnight.Although cells should regularly be passaged in DMEM +10% FBS with penicillin/streptomycin, cells should beplated at this step in DMEM + 10% FBS without antibiotics(no penicillin or streptomycin).Day 2:b. Perform the transfection in the late afternoon because thetransfection mix should only be incubated with the cells for 12-15hours.c. In polypropylene microfuge tubes (do NOT use polystyrenetubes), make a cocktail for each transfection:1 µg pLKO.1 shRNA plasmid750 ng psPAX2 packaging plasmid250 ng pMD2.G envelope plasmidto 20 µl serum-free OPTI-MEMYou may want to vary the ratio of shRNA plasmid,packaging plasmid, and envelope plasmid to obtain theratio that gives you the optimal viral production.d. Create a master mix of FuGENE? 6 transfection reagent inserum-free OPTI-MEM. Calculate the amount of Fugene? andOPTI-MEM necessary given that each reaction will require 6 µLFuGENE? + 74 µL OPTI-MEM. For example:1x master mix: 6 µL FuGENE? + 74 µL OPTI-MEM5x master mix: 30 µL FuGENE? + 370 µL OPTI-MEM10x master mix: 60 µL FuGENE? + 740 µL OPTI-MEM In a polypropylene tube, add OPTI-MEM first. Pipette FuGENE? directly into the OPTI-MEM - do not allow FuGENE? to come incontact with the walls of the tube before it has been diluted. Mix byswirling or gently flicking the tube. Incubate for 5 minutes at roomtemperature.e. Add 80 µL of FuGENE? master mix to each tube from step c fora total volume of 100 µL. Pipette master mix direct ly into the liquidand not onto the walls of the tube. Mix by swirling or gently flickingthe tube.f. Incubate for 20-30 minutes at room temperature.g. Retrieve HEK-293T cells from incubator. The cells should be50-80% confluent and in DMEM that does not contain antibiotics.h. Without touching the sides of the dish, gently addDNA:FuGENE? mix dropwise to cells. Swirl to disperse mixtureevenly. Do not pipette or swirl too vigorously, as you do not wantto dislodge the cells from the plate.i. Incubate cells at 37o C, 5% CO2 for 12-15 hours.Day 3:j. In the morning, change the media to remove the transfectionreagent. Replace with 5 mL fresh DMEM + 10% FBS +penicillin/streptomycin. Pipette the media onto the side of the plateso as not to disturb the transfected cells.k. Incubate cells at 37o C, 5% CO2 for 24 hours.Day 4:l. Harvest media from cells and transfer to a polypropylenestorage tube. The media contains your lentiviral particles. Store at4o C.m. Add 5 mL of fresh media containing antibiotics to the cells andincubate at 37o C, 5% CO2 for 24 hours.Day 5:n. Harvest media from cells and pool with media from Day 4. Spinmedia at 1,250 rpm for 5 minutes to pellet any HEK-293T cellsthat were inadvertently collected during harvesting.In lieu of centrifugation, you may filter the media througha 0.45 µm filter to remove the cells. Do not use a 0.2 µmfilter, as this is likely to shear the envelope of your virus.o. Virus may be stored at 4o C for a few days, but should be frozenat -20o C or -80o C for long-term storage.Freeze/thaw cycles decrease the efficiency of the virus,so Addgene recommends that you use the virusimmediately or aliquot the media into smaller tubes toprevent multiple freeze/thaw cycles.Back to TopF. Infecting Target CellsLentiviral particles can efficiently infect a broad range of cell types, including both dividing and non-dividing cells. Addition of puromycin will allow you to select for cells that are stably expressing your shRNA of interest.F.1. Recommended Materials* Detailed protocols for preparing polybrene, protamine sulfate, andpuromycin are located in the Appendix.F.2. Determining the Optimal Puromycin ConcentrationEach cell line responds differently to puromycin selection. Addgene strongly recommends that you determine the optimal puromycin concentration for your cell line before initiating your experiment.Day 1:a. Plate target cells in ten 6 cm plates and grow at 37o C, 5% CO2overnight.Day 2:b. The target cells should be approximately 80-90% confluent.c. Dilute puromycin in the preferred culture media for your targetcells. The final concentration of puromycin should be from 1-10µg/mL in 1 µg/mL increments.d. Label plates from 1-10 and add appropriatepuromycin-containing media to cells.Days 3+:e. Examine cells each day and change to freshpuromycin-containing media every other day.f. The minimum concentration of puromycin that results in complete cell death after 3-5 days is the concentration that should be used for selection in your experiments. (You may wish to repeat this titration with finer increments of puromycin to determine a more precise optimal puromycin concentration.)F.3. Protocol for Lentiviral Infection and SelectionDay 1:a. Plate target cells and incubate at 37o C, 5% CO2 overnight. Day 2:b. Target cells should be approximately 70% confluent. Change to fresh culture media containing 8 µg/mL polybrene.Polybrene increases the efficiency of viral infection. However, polybrene is toxic to some cell lines. In these cell lines, substitute protamine sulfate for polybrene.c. Add lentiviral particle solution from step E. For a 6 cm target plate, add between 0.05-1 mL virus (add ≥0.5 mL for a high MOI, and ≤0.1 mL for a low MOI). Scale the amount of virus a dded depending on the size of your target plate.MOI (multiplicity of infection) refers to the number ofinfecting viral particles per cell. Addgene recommends thatyou test a range of MOIs to determine the optimal MOI for infection and gene silencing in your target cell line.d. Incubate cells at 37o C, 5% CO2 overnight.Day 3:e. Change to fresh media 24 hours after infection.If viral toxicity is observed in your cell line, you maydecrease the infection time to between 4 - 20 hours.Remove the virus-containing media and replace with freshmedia. Do not add puromycin until at least 24 hours afterinfection to allow for sufficient expression of the puromycinresistance gene.f. To select for infected cells, add puromycin to the media at theconcentration determined in step E.2.Addgene recommends that you maintain one uninfectedplate of cells in parallel. This plate will serve as a positivecontrol for the puromycin selection.Days 4+:g. Change to fresh puromycin-containing media as needed everyfew days.h. Assay infected cells. The following recommendations areguidelines for the number of days you should wait until harvestingyour cells. However, you should optimize the time based on yourcell line and assay:Assay Days post-infectionmRNA knockdown (quantitative PCR) ≥ 3 daysProtein knockdown (western blot) ≥ 4 daysPhenotypic assay ≥ 4 daysBack to TopG. SafetyBL2 safety practices should be followed when preparing and handling lentiviral particles. Personal protective clothing should be worn at all times. Use plastic pipettes in place of glass pipettes or needles. Liquid waste should be decontaminated with at least 10% bleach. Laboratory materials that come in contact with viral particles should be treated as biohazardous waste and autoclaved. Please follow all safety guidelines from your institution and from the CDC and NIH for work in a BL2 facility.If you have any questions about what safety practice to follow, please contact your institution's safety office.To obtain the MSDS for this product, visit /doc/c66f21e6f8c75fbfc77db279.html /sitemap and follow the MSDS link.Back to TopH. ReferencesH.1. Published A rticlesKhvorova A et. al. 2003. Functional siRNAs and miRNAs exhibit strand bias. Cell 115:209-216. (PubMed)Moffat J et. al. 2006. A lentiviral RNAi library for human and mouse genes applied to an arrayed viral high-content screen. Cell 124:1283-1298. (PubMed)Naldini L et. al. 1996. In vivo gene delivery and stable transduction of nondividing cells by a lentiviral vector. Science 272:263-267. (PubMed)Schwarz DS et. al. 2003. Asymmetry in the assembly of the RNAi enzyme complex. Cell 115:199-208. (PubMed)Stewart SA et. al. 2003. Lentivirus-delivered stable gene silencing by RNAi in primary cells. RNA 9(4):493-501. (PubMed) Zufferey R et. al. 1997. Multiply attenuated lentiviral vector achieves efficient gene delivery in vivo. Nat Biotechnol 15(9):871-5. (PubMed)Zufferey R et. al. 1998. Self-inactivating lentivirus vector for safe and efficient in vivo gene delivery. J Virol 72(12):9873-80. (PubMed)H.2. Web resourcesAddgene's mammalian RNAi website: /doc/c66f21e6f8c75fbfc77db279.html /rnaitoolsThe RNAi Consortium (TRC):/doc/c66f21e6f8c75fbfc77db279.html /genome_bio/trc/rnai.htmlBackground on RNAi mechanism:/doc/c66f21e6f8c75fbfc77db279.html /focus/rnai/animations/animation/animation.htm Whitehead siRNA Selection Program: /doc/c66f21e6f8c75fbfc77db279.html /bioc/siRNAext/ Mekentosj iRNAi Program: /doc/c66f21e6f8c75fbfc77db279.html /irnai/Back to TopI. AppendixI.1. Sequence of pLKO.1 TRC-Cloning VectorClick here (/doc/c66f21e6f8c75fbfc77db279.html /10878) to see the sequence of pLKO.1 TRC-cloning vector. The vector is 8901 base pairs total, and the stuffer insert is shown in all capital letters.I.2. RecipesLuria Broth Agar (LB agar) + antibioticPer 40 grams of powder from American Bioanalytical catalog #AB01200-02000, LB contains:10g tryptone5g yeast extract10g sodium chloride15g agar> Prepare LB agar solution by dissolving 40g of LB powder in 1Lof distilled water. Autoclave and cool to 55o C. Add 1mL of100mg/mL ampicillin or carbenicillin to obtain a final concentrationof 100 µg/mL antibiotic. Pour plates and store at 4o C.Hexadimethrine Bromide (Polybrene)Prepare a 1mg/mL solution of polybrene (Sigma-Aldrich catalog #H9268) in 0.9% NaCl. Autoclave to sterilize. Stock solution is stable at 4o C for up to one year. The powder form of polybrene is stable at 4o C for several years.Protamine SulfateStore protamine sulfate (MP Biomedicals catalog #194729) at 4o C. Freely soluble in hot water and slightly soluble in cold water.PuromycinPrepare a 50mg/mL stock solution of puromycin (Sigma-Aldrich catalog #P8833) in distilled water. Sterilize by passing through a 0.22 µm filter. Store aliquots at -20o C.I.3. Warranty InformationAddgene is committed to providing scientists with high-quality goods and services. Addgene makes every effort to ensure the accuracy of its literature, but realizes that typographical or other errors may occur. Addgene makes no warranty of any kind regarding the contents of any literature. Literature are provided to you as a guide and on an "AS IS" "AS AVAILABLE" basis without warranty of any kind either expressed or implied, including but not limited to the implied warranties of fitness for a particular purpose, non-infringement, typicality, safety and accuracy.The distribution of any literature by Addgene is not meant to carry with it, and does not grant any license or rights of access or use to the materials described in the literature.The distribution of materials by Addgene is not meant to carry with it, and does not grant any license, express or implied, under any patent. All transfers of materials from Addgene to any party are governed by Addgene's Terms of Use, Addgene's Terms of Purchase, and applicable Material Transfer Agreements between the party that deposited the material at Addgene and the party receiving the material.Back to TopHome | Contact | Terms of Use | Privacy Policy | Site Map。

CRISPR/Cas9系统操作说明-2 ---基于lentiCRISPR v2应用指南-载体构建和建系汉恒生物提供CRISPR/Cas9载体的快速构建试剂盒，同时也提供各种载体构建和病毒包装（慢病毒、腺病毒和AAV）、建系服务lentiCRISPR v2载体是张锋实验室发布一个慢病毒载体，cas9和sgRNA 表达框在同一各载体上。

而且Cas9的C 端带有FLAG 融合标签，载体包含Puromycin 抗性基因，适合建系。

验证sgRNA 活性的时候也适合顺转；包装成慢病毒适合常规细胞系的建系。

构建非常方便。

说明lentiCRISPR v2https:///52961/☐克隆gDNA 使用BsmBI 位点，载体可以切出一个~1.9 kb 的filler 片段，便于confirm 酶切成功并利于载体回收；☐BsmBI 的位点是，酶切之后不需要CIP 脱磷也不会自连！☐Cas9的COOH 端带有FLAG tag,可以WB 或者Immunostaining；☐EFS promoter 被优化的小而强，极大提高了慢病毒包装的效率；☐载体带有Puromycin 抗性，可以富集转染/感染成功的细胞。

☐gDNA 设计方法和原则请参考上第一篇“CRISPR/Cas9系统操作说明”，链接如下：☐对于lentiCRISPR v2克隆，其合成的oligo 末端和pX330不同，请注意设计；☐怕大家看不懂，举个例子说明（克隆小白千万注意oligo 的方向）：gDNA 设计说明载体克隆说明☐Backbone的酶切体系同上一篇文章（说明：不脱磷处理参考黑框，脱磷参考红框内操作）；☐Oligo的退火条件也参考上一篇文章（说明：如果载体不脱磷，oligo不需要磷酸化；载体脱磷参考红框内操作，oligo就需要加磷处理！！！（红色框内是FengZhang提供的protocol，设计脱磷，可以参考））仅作参考病毒包装体系☐包装病毒使用的包装体系如下（for 100 mm dish ，6x106293T ）☐转染条件：用细胞转染试剂lipofiter （超便宜且好用）（汉恒生物，/cn/products/item/36，（或者lipo2000）DNA/lipofiter=1 μg ：2.5 μl☐收集48hr 和72hr 病毒上清，待用。

从树叶到药物——意大利公司实现抗癌药物生产的自动化
佚名
【期刊名称】《流程工业》
【年(卷),期】2004(000)007
【摘要】Indena开发新型药物，并且需要其工厂自动化的可行性方案。

这个系统不仅可用来控制生产流程。

而且能够管理仪器设备。

最后，公司发现了一个自动化方案，这个方案可以满足FDA的认证条款21CFRPan11的要求。

【总页数】1页(P46)
【正文语种】中文
【中图分类】TQ460.6
【相关文献】
1.百泰生物:抗体药物生产高起点赶超国际水平——访百泰生物药业有限公司董事长白先宏 [J], 刘晓琳
2.DeltaV批量控制在实现单抗药物生产中的应用 [J], 宁盼;焦尚彬;蒋能群;任志刚
3.如何应对小批量无菌生产——无菌灌装新技术实现小批量、中试药物生产线的自动化和灵活性 [J], Dieter Bandtel
4.DeltaV批量控制在实现单抗药物生产中的应用 [J], 宁盼;焦尚彬;蒋能群;任志刚;
5.铂类抗癌药物生产污水的处理探讨 [J], 陈文林; 彭娟; 吴富明; 焦澄; 贝玉祥; 程勇; 何键
因版权原因，仅展示原文概要，查看原文内容请购买。

Self-Organizing Networks:State-of-the-Art,Challenges and PerspectivesNicola Marchetti,Neeli Rashmi Prasad Center for TeleInFrastrukturAalborg University,DenmarkEmail:{nm,np}@es.aau.dk Johan Johansson,Tao Cai Huawei Technologies ABKista,SwedenAbstract—In this paper,a general overview of Self-Organizing Networks(SON),and the rationale and state-of-the-art of wireless SON arefirst presented.The technical and business requirements are then briefly treated,and the research challenges within the field of SON are highlighted.Thereafter,the relation between SON and Cognitive Networks(CN)is covered.At last,the application of Algorithmic Information Theory(AIT)as a pos-sible theoretical tool to support SON in addressing the growing complexity of networks is discussed.I.I NTRODUCTION TO S ELF-O RGANIZING N ETWORKS The phenomenon of self-organization is pervasive in many areas of life.In nature,e.g.,fish organize themselves to swim in well structured swarms,antsfind shortest routes to food sources,andfireflies emit lightflashes in a synchronized fashion.Other examples of self-organized behavior can be observed in economy,population dynamics,psychology,and brain theory.In all the above examples,the participating entities establish an organizational structure that does not require any central coordination.Instead,the entities interact directly with each other,reacting to changes in their local environment.Typically,such self-organizing systems are very flexible,adaptive,failure-robust,and scalable[1]. Lately,with the availability and analysis of volumes of traces and statistics on the behavior of nodes,two major approaches to describe complex networks have been proposed, related to the small world and scale-free concepts.Small world is a property observed in many systems,such as in society and communication networks,and refers to the fact that entities(e.g.people or network nodes)are closer than one may think.Most entities are connected such that the average path length between them is small,the entities tend to form clusters,and the connectivity distribution peaks at an average value,and then decays exponentially.Scale-free properties are those which do not change with the size of the system,that in our case is the network.A particular scale-free property is that the connectivity distributions follow the power law form. This means that the connectivity distribution in a scale-free network tends to remain the same irrespectively of the size of the network,even at different orders of magnitude.Simply stated,the average path length between any two entities does not increase,independently of how large the network grows[2],[3];this property is observed in many complex networks(e.g.the Internet).For Self-OrganizingNetworksFig.1.SON growth and preferential attachment properties.(SON)applied to wireless communications,the fundamental scale-free and small world properties are also set by the limited radio propagation range.Barabasi et al.[4],[5],[6],[7]used the following features of real networks to develop a scale-free network model(see Fig.1):•Real networks expand continuously by the addition of new nodes(growth property);•New nodes attach preferentially to nodes that are already well connected(preferential attachment property).The properties of growth and preferential attachment lead to the scale-free property and are typically exhibited by real large networks,and this is confirmed by observations revealing that,in general,in large networks most of the nodes have very few connections,and few nodes(called hubs)have many connections[8].The remaining part of the paper is organized as follows: in Section II one discusses wireless SON and their rationale; Section III revises the state-of-the-art,while Section IV dis-cusses the technical and business requirements and the chal-lenges within the wireless SON domain.The relation between SON and Cognitive Networks(CN)is treated in Section V. Afterwards,the application of Algorithmic Information TheoryFig.2.SON cycle.(AIT)to complex SON is suggested and motivated in Section VI,while Section VII concludes the paper.II.S ELF-O RGANIZING W IRELESS N ETWORKS AND THEIRR ATIONALEThe application of SON concepts to wireless networks has gained momentum recently;indeed SON are seen a key driver for improving Operation and Maintenance(OAM)as they can help to reduce the cost of installation and management by simplifying operational tasks through automated mechanisms targeting self-configuration,self-optimization and self-healing, which constitute the three main phases of the SON cycle(see Fig.2).The significance of the circle encompassing radio environment,measurements and self-optimization in Fig.2will be explained later on,in Section V.The self-configuration phase is triggered by incidental events of an intentional nature,e.g.the addition of a new site or the introduction of a new service or network feature. These upgrades generally require an initial(re)configuration of a number of radio parameters or resource management algorithms,e.g.pilot powers and neighbors’lists.These pa-rameters have to be set prior to operations and before they can be optimized as part of the continuous self-optimization process[9].In the self-optimization phase,intelligent methods apply to the processed measurements to derive an updated set of radio(resource management)parameters,including e.g. antenna parameters(tilt,azimuth),power settings(including pilot,control and traffic channels),neighbors’lists(cell IDs and associated weights),and other radio resource management parameters(admission/congestion/handover control and packet scheduling)[9].Triggered by incidental events of a non-intentional nature, such as the failure of a cell or site,self-healing methods aim to resolve the loss of coverage or capacity induced by such events to the extent possible.This is done by appropriately adjusting the parameters and algorithms in surrounding cells.Once the actual failure has been repaired,all parameters are restored to their original settings[9].SON are likely to have a relevant impact on Capital Expenditure(CAPEX)and Operational Expenditure(OPEX). Indeed,currently about17%of wireless operators CAPEX is spent on engineering and installation services[10],therefore the self-configuring functions can eliminate the on-site oper-ations for basic settings and updates,which will reduce the CAPEX.Also,since about24%of a typical wireless operator revenue goes to network OPEX[11],the self-optimizing functions of SON can help to reduce the workload associated with site survey and network performance analysis.Moreover, the energy saving functions derived by the application of SON will reduce the costs in terms of power consumed by the equipment.On top of this,self-optimization and self-healing will help to improve the user perceived quality,by optimizing network parameters and by mitigating quality degradations. However,the main rationale for wireless SON is not the current OPEX situation,but what is probable to happen next. For several reasons,it is likely that increasingly more cells will be small in the future:•significant new spectrum becomes available in the high frequencies range;•although there have been very significant advances in spectrum efficient communication,the main capacity growth during the life-time of cellular communication is due to increased network density;•the trend to optimize towards very high peak data rates limits the range of a cell.In the predicted scenario of cells becoming smaller and increasing in number,the network’s OPEX is becoming the major cost.One part of the OPEX problem is the OAM cost, which is directly related to the need of SON.In summary,for SON applied to wireless networks,the main driver is the outlook of increased cost,primarily OPEX,for emerging networks.III.S TATE-OF-THE-A RTA.Standardization Bodies and Research ForumsIn2007,Next Generation Mobile Networks(NGMN)Al-liance released a white paper highlighting several operational use cases where automatic procedures may be introduced in order to enable the vendors to identify solutions for improving the operational efficiency of next generation networks,where the3GPP network architecture has been considered[12]. Another document was released by NGMN on requirements of operators aiming to implement SON with focus on enablers, self-configuration,self-optimization,fault management,fault correction and SON-related OAM[13].Concerning standardization,3GPP has introduced SON items in its standardization path as required features for Long Term Evolution(LTE)deployments.In2008,3GPP released a document on self-configuring and self-optimizing network use cases and solutions[14].It was a part of the standardization work on evolved UMTS Terrestrial Radio Access Network(e-UTRAN),to study and specify the impact of self-organizationon architecture,protocols and measurements.3GPP release8 includes thefirst specifications on requirements,integration with operators processes,and identification of main use cases. Release9is expected to define advanced features,which will introduce self-healing and self-optimization capabilities into LTE[15].At a glance,the overall picture on SON-related standard-ization activities can be summarized as follows:•Standard progress:support for mobility related self-optimization(Automatic Neighbor Relation,Mobility Ro-bustness Optimization,Mobility Load Balancing),uplink Random Access Channel optimization,cell ID conflict resolution have been introduced in LTE releases8and9.Support for energy saving and coverage-related self-optimization is expected in release10.•Standards focus:3GPP focuses on interfaces,and thus on SON enabling measurements,control triggers and signal-ing interactions.Algorithms for control and optimization are out of the scope of the standard.•Work methodology:3GPP and NGMN discussions are all very use-case oriented,and each use-case is discussed separately,including architecture issues.So far there has been limited effort to handle interaction between use cases.•Architecture:According to3GPP principles and tradi-tion,to allow inexpensive,easy upgradable and testable implementation,the UE does not host any significant SON intelligence,which is instead located in the network.The interface between the RAN and its OAM system is not an open interface(except for Home evolved Node B(HeNB)/HNB).Although there have been significant efforts to standardize parts of the interface into the next level Network Management System(NMS),in principle the choice of network architecture for SON functions (centralized vs.distributed)is a vendor’s implementation choice.Signaling support on the X2interface among NodeBs has been introduced to allow for distributed solutions for most of the use cases addressed so far. B.European ProjectsThere are and there have been several on going projects at European level within the area of SON.Here we will mention some of the most prominent.SOCRATES[16]is an FP7project that aims to develop self-organization methods for enhancing the operation of wireless access networks,by integrating network planning,configura-tion and optimization into a single,mostly automated process requiring minimum manual intervention.3GPP LTE radio interface has been chosen as the central radio technology.4WARD[17]aims to research and develop an architecture for a Future Internet,in order to enable the co-existence of multiple networks on common platforms,through virtualiza-tion of networking resources.This will enhance the utility of networks,by making them capable of self-management and will also increase their robustness and efficiency,through leveraging diversity by using a novel transport approach.One improves the application support,by a new information-centric paradigm in place of the old host-centric approach.These solutions embrace a full range of technologies,fromfiber backbones to wireless and sensor networks.4WARD also addresses non-technical drivers focusing on society,business and government in order to provide input to the technical work. E3project[18]focuses on optimizing the use of radio resources and spectrum by employing cognitive radios and networks’paradigms whose characteristic features include re-configurability,self-adaptability,autonomous and collaborative behavior.The project studies the design of a Cognitive Radio (CR)system exploiting the capabilities of reconfigurable net-works and self-adaptation to a dynamically changing environ-ment.Collaborative CR resource management,spectrum man-agement and self-organization with focus on network-based decisions,autonomous functionalities and algorithms focusing on terminal-based decisions are some of the research areas. Apart from the system research on requirements,features and architecture,one also studies the business research,regulation and standardization.FUTON[19],is also investigating NMS aligned with the specifications for next generation networks,optimization of heterogeneous radio resources and fault tolerance aspects. The FUTON architecture comprises of hybrid radio-optical infrastructure,a central unit and mobile/wireless terminals.C.Academia and IndustryThere has been quite some activity on going in thefield of SON within academia,see e.g.[1],[3],[20],[21],and more recently e.g.[22]and[23];in particular the latter analyzes some methods to implement self optimization in LTE RAN system.In[23],how to make the system working in an optimized state is elaborated,especially for the co-existence of eNB,HeNB,3G HNB etc.Several major industrial partners have recently published white papers on SON,clearly indicating that the industry looks with attention to thisfield[24],[25],[26],[27].IV.R EQUIREMENTS AND C HALLENGESThe requirements to be met in order to develop the SON functionalities can be classified broadly into the following two categories:technical and business requirements.The purpose of specifying the technical requirements is to help in the development of novel algorithms and functionalities and to highlight the relevant network characteristics for self-organization.The list of the technical requirements to be addressed comprises:performance and complexity,stability, robustness,timing,interaction among SON functionalities, architecture and scalability,and required inputs.Defining the business requirements helps to consider factors related to the involved operational costs and incorporate them while developing the solutions.These requirements can be broadly classified into cost efficiency and deployment[28]. As per the important challenges for designing effective and dependable self-organization functionalities in future mobile radio networks,these include[29]:•Measurement and probing:this involves issues such as determining what kind of data are required,at what rate they should be collected,and also devising techniques for collecting them.There is a tradeoff between the optimal-ity of SON methods and the signaling cost associated for performing these processes;•Measurement/data processing:this deals with design-ing methods for appropriate processing of the collected measurements and also efficient handling of erroneous measurements’reports;•Incomplete,delayed and faulty feedback:this may affect the efficiency of the self-optimization process and should be considered while designing algorithms,introducing safety margins which might degrade the performance with respect to ideal case;•Reliability of SON methods:in order to minimize human intervention,the control decisions should be reliable and operate autonomously.As mentioned above,the reduction of operational efforts and complexity are key drivers for RANs in LTE.One of the important aspects concerning this is that the system oper-ability shall be improved under multi-vendor environment. With respect to this,it is important that measurements and performance data of different vendors share the same lan-guage.Such alignment eases network performance analysis and troubleshooting,and reduces efforts in maintaining the network at a properly working state.As we already stated,it is also of interest to minimize operational efforts by introducing self-configuring and self-optimizing mechanisms.Especially in the early deployment phase,the configuration and optimization efforts are signifi-cant and traditionally lead to lengthy periods for getting an optimum and stable system setup.It is thus essential to have the necessary set of self-configuration and self-optimization mechanisms already available when initial deployment starts. From the discussion above,we can see that standardization is asked to define the necessary measurements,procedures and open interfaces to support better operability under multi-vendor environment.Such standardized functions shall also facilitate self-configuration and self-optimization.Especially the interaction between self-configuring/optimizing networks and OAM has to be considered[14].V.R ELATION BETWEEN S ELF-O RGANIZING ANDC OGNITIVE N ETWORKSCognitive Networks(CN)are formed by spatially distributed nodes that are linked together through a connection topology. The nodes cooperate with each other through local interactions and adapt their states in response to both local data collected at the nodes and data received from their immediate neighbors. Information arriving at any particular node creates a ripple effect that propagates throughout the network by means of a diffusion process,which results in a form of collective intelligence leading to improved adaptation,learning,tracking, and convergence behavior with respect to non-cognitive net-works.The edges linking the nodes can be assigned adjustableFig.3.CR cycle.weights in accordance with the quality of the information that is exchanged over these edges;in this way,CN can adjust their topologies as well.Distributed processing techniques over such adaptive networks do not experience one of the main drawbacks of classical centralized fusion methods,i.e.the fact that central fusion approaches limit the autonomy of the network and add a critical point of failure due to the presence of a central node[30].It has been observed in social and biological sciences studies on animalflocking behavior that while each individual agent in an animal colony is not capable of complex behavior,the combined coordination among multiple agents leads instead to the manifestation of regular patterns of behavior and swarm intelligence.In a similar manner,CN should benefit from local cooperation among the nodes,leading to enhanced per-formance in terms of e.g.improved learning,robustness,and convergence abilities[30].CN can be designed to perform a variety of tasks such as detection,estimation,or resource allocation,through dis-tributed processing.Their applications include environmental monitoring,distributed event detection,resource monitoring, target tracking,cooperation among CR searching for spectral resources,among others[30].The cognitive cycle followed by CR(see Fig.3[31])in their quest for free spectrum can be seen as a special case of a subset of the SON cycle showed in Fig.2(the one circled at the right-bottom of thatfigure),i.e.of the self-optimization phase of a SON cycle.As a matter of fact,the ubiquitous and pervasive com-puting and networking is becoming a clear trend in wireless communications:this is confirmed by the fact that computer processors are becoming part of more and more everyday items,which may form a wireless network.This trend corre-sponds to a shift from the very large to the very small,leading to disappearing electronics with the following characteristics: low-cost,miniature size and self-contained from energy per-spective[32].The ultimate goal is to achieve reliable universalcoverage at all times and this brings to several challenges[33]:•this large amount of devices will very rapidly run out of spectrum;•most devices will have limitations in energy consumption;•wireless might be unreliable(bigger challenges due to the medium than in wired counterpart);•from the very high heterogeneity of devices it might come incompatibility.The above challenges in such complex networks’scenarios can be faced only if a certain degree of self-organization is put into the system.In particular,self-optimized/cognitive networks will play a crucial role in identifying the needed spectrum of the proper quality for the several coexisting systems,devices and applications.Examples of possible scenarios for self-optimized and,in particular,cognitive networks,are[34]:•vehicular networking(among cars,e.g.targeting acci-dents warnings,and within the car,e.g.establishing a network among personal devices);•wireless sensor networks(applied e.g.to monitoring of humans,in the context of assisted living and medical engineering);•wearable computing.VI.A PPLICATION TO A LGORITHMIC I NFORMATIONT HEORY TO SONSON can also be seen as a means to address the growing complexity of networks.SON are in nature decentralized and this implies a limited amount of information available compared to centralized networks;one key issue related to this,is how to quantify and minimize the information required and exchanged by the different subnetworks of a SON such that still self-organization processes’output will be acceptable. Another possible situation related with SON is associated with the need to send information on the network to a third party, e.g.an OAM server.To understand the structure of a large-scale network(could be e.g.biological,social,or as in the case of this paper, technological),it might be helpful to decompose the network into smaller subunits or modules.[35]identifies the modules in which the network can be decomposed byfinding an optimal compression of its topology,exploiting the regularities in its structure.It is assumed that a signaler knows the full network structure,i.e.the adjacency matrix(an unweighted and undirected network X is considered)A ij= 1if there is a link between nodes i and j0otherwise(1) and wants to send as much information as possible about the network to a receiver over a channel with limited capacity. The signaler then encodes the network into modules in a way that maximizes the amount of information about the original network.In general,the problem is to determine the number of modules in the network,and to partition the nodes into that number of modules.[35]provides a solution to this description problem based on Algorithmic Information Theory(AIT). AIT is a subfield of information theory,computer science, statistics and recursion theory,that deals with the relationship between computation,information,and randomness.One of the key concepts of AIT is Algorithmic Kolmogorov Com-plexity.Kolmogorov defined the complexity K of a string x as the length of its shortest description p on a universal Turing machine U,i.e.K(x)=min{l(p):U(p)=x}.A string is simple if it can be described by a short program, like“the string of one million ones”,and is complex if there is no such short description,like for a random string whose shortest description is specifying it bit-by-bit.An important property of K is that it is nearly independent of the choice of U.Furthermore it leads to shorter codes than any other effective code.K shares many properties with Shannon’s entropy(information measure)S,but K is superior to S in many respects.To be brief,K is an excellent universal complexity measure[36].In[35]the signaler does an encoding seeking tofind a compression of the network structure so that the decoder can make the best possible estimate of the actual network.To minimize the description length of the original network X, one looks for the number of modules that minimizes the length of the modular description Y plus the conditional description length,i.e.the amount of information that would be needed to specify X exactly to a receiver who had already decoded the description Y,i.e.[35]tries to minimize the sumL(Y)+L(X|Y)(2) where L(Y)is the length in bits of the signal,and L(X|Y) is the number of bits needed to specify which of the network estimates implied by the signal Y is actually realized.A tradeoff emerges as a consequence of the described approach,i.e.between how much of the network structure one can capture and how big is the amount of information to be exchanged,i.e.how many network modules and how long their descriptions.By abstracting the problem offinding patterns in networks to a problem of data compression,the information-theoretic view described in[35]provides a general basis for how to get the most information out of a network structure.A possible generalization in the context of wireless SON,could be to consider a weighted network instead of an unweighted one, compressing and transmitting not only the information on whether a link between two network nodes exists or not,but also what is the signal quality achieved over that link.This could help in planning a self-optimized resources’distribution over the network,in either a distributed fashion(the sub-networks descriptions are exchanged among the subnetworks themselves)or in a centralized one(the network description is sent to an OAM server).VII.C ONCLUSIONThis paper intended to give a general overview of Self-Organizing Networks(SON),their properties and applicationto wireless networks.After a general introduction to SON,the rationale of wireless SON was presented;thereafter the related state-of-the-art was reviewed from standardization,European projects,academia and industry viewpoints.Then,the require-ments and research challenges within wireless SON domain were highlighted.The relations and analogies between SON and Cognitive Networks were then discussed.Afterwards,the application of Algorithmic Information Theory as a possible theoretical tool to support SON in addressing the growing complexity of networks was treated.R EFERENCES[1] C.Prehofer and C.W.Bettstetter,Self Organization in CommunicationNetworks:Principles and Design Paradigms,IEEE Communication Magazine,July2005.[2]S.Dixit and A.Sarma,Advances in Self-Organizing Networks,IEEECommunication Magazine,July2005.[3]S.Dixit,E.Yanmaz and O.K.Tonguz,On the Design of Self-OrganizedCellular Wireless Networks,IEEE Communication Magazine,July2005.[4]A-L.Barabasi,R.Albert and H.Jeong,Mean-field Theory for Scale-freeRandom Networks,Physica A,vol.272,1999,pp.17387.[5] A.-L.Barabasi and E.Bonabeau,Scale-Free Networks,Sci.Amer.,vol.288,May2003,pp.5059.[6] A.-L.Barabasi and R.Albert,Emergence of Scaling in Random Net-works,Science,vol.286,Oct.1999,pp.50912.[7]R.Albert and A.-L.Barabasi,Statistical Mechanics of Complex Net-works,Rev.Mod.Physics,vol.74,Jan.2002,pp.4791.[8]X.Wang and G.Chen,Complex Networks:Small-World,Scale-Free andBeyond,IEEE Circuits and Sys.,vol.3,no.1,2003,pp.620.[9]L.Schmelz et al.,Self-configuration,-optimisation,and-healing inwireless networks,Wireless World Research Forum Meeting20,April 2008.[10]J.M.Celentano,Carrier Capital Expenditures,IEEE CommunicationsMagazine,June2008.[11]S.Shen,How to Cut Mobile Network Costs to Serve Emerging Markets,Gartner Inc.,November2005.[12]NGMN Alliance,NGMN Use Cases related to Self Organising Network,Overall Description,white paper,May2007.[13]NGMN Alliance,NGMN Recommendation on SON and O&M Require-ments,requirement specification,December2008.[14]Self-configuring and self-optimizing network use cases and solutions,3GPP TS36.902,September2008.[15]NEC Corporation,Self Organizing Network:NEC’s proposals for next-generation radio network management,white paper,February2009. [16]Self-Optimisation&self-ConfiguRATion in wirelEss networkS(SOCRATES),EU FP7project,/?q=node/1.[17]4WARD,EU FP7project,http://www.4ward-project.eu/.[18]End-to-End Efficiency(E3),EU FP7project,https://ict-e3.eu/.[19]Fibre-Optic Networks for Distributed Extendible Heterogeneous RadioArchitectures and Service Provisioning(FUTON),EU FP7project, http://www.ict-futon.eu/default.aspx.[20] D.Alderson et al.,A Contrasting Look at Self-Organization in theInternet and Next Generation Communication Networks,IEEE Com-munigation Magazine,2005.[21]L.Jun et al.,A Novel Network Management Architecture for Self Orga-nizing Network,International Conference on Networking,Architecture and Storage(NAS),2007.[22]M.I.Tiwana,B.Sayrac,Z.Altman,Statistical learning for automatedRRM:Application to eUTRAN mobility,IEEE ICC,2009.[23]L.Xu,C.Sun,X.Li,C.Lim,H.He,The methods to implementate selfoptimisation in LTE system,IEEE ICCTA,October2009.[24]3G Americas,The Benefits of SON in LTE-Self-Optimizing and Self-Organizing Networks,white paper,December2009.[25]Motorola,Motorola LTE Self Organizing Networks-Motorola’s revo-lutionary SON solution for LTE OPEX reductions,white paper,2009.[26]Nokia Siemens Networks,Introducing the Nokia Siemens Networks SONSuite-an efficient,future-proof platform for SON,white paper,October 2009.[27]Texas Instruments,A.Gatherer,P.Dent,S.Bhadra,R.Vedantham,Self-optimizing networks(SON):doing more with less,white paper,2009.[28]L.Schmelz et al.,Requirements for Self-Organizing Networks,SOCRATES Deliverable2.1,FP7,March2008.[29]J.L.Van et al.,SOCRATES:Self Optimization and Self Configuration inWireless Networks,COST2100TD(08)422,Wroclaw,Poland,Feb2008.[30]NSF Workshop on Distributed Processing over Cognitive Networks,/NSF%20workshop%202009.htm[31]S.Haykin,Cognitive radio:brain-empowered wireless communications,IEEE JSAC,vol.23,no.2,February2005,pp.201220.[32]J.M.Rabaey and D.O.Pederson,A Brand New Wireless Day-Whatdoes it mean for design technology?,Ambient Society Symposium. [33]J.Rattner,Crossing the Chasm between Humans and Machines...theNext40Years,Intel Developer Forum.[34] C.Bettstetter,Self-Organization in Computer and Communication Net-works,available online at /talks/bettstetter-2009-12-wien.pdf,December2009.[35]M.Rosvall and C.T.Bergstrom,An Information-Theoretic Frameworkfor Resolving Community Structure in Complex Networks,Proceedings of the National Academy of Sciences of the United States of America, Applied Mathematics,vol.104,no.18,May2007,pp.7327-7331. [36]Algorithmic Information Theory,available online at/ait.htm。

慢病毒载体构建是一种用于基因治疗和基因转导的重要工具，其用于将外源基因或shRNA等插入到慢病毒载体中，从而实现对特定基因的表达调控。

下面是慢病毒载体构建所需试剂和耗材、实验仪器、准备工作、实验方法、注意事项、常见问题及解决方法。

一、所需试剂和耗材1.慢病毒载体：用于包装目的基因的包装细胞系，如HepG2.2.15等。

2.目的基因或shRNA：需要插入慢病毒载体的DNA或RNA片段。

3.质粒DNA：用于构建慢病毒载体，包括表达盒质粒和包装质粒等。

4.DNA聚合酶：用于DNA扩增和连接。

5.限制性内切酶：用于DNA切割。

6.DNA连接酶：用于DNA连接。

7.缓冲液：维持反应液的pH值和其他辅助因子的浓度。

8.dNTPs（脱氧核糖核苷三磷酸）：DNA合成的原材料，包括dATP、dTTP、dCTP、dGTP。

9.细胞培养基：用于细胞培养。

10.胎牛血清：提供细胞生长所需的营养物质。

11.抗生素：用于防止细胞污染。

12.其他细胞生物学试剂：如胰蛋白酶、无血清培养基等。

二、实验仪器1.实验室搅拌器：用于混合和振荡反应液。

2.离心机：用于离心管和细胞培养瓶等。

3.水浴锅：用于保温反应液。

4.移液器：用于精确添加试剂和溶液。

5.细胞培养箱：用于细胞培养。

6.倒置显微镜：观察细胞生长状态和感染情况。

7.紫外线分光光度计：用于测量DNA浓度。

8.电泳仪和电泳槽：用于分析DNA样品。

9.定量PCR仪：用于定量分析目的基因的转导效率。

三、准备工作1.了解慢病毒载体构建的基本原理和步骤。

2.设计并合成目的基因或shRNA序列，并确认其正确性。

3.准备所有所需的试剂和耗材，并确保它们处于保质期内。

4.检查实验室内是否具备上述实验仪器，并确保其正常运行。

5.准备好实验服、口罩、手套等个人防护用品。

6.用70%乙醇擦拭实验台面，以确保无菌环境。

7.用高压蒸汽灭菌法灭菌所有的实验器具，包括离心管、移液器等。

8.设置细胞培养箱的温度和湿度等参数。

rna聚合酶 nature 1969下载温馨提示:该文档是我店铺精心编制而成，希望大家下载以后，能够帮助大家解决实际的问题。

文档下载后可定制随意修改，请根据实际需要进行相应的调整和使用，谢谢!并且，本店铺为大家提供各种各样类型的实用资料，如教育随笔、日记赏析、句子摘抄、古诗大全、经典美文、话题作文、工作总结、词语解析、文案摘录、其他资料等等，如想了解不同资料格式和写法，敬请关注!Download tips: This document is carefully compiled by theeditor.I hope that after you download them,they can help yousolve practical problems. The document can be customized andmodified after downloading,please adjust and use it according toactual needs, thank you!In addition, our shop provides you with various types ofpractical materials,such as educational essays, diaryappreciation,sentence excerpts,ancient poems,classic articles,topic composition,work summary,word parsing,copy excerpts,other materials and so on,want to know different data formats andwriting methods,please pay attention!RNA聚合酶：1969年的科学里程碑在科学的历史长河中，1969年是一个关键的年份，特别是在生物学领域，RNA聚合酶的研究开启了一个全新的篇章。

Takara Bio USA, Inc. 1290 Terra Bella Avenue, Mountain View, CA 94043, USA U.S. Technical Support: *******************************United States/Canada Asia Pacific Europe Japan Page 1 of 9Takara Bio USA, Inc. Guide-it™ Recombinant Cas9 (3 µg/µl) User ManualCat. Nos. 632640, 632641 (021121)Table of ContentsI. Introduction (3)A. Summary (3)II. List of Components (3)III. Additional Materials Required (3)A. Electroporation Supplies (3)B. Mammalian Cell Culture Supplies (4)C. General Supplies (4)D. sgRNA Development and Production (4)E. Detection and Characterization of Gene Editing (4)IV. Protocol Overview (5)V. Electroporation Protocol for Neon Transfection System (5)A. Protocol: Preparation of Cells and Media (5)B. Protocol: Preparation of Cas9-sgRNA RNP Complex (6)C. Protocol: Electroporation (6)VI. Electroporation Protocol for 4D-Nucleofector System (7)A. Protocol: Preparation of Cells (7)B. Protocol: Preparation of Cas9-sgRNA RNP Complex (8)C. Protocol: Electroporation (8)VII. References (9)Table of FiguresFigure 1. Protocol overview for Guide-it Recombinant Cas9 (3 µg/µl). (5)I. IntroductionA. SummaryThe CRISPR/Cas9 system has emerged as a powerful tool for gene editing because of its high targetingspecificity, editing efficiency, and ease of use in virtually any organism. CRISPR/Cas9 technologyconsists of two key components that form a complex: Cas9 endonuclease and a single guide RNA(sgRNA) that directs Cas9 to cleave genomic DNA in a sequence-specific manner (Jinek et al. 2012).This RNA-programmable method exploits the error-prone nature of the non-homologous end joiningDNA repair pathway (NHEJ) to generate gene knockouts (via insertion/deletion). The method can also beused to generate knockins via the homology-directed repair (HDR) pathway.CRISPR/Cas9 system components have been delivered successfully into target cells through a variety ofapproaches, including vector-based expression systems, transfection of RNA, and more recently,introduction of Cas9-sgRNA ribonucleoprotein (RNP) complexes. Delivery of Cas9-sgRNA RNPsprovides a fast turnaround for gene-editing experiments while minimizing the likelihood of off-targeteffects compared to vector-based approaches (Sander and Joung 2014), and this approach has beenoptimized for various cell types using microinjection, electroporation, and lipid-mediated transfection(Liang et al. 2015).Guide-it Recombinant Cas9 (3 µg/µl) is a recombinant wild-type Streptococcus pyogenes Cas9 nucleaseexpressed with a C-terminal nuclear-localization signal (NLS)and purified from E. coli for use inCRISPR/Cas9-mediated gene editing experiments. The Cas9 protein solution has been verified to besterile and well-tolerated by mammalian cells when electroporated as a ribonucleoprotein complex (RNP)with a single guide RNA (sgRNA) for knockout experiments, or as an RNP with a donor repair templatefor knockin experiments.II. List of ComponentsGuide-it Recombinant Cas9 (3 µg/µl) (Cat. No. 632641)•100 µg Guide-it Recombinant Cas9 (3 µg/µl)Guide-it Recombinant Cas9 (3 µg/µl) (Cat. No. 632640)• 3 x 100 µg Guide-it Recombinant Cas9 (3 µg/µl)•Store Guide-it Recombinant Cas9 (3 µg/µl) at –70°C.•Avoid repeated freeze/thaw cycles. We recommend preparing aliquots upon initial thawing of Guide-it Recombinant Cas9 (3 µg/µl).III. Additional Materials RequiredThe following reagents/materials are required but not included.A. Electroporation SuppliesUse of this product requires an electroporator, electroporation chamber (typically cuvettes or tips), and anelectroporation buffer that is suitable for your target cells. Here we provide separate guidelines for theNeon Transfection System (Thermo Fisher Scientific, Cat. No. MPK5000) and the 4D-NucleofectorSystem (Lonza, Cat. No. AAF-1002B).B. Mammalian Cell Culture Supplies•Culture medium, supplies, and additives specific to your target cells•Cell culture plates•PBS without Ca2+ or Mg2+•Trypsin/EDTA or equivalent•Humidified incubator (set at 37º C, 5% CO2)C. General Supplies•Single-channel pipettes•Nuclease-free thin-wall PCR tubes or stripsD. sgRNA Development and ProductionCRISPR/Cas9 gene editing requires a custom sgRNA with a user-designed targeting sequence that ishomologous to the target gene or genomic region of interest. Selecting an appropriate DNA sequence at the target region is critical for maximizing the potential for efficient cleavage at the target site and forminimizing the likelihood of non-specific cleavage events. There are several freely available online tools that can be helpful for determining suitable sgRNA target sequences for a given organism and genomic target. For a list of these tools, please refer to:/US/Products/Genome_Editing/CRISPR_Cas9/Resources/Online_tools_for_gui de_RNA_design.NOTE: For many applications, it is advisable to design and test several variant sgRNAs against the same genomic target region.Candidate sgRNAs must ultimately be produced in sufficient quantity for the generation of functionalCas9-sgRNA RNPs. For development and production of user-designed sgRNAs, we recommend either of the following kits:•For constructing and purifying sgRNAs: Guide-it sgRNA In Vitro Transcription Kit (Takara Bio, Cat.No. 632635).•For constructing and purifying sgRNAs, and testing target cleavage efficiencies in vitro: Guide-it Complete sgRNA Screening System (Takara Bio, Cat. No. 632636).E. Detection and Characterization of Gene EditingThese items are recommended for determining the efficiency of gene editing and the nature of the edits:Cat. No. Product Size631443 Guide-it Mutation Detection Kit 100 rxns631448 Guide-it Mutation Detection Kit 25 rxns632611 Guide-it Genotype Confirmation Kit 100 rxns631444 Guide-it Indel Identification Kit 10 rxnsIV. Protocol OverviewPlease read each relevant protocol completely before starting. Successful results depend on understanding and performing the following steps correctly.Figure 1. Protocol overview for Guide-it Recombinant Cas9 (3 µg/µl).V. Electroporation Protocol for Neon Transfection SystemHere we provide protocols for performing knockout and knockin experiments in hiPS cells and CD34-positive stem cells using the Neon Transfection System. While these protocols may serve as a helpful starting point forelectroporation of other cell types as well, further optimization will be required. Please refer to the Neon Transfection System User Manual and manufacturer’s website for detailed operating instructions for the Neon Transfection System.A. Protocol: Preparation of Cells and MediaCultured target cells are harvested, washed, and resuspended in the appropriate buffer.1.Prepare a sufficient number of fresh cells for your experiment.NOTE: Each electroporation requires 1 x 105 cells. However, due to the potential variation of pipetteand tip volumes, we recommend preparing 1.5X the necessary volume of cell suspension (i.e., 1.5 x 105cells) for electroporation with a 10-µl Neon Tip to ensure that there is sufficient volume.2.For hiPS cells (adherent cells), continue to Step3. For CD34-positive stem cells (suspension cells),skip to Step 5.3.Aspirate the medium, wash the cell layer once with PBS (without Ca2+ and Mg2+), and dissociate thecells using TrypLE Select Enzyme (1X) (Thermo Fisher Scientific, Cat. No. 12563011).4.Harvest the cells in growth medium.5.Take an aliquot of the cell suspension and measure the cell density using your preferred method.6.Harvest the cells by centrifugation at 400g for 5 min in a 15-ml conical tube.7.Wash the cells once with PBS (without Ca2+ and Mg2+), and then resuspend hiPS cells in Buffer R andCD34-positive stem cells in Buffer T (included with Neon kits) at a concentration of 2 x 107 cells/ml(i.e., 1.5 x 105 cells in 7.5 µl).NOTE: Use Resuspension Buffer R for established adherent and suspension cells as well as primaryadherent cells, and use Resuspension Buffer T for primary blood-derived suspension cells.8.Keep the cell suspension on ice until use.B. Protocol: Preparation of Cas9-sgRNA RNP ComplexCas9 and sgRNA components are combined to form RNP complexes for electroporation.1.Thaw Guide-it Recombinant Cas9 (3 µg/µl) and sgRNA solutions at room temperature.NOTE: We recommend preparing aliquots upon initial thawing of Guide-it Recombinant Cas9(3 µg/µl) to avoid repeated freeze/thaw cycles.bine the following components in a 200-µl PCR tube to mix the Cas9 protein and sgRNA at a 5:1mass ratio. The molar ratio of Cas9 protein to sgRNA will be approximately 1:1 in this mixture, andthe total volume will be 7.5 µl. Be sure to use the same buffer that was used to resuspend the cells.NOTE: The reaction volume indicated below is 1.5X the required volume.Per reaction:0.45 μl* sgRNA (e.g., 1 µg/µl)0.75 μl Guide-it Recombinant Cas9 (3 µg/µl)6.3 μl* Resuspension Buffer R or T7.5 μl Total volume*The added volume of sgRNA will vary depending on sgRNA concentration, and the added volume ofResuspension Buffer should be adjusted such that the total reaction volume is 7.5 µl. The volumesindicated above are based on a sgRNA concentration of 1 µg/µl.NOTE: Make a master mix if you are performing multiple electroporations.NOTE: The optimal amount of RNP complex may vary for different cell types.NOTE: To maximize electroporation efficiency, the combined volume of the Cas9 and sgRNA solutionsshould be ≤20% of the total volume of the Cas9-sgRNA RNP complex reaction (e.g., for the 7.5-µlreaction specified above, the combined volume of the sgRNA and Cas9 solutions should be ≤1.5 µl).NOTE: If you plan to use donor DNA to induce HDR-mediated knockin, add the DNA after thesubsequent incubation step (Step 3). We recommend using ≤1 µg of DNA for knockin experiments.Adjust the volume of Resuspension Buffer R or T included in the reaction such that the final volumeupon addition of donor DNA is 7.5 µl.3.Mix the reaction well by gently pipetting up and down. Incubate using a thermal cycler preheated to37°C with the following program:37°C 5 min4°C hold4.OPTIONAL: Add donor DNA and keep on ice until use.C. Protocol: ElectroporationCas9-sgRNA RNPs are electroporated into target cells.1.Fill the Neon Tube with 3 ml of Buffer E (included with Neon kits) and insert the Neon Tube into theNeon Pipette Station.ing the touchscreen on the Neon system, set up the electroporation parameters as follows:Pulse voltage / Pulse width / Pulse number = 1100 v / 20 ms / 2 pulsesNOTE: We have used these parameters successfully for hiPS cells and CD34-positive stem cellsusing the Neon Transfection System. Optimization of electroporation parameters will be required fordifferent target cell types. Suggested parameters for different cell types are included in thesupplementary material for (Liang et al. 2015).3.Gently resuspend the cells by tapping, and transfer 7.5 µl of the cell suspension into the PCR tubecontaining the 7.5 µl of Cas9-sgRNA RNP complex solution.4.Mix well by gently pipetting up and down.5.Insert the Neon Pipette into the Neon Tip and confirm that the pipette and tip are tightly connected.ing the Neon Pipette, aspirate the mixture slowly into the Neon Tip.NOTE: Avoid any air bubbles in the tip. If you notice air bubbles, place the sample back into thePCR tube and aspirate again into the tip without any air bubbles.7.Insert the Neon Pipette into the Neon Tube placed in the Neon Pipette Station and run the program.8.Remove the pipette very carefully and transfer the cells into a cell culture plate with pre-warmedmedium.NOTE: Use an appropriate well plate for your target-cell type. We had success using 24 and 48-wellplates for CD34-positive stem cells and hiPS cells, respectively. hiPS cells typically require greaterconfluence than regular adherent cells.9.Shake the plate appropriately to disperse the cells and incubate at 37°C in a humidified incubator with5% CO2 until the next necessary procedure.VI. Electroporation Protocol for 4D-Nucleofector SystemHere we provide protocols for performing knockout and knockin experiments in Jurkat and CD34-positive stem cells using the 4D-Nucleofector System with 16-well Nucleocuvette Strips. While these protocols may serve as a helpful starting point for electroporation of other cell types as well, further optimization will be required. Please refer to the 4D-Nucleofector System User Manual and manufacturer’s website for more detailed information.A. Protocol: Preparation of CellsCultured target cells are harvested, washed, and resuspended in the appropriate solution.1.Prepare a sufficient number of fresh cells for your experiment.NOTE: Each electroporation requires 2 x 105 cells.2.Take an aliquot of the cell suspension and measure the cell density using your preferred method.3.Harvest the cells by centrifugation at 400g for 5 min in a 15-ml conical tube.4.Wash once with PBS (without Ca2+ and Mg2+), and then resuspend Jurkat cells in SE NucleofectorSolution (with supplement) and CD34-positive stem cells in P3 Nucleofector Solution (withsupplement) at a concentration of 1 x 107 cells/ml (i.e., 2 x 105 cells in 20 µl).NOTE: Please refer to the 4D-Nucleofector System User Manual and manufacturer’s website formore information about working with other cell types.NOTE: 20 µl of cell suspension will be needed per well of the Nucleocuvette Strip.5.Keep the cell suspension on ice until use.B. Protocol: Preparation of Cas9-sgRNA RNP ComplexCas9 and sgRNA components are combined to form RNP complexes for electroporation.1.Thaw Guide-it Recombinant Cas9 (3 µg/µl) and sgRNA solutions at room temperature.NOTE: We recommend preparing aliquots upon initial thawing of Guide-it Recombinant Cas9(3 µg/µl) to avoid repeated freeze/thaw cycles.bine the following components in a 200-µl PCR tube to mix the Cas9 protein and sgRNA at a 5:1mass ratio:Per reaction (e.g. 5 µl):2μl* sgRNA (e.g., 1 µg/µl)3.3 μl Guide-it Recombinant Cas9 (3 µg/µl)5.3 μl Total volume*The added volume of sgRNA will vary depending on sgRNA concentration. The volume indicated aboveis based on an sgRNA concentration of 1 µg/µl.NOTE: Make a master mix if you are performing multiple electroporations.NOTE: The RNP volume required for efficient transfection needs to be optimized for different celltypes. Usually ≤10 µl of the RNP solution will be tested for electroporation in each well of the 16-well Nucleocuvette Strip.3.Mix the reaction well by gently pipetting up and down. Incubate using a thermal cycler preheated to37°C with the following program:37°C 5 min4°C HoldC. Protocol: ElectroporationCas9-sgRNA RNPs are electroporated into target cells.bel wells of Nucleocuvette Strips to be used for electroporation.bine 20 µl of cell suspension with 5 µl Cas9-sgRNA RNP complex solution in each well of theNucleocuvette Strip, and mix well by gently pipetting up and down.NOTE: If you plan to use donor DNA to induce HDR-mediated knockin, add the donor DNA at thisstep.3.Select the program CL-120 for Jurkat cells or the program D0-100 for CD34-positive stem cells.4.Insert the Nucleocuvette Strip into the Nucleofector machine and run the program.5.Add 80 µl of pre-warmed medium to each cuvette and allow electroporated cells to recover for 12min post-transfection at room temperature.6.Gently collect the cells along with the media from each well and transfer to individual wells of a 48-well plate containing pre-warmed medium.7.Shake the plate appropriately to disperse the cells and incubate at 37°C in a humidified incubator with5% CO2 until the next necessary procedure.VII. References1.Jinek, M., Chylinsky, K., Fonfara, I., Hauer, M., Doudna, J.A., & Charpentier, E. A programmable dual-RNA-guided DNA endonuclease in adaptive bacterial immunity. Science. 337(6096), 816–21 (2012).2.Liang, X. et al. Rapid and highly efficient mammalian cell engineering via Cas9 protein transfection. J.Biotechnol.208, 44–53 (2015).3.Sander, J.D. & Joung, J.K. CRISPR-Cas9 systems for genomic editing, regulation and targeting. Nat.Biotechnol. 32, 347-55 (2014).Contact UsCustomer Service/Ordering Technical Supporttel: 800.662.2566 (toll-free) tel: 800.662.2566 (toll-free)fax: 800.424.1350 (toll-free) fax: 800.424.1350 (toll-free)web: web: e-mail: **********************e-mail: ********************Notice to PurchaserOur products are to be used for Research Use Only. They may not be used for any other purpose, including, but not limited to, use in humans, therapeutic or diagnostic use, or commercial use of any kind. Our products may not be transferred to third parties, resold, modified for resale, or used to manufacture commercial products or to provide a service to third parties without our prior written approval.Your use of this product is also subject to compliance with any applicable licensing requirements described on the product’s web page at . It is your responsibility to review, understand and adhere to any restrictions imposed by such statements© 2021 Takara Bio Inc. All Rights Reserved.All trademarks are the property of Takara Bio Inc. or its affiliate(s) in the U.S. and/or other countries or their respective owners. Certain trademarks may not be registered in all jurisdictions. Additional product, intellectual property, and restricted use information is available at .This document has been reviewed and approved by the Quality Department.。