NB-IoT: چگونه کار می کند؟ بخش 3: SCEF - پنجره واحد دسترسی به خدمات اپراتور

در مقاله «NB-IoT: چگونه کار می کند؟ قسمت 2"، با صحبت در مورد معماری هسته بسته شبکه NB-IoT، به ظاهر یک گره SCEF جدید اشاره کردیم. در قسمت سوم توضیح می دهیم که چیست و چرا لازم است؟

هنگام ایجاد یک سرویس M2M، توسعه دهندگان برنامه با سوالات زیر روبرو می شوند:

• نحوه شناسایی دستگاه ها؛
• از چه الگوریتم تأیید و احراز هویت استفاده شود.
• کدام پروتکل حمل و نقل را برای تعامل با دستگاه ها انتخاب کنید.
• نحوه تحویل قابل اعتماد داده ها به دستگاه ها؛
• نحوه سازماندهی و ایجاد قوانینی برای تبادل داده با آنها؛
• نحوه نظارت و کسب اطلاعات در مورد وضعیت آنها به صورت آنلاین؛
• چگونه به طور همزمان داده ها را به گروهی از دستگاه های خود تحویل دهید.
• نحوه ارسال همزمان داده ها از یک دستگاه به چندین مشتری؛
• نحوه دسترسی یکپارچه به خدمات اپراتور اضافی برای مدیریت دستگاه خود.

برای حل آنها، نیاز به ایجاد راه حل های فنی اختصاصی "سنگین" است که منجر به افزایش هزینه های نیروی کار و خدمات زمان عرضه به بازار می شود. اینجاست که گره SCEF جدید به کمک می آید.

همانطور که توسط 3GPP تعریف شده است، SCEF (عملکرد نوردهی قابلیت سرویس) یک جزء کاملاً جدید از معماری 3GPP است که وظیفه آن نشان دادن ایمن خدمات و قابلیت های ارائه شده توسط رابط های شبکه 3GPP از طریق API است.

به عبارت ساده، SCEF یک واسطه بین شبکه و سرور برنامه (AS)، یک پنجره واحد از دسترسی به خدمات اپراتور برای مدیریت دستگاه M2M شما در شبکه NB-IoT از طریق یک رابط API بصری و استاندارد است.

SCEF پیچیدگی شبکه اپراتور را پنهان می کند و به توسعه دهندگان برنامه اجازه می دهد مکانیسم های پیچیده و خاص دستگاه را برای تعامل با دستگاه ها انتزاع کنند.

با تبدیل پروتکل های شبکه به یک API آشنا برای توسعه دهندگان برنامه، SCEF API ایجاد سرویس های جدید را تسهیل می کند و زمان ورود به بازار را کاهش می دهد. گره جدید همچنین شامل توابعی برای شناسایی/تأیید هویت دستگاه‌های تلفن همراه، تعریف قوانین تبادل داده بین دستگاه و AS، حذف نیاز توسعه‌دهندگان برنامه به پیاده‌سازی این توابع در کنار خود، انتقال این عملکردها به شانه‌های اپراتور است.

SCEF رابط های لازم برای احراز هویت و مجوز سرورهای برنامه، حفظ تحرک UE، انتقال داده و راه اندازی دستگاه، دسترسی به خدمات اضافی و قابلیت های شبکه اپراتور را پوشش می دهد.

در سمت AS یک رابط T8 وجود دارد، یک API (HTTP/JSON) که توسط 3GPP استاندارد شده است. تمام رابط ها، به استثنای T8، بر اساس پروتکل DIAMETER عمل می کنند (شکل 1).

T6a - رابط بین SCEF و MME. برای رویه‌های مدیریت تحرک/جلسه، انتقال داده‌های غیر IP، ارائه رویدادهای نظارت و دریافت گزارش‌ها در مورد آنها استفاده می‌شود.

S6t - رابط بین SCEF و HSS. برای احراز هویت مشترک، مجوز سرورهای برنامه، دریافت ترکیبی از شناسه خارجی و IMSI/MSISDN، تهیه رویدادهای نظارت و دریافت گزارش در مورد آنها مورد نیاز است.

S6m/T4 – رابط‌های SCEF به HSS و SMS-C (3GPP گره MTC-IWF را تعریف می‌کند که برای راه‌اندازی دستگاه و ارسال پیام کوتاه در شبکه‌های NB-IoT استفاده می‌شود. با این حال، در همه پیاده‌سازی‌ها عملکرد این گره در یکپارچه است. SCEF، بنابراین برای ساده سازی مدار، آن را جداگانه در نظر نمی گیریم). برای به دست آوردن اطلاعات مسیریابی برای ارسال پیامک و تعامل با مرکز پیام کوتاه استفاده می شود.

T8 - رابط API برای تعامل SCEF با سرورهای برنامه. هم دستورات کنترلی و هم ترافیک از طریق این رابط منتقل می شود.

*در واقع رابط‌های بیشتری وجود دارد؛ فقط ابتدایی‌ترین آن‌ها در اینجا فهرست شده‌اند. یک لیست کامل در 3GPP 23.682 (4.3.2 List of Reference Points) ارائه شده است.

در زیر توابع و خدمات کلیدی SCEF آمده است:

• پیوند دادن شناسه سیم کارت (IMSI) به شناسه خارجی؛
• انتقال ترافیک غیر IP (تحویل داده های غیر IP، NIDD)؛
• عملیات گروهی با استفاده از شناسه گروه خارجی.
• پشتیبانی از حالت انتقال داده با تایید؛
• بافر کردن داده های MO (Mobile Originated) و MT (Mobile Terminated).
• احراز هویت و مجوز دستگاه ها و سرورهای برنامه؛
• استفاده همزمان از داده های یک UE توسط چندین AS.
• پشتیبانی از عملکردهای ویژه نظارت بر وضعیت UE (MONTE - Monitoring Events)؛
• راه اندازی دستگاه؛
• ارائه رومینگ داده غیر IP

اصل اساسی تعامل بین AS و SCEF به اصطلاح بر اساس طرح است. اشتراک ها در صورت نیاز به دسترسی به هر سرویس SCEF برای یک UE خاص، سرور برنامه باید با ارسال دستوری به API خاص سرویس درخواستی، یک اشتراک ایجاد کند و در پاسخ یک شناسه منحصر به فرد دریافت کند. پس از آن تمام اقدامات و ارتباطات بعدی با UE در چارچوب این سرویس با استفاده از این شناسه انجام می شود.

شناسه خارجی: شناسه جهانی دستگاه

یکی از مهم ترین تغییرات در طرح تعامل بین AS و دستگاه ها هنگام کار از طریق SCEF ظاهر یک شناسه جهانی است. اکنون، به جای شماره تلفن (MSISDN) یا آدرس IP، همانطور که در شبکه کلاسیک 2G/3G/LTE رخ داد، شناسه دستگاه برای سرور برنامه به «شناسه خارجی» تبدیل می‌شود. توسط استاندارد در قالبی آشنا برای توسعه دهندگان برنامه تعریف شده است. @ "

توسعه دهندگان دیگر نیازی به پیاده سازی الگوریتم های احراز هویت دستگاه ندارند؛ شبکه به طور کامل این عملکرد را بر عهده می گیرد. شناسه خارجی به IMSI گره خورده است و توسعه دهنده می تواند مطمئن باشد که هنگام دسترسی به یک شناسه خارجی خاص، با یک سیم کارت خاص تعامل دارد. هنگام استفاده از یک تراشه سیم کارت، زمانی که شناسه خارجی یک دستگاه خاص را به طور منحصربه‌فرد شناسایی می‌کند، یک موقعیت کاملا منحصربه‌فرد دریافت می‌کنید!

علاوه بر این، چندین شناسه خارجی را می توان به یک IMSI مرتبط کرد - زمانی که شناسه خارجی به طور منحصر به فرد یک برنامه خاص را که مسئول یک سرویس خاص در یک دستگاه خاص است، شناسایی می کند، وضعیت جالب تری ایجاد می شود.

یک شناسه گروه نیز ظاهر می شود - شناسه گروه خارجی، که شامل مجموعه ای از شناسه های خارجی فردی است. اکنون، با یک درخواست به SCEF، AS می تواند عملیات گروهی را آغاز کند - ارسال داده یا دستورات کنترلی به چندین دستگاه متحد شده در یک گروه منطقی واحد.

با توجه به این واقعیت که برای توسعه دهندگان AS انتقال به یک شناسه دستگاه جدید نمی تواند آنی باشد، SCEF امکان ارتباط AS با UE را از طریق یک شماره استاندارد - MSISDN باقی گذاشت.

انتقال ترافیک غیر IP (تحویل داده غیر IP، NIDD)

در NB-IoT، به عنوان بخشی از بهینه سازی مکانیسم برای انتقال مقادیر کم داده، علاوه بر انواع PDN موجود، مانند IPv4، IPv6 و IPv4v6، نوع دیگری نیز ظاهر شده است - غیر IP. در این حالت به دستگاه (UE) آدرس IP اختصاص داده نمی شود و داده ها بدون استفاده از پروتکل IP منتقل می شوند. ترافیک برای چنین اتصالاتی را می توان به دو روش هدایت کرد: کلاسیک - MME -> SGW -> PGW و سپس از طریق تونل PtP به AS (شکل 2) یا با استفاده از SCEF (شکل 3).

روش کلاسیک هیچ مزیت خاصی نسبت به ترافیک IP ارائه نمی دهد، به جز کاهش اندازه بسته های ارسالی به دلیل عدم وجود هدر IP. استفاده از SCEF تعدادی از احتمالات جدید را باز می کند و به طور قابل توجهی روش های تعامل با دستگاه ها را ساده می کند.

هنگام انتقال داده ها از طریق SCEF، دو مزیت بسیار مهم نسبت به ترافیک IP کلاسیک ظاهر می شود:


تحویل ترافیک MT به دستگاه از طریق شناسه خارجی

برای ارسال پیام به یک دستگاه IP کلاسیک، AS باید آدرس IP آن را بداند. در اینجا یک مشکل ایجاد می شود: از آنجایی که دستگاه معمولاً یک آدرس IP "خاکستری" را هنگام ثبت نام دریافت می کند، از طریق یک گره NAT با سرور برنامه که در اینترنت قرار دارد ارتباط برقرار می کند، جایی که آدرس خاکستری به سفید ترجمه می شود. ترکیب آدرس‌های IP خاکستری و سفید بسته به تنظیمات NAT برای مدت زمان محدودی دوام دارد. به طور متوسط، برای TCP یا UDP - بیش از پنج دقیقه نیست. یعنی اگر ظرف مدت 5 دقیقه با این دستگاه تبادل داده نشود، اتصال از بین می رود و دستگاه دیگر در آدرس سفیدی که جلسه با AS با آن شروع شده است قابل دسترسی نخواهد بود. چندین راه حل وجود دارد:

1. از ضربان قلب استفاده کنید. هنگامی که یک اتصال برقرار شد، دستگاه باید هر چند دقیقه یک بار بسته ها را با AS مبادله کند، در نتیجه از بسته شدن ترجمه های NAT جلوگیری می کند. اما در اینجا نمی توان در مورد بهره وری انرژی صحبت کرد.

2. هر بار، در صورت لزوم، در دسترس بودن بسته های دستگاه را در AS بررسی کنید - یک پیام به uplink ارسال کنید.

3. یک APN خصوصی (VRF) ایجاد کنید، جایی که سرور برنامه و دستگاه‌ها در یک زیرشبکه قرار دارند و آدرس‌های IP ثابت را به دستگاه‌ها اختصاص دهید. این کار خواهد کرد، اما زمانی که ما در مورد ناوگان هزاران، ده ها هزار دستگاه صحبت می کنیم، تقریبا غیرممکن است.

4. در نهایت، مناسب ترین گزینه: استفاده از IPv6؛ نیازی به NAT ندارد، زیرا آدرس های IPv6 مستقیماً از طریق اینترنت قابل دسترسی هستند. با این حال، حتی در این حالت، هنگامی که دستگاه مجدداً ثبت می شود، یک آدرس IPv6 جدید دریافت می کند و دیگر با استفاده از آدرس قبلی قابل دسترسی نخواهد بود.

بر این اساس، لازم است مقداری بسته اولیه با شناسه دستگاه به سرور ارسال شود تا آدرس IP جدید دستگاه گزارش شود. سپس منتظر یک بسته تایید از AS باشید که بر بهره وری انرژی نیز تاثیر می گذارد.

این روش‌ها برای دستگاه‌های 2G/3G/LTE به خوبی کار می‌کنند، جایی که دستگاه الزامات سخت‌گیری برای استقلال ندارد و در نتیجه محدودیتی در زمان پخش و ترافیک وجود ندارد. این روش ها به دلیل مصرف بالای انرژی برای NB-IoT مناسب نیستند.

SCEF این مشکل را حل می کند: از آنجایی که تنها شناسه دستگاه برای یک AS یک شناسه خارجی است، AS فقط باید یک بسته داده برای یک شناسه خارجی خاص به SCEF ارسال کند و SCEF بقیه موارد را بر عهده می گیرد. در صورتی که دستگاه در حالت صرفه جویی در انرژی PSM یا eDRX باشد، داده ها بافر می شوند و با در دسترس قرار گرفتن دستگاه تحویل داده می شوند. اگر دستگاه برای ترافیک در دسترس باشد، داده ها بلافاصله تحویل داده می شود. همین امر در مورد تیم های مدیریتی نیز صادق است.

در هر زمان، AS می تواند پیام بافر شده را به UE فراخوانی کند یا آن را با پیام جدیدی جایگزین کند.

مکانیسم بافر همچنین می تواند هنگام انتقال داده های MO از UE به AS استفاده شود. اگر SCEF نتواند داده‌ها را فوراً به AS تحویل دهد، به عنوان مثال اگر کار تعمیر و نگهداری در سرورهای AS ادامه داشته باشد، این بسته‌ها به محض در دسترس قرار گرفتن AS بافر می‌شوند و تضمین می‌شوند که تحویل داده شوند.

همانطور که در بالا ذکر شد، دسترسی به یک سرویس خاص و UE برای یک AS (و NIDD یک سرویس است) توسط قوانین و خط مشی هایی در سمت SCEF تنظیم می شود، که امکان استفاده همزمان از داده های یک UE توسط چندین AS را فراهم می کند. آن ها اگر چندین AS در یک UE مشترک شده باشند، پس از دریافت داده از UE، SCEF آن را برای همه AS مشترک ارسال می کند. این برای مواردی مناسب است که سازنده ناوگانی از دستگاه های تخصصی داده ها را بین چندین مشتری به اشتراک می گذارد. به عنوان مثال، با ایجاد شبکه ای از ایستگاه های هواشناسی که بر روی NB-IoT کار می کنند، می توانید داده های آنها را به بسیاری از خدمات به طور همزمان بفروشید.

مکانیزم تحویل پیام تضمینی

Reliable Data Service مکانیزمی است برای تحویل تضمینی پیام‌های MO و MT بدون استفاده از الگوریتم‌های تخصصی در سطح پروتکل، مانند به عنوان مثال، دست دادن در TCP. هنگام رد و بدل شدن بین UE و SCEF، با گنجاندن یک پرچم ویژه در بخش خدمات پیام کار می کند. فعال شدن یا نشدن این مکانیسم هنگام انتقال ترافیک توسط AS تعیین می شود.

اگر مکانیزم فعال شود، UE یک پرچم ویژه را در قسمت بالای بسته زمانی که به تحویل تضمینی ترافیک MO نیاز دارد، اضافه می کند. به محض دریافت چنین بسته ای، SCEF با یک تایید به UE پاسخ می دهد. اگر UE بسته تایید را دریافت نکند، بسته به سمت SCEF دوباره ارسال می شود. همین اتفاق برای ترافیک MT نیز می افتد.

نظارت بر دستگاه (پایش رویدادها - MONTE)

همانطور که در بالا ذکر شد، عملکرد SCEF، در میان چیزهای دیگر، شامل توابعی برای نظارت بر وضعیت UE، به اصطلاح است. نظارت بر دستگاه و اگر شناسه‌های جدید و مکانیسم‌های انتقال داده بهینه‌سازی (البته بسیار جدی) رویه‌های موجود باشند، MONTE یک عملکرد کاملاً جدید است که در شبکه‌های 2G/3G/LTE در دسترس نیست. MONTE به AS اجازه می دهد تا پارامترهای دستگاه مانند وضعیت اتصال، در دسترس بودن ارتباطات، مکان، وضعیت رومینگ و غیره را نظارت کند. کمی بعد در مورد هر کدام با جزئیات بیشتر صحبت خواهیم کرد.

اگر لازم باشد هر رویداد نظارتی برای یک دستگاه یا گروهی از دستگاه‌ها فعال شود، AS با ارسال فرمان API MONTE مربوطه به SCEF، که شامل پارامترهایی مانند شناسه خارجی یا شناسه گروه خارجی، شناسه AS، نظارت است، در سرویس مربوطه مشترک می‌شود. نوع، تعداد گزارش هایی که AS می خواهد دریافت کند. اگر AS مجاز به اجرای درخواست باشد، SCEF، بسته به نوع، رویداد را در اختیار HSS یا MME قرار می دهد (شکل 4). هنگامی که یک رویداد رخ می دهد، MME یا HSS گزارشی را به SCEF تولید می کند که آن را به AS ارسال می کند.

ارائه همه رویدادها، به استثنای "تعداد UE های موجود در یک منطقه جغرافیایی" از طریق HSS انجام می شود. دو رویداد "تغییر انجمن IMSI-IMEI" و "وضعیت رومینگ" مستقیماً در HSS ردیابی می شوند، بقیه توسط HSS در MME ارائه می شود.
رویدادها می توانند یک بار یا دوره ای باشند و بر اساس نوع آنها تعیین می شوند.

ارسال گزارش در مورد یک رویداد (گزارش) توسط گره ای انجام می شود که رویداد را مستقیماً به SCEF ردیابی می کند (شکل 5).

نکته مهم: رویدادهای نظارت را می توان برای هر دو دستگاه غیر IP متصل شده از طریق SCEF و دستگاه های IP اعمال کرد که داده ها را به روش کلاسیک از طریق MME-SGW-PGW منتقل می کنند.

بیایید نگاهی دقیق تر به هر یک از رویدادهای نظارت داشته باشیم:

از دست دادن اتصال - به AS اطلاع می دهد که UE دیگر برای ترافیک داده یا سیگنالینگ در دسترس نیست. این رویداد زمانی رخ می‌دهد که «تایمر دسترسی به تلفن همراه» برای UE در MME منقضی شود. در یک درخواست برای این نوع نظارت، AS می تواند مقدار "حداکثر زمان تشخیص" خود را نشان دهد - اگر در این مدت UE هیچ گونه فعالیتی را نشان ندهد، به AS اطلاع داده می شود که UE در دسترس نیست و دلیل آن را نشان می دهد. این رویداد همچنین در صورتی رخ می دهد که UE به هر دلیلی به اجبار توسط شبکه حذف شود.

* برای اینکه شبکه بداند دستگاه هنوز در دسترس است، به طور دوره ای یک روند به روز رسانی را آغاز می کند - به روز رسانی منطقه ردیابی (TAU). فرکانس این رویه توسط شبکه با استفاده از تایمر T3412 یا (T3412_extended در مورد PSM) تنظیم می شود که مقدار آن در طول رویه Attach یا TAU بعدی به دستگاه منتقل می شود. تایمر دسترسی به موبایل معمولا چند دقیقه طولانی تر از T3412 است. اگر UE قبل از انقضای "تایمر دسترس پذیری تلفن همراه" TAU ایجاد نکرده باشد، شبکه آن را دیگر قابل دسترسی نمی داند.

دسترسی به UE – زمانی را نشان می دهد که UE برای ترافیک DL یا پیامک در دسترس می شود. این زمانی اتفاق می‌افتد که UE برای صفحه‌بندی در دسترس می‌شود (برای UE در حالت eDRX) یا زمانی که UE وارد حالت ECM-CONNECTED می‌شود (برای UE در حالت PSM یا eDRX)، یعنی. یک TAU می سازد یا یک بسته uplink ارسال می کند.

گزارش موقعیت مکانی - این نوع رویدادهای نظارتی به AS اجازه می دهد تا مکان UE را جستجو کند. مکان فعلی (موقعیت فعلی) یا آخرین مکان شناخته شده (مشخص شده توسط شناسه سلولی که دستگاه آخرین بار از آن TAU ساخته یا ترافیک ارسال کرده است) را می توان درخواست کرد، که برای دستگاه هایی در حالت های ذخیره انرژی PSM یا eDRX مرتبط است. برای «موقعیت مکانی فعلی»، AS می‌تواند پاسخ‌های مکرر را درخواست کند، با هر بار تغییر مکان دستگاه، MME به AS اطلاع می‌دهد.

تغییر انجمن IMSI-IMEI – هنگامی که این رویداد فعال می شود، SCEF شروع به نظارت بر تغییرات در ترکیب IMSI (شناسه سیم کارت) و IMEI (شناسه دستگاه) می کند. هنگامی که یک رویداد رخ می دهد، به AS اطلاع می دهد. می توان از آن برای اتصال خودکار یک شناسه خارجی به دستگاه در طول کار تعویض برنامه ریزی شده استفاده کرد یا به عنوان شناسه سرقت دستگاه عمل کرد.

وضعیت رومینگ - این نوع نظارت توسط AS برای تعیین اینکه آیا UE در شبکه خانگی است یا در شبکه یک شریک رومینگ استفاده می شود. به صورت اختیاری، PLMN (شبکه موبایل زمین عمومی) اپراتوری که دستگاه در آن ثبت شده است، قابل انتقال است.

شکست ارتباطات — این نوع نظارت بر اساس دلایل قطع اتصال (کد علت انتشار) دریافتی از شبکه دسترسی رادیویی (پروتکل S1-AP) AS را از خرابی در ارتباط با دستگاه مطلع می کند. این رویداد می تواند به تعیین علت شکست ارتباط کمک کند - به دلیل مشکلات موجود در شبکه، به عنوان مثال، زمانی که eNodeb بیش از حد بارگذاری شده است (منابع رادیو در دسترس نیست) یا به دلیل خرابی خود دستگاه (اتصال رادیویی با UE Lost).

در دسترس بودن پس از خرابی DDN - این رویداد به AS اطلاع می دهد که دستگاه پس از قطع ارتباط در دسترس قرار گرفته است. می تواند در مواقعی که نیاز به انتقال داده ها به یک دستگاه وجود دارد استفاده شود، اما تلاش قبلی موفقیت آمیز نبود زیرا UE به یک اعلان از شبکه (صفحه بندی) پاسخ نداد و داده ها تحویل داده نشد. اگر این نوع نظارت برای UE درخواست شده باشد، به محض اینکه دستگاه یک ارتباط ورودی برقرار کند، یک TAU ایجاد کند یا داده ها را به uplink ارسال کند، به AS اطلاع داده می شود که دستگاه در دسترس قرار گرفته است. از آنجایی که رویه DDN (اعلان داده‌های لینک پایین) بین MME و S/P-GW کار می‌کند، این نوع نظارت فقط برای دستگاه‌های IP در دسترس است.

وضعیت اتصال PDN - هنگامی که وضعیت دستگاه تغییر می کند (وضعیت اتصال PDN) - اتصال (فعال سازی PDN) یا قطع (حذف PDN) به AS اطلاع می دهد. این می تواند توسط AS برای شروع ارتباط با UE یا برعکس برای درک اینکه ارتباط دیگر امکان پذیر نیست استفاده شود. این نوع نظارت برای دستگاه های IP و غیر IP در دسترس است.

تعداد UE های موجود در یک منطقه جغرافیایی - این نوع نظارت توسط AS برای تعیین تعداد UE ها در یک منطقه جغرافیایی خاص استفاده می شود.

راه اندازی دستگاه)

در شبکه های 2G/3G، روند ثبت نام در شبکه دو مرحله ای بود: ابتدا، دستگاه با SGSN (رویه پیوست) ثبت می شد، سپس در صورت لزوم، زمینه PDP را فعال می کرد - اتصال با دروازه بسته (GGSN) برای انتقال داده ها در شبکه های 3G، این دو رویه به صورت متوالی رخ می دهند، یعنی. دستگاه برای لحظه ای که نیاز به انتقال داده داشت منتظر نمی ماند، اما بلافاصله پس از اتمام مراحل پیوست، PDP را فعال می کرد. در LTE، این دو رویه در یکی ترکیب شدند، یعنی هنگام اتصال، دستگاه بلافاصله درخواست فعال سازی اتصال PDN (مشابه PDP در 2G/3G) را از طریق eNodeB به MME-SGW-PGW کرد.

NB-IoT یک روش اتصال را به عنوان "اتصال بدون PDN" تعریف می کند، یعنی UE بدون ایجاد یک اتصال PDN متصل می شود. در این حالت برای انتقال ترافیک در دسترس نیست و فقط می تواند پیامک دریافت یا ارسال کند. به منظور ارسال فرمان به چنین دستگاهی برای فعال کردن PDN و اتصال به AS، عملکرد "راه‌اندازی دستگاه" توسعه داده شد.

هنگام دریافت فرمان برای اتصال چنین UE از AS، SCEF ارسال پیامک کنترلی را از طریق مرکز پیام کوتاه به دستگاه آغاز می کند. هنگام دریافت پیامک، دستگاه PDN را فعال می کند و برای دریافت دستورالعمل های بیشتر یا انتقال داده به AS متصل می شود.

ممکن است زمانی وجود داشته باشد که اشتراک دستگاه شما در SCEF منقضی شود. بله، اشتراک طول عمر خاص خود را دارد که توسط اپراتور تنظیم شده یا با AS توافق شده است. پس از انقضا، PDN در MME غیرفعال می شود و دستگاه برای AS از دسترس خارج می شود. در این مورد، عملکرد «راه‌اندازی دستگاه» نیز کمک خواهد کرد. هنگام دریافت داده های جدید از AS، SCEF وضعیت اتصال دستگاه را می یابد و داده ها را از طریق کانال پیام کوتاه تحویل می دهد.

نتیجه

البته عملکرد SCEF به خدماتی که در بالا توضیح داده شد محدود نمی شود و دائما در حال توسعه و گسترش است. در حال حاضر بیش از ده ها سرویس برای SCEF استاندارد شده اند. اکنون ما فقط به توابع اصلی مورد تقاضای توسعه دهندگان دست زده ایم؛ در مقالات بعدی در مورد بقیه صحبت خواهیم کرد.

بلافاصله این سؤال مطرح می شود: چگونه می توان برای آزمایش اولیه و اشکال زدایی موارد احتمالی به این گره "معجزه" دسترسی آزمایشی داشت؟ همه چیز بسیار ساده است. هر توسعه دهنده ای می تواند درخواست خود را ارسال کند [ایمیل محافظت شده]، که در آن کافی است هدف از اتصال، شرح یک مورد احتمالی و اطلاعات تماس برای ارتباط مشخص شود.

تا دفعه بعد!

نویسنده:

• سرگئی نوویکوف، کارشناس ارشد بخش راه حل های همگرا و خدمات چند رسانه ای sanov,
• الکسی لاپشین، کارشناس بخش راه حل های همگرا و خدمات چند رسانه ای اسلپش

منبع: www.habr.com