NB-IoT: دا څنګه کار کوي؟ دریمه برخه: SCEF - د آپریټر خدماتو ته د لاسرسي واحد کړکۍ

په مقاله کې "NB-IoT: دا څنګه کار کوي؟ 2 برخه"، د NB-IoT شبکې د پاکټ کور د جوړښت په اړه خبرې کول، موږ د نوي SCEF نوډ بڼه یادونه وکړه. موږ په دریمه برخه کې تشریح کوو چې دا څه دي او ولې ورته اړتیا ده؟

کله چې د M2M خدمت رامینځته کړئ ، د غوښتنلیک پراختیا کونکي د لاندې پوښتنو سره مخ کیږي:

• د وسایلو پیژندلو څرنګوالی؛
• کوم تصدیق او تصدیق الګوریتم کارول کیږي؛
• کوم ټرانسپورټ پروتوکول د وسیلو سره د متقابل عمل لپاره غوره کول؛
• څنګه وسايلو ته په ډاډمن ډول معلومات وړاندې کړئ؛
• د دوی سره د معلوماتو تبادلې لپاره څنګه تنظیم او تنظیم کول؛
• د دوی د حالت په اړه آنلاین معلومات څنګه څارل او ترلاسه کول؛
• څنګه کولی شئ په ورته وخت کې ستاسو د وسیلو یوې ډلې ته معلومات وړاندې کړئ؛
• څنګه کولای شو چی په یو وخت کې د یوې وسیلې څخه څو پیرودونکو ته معلومات ولیږو؛
• ستاسو د وسیلې اداره کولو لپاره اضافي آپریټر خدماتو ته متحد لاسرسي څنګه ترلاسه کړئ.

د دوی د حل کولو لپاره، دا اړینه ده چې د ملکیت تخنیکي پلوه "درانه" حلونه رامینځته کړي، کوم چې د کار لګښتونو او بازار ته د وخت خدماتو زیاتوالي لامل کیږي. دا هغه ځای دی چې د نوي SCEF نوډ ژغورنې ته راځي.

لکه څنګه چې د 3GPP لخوا تعریف شوی، SCEF (د خدماتو وړتیا افشا کولو فعالیت) د 3GPP جوړښت یوه بشپړه نوې برخه ده چې دنده یې د APIs له لارې د 3GPP شبکې انٹرفیسونو لخوا چمتو شوي خدمات او وړتیاوې په خوندي ډول افشا کول دي.

په ساده کلمو کې، SCEF د شبکې او غوښتنلیک سرور (AS) ترمنځ منځګړیتوب دی، د انټرنېټ، معیاري API انٹرفیس له لارې د NB-IoT شبکې کې ستاسو د M2M وسیله اداره کولو لپاره د آپریټر خدماتو ته د لاسرسي یوه کړکۍ ده.

SCEF د آپریټر شبکې پیچلتیا پټوي، د غوښتنلیک پراختیا کونکو ته اجازه ورکوي چې د وسایلو سره د تعامل لپاره پیچلي، د وسیلې ځانګړي میکانیزمونه خلاص کړي.

د غوښتنلیک پراختیا کونکو لپاره د شبکې پروتوکولونو په پیژندل شوي API بدلولو سره ، SCEF API د نوي خدماتو رامینځته کول اسانه کوي او بازار ته وخت کموي. په نوي نوډ کې د ګرځنده وسیلو پیژندلو / تصدیق کولو دندې هم شاملې دي ، د وسیلې او AS ترمینځ د ډیټا تبادلې لپاره مقررات تعریف کول ، د غوښتنلیک پراختیا کونکو اړتیا لرې کول چې دا دندې په خپل اړخ کې پلي کړي ، دا دندې د آپریټر اوږو ته لیږدوي.

SCEF د غوښتنلیک سرورونو تصدیق او تصویب لپاره اړین انٹرفیسونه پوښي، د UE خوځښت ساتل، د معلوماتو لیږد او د وسیلې محرک کول، اضافي خدماتو ته لاسرسی او د آپریټر شبکې وړتیاوې.

د AS په لور یو واحد T8 انٹرفیس شتون لري، یو API (HTTP/JSON) د 3GPP لخوا معیاري شوی. ټول انٹرفیسونه، د T8 په استثنا سره، د DIAMETER پروتوکول پر بنسټ کار کوي (انځور 1).

T6a - د SCEF او MME ترمنځ انٹرفیس. د خوځښت / سیشن مدیریت پروسیجرونو لپاره کارول کیږي، د غیر IP معلوماتو لیږد، د پیښو نظارت کولو چمتو کول او د دوی په اړه راپورونه ترلاسه کول.

S6t - د SCEF او HSS ترمنځ انٹرفیس. د پیرودونکي تصدیق لپاره اړین دی، د غوښتنلیک سرورونو واک ورکول، د بهرني ID او IMSI/MSISDN ترکیب ترلاسه کول، د څارنې پیښو چمتو کول او د دوی په اړه راپورونه ترلاسه کول.

S6m/T4 – له SCEF څخه HSS او SMS-C ته انٹرفیسونه (3GPP د MTC-IWF نوډ تعریفوي، کوم چې په NB-IoT شبکو کې د وسیلې د محرک کولو او ایس ایم ایس لیږد لپاره کارول کیږي. په هرصورت، په ټولو تطبیقونو کې د دې نوډ فعالیت سره یوځای کیږي. SCEF، نو د سرکټ ساده کولو لپاره، موږ به دا په جلا توګه په پام کې ونیسو). د ایس ایم ایس لیږلو او د ایس ایم ایس مرکز سره متقابل عمل کولو لپاره د روټینګ معلوماتو ترلاسه کولو لپاره کارول کیږي.

T8 - د غوښتنلیک سرورونو سره د SCEF تعامل لپاره API انٹرفیس. د کنټرول کمانډونه او ترافیک دواړه د دې انٹرفیس له لارې لیږدول کیږي.

* په حقیقت کې ډیر انٹرفیسونه شتون لري؛ یوازې خورا لومړني لیست شوي دي. یو بشپړ لیست په 3GPP 23.682 (4.3.2 د حوالې ټکي لیست) کې ورکړل شوی.

لاندې د SCEF کلیدي دندې او خدمات دي:

• د سیم کارت پیژندونکی (IMSI) د بهرني ID سره نښلول؛
• د غیر IP ټرافیک لیږد (غیر IP ډیټا تحویلي، NIDD)؛
• د بهرني ګروپ ID په کارولو سره ډله ایز عملیات؛
• د تایید سره د معلوماتو لیږد حالت لپاره ملاتړ؛
• د MO (موبایل اوریګینټ) او MT (موبایل ختم شوی) ډیټا بفرینګ؛
• د وسیلو او غوښتنلیک سرورونو تصدیق او اختیار؛
• د یو UE څخه د څو ASs لخوا په ورته وخت کې د معلوماتو کارول؛
• د ځانګړو UE وضعیت څارنې دندو لپاره ملاتړ (MONTE - د پیښو څارنه)؛
• آله محرک؛
• د غیر IP ډیټا رومینګ چمتو کول.

د AS او SCEF ترمنځ د متقابل عمل بنسټیز اصل د تش په نامه سکیم پر بنسټ والړ دی. ګډون که دا اړینه وي چې د ځانګړي UE لپاره کوم SCEF خدمت ته لاسرسی ومومئ ، د غوښتنلیک سرور اړتیا لري د غوښتل شوي خدمت ځانګړي API ته د کمانډ په لیږلو سره ګډون رامینځته کړي او په ځواب کې یو ځانګړی پیژندونکی ترلاسه کړي. وروسته له دې چې د دې خدمت په چوکاټ کې د UE سره نور ټولې کړنې او اړیکې به د دې پیژندونکي په کارولو سره ترسره شي.

بهرنۍ ID: یونیورسل وسیله پیژندونکی

د AS او وسیلو ترمینځ د متقابل عمل سکیم کې یو له خورا مهم بدلونونو څخه کله چې د SCEF له لارې کار کوي د نړیوال پیژندونکي ظاهري بڼه ده. اوس، د تلیفون شمیرې (MSISDN) یا IP پتې پرځای، لکه څنګه چې په کلاسیک 2G/3G/LTE شبکه کې قضیه وه، د غوښتنلیک سرور لپاره وسیله پیژندونکی "بهرنی ID" کیږي. دا د معیار لخوا تعریف شوی په ب formatه کې چې د غوښتنلیک پراختیا کونکو ته پیژندل کیږي " @ "

پراختیا کونکي نور اړتیا نلري د وسیلې تصدیق کولو الګوریتم پلي کړي؛ شبکه په بشپړ ډول دا فعالیت په غاړه اخلي. بهرنۍ ID د IMSI سره تړلې ده، او پراختیا کونکی کولی شي ډاډه شي چې کله یو ځانګړي بهرني ID ته لاسرسی ومومي، دا د ځانګړي سیم کارت سره اړیکه لري. کله چې د سیم چپ کاروئ ، تاسو یو بشپړ ځانګړی حالت ترلاسه کوئ کله چې بهرنۍ ID په ځانګړي ډول یو ځانګړی وسیله پیژني!

سربیره پردې ، ډیری بهرني IDs د یو IMSI سره تړل کیدی شي - حتی ډیر په زړه پوری حالت رامینځته کیږي کله چې بهرنۍ ID په ځانګړي ډول یو ځانګړي غوښتنلیک پیژني چې په ځانګړي وسیله کې د ځانګړي خدمت لپاره مسؤل دی.

د ګروپ پیژندونکی هم څرګندیږي - د بهرنۍ ډلې ID، چې د انفرادي بهرني IDs سیټ پکې شامل دي. اوس، SCEF ته د یوې غوښتنې سره، AS کولی شي د ګروپ عملیات پیل کړي - په یو واحد منطقي ګروپ کې متحد ډیری وسیلو ته د ډیټا یا کنټرول کمانډ لیږل.

د دې حقیقت له امله چې د AS پراختیا کونکو لپاره نوي وسیلې پیژندونکي ته لیږد سمدستي نشي کیدی ، SCEF د معیاري شمیرې - MSISDN له لارې UE سره د AS ارتباط امکان پریښود.

د غیر 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 ترافیک په اړه څرګندیږي:


د بهرني ID له لارې وسیلې ته د MT ترافیک تحویلول

د کلاسیک IP وسیلې ته د پیغام لیږلو لپاره ، AS باید خپل IP پته وپیژني. دلته یوه ستونزه رامینځته کیږي: ځکه چې وسیله معمولا د راجسټریشن پرمهال "خړ" IP پته ترلاسه کوي ، دا د غوښتنلیک سرور سره اړیکه نیسي ، کوم چې په انټرنیټ کې موقعیت لري ، د NAT نوډ له لارې ، چیرې چې خړ پته په سپینه ژباړل کیږي. د خړ او سپین IP پتې ترکیب د محدود وخت لپاره دوام کوي، د NAT ترتیباتو پورې اړه لري. په اوسط ډول، د TCP یا UDP لپاره - له پنځو دقیقو څخه ډیر نه. دا دی، که چیرې په 5 دقیقو کې د دې وسیلې سره د معلوماتو تبادله شتون ونلري، پیوستون به منحل شي او وسیله به نور په هغه سپین پته کې د لاسرسي وړ نه وي چې د AS سره ناسته پیل شوې وه. څو حلونه شتون لري:

1. د زړه ټکان وکاروئ. یوځل چې اړیکه جوړه شي، وسیله باید په هر څو دقیقو کې د AS سره پاکټونه تبادله کړي، په دې توګه د NAT ژباړې د تړلو مخه نیسي. مګر دلته د انرژي موثریت په اړه خبرې نشي کیدی.

2. هر وخت، که اړتیا وي، په AS کې د وسیلې لپاره د کڅوړو شتون وګورئ - اپلنک ته پیغام واستوئ.

3. یو شخصي APN (VRF) جوړ کړئ، چیرې چې د اپلیکیشن سرور او وسایل به په ورته سبنټ کې وي، او وسایلو ته جامد IP پتې وټاکئ. دا به کار وکړي، مګر دا تقریبا ناممکن دی کله چې موږ د زرګونو، لسګونو زرو وسیلو په اړه خبرې کوو.

4. په پای کې، ترټولو مناسب انتخاب: IPv6 وکاروئ؛ دا NAT ته اړتیا نلري، ځکه چې د IPv6 پتې مستقیم له انټرنیټ څخه د لاسرسي وړ دي. په هرصورت، حتی پدې حالت کې، کله چې وسیله بیا راجستر شي، دا به یو نوی IPv6 پته ترلاسه کړي او نور به د مخکیني په کارولو سره د لاسرسي وړ نه وي.

په دې اساس، دا اړینه ده چې د وسیلې پیژندونکي سره ځینې ابتدايي کڅوړې سرور ته واستوي ترڅو د وسیلې نوي IP پته راپور کړي. بیا د AS څخه د تایید کڅوړې ته انتظار وکړئ ، کوم چې د انرژي موثریت هم اغیزه کوي.

دا میتودونه د 2G/3G/LTE وسیلو لپاره ښه کار کوي ، چیرې چې وسیله د خپلواکۍ لپاره سخت اړتیاوې نلري او په پایله کې ، د هوایی وخت او ترافیک محدودیتونه شتون نلري. دا میتودونه د NB-IoT لپاره د دوی د لوړې انرژي مصرف له امله مناسب ندي.

SCEF دا ستونزه حل کوي: ځکه چې د AS لپاره یوازینی وسیله پیژندونکی بهرنۍ ID دی، AS یوازې اړتیا لري چې د ځانګړي بهرني ID لپاره SCEF ته د ډیټا کڅوړه واستوي، او SCEF د پاتې برخې پاملرنه کوي. په هغه صورت کې چې وسیله د PSM یا eDRX بریښنا سپمولو حالت کې وي، ډاټا به بفر شي او تحویل شي کله چې وسیله شتون ولري. که چیرې وسیله د ترافیک لپاره شتون ولري ، معلومات به سمدلاسه وسپارل شي. ورته د مدیریت ټیمونو لپاره ریښتیا ده.

په هر وخت کې، AS کولی شي بفر شوی پیغام UE ته یاد کړي یا یې د نوي سره بدل کړي.

د بفرینګ میکانیزم هم کارول کیدی شي کله چې د UE څخه AS ته د MO ډیټا لیږدول کیږي. که SCEF ونه توانیده چې سمدستي AS ته معلومات ورسوي، د بیلګې په توګه که چیرې د AS سرورونو کې د ساتنې کار روان وي، دا پاکټونه به بفر شي او د AS شتون سره سم به د سپارلو تضمین شي.

لکه څنګه چې پورته یادونه وشوه، د AS لپاره یو ځانګړي خدمت او UE ته لاسرسی (او NIDD یو خدمت دی) د SCEF اړخ کې د مقرراتو او پالیسیو لخوا تنظیم کیږي، کوم چې د یو UE څخه د ډیری ASs لخوا د ډیټا یوځل کارولو ځانګړي امکان ته اجازه ورکوي. هغوی. که څو AS یو UE ته ګډون کړی وي، نو د UE څخه د معلوماتو ترلاسه کولو وروسته، SCEF به دا ټولو ګډون شوي AS ته واستوي. دا د هغو قضیو لپاره مناسب دی چیرې چې د ځانګړو وسیلو بیړۍ جوړونکی د ډیری پیرودونکو ترمینځ ډیټا شریکوي. د مثال په توګه، په NB-IoT کې د هوا سټیشنونو شبکې رامینځته کولو سره ، تاسو کولی شئ له دوی څخه ډیټا په ورته وخت کې ډیری خدماتو ته وپلورئ.

د تضمین پیغام رسولو میکانیزم

د اعتبار وړ ډیټا خدمت د پروتوکول په کچه د ځانګړي الګوریتمونو کارولو پرته د 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 ته لیږلو سره اړونده خدمت ته ګډون کوي ​​، چې پدې کې پیرامیټرې شاملې دي لکه بهرنۍ ID یا بهرنۍ ډلې ID ، AS پیژندونکی ، نظارت ډول، د راپورونو شمیر، کوم چې AS غواړي ترلاسه کړي. که چیرې AS د غوښتنې اجرا کولو واک ولري، SCEF، د ډول پورې اړه لري، HSS یا MME ته به پیښه چمتو کړي (4 شکل). کله چې یوه پیښه رامنځ ته شي، MME یا HSS SCEF ته یو راپور چمتو کوي، کوم چې دا AS ته لیږي.

د ټولو پیښو چمتو کول، پرته له دې چې "په جغرافيائی سیمه کې د UEs شمیر شتون" د 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 په قضیه کې) په کارولو سره تنظیم شوې ، د کوم ارزښت چې د ضمیمې پروسې یا راتلونکي TAU په جریان کې وسیله ته لیږدول کیږي. د ګرځنده لاسرسي ټایمر معمولا د T3412 څخه څو دقیقې اوږد وي. که UE د "موبایل لاسرسي ټایمر" له پای ته رسیدو دمخه TAU نه وي رامینځته کړی ، نو شبکه فکر کوي چې دا نور د لاسرسي وړ ندي.

د UE لاسرسی - په ګوته کوي کله چې UE د DL ترافیک یا SMS لپاره شتون ولري. دا هغه وخت پیښیږي کله چې UE د پاڼې کولو لپاره شتون ولري (په eDRX حالت کې د UE لپاره) یا کله چې UE ECM-Connected حالت ته ننوځي (د UE لپاره په PSM یا eDRX حالت کې)، د بیلګې په توګه. TAU جوړوي یا د اپلنک کڅوړه لیږي.

د ځای راپور ورکول - د څارنې دا ډول پیښې AS ته اجازه ورکوي چې د UE موقعیت پوښتنه وکړي. یا هم اوسنی موقعیت (اوسنی موقعیت) یا وروستی پیژندل شوی موقعیت (د حجرې ID لخوا ټاکل شوی چې له هغې څخه وسیلې TAU رامینځته کړی یا تیر ځل ترافیک لیږدولی) غوښتنه کیدی شي ، کوم چې د PSM یا eDRX بریښنا سپمولو حالتونو کې د وسیلو لپاره اړونده وي. د "اوسني ځای" لپاره، AS کولی شي د تکرار ځوابونو غوښتنه وکړي، د MME سره هرکله چې د وسیلې موقعیت بدل شي AS ته خبر ورکوي.

د IMSI-IMEI ټولنې بدلون - کله چې دا پیښه فعاله شي ، SCEF د IMSI (سیم کارت پیژندونکي) او IMEI (د وسیلې پیژندونکي) ترکیب کې د بدلونونو څارنه پیل کوي. کله چې پیښه رامنځته شي، AS ته خبر ورکوي. د ټاکل شوي بدیل کار په جریان کې په اتوماتيک ډول د وسیلې ته د بهرني ID بیرته راګرځولو لپاره کارول کیدی شي یا د وسیلې غلا لپاره د پیژندونکي په توګه خدمت وکړي.

د رومینګ حالت - دا ډول څارنه د AS لخوا کارول کیږي ترڅو معلومه کړي چې ایا UE په کور شبکه کې دی یا د رومینګ ملګري په شبکه کې. په اختیاري توګه، د آپریټر PLMN (د عامه ځمکې ګرځنده شبکه) چیرې چې وسیله ثبت شوې وي لیږدول کیدی شي.

د مخابراتو ناکامي - دا ډول نظارت AS ته د وسیلې سره په اړیکه کې د ناکامۍ په اړه خبر ورکوي ، د اتصال له لاسه ورکولو دلایلو (د خپریدو لامل کوډ) د راډیو لاسرسي شبکې (S1-AP پروتوکول) څخه ترلاسه شوي. دا پیښه کولی شي د دې معلومولو کې مرسته وکړي چې ولې اړیکه ناکامه شوه - په شبکه کې د ستونزو له امله، د بیلګې په توګه، کله چې eNodeb ډیر بار وي (د راډیو سرچینې شتون نلري) یا پخپله د وسیلې د ناکامۍ له امله (د UE سره د راډیو اتصال له لاسه ورکړ).

د DDN ناکامۍ وروسته شتون - دا پیښه AS ته خبر ورکوي چې وسیله د مخابراتو له ناکامۍ وروسته شتون لري. کارول کیدی شي کله چې وسیلې ته ډیټا لیږدولو ته اړتیا وي ، مګر پخوانۍ هڅه بریالۍ نه وه ځکه چې UE د شبکې (پاینګ) څخه خبرتیا ته ځواب نه و ورکړی او معلومات ندي سپارل شوي. که چیرې د UE لپاره د دې ډول څارنې غوښتنه شوې وي، نو هرڅومره ژر چې وسیله راتلونکی اړیکه رامینځته کړي، TAU جوړوي یا اپلینک ته ډاټا لیږي، AS به خبر شي چې وسیله شتون لري. څرنګه چې د DDN (ډاون لینک ډیټا خبرتیا) طرزالعمل د MME او S/P-GW ترمنځ کار کوي، دا ډول څارنه یوازې د IP وسیلو لپاره شتون لري.

د PDN ارتباط حالت - AS ته خبر ورکوي کله چې د وسیلې حالت بدل شي (PDN ارتباط حالت) - پیوستون (PDN فعالول) یا قطع کول (PDN حذف کول). دا د AS لخوا کارول کیدی شي د UE سره اړیکه پیل کړي، یا برعکس، پدې پوه شي چې ارتباط نور امکان نلري. دا ډول څارنه د IP او غیر IP وسیلو لپاره شتون لري.

د UEs شمیر چې په جغرافیه کې شتون لري - دا ډول نظارت د AS لخوا کارول کیږي ترڅو په یوه ټاکلې جغرافیه کې د UEs شمیر معلوم کړي.

د وسیله محرک کول)

په 2G/3G شبکو کې، په شبکه کې د ثبت کولو پروسه دوه پړاوه وه: لومړی، هغه وسیله چې د SGSN سره راجستر شوې (د ضمیمه کړنالرې)، بیا، که اړتیا وي، دا د PDP شرایط فعال کړي - د پاکټ دروازې (GGSN) سره اړیکه د معلوماتو لیږدولو لپاره. په 3G شبکو کې، دا دوه پروسیجرونه په ترتیب سره واقع شوي، د بیلګې په توګه. وسیلې هغه شیبې ته انتظار نه کاوه کله چې دا د معلوماتو لیږدولو ته اړتیا لري ، مګر د ضمیمې پروسې بشپړیدو وروسته سمدلاسه PDP فعال کړ. په LTE کې، دا دوه پروسیجرونه په یو کې یوځای شوي، دا دی، کله چې ضمیمه شي، وسیله سمدلاسه د PDN اتصال فعالولو غوښتنه وکړه (په 2G/3G کې د PDP سره ورته والی) د eNodeB له لارې MME-SGW-PGW ته.

NB-IoT د پیوستون میتود تعریفوي لکه "د PDN پرته ضمیمه"، دا دی، UE د PDN اتصال رامینځته کولو پرته ضمیمه کوي. په دې حالت کې، دا د ټرافیک لیږدولو لپاره شتون نلري، او یوازې ایس ایم ایس ترلاسه یا لیږلی شي. د PDN فعالولو او AS سره وصل کولو لپاره ورته وسیلې ته د قوماندې لیږلو لپاره ، د "وسیلې محرک" فعالیت رامینځته شوی.

کله چې د AS څخه د ورته UE سره وصل کولو قومانده ترلاسه کوي ، SCEF د SMS مرکز له لارې وسیله ته د کنټرول SMS لیږل پیل کوي. کله چې یو ایس ایم ایس ترلاسه کوي، وسیله PDN فعالوي او د AS سره نښلوي ترڅو نور لارښوونې ترلاسه کړي یا ډاټا لیږد کړي.

ممکن ځینې وختونه وي کله چې ستاسو د وسیلې ګډون په SCEF کې پای ته ورسیږي. هو، ګډون د خپل ژوند موده لري، د آپریټر لخوا ټاکل شوی یا د AS سره موافق دی. د ختمیدو سره، PDN به په MME کې غیر فعال شي او وسیله به AS ته شتون ونلري. په دې حالت کې، د "وسیلې محرک" فعالیت به هم مرسته وکړي. کله چې د AS څخه نوي معلومات ترلاسه کوي، SCEF به د وسیلې پیوستون حالت ومومي او ډاټا به د SMS چینل له لارې وړاندې کړي.

پایلې

د SCEF فعالیت، البته، پورته ذکر شوي خدماتو پورې محدود نه دی او په دوامداره توګه وده کوي او پراخیږي. اوس مهال، د درجن څخه ډیر خدمتونه دمخه د SCEF لپاره معیاري شوي دي. اوس موږ یوازې اصلي دندو ته اشاره کړې چې د پراختیا کونکو لخوا غوښتنه کیږي؛ موږ به په راتلونکو مقالو کې د پاتې نورو په اړه وغږیږو.

پوښتنه سمدلاسه راپورته کیږي: د احتمالي قضیو د لومړني ازموینې او ډیبګ کولو لپاره دې "معجزې" نوډ ته د ازموینې لاسرسی څنګه ترلاسه کول؟ هرڅه خورا ساده دي. هر پراختیا کونکی کولی شي iot.info@mts.ru ته غوښتنه واستوي، په کوم کې چې د اړیکې هدف، د احتمالي قضیې توضیحات او د اړیکو لپاره د اړیکو معلومات په ګوته کول کافي دي.

ژر به سره ګورو!

لیکوالان:

• د متقابل حلونو او ملټي میډیا خدماتو څانګې لوړ کارپوه سرګي نویکوف سانوف,
• د متقابل حلونو او ملټي میډیا خدماتو څانګې متخصص الیکسي لپشین aslapsh

سرچینه: www.habr.com