Yerel alan ağları ve ATM (asenkron iletim metodu) ağları bağlantılılığı
Başlık çevirisi mevcut değil.
- Tez No: 66600
- Danışmanlar: PROF. DR. A. EMRE HARMANCI
- Tez Türü: Yüksek Lisans
- Konular: Bilgisayar Mühendisliği Bilimleri-Bilgisayar ve Kontrol, Computer Engineering and Computer Science and Control
- Anahtar Kelimeler: Belirtilmemiş.
- Yıl: 1997
- Dil: Türkçe
- Üniversite: İstanbul Teknik Üniversitesi
- Enstitü: Fen Bilimleri Enstitüsü
- Ana Bilim Dalı: Kontrol ve Bilgisayar Mühendisliği Ana Bilim Dalı
- Bilim Dalı: Belirtilmemiş.
- Sayfa Sayısı: 122
Özet
ÖZET İçinde yaşadığımız yüzyıl belki de insanlık tarihinde en hızlı yol alınan dönemdir. 21. yüzyılı karşılamaya hazırladığımız bu dönemde, soğuk savaş rüzgarlarından esintiler devam etse de, teknolojik olarak liderliği elinde bulunan ülkelerin dünya üzerinde söz sahibi olmaya başladıklarını görüyoruz. Sıcak savaşlar medeniyeti hale sindirememiş ülkeler arasında hala devam ediyor. Buna karşın yeni bir çağı, bilgi çağım yaşamaya başlayan ülkeler ise diğer ülkelerin şaşkın bakışları arasında, farklı toplumlar olma yolunda ilerliyorlar. Dünya, süper güçlerinin teknolojik savaşına ev sahipliği yapıyor. Bu savaşın sonucu ne olur bilinmez. Kazananı ve kaybedeni hiç bir zaman belli olamayacak çünkü bu savaş insanoğlu varoldukça devam edecektir. Ama bu yarışta önde olanlar her zaman diğer ülkeleri yönetme hakkına sahip olacaklar. Her ne kadar ülkelerin bağımsızlıkları devam edecek olsa da küreselleşme olarak nitelenen bu olay, şahsi fikrime göre kaleyi içten fethetmekten başka bir şey değildir. Teknolojisinde dışarıya bağımlı kalan ülkeler, hem diğer ülkeleri izleyemeyecekler ve hem de denetlendiklerinin ve kumanda edildiklerinin farkında olmayacaklardır. Yetişmiş insan erozyonunu da durduramayacak bu ülkeler, beyin göçünü hızlandıracaklar ve insanlarının teknoloji lideri ülkelerin hesabına çalışmalarını engelleyemeyeceklerdir. Bilgi çağında en önemli olgu bilgiye hızlı ve kolay erişimdir. Eskiden bir ülkenin gücünü orduları ve silahlarının çokluğu belirlerken, bugün buna eklenen başka bir faktörde iletişim alt yapısının ne kadar hızlı olduğudur. Bilgiye ne kadar hızlı ulaşırsanız, bu bilgileri ne kadar hızlı yorumlarsanız, rakiplerinizden o kadar adım daha fazla atmış olursunuz. Bu gerçek geleceği belirleyecektir. Yukarıda birazda konudan uzaklaşarak yaptığımız girişin asıl amacı veri iletişim alt yapısının önemini vurgulamaktı. Bilgisayar ağlarının önemi günümüzde tartışılmaz iken yüksek hızlı ve entegre servis veren bir ağın ne gibi getirileri olabileceğini düşünmek bile insana heyecan veriyor. Son onbeş yıldır bilim adamları tüm medyaları birleştirebilecekleri bir ağın hayali peşinde koşuyorlar. BISDN denilen bu teoriye cevap verebilecek tek topoloji Asenkron İletim Modu, ATM) olarak belirlenmiştir. ATM çok yeni bir teknoloji olmamasına karşın gerçeklemedeki sorunlar ancak 90'lı yılların başında aşılmıştır. Günümüzde bu konu dünyadaki en popüler konulardan bir tanesidir. Ağın temelini oluşturan anahtarlardaki yalınlık ve şimdiye kadar hep bağlantısız ortamlarda çalışan bilgisayar ağlarının bağlantılı bir ortama geçirilmesinde karşılaşılan zorluklar, bu konuda gidilecek daha çok yolun olduğunu gösteriyor. Bu teknolojinin üniversitemize girmiş olmasını değerlendirerek çalışmamı bu konuda seçtim. Çalışma, gittikçe yaygınlaşan ATM kullanımının LINUX işletim sistemi altında bir incelemesidir. PCTer için üretilmiş ATM kartları üzerinde İP protokollerinin gerçeklenmesi ve ATM ağına adaptasyonu incelenmiştir. İPprotokollerinin ATM'e nasıl uyarlanacağı konusu ön planda ele alınmıştır. Bu anlamda Yerel Alan Ağları ve ATM Ağlarının bağlantılılığının nasıl gerçeklendiği anlatılmıştır. ATM kartlarının LINUX' e uyarlanması çalışmada üzerinde durulan en önemli konulardan bir tanesidir.
Özet (Çeviri)
SUMMARY It is clear that Asynchronous Transfer Mode (ATM) technology will play a central role in the evolution of current workgroup, campus and enterprise networks. ATM delivers important advantages over existing LAN and WAN technologies, including scalable bandwidths, Quality of Service (QoS) guarantees, which facilitate new classes of applications such as multimedia. However, ATM is a very complex technology, perhaps the most complex ever developed by the networking industry. While the structure of ATM cells and cell switching do facilitate the development of hardware intensive, high performance ATM switches, the deployment of ATM networks requires the overlay of a highly complex, software intensive, protocol infrastructure. This infrastructure is required to both allow individual ATM switches to be linked into a network, and for such networks to internetwork with the vast installed base of existing local and wide area networks. This paper assumes that the reader is familiar with basics of ATM technology - such as the ATM layer protocols and cell formats, and the operation of ATM switching systems, its connection oriented nature, which contributes to the complexity of ATM protocols. The fact that ATM is connection oriented implies the need for ATM specific signaling protocols and addressing structures, as well as protocols to route ATM connection requests across the ATM network. These ATM protocols, in turn, influence the manner in which existing higher layer protocols can operate over ATM networks. The latter can be done in a number of different ways, each with its own advantages and characteristics, which will be discussed. Many of the protocols described in this paper were still under development, as of the time of writing, and aspects of their operation may change by the time the protocols are finalized. ATM Network Operation An ATM network consists of a set of ATM switches interconnected by point- to-point ATM links or interfaces. ATM switches support two kinds of interfaces: user-network interfaces (UNI) and network-node interfaces (NNI). UNI connect ATM end-systems (hosts, routers, and so on) to an ATM switch, while an NNI may be imprecisely defined as an interface connecting two ATM switches together; slightly different cell formats are defined across UNI and NNI. More precisely, however, an NNI is any physical or logical link across which two ATM switches exchange the NNI protocol. As noted above, ATM networks are fundamentally connection oriented. This means that a virtual circuit needs to be set up across the ATM network prior to any data transfer. ATM circuits are of two types: virtual paths, identified by virtual pathidentifiers (VPI); and virtual channels, identified by the combination of a VPI and a virtual channel identifier (VCI). A virtual path is a bundle of virtual channels, all of which are switched transparently across the ATM network on the basis of the common VPI. All VCI and VPI, however, have only local significance across a particular link, and are remapped, as appropriate, at each switch. In normal operation, switches allocate all UNI connections within VPI=0. The basic operation of an ATM switch is very simple: to receive a cell across a link on a known VCI or VPI value; to look up the connection value in a local translation table to determine the outgoing port (or ports) of the connection and the new VPI/VCI value of the connection on that link; and to then retransmit the cell on that outgoing link with the appropriate connection identifiers. The switch operation is so simple because external mechanisms set up the local translation tables prior to the transmittal of any data. The manner in which these tables are set up determine the two fundamental types of ATM connections: ? Permanent Virtual Connections (PVC): A PVC is a connection set up by some external mechanism, typically network management, in which a set of switches between an ATM source and destination ATM system are programmed with the appropriate VPI/VCI values. As is discussed later, ATM signaling can facilitate the set up of PVCs, but, by definition, PVCs always require some manual configuration. As such, their use can often be cumbersome. ? Switched Virtual Connections (SVC): An SVC is a connection that is set up automatically through a signaling protocol. SVCs do not require the manual interaction needed to set up PVCs and, as such, are likely to be much more widely used. All higher layer protocols operating over ATM primarily use SVCs. ATM signaling is initiated by an ATM end-system that desires to set up a connection through an ATM network; signaling packets are sent on a well known 6 virtual channel, VPI=0, VCI=5. The signaling is routed through the network, from switch to switch, setting up the connection The latter can either accept and confirm the connection request, or can reject it, clearing the connection. Note that because the connection is set up along the path of the connection request, the data also flows along this same path. Different types of ATM connections can be set up, either as SVCs or PVCs. There are two fundamental types of ATM connections: ? Point-to-point connections, which connect two ATM end-systems. Such connections can be unidirectional or bidirectional. ? Point-to-multipoint connections, which connects a single source end-system (known as the root node) to multiple destination end-systems (known as leaves). Cell replication is done within the network by the ATM switch at which the connection splits into two or more branches. Such connections are unidirectional, permitting the root to transmit to the leaves, but not the leaves to transmit to theroot, or to each other, on the same connection. The reason why such connections are only unidirectional are described below. What is notably missing from these types of ATM connections is an analog to the multicasting or broadcasting capability common in many shared medium LAN technologies such as Ethernet or Token Ring. In such technologies, multicasting allows multiple end systems to both receive data from other multiple systems, and to transmit data to; these multiple systems. Such capabilities are easy to implement in shared media technologies such as LANs, all nodes on a single LAN segment must necessarily process all packets sent on that segment. The obvious analog in ATM to a multicast LAN group would be a (bidirectional) multipoint-to-multipoint connection. Unfortunately, this obvious solution cannot be implemented when using AAL5, the most common ATM Adaptation Layer (AAL) used to transmit data across ATM networks. Unlike AAL 3/4, with its Message Identifier (MID) field,AAL 5 does not have any provision within its cell format for the interleaving of cells from differentAAL5 packets on a single connection. This means that all AAL5 packets sent to a particular destination across a particular connection must be received in sequence, with no interleaving between the cells of different packets on the same connection, or the destination reassembly process would not be able to reconstruct the packets. This is why ATM AAL 5 point-to-multipoint connections can only be unidirectional, for if a leaf node was to transmit an AAL 5 packet onto the connection, it would be received by both the root node and all other leaf nodes. However, at these nodes, the packet sent by the leaf could well be interleaved with packets sent by the root, and possibly other leaf nodes; this would preclude the reassembly of any of the interleaved packets. Clearly, this is not acceptable. ATM Signaling and Addressing The current and planned ATM signaling protocols and their associated ATM addressing models are discussed in this section. ATM signaling protocols vary by the type of ATM link - ATM UNI signaling is used between an ATM end-system and an ATM switch across an ATM UNI; ATM NNI signaling is used across NNI links. As of the time of this writing, standards exist only for ATM UNI signaling, although work is continuing on NNI signaling. UNI signaling requests are carried across the UNI in a well known default connection: VPI=0, VCI=5. The UNI 3.1 specification is based upon Q.2931, a public network signaling protocol developed by the International Telecommunications Union- Telecommunications Sector (ITU-T), which, in turn, was based upon the Q.931 signaling protocol used with Narrowband ISDN (N-ISDN). The ATM signaling protocols run on top of a Service Specific Convergence Protocol (SSCOP), defined by the ITU-T Recommendations Q.2100, Q.2110, and Q.2130. This is a data link protocol that guarantees delivery through the use of windows and retransmissions. The most important contribution of UNI 3.0/3.1 in terms of internetworking across ATM was its addressing structure. Any signaling protocol, of course, requires an addressing scheme to allow the signaling protocol to identify the sources anddestination of connections. The ITU-T has long settled upon the use of telephone number-like E.164 addresses as the addressing structure for public ATM (B-ISDN) networks. Since E.164 addresses are a public (and expensive) resource, and cannot typically be used within private networks, the ATM Forum extended ATM addressing to include private networks. In developing such a private network addressing scheme for UNI 3.0/3.1, the ATM Forum evaluated two fundamentally different models for addressing. These two models differed in the way in which the ATM protocol layer was viewed in relation to existing protocol layers, in particular, existing network layer protocols such as IP, IPX, and so on. These existing protocols all have their own addressing schemes and associated routing protocols. One proposal was to also use these same addressing schemes within ATM networks. Hence ATM endpoints would be identified by existing network layer addresses (such as IP addresses), and ATM signaling requests would carry such addresses. Existing network layer routing protocols (such as IGRP and OSPF) would also be used within the ATM network to route the ATM signaling requests, since these requests, using existing network layer addresses, would look essentially like connectionless packets. i This model was known as the peer model, since it essentially treats the ATM layer as a peer of existing network layers. An alternate model sought to decouple the ATM layer from any existing protocol, defining for it an entirely new addressing structure. By implication, all existing protocols would operate over the ATM network. For this reason, the model is known as the subnetwork or overlay model. This mode of operation is, infact, the manner in which such protocols as IP operate over such protocols like X.25 or over dial-up lines. The overlay model requires the definition of both a new addressing structure, and an associated routing protocol. All ATM systems would need to be assigned an ATM address in addition to any higher layer protocol addresses it would also support. The ATM addressing space would be logically disjoint from the addressing space of whatever protocol would run over the ATM layer, and typically would not bear any relationship with it. Hence, all protocols operating over an ATM subnet would also require some form of ATM address resolution protocol to map higher layer addresses (such as IP addresses) to their corresponding ATM addresses. Note that the peer model does not require such address resolution protocols. By using existing routing protocols, the peer model also may have precluded the need for the development of a new ATM routing protocol. The 20-byte NS AP format ATM addresses are designed for use within private ATM networks, while public networks typically use E.164 addresses that are formatted as defined by ITU-T. The Forum did specify, however, an NSAP encoding for E.164 addresses. This will be used for encoding E.164 addresses within private networks but may also be used by some private networks. Such networks may base their own (NSAP format) addressing on the E.164 address of the public UNI to which they are connected and take the address prefix from the E.164 number, identifying local nodes by the lower order bits. xviAll NSAP format ATM addresses consist of three components: an Authority and Format Identifier (AFI), which identifies the type and format of the Initial Domain Identifier (IDI); the IDI, which identifies the address allocation and administration authority; and the Domain Specific Part (DSP), which contains actual routing information. The Q.2931 protocol defines source and destination address fields for signaling requests, and also defines subaddress fields for each. There are three formats of private ATM addressing that differ by the nature of the AFI and IDI: ? NSAP Encoded E. 164 format: In this case, the IDI is an E. 1 64 number. ? DCC Format: In this case, the IDI is a Data Country Code (DCC); these identify particular countries, as specified in ISO 3166. Such addresses are administered by the ISO National Member Body in each country. ? ICD Format: In this case, the IDI is an International Code Designator (ICD); these are allocated by the ISO 6523 registration authority (the British Standards Institute). ICD codes identify particular international organizations. LAN Emulation There are, two fundamentally different ways of running network layer protocols across an (overlay mode) ATM network. In one method, known as native mode operation, address resolution mechanisms are used to map network layer addresses directly into ATM addresses, and the network layer packets are then carried across the ATM network. Native mode protocols will be examined in the next section. The alternate method of carrying network layer packets across an ATM network is known as LAN emulation (LANE). The ATM Forum has recently completed a Phase 1 LAN Emulation specification. This section discusses the rationale for LAN emulation and describes the operation of the protocol. As the name suggests, the function of the LANE protocol is to emulate a local area network on top of an ATM network. Specifically, the LANE protocol defines mechanisms for emulating either an IEEE 802.3 Ethernet or an 802.5 Token Ring LAN. What LAN emulation means is that the LANE protocol defines a service interface for higher layer (that is, network layer) protocols, which is identical to that of existing LANs, and that data sent across the ATM network are encapsulated in the appropriate LAN MAC packet format. It does not mean that any attempt is made to emulate the actual media access control protocol of the specific LAN concerned (that is, CSMA/CD for Ethernet or token passing for 802.5). In other words, the LANE protocols make an ATM network look and behave like an Ethernet or Token Ring LAN - albeit one operating much faster than a real such network. The LANE protocol defines the operation of a single emulated LAN (ELAN). Multiple ELANs may coexist simultaneously on a single ATM network since ATM connections do not“collide.”A single ELAN emulates either Ethernet or Token Ring, and consists of the following entities: LAN Emulation Client (LEC): A LEC is the entity in an end system that performs data forwarding, address resolution, and other control functions for a single end- system within a single ELAN. LAN Emulation Server (LES): The LES implements the control function for a particular ELAN. There is only one logical LES per ELAN, and to belong to a particular ELAN means to have a control relationship with that ELAN's particular LES. Each LES is identified by a unique ATM address. Broadcast and Unknown Server (BUS): The BUS is a multicast server that is used to flood unknown destination address traffic and forward multicast and broadcast traffic to clients within a particular ELAN. Each LEC is associated with only a single BUS per ELAN. The BUS to which a LEC connects is identified by a unique ATM address. In the LES, this is associated with the broadcast MAC address (“all ones”), and this mapping is normally configured into the LES. The Phase 1 LANE entities communicate with each other using a series of ATM connections. LECs maintain separate connections for data transmission and control traffic. The control connections are as follows: ? Configuration Direct VCC: This is a bidirectional point-to-point VCC set up by the LEC to the LECS. ? Control Direct VCC: This is a bidirectional VCC set up by the LEC to the LES. ? Control Distribute VCC: This is a unidirectional VCC set up from the LES back to the LEC; this is typically a point-to-multipoint connection. The data connections are as follows: ? Data Direct VCC: This is a bidirectional point-to-point VCC set up between two LECs that want to exchange data. Two LECs will typically use the same data direct VCC to carry all packets between them, rather than opening a new VCC for each MAC address pair between them, so as to conserve connection resources and connection set-up latency. Since LANE emulates existing LANs, including their lack of QoS support, data direct connections will typically be UBR or ABR connections, and will not offer any type of QoS guarantees. ? Multicast Send VCC: This is a bidirectional point-to-point VCC set up by the LEC to the BUS. ? Multicast Forward VCC: This is a unidirectional VCC set up to the LEC from the BUS, this is typically a point-to-multipoint connection, with each LEC as a leaf. Native Mode Protocols This section discusses the alternate manner of carrying network layer protocols across an ATM network - not through LANE, but with native mode xvinprotocols. While all current network layer protocols could be enhanced to run directly across an ATM network, currently, the only protocols for which extensive work has been done is IP. IP Over ATM The transport of any network layer protocol over an overlay mode ATM network involves two aspects: packet encapsulation and address resolution. Both of these aspects have been tackled by the IETF, and are described below: Packet Encapsulation The IETF worked first on defining a method for transporting multiple types of network or link layer packets across an ATM (AAL 5) connection and also for multiplexing multiple packet types on the same connection. As with LANE, there is value to reusing the same connection for all data transfers between two nodes since this conserves the (typically scarce) connection resource space, and saves on connection setup latency, after the first connection set-up. This is only possible, however, as long as only UBR or ABR connections are used - if the network layer requires QoS guarantees then every distinct flow will typically require its own (VBR) connection. In order to allow connection re-use, there must be a means for a node that receives a network layer packet across an ATM connection to know what kind of packet has been received, and to what application or higher level entity to pass the packet to; hence, the packet must be prefixed with a multiplexing field. Two methods for doing this are defined in RFC 1483. ? LLC/SNAP Encapsulation. In this method, multiple protocol types can be carried across a single connection with the type of encapsulated packet identified by a standard LLC/SNAP header. A further implication of LLC/SNAP encapsulation, however, is that all connections using such encapsulations terminate at the LLC layer within the end-systems, since it is here that the packet multiplexing occurs. ? VC Multiplexing. In the VC muxing method, only a single protocol is carried across an ATM connection, with the type of protocol implicitly identified at connection set-up. As a result, no multiplexing or packet type field is required or carried within the packet, though the encapsulated packet may be prefixed with a pad field. The type of encapsulation used by LANE for data packets is actually a form of VC muxing. Address Resolution In order to operate IP over ATM, a mechanism must be used to resolve IP addresses to their corresponding ATM addresses. For instance, consider the case of two routers connected across an ATM network. If one router receives a packet across a LAN interface, it will first check its next-hop table to determine through which port, and to what next-hop router, it should forward the packet. If this look-up indicates that the packet is to be sent across an ATM interface, the router will then XIXneed to consult an address resolution table to determine the ATM address of the destination next-hop router (the table could also be configured, of course, with the VP I/VCI value of a PVC connecting the two routers). This address resolution table could be configured manually, but this is not a very scalable solution. The IP-Over-ATM working group has defined a protocol to support automatic address resolution of IP addresses in RFC 1 577. This protocol is known as“classical IP over ATM”(for reasons that are discussed later) and introduces the notion of a Logical IP Subnet (LIS). Like a normal IP subnet, a LIS consists of a group of IP nodes (such as hosts or routers) that connect to a single ATM network and belong to the same IP subnet. To resolve the addresses of nodes within the LIS, each LIS supports a single ATMARP server, while all nodes (LIS Clients) within the LIS are configured with the unique ATM address of the ATMARP server. When a node comes up within the LIS, it first establishes a connection to the ATMARP server, using the configured address. Once the ATMARP server detects a connection from a new LIS client, it transmits an Inverse ARP request to the attaching client and requests the node's IP and ATM addresses, which it stores in its ATMARP table. Subsequently, any node within the LIS wishing to resolve a destination IP address would send an ATMARP request to the server, which would then respond with a ATMARP reply if an address mapping is found. If not, it returns an ATM_NAK response to indicate the lack of a registered address mapping. The ATMARP server ages out its address table for robustness, unless clients periodically refresh their entry with responses to the servers Inverse ARP queries. Once an LIS client has obtained the ATM address that corresponds to a particular IP address, it can then set up a connection to the address. UNIX Sockets ATM API, used for ATM on LINUX package is depend on the UNIX sockets. The two most prevalent communication APIs for Unix systems are Berkeley Sockets and the System V Transport Layer Interface (TLI). ATM API is depend on Berkeley sockets.The typical client-server relationship is not symmetrical. To initiate a network connection requires that the program know which role (client or server) it is to play. A network connection can be connection-oriented or connectionless. For connection-oriented protocols, server uses socket( ), bind( ), listen( ), accept( ), read( ), write( ) and client uses socket ( ), connect( ), write( ), read( ) system calls. For connectionless protocol, server uses socket( ), bind( ), recvfrom( ),sendto( ) and client uses socket( ), bind( ), sendto( ), recvfrom( ) system calls. ATM on LINUX The first step in bringing ATM to LINUX was to find ATM adapters that offered sufficient performance, that were available on the market, and for which programming information was openly available. In spring 1995, a driver fot the Efficient Networks ENI155p adapter was written. In order to send data over even only PVCs, a device driver alone isn't enough, but also an API is needed. AlthoughATM Forum is defining a semantic API, this description is far too general for any concrete implementation. Early tests revealed that throughput left much to be desired : instead of the theoretical maximum of 135.6 Mbps for user data with raw ATM, only a throughput of approximately 100 Mbps was obtained under ideal conditions. The results for IP over ATM were much worse. The reason was easily found : because PCs tend to have a slow memory interface, the comparably large number of copy operations in the kernel created a bottleneck. The problem was resolved using a concept called“single-copy”, where data is copied directly between user space and the device driver, without additional copying to kernel buffers. With single-copy, transfer rates of up to 130 Mbps are possible on Linux PCs with native ATM when using sufficiently large datagrams. Signaling protocols are implemented in a demon in user mode. The Linux kernel only implements a very simple protocol to support ATM signaling. All the complexity of ATM signaling is delegated to a user-mode demon process. The internal signaling protocol is much simpler than the signaling protocol that is used on the network, because the following assumptions can be made :. Communication is well-behaved (reliable, preserves sequence, etc.). The communication parties agree on every protocol detail, including the version or revision of the protocol.. The communicating parties always cooperate. Both parties share the same architecture. The protocol is designed for the use with Berkeley-style socket. All the general operations, such as binding to a local address, requesting an outgoing call (either blocking or non-blocking), accepting of incoming connections, etc. are supported.
Benzer Tezler
- Yüksek hızlı yerel alan ağlarının tasarımı ve uygulamaları
Design and applications of high-speed local area networks
SAİT ESER KARLIK
Yüksek Lisans
Türkçe
1999
Elektrik ve Elektronik MühendisliğiUludağ ÜniversitesiElektronik Mühendisliği Ana Bilim Dalı
DR. GÜNEŞ YILMAZ
- Aralarında uzak mesafe bulunan bilgisayarlar ve yerel alan ağları arasında iletişimin sağlanması
The Communication to obtain between remote computers and local area networks
GÜLTEKİN KEKEÇOĞLU
Yüksek Lisans
Türkçe
1999
Elektrik ve Elektronik MühendisliğiErciyes ÜniversitesiElektronik Mühendisliği Ana Bilim Dalı
YRD. DOÇ. DR. SABRİ ÇELİK
- Sakarya Üniversitesi networkünün ATM backbone yapısına uyarlanması ve uygulanması
The Sakarya University's network is adaptationed applicationed to ATM backbone configuration
CEBRAİL TAŞKIN
Yüksek Lisans
Türkçe
1999
Elektrik ve Elektronik MühendisliğiSakarya ÜniversitesiElektrik ve Elektronik Mühendisliği Ana Bilim Dalı
DOÇ. DR. HÜSEYİN EKİZ
- 21 st century university campus internetworking infrastructure
Başlık çevirisi yok
HAKAN BÜYÜKTOPÇU
Yüksek Lisans
İngilizce
2003
Bilgisayar Mühendisliği Bilimleri-Bilgisayar ve KontrolIşık ÜniversitesiBilgisayar Mühendisliği Ana Bilim Dalı
PROF. DR. SIDDIK YARMAN
- Endüstri 4.0'a geçişte örgütsel öğrenme üzerine model önerisi: Bir KOBİ örneği
Model proposal on organizational learning in transition to industry 4.0: An SME example
MERVE VUSLAT AKSU