منابع پایان نامه ارشد با موضوع تلفن همراه

دانلود پایان نامه

مش استفاده شود، بلکه برای ارائه قابلیت های اضافی در WMN می باشد.
نگوین در پایان نامه کارشناسی ارشد خود، 3 توافق برای OF در WMN ها پیشنهاد کرد. اول، زمانی که کنترل کنند? OF متوجه می شود که اتصال در یکی از پورت های سوئیچ ها پایین است، اقدام مناسبی انجام دهید. این امر منجر به پیکر بندی مجدد پویا بر اساس توپولوژی می شود. دوم، هنگامی که ارتباط با کنترل کننده وجود ندارد، سوئیچ را برای کار در حالت مستقل آموزش دهید و نسخه ی پشتیبان کنترل کننده را برای مقابله با ناپایداری اتصالات WMN ارائه دهید. سوم، پیام هایی را که آمارها را از سوئیچ ها به کنترل کننده ها انتقال می دهند و پیام های ارسالی از سوئیچ ها را که سلامت کنترل کننده را بررسی می کنند، کاهش دهید. تطابق اول در واقع می تواند در کنترل کننده های اجرایی سفارشی، اجرا شود، اما با این وجود، با ناپایداری توپولوژی ناشی از چالش 1 مواجه است. تطابق دوم و سوم روش های فنی جالبی برای مواجه با چالش 2 می باشند.
2.14.2 SDN در محیط های ناهمگن و روستایی
حسن و همکاران [20] روش های بکارگیری SDN در شبکه های روستایی را به منظور کار کردن به عنوان ارائه دهندگان ISP زیر ساخت ها مورد بررسی قرار می دهد. این مقاله، فرصت ها و چالش های موجود در این تلاش را توضیح می دهد. در حالیکه شبکه های روستایی شباهت های بسیاری را با CN ها ارائه می دهند، این کار به مشکل موجود در روش نظری انتزاعی بدون ارائه ی هیچ گونه راه حلی نزدیک می شود. یک رویکرد مشابه و کلی تر توسط مندونکا و همکاران[21] در کنفرانس دانشجویان ACM ارائه شد. نویسندگان یک توصیف انتزاعی از چگونگی استفاده ی تکنیک های SDN در WMN های ناهمگن ارائه می دهند. آنها موارد استفاده ی اصلی را تعریف می کنند، یعنی مجموعه ای از شرایطی که SDN ناهمگن باید موارد استفاده را فعال کنند و از شرایطی که مجموعه ای از چالش های پژوهش های مواجه شده را به دست می آورند. متأسفانه هیچ ساختار و یا توصیه های فنی ارائه نشده است، اما در نظر می گیریم که تلاش آنها در تشویق مبحثی که به ایجاد سریع تر این دامنه تحقیقات منجر می شود، مهم است.
2.14.3 SDN در شبکه های تلفن همراه
یاپ [22] به همراه برخی از محرک های اولیه ی OF، OpenRoods ، یک پلت فرم مبتنی بر of را برای پژوهش در شبکه های تلفن همراه ارائه می دهد. این پلت فرم در درجه اول آزمایش های تحرک را مورد هدف قرار می دهد. OpenRoods از of برای کنترل صفحه داده ها و از SNMP برای کنترل تنظیمات دستگاه استفاده می کند. OpenRoods برای استفاده در محیط های کنترل شده با زیر ساخت همگن ارائه شده، ساخته شده است. به نظر می رسد که به جز حفظ توپولوژی و به طور ویژه توپولوژی سرویس گیرنده، این پروژه حاوی هیچ کمکی مربوط به کار ما نیست. همانطور که در بالا نشان داده شده است، SDN در WMN ها و یا در زمینه های مرتبط کاملاً نابالغ می باشند. فهرست مقالات مرتبط با آن بسیار کم است و راه حل های ارائه شده به مشکلات بسیار خاص با راه حل های بسیار خاص می پردازند. هم چنین متوجه می شویم، همانطور که قبلاً ادعا کردیم، هیچ پژوهش در به کارگیری OF در محیط های متفاوت و ناهمگن واقعا وجود ندارد. امیدواریم که تلاش های ما قادر به کمک در تکامل این موضوع باشد.
2.15 نتیجه گیری
زیرساخت‌های شبکه‌های موجود می‌توانتد به تغییر نیازمندی‌ها برای مدیریت جریان‌های ترافیکی، تهیه سطوح متمایز کیفیت سرویس و امنیت برای جریان‌های مجزا پاسخ دهند ولی این روند می‌تواند خیلی وقت‌گیر باشد و اگر شبکه در سازمانی بزرگ مثل شبکه های اجتماعی باشد و یا شامل دستگاه‌ها و تجهیزات شبکه‌ای از فروشندگان مختلف باشد، مدیر شبکه باید هر یک از تجهیزات مختلف را به طور مجزا پیکربندی نموده و پارامترهای امنیتی و کارایی را بر اساس هر session و application تنظیم نماید.
در سازمان‌های بزرگ هر بار که یک ماشین مجازی جدید ایجاد می‌شود، انجام کارهای ضروری توسط مدیر شبکه در زمینه پیکربندی مجدد آن می‌تواند ساعت‌ها و حتی روزها به طول بینجامد. در دوره mainframe، applicationها، سیستم عاملها و سخت‌افزارها همگی توسط یک سازنده تهیه می‌شدند. ولی امروزه اکثر platformها از مجموعه دستورالعمل‌های X86 و چندین سیستم عامل (ویندوز-لینوکس یا MAC OS) استفاده می‌کنند. هر سیستم عامل، APIهایی را فراهم می‌کند که به تهیه‌کنندگان خارجی این امکان را می‌دهد که applicationها را توسعه دهند که باعث نوآوری‌ها و توسعه سریع آنها می‌شود.
همان طور که بعداً خواهیم دید، معماری SDN و استاندارد OpenFlow یک معماری باز را فراهم می‌کنند که در آن توابع کنترلی از تجهیزات شبکه جدا شده است و روی سرورهای کنترل دسترسی قرار دارند. این تنظیمات باعث می‌شود زیرساخت‌های اساسی برای application ها و سرویس‌های شبکه مجزا باشند و با شبکه به عنوان یک موجودیت منطقی رفتار شود.

مطلب مرتبط با این موضوع :  تحقیق دربارهانتقال اطلاعات

3 فصل سوم
روش تحقیق

3.1 مرور کلی و توصیف ساختار
به منظور ارائه درست ساختار خود، ما باید اول محیطی را که در آن آزمایشات اجرا می شود معرفی کنیم. ما یک ساختار بستر آزمایشی شبیه به جامعه آزمایشگاهی را فرض می کنیم که یک فرض معتبر است چرا که رویکردهایی را از بسترهای آزمایشی موفق موجود مانند Planetlab که برای تحقق نیازهای WMN ها و CN ها اصلاح شده به کار گرفته شده. همانطور که در شکل 3.1 مشاهده می کنید، محیط ما توسط گره های بستر آزمایشی، گره های جامعه، و سرور بستر آزمایشی و درواز? بستر آزمایشی تشکیل شده است. این
آزمایش ها در واقع در گره های بستر آزمایشی انجام می شوند اما ترافیک می تواند از گره های جامعه نیز عبور کند. گره های بستر آزمایشی حداقل دو واسط شبکه دارند.

شکل 3.1 ساختار کلی معماری
آنها از طریق یکی از واسط ها به شبکه مدیریت بستر آزمایشی متصل می شوند و هم چنین به سرور بستر آزمایشی می رسند. علاوه بر این، هر گره باید حداقل از یک واسط شبکه برای اتصالات بی سیم محلی به منظور ارتباط با گره های جامعه ی مجاور استفاده کند. کاربران برای ایجاد و گسترش آزمایش خود، به سرور بستر آزمایشی متصل می شوند. هنگامی که کاربر می خواهد یک آزمایش ایجاد کند، قطعه ای جدید و چندین میزبان را ایجاد می کند که به این قطعه متعلق هستند. میزبان ها به عنوان VM ها در داخل گره های بستر آزمایشی اجرا می شوند.
3.1.2 تصمیم گیری
با فرض محیط توصیف شده در بالا، می خواهیم قابلیت های بستر آزمایشی را گسترش دهیم و توانایی انجام آزمایشات L2 را با استفاده از تکنیک های SDN به آزمایشگران ارائه دهیم. گروه خاصی از آزمایش هایی که برای به کارگیری انتخاب می کنیم نیازمند توانایی مدیریت توپولوژی L2 در تمام میزبان های متعلق به یک قطعه می باشند. لازم است یادآوری کنیم که این فقط مثالی است که طراحی ما را جلو خواهد برد، اما مطمئناً تنها نوع آزمایشی که ساختار ما می تواند پشتیبانی کند، نیست. پس از توصیف تمام اینها، اکنون اقدام به ارائه ساختار خود می نماییم که مهمترین تصمیم های ما را توضیح می دهد. این تصمیم های ارائه شده می توانند در 3 گروه قرار بگیرند: پایه ای، که مربوط به زیر ساخت های لازم است؛ عاملیت، که قابلیت های مورد نظر را به سیستم اضافه می کند؛ و در نهایت بهینه سازی، که عملکرد سیستم را افزایش می دهد. این ها را با این ترتیب، با شروع از تصمیمات اساسی ارائه می دهیم.
3.1.2.1 تصمیم 1 : سوئیچ های OF در قسمت میزبان گره های بستر آزمایشی
از آنجا که می خواهیم SDN را برای آزمایشات پشتیبانی کنیم، هر گره ی آزمایشی باید سوئیچ های OF اختصاصی خود را داشته باشد. این سوئیچ ها یا می توانند داخل میزبان و یا در گره ی میزبان واقع شوند. انتخاب ما این بود که سوئیچ های OF را در گره ی میزبان قرار دهیم به طوری که کاربران بتوانند OF را بدون نیاز به جزئیات فنی مورد استفاده قرار دهند. هم چنین، این روش به OF اجازه می دهد تا از مدیران بستر آزمایشی برای مدیریت منابع شبکه ی میزبان ها، به عنوان مثال برای به کارگیری سیاست های QOS استفاده کنند.

مطلب مرتبط با این موضوع :  تحقیق رایگان درموردقانون استخدام کشوری

شکل 3.2 استقرار OpenVswitch
3.1.2.2 تصمیم 2 : کنترل کننده ی OF در سرور بستر آزمایشی
برای مدیریت سوئیچ های OF، به یک کنترل کننده ی OF نیاز داریم. کنترل کننده ی OF باید با تمام سوئیچ های OF و از این رو با میزبان های گره های مرتبط اتصال داشته باشد. علاوه بر این، این کنترل کننده باید در دسترس کاربر باشد چرا که نهادی است که از طریق آن سوئیچ ها می توانند مدیریت شوند. با در نظر گرفتن تمام این موارد، همراه با این واقعیت که سیستم ما باید به عنوان یک سرویس بستر آزمایشی به کار گرفته شوند، تصمیم گرفتیم که کنترل کننده ی OF را در سرور بستر آزمایشی قرار دهیم. سرور بستر آزمایشی برای تمام گره های بستر آزمایشی در دسترس است و علاوه بر آن، یک رابط برای کاربران به منظور مدیریت آزمایشات فراهم می کند. ما در حال حاضر مهم ترین نهادهای ساختار خود را قرار داده ایم. آنچه که باقی می ماند، فراهم نمودن عملکرد آزمایشات L2 و تلاش برای بهینه سازی ساختار با توجه به محیط می باشد.

شکل 3.3 استقرار کنترلر
3.1.2.3 تصمیم 3 : پروتکل مسیریابی لایه 2 مش برای اتصال چندگره ای L2

دیدگاهتان را بنویسید