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 מוכר עבור מפתחי יישומים, ה-API של SCEF מקל על יצירת שירותים חדשים ומצמצם את זמן היציאה לשוק. הצומת החדש כולל גם פונקציות לזיהוי/אימות מכשירים ניידים, הגדרת הכללים לחילופי נתונים בין המכשיר ל-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, המשמש להפעלת מכשירים והעברת SMS ברשתות NB-IoT. עם זאת, בכל המימושים הפונקציונליות של צומת זה משולבת ב- SCEF, אז לשם פישוט המעגל, לא נשקול אותו בנפרד). משמש לקבלת מידע ניתוב לשליחת SMS ואינטראקציה עם מרכז ה-SMS.

T8 – ממשק API לאינטראקציה של SCEF עם שרתי יישומים. הן פקודות הבקרה והן התעבורה מועברות דרך ממשק זה.

*במציאות יש יותר ממשקים; רק הבסיסיים ביותר מפורטים כאן. רשימה מלאה מובאת ב-3GPP 23.682 (4.3.2 רשימת נקודות התייחסות).

להלן הפונקציות והשירותים העיקריים של SCEF:

• קישור מזהה כרטיס ה-SIM (IMSI) לזיהוי חיצוני;
• העברת תעבורת שאינה IP (Non-IP Data Delivery, NIDD);
• פעולות קבוצתיות באמצעות מזהה קבוצה חיצוני;
• תמיכה במצב העברת נתונים עם אישור;
• אחסון נתונים של MO (Mobile Originated) ו-MT (Mobile Terminated);
• אימות והרשאה של מכשירים ושרתי יישומים;
• שימוש בו-זמני בנתונים מ-UE אחד על ידי מספר ASes;
• תמיכה בפונקציות מיוחדות לניטור מצב UE (MONTE - ניטור אירועים);
• הפעלת מכשיר;
• מתן נדידת נתונים ללא IP.

העיקרון הבסיסי של אינטראקציה בין AS ו-SCEF מבוסס על מה שנקרא סכמה. מנויים. אם יש צורך לקבל גישה לשירות SCEF כלשהו עבור UE ספציפי, שרת היישומים צריך ליצור מנוי על ידי שליחת פקודה ל-API הספציפי של השירות המבוקש ולקבל מזהה ייחודי בתגובה. לאחר מכן כל הפעולות והתקשורת הנוספת עם ה-UE במסגרת שירות זה יתקיימו באמצעות מזהה זה.

מזהה חיצוני: מזהה מכשיר אוניברסלי

אחד השינויים החשובים ביותר בסכימת האינטראקציה בין AS ומכשירים בעת עבודה דרך SCEF הוא הופעתו של מזהה אוניברסלי. כעת, במקום מספר טלפון (MSISDN) או כתובת IP, כפי שהיה ברשת 2G/3G/LTE הקלאסית, מזהה ההתקן של שרת היישומים הופך ל"מזהה חיצוני". הוא מוגדר על ידי התקן בפורמט המוכר למפתחי אפליקציות " @ "

מפתחים כבר לא צריכים ליישם אלגוריתמי אימות מכשירים; הרשת משתלטת לחלוטין על הפונקציה הזו. מזהה חיצוני קשור ל-IMSI, והמפתח יכול להיות בטוח שכאשר הוא ניגש למזהה חיצוני ספציפי, הוא יוצר אינטראקציה עם כרטיס SIM ספציפי. בשימוש בשבב סים מקבלים מצב ייחודי לחלוטין כאשר המזהה החיצוני מזהה באופן ייחודי מכשיר ספציפי!

יתרה מכך, ניתן לקשר מספר מזהים חיצוניים ל-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 אחד על ידי מספר ASes. הָהֵן. אם מספר 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.

אספקת כל האירועים, למעט "מספר UEs הנמצאים באזור גיאוגרפי", מתבצעת באמצעות HSS. שני אירועים "שינוי איגוד IMSI-IMEI" ו"סטטוס נדידה" נמצאים במעקב ישירות ב-HSS, השאר יסופקו על ידי HSS ב-MME.
אירועים יכולים להיות חד-פעמיים או תקופתיים, והם נקבעים לפי סוגם.

שליחת דיווח על אירוע (דיווח) מתבצעת על ידי הצומת העוקב אחר האירוע ישירות ל-SCEF (איור 5).

נקודה חשובה: ניתן להחיל אירועי ניטור הן על התקני שאינם IP המחוברים באמצעות SCEF והן על התקני IP המשדרים נתונים בצורה הקלאסית באמצעות MME-SGW-PGW.

בואו נסתכל מקרוב על כל אחד מאירועי הניטור:

אובדן קישוריות - מודיע ל-AS שה-UE אינו זמין עוד עבור תעבורת נתונים או איתות. האירוע מתרחש כאשר "טיימר הנגישות לנייד" עבור ה-UE יפוג ב-MME. בבקשה לסוג זה של ניטור, ה-AS יכול לציין את ערך "זמן הזיהוי המקסימלי" שלו - אם במהלך זמן זה ה-UE לא מראה כל פעילות, ה-AS יקבל הודעה שה-UE אינו זמין, תוך ציון הסיבה. האירוע מתרחש גם אם ה-UE הוסר בכוח על ידי הרשת מכל סיבה שהיא.

* כדי ליידע את הרשת שהמכשיר עדיין זמין, היא מתחילה מעת לעת הליך עדכון - Tracking Area Update (TAU). התדירות של הליך זה נקבעת על ידי הרשת באמצעות טיימר T3412 או (T3412_extended במקרה של PSM), שערכו מועבר למכשיר במהלך הליך ה- Attach או ה- TAU הבא. טיימר נגישות לנייד ארוך בדרך כלל בכמה דקות מ-T3412. אם ה-UE לא ביצע TAU לפני שפג תוקפו של "טיימר הנגישות הניידת", הרשת מחשיבה אותו ככזה שאינו נגיש יותר.

גישה ל-UE - מציין מתי ה-UE הופך זמין עבור תעבורת DL או SMS. זה מתרחש כאשר ה-UE הופך זמין להחלפה (עבור UE במצב eDRX) או כאשר ה-UE נכנס למצב ECM-CONNECTED (עבור UE במצב PSM או eDRX), כלומר. עושה TAU או שולח חבילת uplink.

דיווח מיקום – סוג זה של אירועי ניטור מאפשר ל-AS לשאול את מיקומו של ה-UE. ניתן לבקש את המיקום הנוכחי (Current Location) או את המיקום האחרון הידוע (נקבע על פי מזהה התא שממנו המכשיר עשה TAU או שידר תעבורה בפעם האחרונה), הרלוונטי למכשירים במצבי חיסכון בחשמל PSM או eDRX. עבור "מיקום נוכחי", ה-AS יכול לבקש תשובות חוזרות, כאשר ה-MME יודיע ל-AS בכל פעם שמיקום המכשיר משתנה.

שינוי איגוד IMSI-IMEI - כאשר אירוע זה מופעל, SCEF מתחיל לעקוב אחר שינויים בשילוב של IMSI (מזהה כרטיס SIM) ו-IMEI (מזהה מכשיר). כאשר מתרחש אירוע, מודיע ל-AS. יכול לשמש לאיגד אוטומטי של מזהה חיצוני למכשיר במהלך עבודת החלפה מתוזמנת או לשמש כמזהה לגניבה של מכשיר.

מצב נדידה - סוג זה של ניטור משמש את AS כדי לקבוע אם ה-UE נמצא ברשת הביתית או ברשת של שותף נודד. לחלופין, ניתן לשדר את ה-PLMN (Public Land Mobile Network) של המפעיל שבו המכשיר רשום.

כשל בתקשורת - סוג זה של ניטור מודיע ל-AS על כשלים בתקשורת עם המכשיר, בהתבסס על הסיבות לאובדן החיבור (קוד שחרור סיבה) שהתקבל מרשת הגישה לרדיו (פרוטוקול S1-AP). אירוע זה יכול לעזור לקבוע מדוע התקשורת נכשלה - עקב בעיות ברשת, למשל, כאשר ה-eNodeb עמוס יתר על המידה (משאבי רדיו אינם זמינים) או עקב כשל במכשיר עצמו (Radio Connection With UE Lost).

זמינות לאחר כשל ב-DDN - אירוע זה מודיע ל-AS שהמכשיר הפך לזמין לאחר כשל בתקשורת. ניתן להשתמש כאשר יש צורך בהעברת נתונים למכשיר, אך הניסיון הקודם לא הצליח מכיוון שה-UE לא הגיב להודעה מהרשת (החלפה) והנתונים לא נמסרו. אם סוג זה של ניטור התבקש עבור ה-UE, אז ברגע שהמכשיר מבצע תקשורת נכנסת, מבצע TAU או שולח נתונים ל-uplink, ה-AS יקבל הודעה שהמכשיר הפך לזמין. מכיוון שהליך ה-DDN (התראה על קישור נתונים למטה) פועל בין MME ל-S/P-GW, סוג זה של ניטור זמין רק עבור התקני IP.

מצב קישוריות PDN – מודיע ל-AS כאשר מצב המכשיר משתנה (סטטוס קישוריות PDN) - חיבור (הפעלת PDN) או ניתוק (מחיקת PDN). זה יכול לשמש את ה-AS כדי ליזום תקשורת עם ה-UE, או להיפך, כדי להבין שתקשורת אינה אפשרית עוד. סוג זה של ניטור זמין עבור התקני IP ולא IP.

מספר UEs הנמצאים באזור גיאוגרפי – סוג זה של ניטור משמש את ה-AS כדי לקבוע את מספר ה-UEs באזור גיאוגרפי מסוים.

הפעלת מכשיר)

ברשתות 2G/3G, הליך הרישום ברשת היה דו-שלבי: ראשית, המכשיר נרשם ב-SGSN (הליך attach), לאחר מכן, במידת הצורך, הוא הפעיל את ההקשר של PDP - חיבור עם שער המנות (GGSN) להעביר נתונים. ברשתות דור שלישי, שני ההליכים הללו התרחשו ברצף, כלומר. המכשיר לא חיכה לרגע שבו היה צריך להעביר נתונים, אלא הפעיל את PDP מיד לאחר השלמת הליך החיבור. ב-LTE, שני ההליכים הללו שולבו לאחד, כלומר, בעת ההצמדה, המכשיר ביקש מיד הפעלה של חיבור ה-PDN (אנלוגי ל-PDP ב-3G/2G) דרך ה-eNodeB ל-MME-SGW-PGW.

NB-IoT מגדיר שיטת חיבור כ"צרף ללא PDN", כלומר, ה-UE מתחבר מבלי ליצור חיבור PDN. במקרה זה, הוא אינו זמין להעברת תעבורה, והוא יכול רק לקבל או לשלוח SMS. על מנת לשלוח פקודה למכשיר כזה כדי להפעיל PDN ולהתחבר ל-AS, פותחה הפונקציונליות של "הפעלת התקן".

בעת קבלת פקודה לחיבור UE כזה מה-AS, SCEF יוזם שליחת SMS בקרה למכשיר דרך מרכז ה-SMS. בעת קבלת SMS, המכשיר מפעיל את ה-PDN ומתחבר ל-AS כדי לקבל הוראות נוספות או להעביר נתונים.

עשויים להיות מקרים שבהם יפוג תוקף המינוי למכשיר שלך ב-SCEF. כן, למנוי יש משך חיים משלו, שנקבע על ידי המפעיל או מוסכם עם AS. עם התפוגה, ה-PDN יושבת ב-MME והמכשיר לא יהיה זמין ל-AS. במקרה זה, הפונקציונליות של "הפעלת מכשיר" תעזור גם היא. בעת קבלת נתונים חדשים מ-AS, SCEF יגלה את מצב חיבור המכשיר וימסור את הנתונים באמצעות ערוץ SMS.

מסקנה

הפונקציונליות של SCEF, כמובן, אינה מוגבלת לשירותים שתוארו לעיל והיא מתפתחת ומתרחבת כל הזמן. נכון לעכשיו, יותר מתריסר שירותים כבר תוקננו עבור SCEF. כעת נגענו רק בפונקציות העיקריות המבוקשות ממפתחים; על השאר נדבר במאמרים עתידיים.

מיד מתעוררת השאלה: כיצד ניתן לקבל גישה לבדיקה לצומת ה"נס" הזה לבדיקה ראשונית וניפוי באגים של מקרים אפשריים? הכל מאוד פשוט. כל מפתח יכול להגיש בקשה ל [מוגן בדוא"ל], בו די לציין את מטרת החיבור, תיאור מקרה אפשרי ופרטי התקשרות לתקשורת.

להתראות שוב!

מחברים:

• מומחה בכיר של המחלקה לפתרונות מתכנסים ושירותי מולטימדיה סרגיי נוביקוב sanov,
• מומחה מחלקת פתרונות מתכנסים ושירותי מולטימדיה אלכסיי לאפשין אטום

מקור: www.habr.com