‏הצגת רשומות עם תוויות LTE. הצג את כל הרשומות
‏הצגת רשומות עם תוויות LTE. הצג את כל הרשומות

יום רביעי, יולי 09, 2025

האם זה הסוף לשימוש במכשירי לינוקס ומכשירי טלפון זולים ברשתות התקשורת בארץ ?

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

ההודעה:

גם אני קיבלתי את הסמס המגניב שהמכשיר שלי, ה Purism Librem5 שאני מכנה החמישיה החופשית, לא תומך ב VoLTE ואני לא אוכל לקבל ולהוציא שיחות לאחר סוף השנה, חשדתי שאולי מדובר בתקלה במערכת הבדיקה  של ספק הטלפוניה שלי , וניגשתי לספק הסלולארי שלי וביצעתי בדיקה מהאתר שלהם, הפעם קיבלתי הודעה שהמכשיר עצמו תומך אבל ה VoLTE  לא מופעל.  ביצעתי גם ניסיון בדיקה עם הגבלת הגישה רק לגלישת 4G וניסיון ביצוע שליחה, ובאמת השיחות נכשלו, מה שמצביע על בעייה בהוצאות שיחות רק תחת ה VoLTE.

קצת רקע:

החל מהראשון לינואר, רשתות ה 3G וה 2G ינותקו בישראל, ורק שימוש ברשתות 4G ו 5G יאפשר שימוש ברשתות הסלולאריות, במצב תקין שיחות הקול ב 4G ו LTE משתמש ב VoLTE ,כיום כאשרהמכשיר לא מצליח להשתמש ב VoLTE בעת חיבור לרשת 4G המכשיר ייבצע fallback ומשתמש ברשת ה 3G  בשביל לבצע את השיחה, מה קורה אם אין VoLTE ואין 3G ? אין ייכולת להוציא או לקבל שיחות.  ה VoLTE עצמו אינו נדרש לשימוש בדאטא או סמס, כי יש סמס ע"ג דאטא אבל גם זה יכול להיות רק אם אתם מצליחים לבצע הרשמה לשירות ה IMS אצל ספק הסלולאר שלכם, עכשיו ברגע שמנתקים את ה3G כבר לא יהיה ירידה ל רשת ה3G מה שיימנע ביצוע שיחות.

חשוב להבין שיש הבדל בין העובדה שהמכשיר תומך ב VoLTE , שה VoLTE מופעל במכשיר, שה VoLTE קיים אצל הספק, ושהמכשיר שלכם יוכל להשתמש ב VoLTE אצל הספק שלכם, ושהמכשיר שלכם באמצעות הסים שלכם יצליח לבצע רישום ל ims ויצליח להוציא שיחות VoLTE אצל הספק שלכם. שמתם לב כמה שלבי תקלות יכולים להיות ? אז זה מהות הפוסט הזה, לנסות לגלות הייכן הבעיה קיימת.

במידה והספק איננו משתמש בהגדרות ברירת המחדל בVoLTE  יכול להיות מצב שלמרות שה VoLTE נתמך ומופעל במכשיר שלכם, לא תוכלו להשתמש בו.

בעבר מכשירי הpurism librem5 יצאו מהמפעל עם VoLTE מכובים כברירת מחדל, והיה צורך להפעיל את ה VoLTE ולהגדיר את ה APN המתאים במכשיר, לפי התיאור של פוריסם על מנת לתמוך ב VoLTE אצל חלק מהספקים נדרשת עבודה של purism ביחד עם ספקי התקשורת עצמה על מנת לקבל יכולת חיבור, מהידוע לי זה נדרש כאשר הספק איננו משתמש בפרופיל ברירת המחדל ל VoLTE והדבר דורש התערבות ברת הfirmware במודם עצמו.
 

התחלת הדיבגינג:

המכשיר שברשותי הוא החמישיה החופשית, באתר התיעוד של פוריסם (החברה המייצרת) נאמר כי המודם הוא bm818 והתוכנה שאחראית על אחזקת המודם נקראת bm818-tools, אותה ניתן להוריד משרת ה gitlab של חברת פוריסם,

הלכתי להשתמש ברכיב התוכנה הזה, שלפתי את ההודעות ה AT מתוך הקוד שקיים ב bm818-tools ושלחתי אותן באמצעות socat למודם שלי בשביק לבדוק האם המודם מפעיל את רכיב ה LTE ולפי התשובה המודם כן תומך, כי קיים המלל BMRAT בתגובה.

אבל מכיוון שספק הטלפוניה שלי התריע כי ה VoLTE לא מופעל ,חשבתי שאולי אני עושה משהוא לא נכון, והפעלתי את התסריט bm818-volte-check וקיבלתי גם ממנו כי ה VoLTE מופעל. 

sudo ./bm818-volte-check  
chat:  Jul 09 10:05:55 +BMRAT: FDD LTE
BMRAT state active  FDD LTE

הבדיקה היידנית שלי נראתה  כך:
  echo "AT+BMRAT" | sudo socat - /dev/ttyUSB2,crnl
AT+BMRAT
+BMRAT: FDD LTE

OK

  
הפקודה socat מאפשרת לנו לשלוח הודעות למודם בצורה נוחה למדי, יש כאלה שמעדיפים את minicom אבל אני אישית מעדיף את socat.

אמרתי אולי יש משהוא בGUI אז אולי אני אנסה משהוא משם, מכיוון שbm818-tools לא קיים במוביין-טריקיסי, הורדתי את קוד המקור ובניתי את חבילת ה deb והתקנתי אותו,

הייתי צריך לשנות את החבילה של bm818-tools כי policykit-1 לא קיימת יותר בדביאן טריקסי,  את הבנייה עשיתי אחרי מחיקת הדרישה לpolicykit-1  בקובץ הdebian/control,  לאחר ההתקנה והפעלה מחדש של המכשיר הפעלתי אותו בצורה ויזואלית , אבל משום מה הממשק הגרפי לא עלה (ומצאתי אפילו באג מדווח על זה)/

גם הפעלה בצורה מרוחקת זרקה הודעות שגיאה:
 
(bm818-tool:2881): Gtk-CRITICAL **: 01:25:32.591: _gtk_css_lookup_resolve: assertion '(((__extension__ ({ GTypeInstance *__inst = (GTypeInstance*) ((provider)); GType __t = ((_gtk_style_provider_private_get_type
())); gboolean __r; if (!__inst) __r = (0); else if (__inst->g_class && __inst->g_class->g_type == __t) __r = (!(0)); else __r = g_type_check_instance_is_a (__inst, __t); __r; }))))' failed
/home/mobian/src/bm818-tools/usr/bin/./bm818-tool:159: Warning: g_object_set_data_full: assertion 'G_IS_OBJECT (object)' failed
 builder.add_from_file("../../data/bm818-tool.glade")

(bm818-tool:2881): Gtk-ERROR **: 01:25:32.592: Can't create a GtkStyleContext without a display connection
Trace/breakpoint trap

 
ככל הנראה אין לי ברירה אלא לסמוך שהתסריט שהפעלתי ופקודות ה socat שלי לאימות היו נכונות. שימו לב שהתסריטים של  bm818 משתמשים בפקודה chat מתוך חבילת ppp ואינם נגישים למשתמש הרגיל, ולכן צריך או לשנות, או לתת הרשאה מפורשת אני פשוט השתמשתי ב sudo וזהוא.

מבחינת הקוד של bm818-tools אין הבדל בין התחברות ל LTE לחיבור ל VoLTE , בדיקת התמיכה ב VoLTE בקוד אצלהם מתייחסת רק להודעה הזאת. מהבנתי זה הוא תנאי סף לעבודה עם VoLTE זה לא אומר שהזיהוי יעבוד מול הספק או שיציליח להתחבר.
 
בנקודה הזאת אנחנו יודעים שתאורתית המודם כן תומך ב VoLTE והאפשרות להתחבר ל VoLTE  מופעלת, למה אני אומר תאורתית למרות שיש מקומות בהם זה כן עובד ?  כי זה לא אומת במקרה שלי, אבל אנחנו עוד לא הגענו לנקודה בה אנחנו באמת מתחברים ל ims. המודם יצטרך לבצע רישום ל ims לעדת לבחור פרופיל MBN נכון, ולעבוד מול ספק הטלפוניה.

הפתרון שמוצא בבעיה 162 של פוריסם מציע לבצע שני פקודות AT על מנת לבצע רישום ל ims, האמת חששתי מהן אבל הרצתי אותן, אבל למרות זאת שיחות רק תחת 4G לא הצליחו לעבור.

לפי מה שאני זוכר, ספק הטלפוניה מכריז על פרופיל מסוים, ובמידה ויש אי התאמה בין הפרופיל ויכולות המודם אז VoLTE לא יעבד כלל, וזה מדוע למה באנדרויד למשל על אותו המכשיר לא יופיע תמיכה ב VoLTE אצל ספק אחד אבל כן יופיע עם ספק אחר על אותו המכשיר באותו המקום.
 
הפעלתי את מנהל המודם (modem manager)  במצד דיבאג , וניסתי להוציא שיחה, במצב כזה פעם אחת ראיתי הודעה הקשורה ל VoLTE שנראתיה כך:
<<<<<< QMUX: 
<<<<<<   length  = 85 
<<<<<<   flags   = 0x80 
<<<<<<   service = "pdc" 
<<<<<<   client  = 2 
<<<<<< QMI: 
<<<<<<   flags       = "indication" 
<<<<<<   transaction = 2 
<<<<<<   tlv_length  = 73 
<<<<<<   message     = "Get Config Info" (0x28) 
<<<<<< TLV: 
<<<<<<   type       = "Indication Result" (0x01) 
<<<<<<   length     = 2 
<<<<<<   value      = 00:00 
<<<<<<   translated = 0 
<<<<<< TLV: 
<<<<<<   type       = "Token" (0x10) 
<<<<<<   length     = 4 
<<<<<<   value      = 01:00:00:00 
<<<<<<   translated = 1 
<<<<<< TLV: 
<<<<<<   type       = "Total Size" (0x11) 
<<<<<<   length     = 4 
<<<<<<   value      = 98:7C:00:00 
<<<<<<   translated = 31896 
<<<<<< TLV: 
<<<<<<   type       = "Description" (0x12) 
<<<<<<   length     = 30 
<<<<<<   value      = 1D:56:6F:6C:74:65:5F:4F:70:65:6E:4D:6B:74:2D:43:6F:6D:6D:65:72:63:69:61:6C:2D:43:4D:43:43 
<<<<<<   translated = Volte_OpenMkt-Commercial-CMCC 
<<<<<< TLV: 
<<<<<<   type       = "Version" (0x13) 
<<<<<<   length     = 4 
<<<<<<   value      = 72:20:01:05 
<<<<<<   translated = 83959922 
<<<<<< TLV: 
<<<<<<   type   = 0x14
<<<<<<   length = 4 
<<<<<<   value  = 00:00:00:00 
<<<<<< TLV: 
<<<<<<   type   = 0x16 
<<<<<<   length = 4 
<<<<<<   value  = 72:20:01:05 
dbg> [1752158379.322409] [/dev/cdc-wdm0] received message... 
<<<<<< RAW: 
<<<<<<   length = 20 
<<<<<<   data   = 01:13:00:80:24:02:02:02:00:28:00:07:00:02:04:00:00:00:00:00 
dbg> [1752158379.322740] [/dev/cdc-wdm0] received generic response (translated)... 
<<<<<< QMUX: 
<<<<<<   length  = 19 
<<<<<<   flags   = 0x80 
<<<<<<   service = "pdc" 
<<<<<<   client  = 2 
<<<<<< QMI: 
<<<<<<   flags       = "response" 
<<<<<<   transaction = 2 
<<<<<<   tlv_length  = 7 
<<<<<<   message     = "Get Config Info" (0x28) 
<<<<<< TLV: 
<<<<<<   type       = "Result" (0x02) 
<<<<<<   length     = 4 
<<<<<<   value      = 00:00:00:00 
<<<<<<   translated = SUCCESS
  
 אני רואה פה הודעה הקשורה למה שאני מניח שהוא פרופיל MBN שהמודם צריך לבחור, אבל בשונה מהמצב בpinephone אין רשימת פקודות AT מפורסמת ופתרון איך לבחור בצורה ידינית את הפרופיל המתאים. ניסיתי את הפקודה AT+QMBNCFG אבל היא מוכרת למודם בשביל לבצע בחירת פרופיל ,  ב pinephone היתי פשוט הולך לפי רשימת הפקודות שהם תיארו בדף המוצר https://pine64.org/documentation/PinePhone/_full, אבל הפרופיל בשם: Volte_OpenMkt-Commercial-CMCC אבל כן נמצא ברשימה בהודעה בפורום של quectel מה שאומר שככל הנראה מודם עם גרסת קושחא עדכנית של המודם ב pinephone pro יכול להיות שיעבוד כמו שצריך. המודם של bm818 אינו מכיל גרסת קושחא פתוחה כמו המודם של quectell שמותקן בpinephone לכן אנחנו נתונים לחסדיהם של purism ו הייצרן של bm818.

בדקתי וקבלת סמס ע"ג 4G בלבד עבדה, כך גם MMS ו דאטא טהור.
 
אמרתי אולי הבעייה היא שאני משתמש בספק שהוא MNVO, אז הלכתי ורכשתי סים של MVNE , החברה ממנה הספק שאני מנויי אצלו רוכש את שירותים, גם שימוש בסים של הספק של ספק ה MVNE לא נתן אפשרות לשיחות ברשת 4G בלבד

סיום:

לסיום כרגע לא ניתן להשתמש במכשיר librm5 של פוריסם עם bm818 בשביל לבצע שיחות ולקבל שיחות ברשת ה 4G בלבד באזור שלי. אני מאמין שזה משהוא בין המודם כלפי ספק הטלפוניה, כלומר זה לא רק שפוריסם צריכים לעבוד ביחד עם ספק הטלפוניה זה ספק המודם עצמו צריך לשחרר גרסת קושחא המתאימה ויודעת לעבד עם הפרופילים הנמצאים בארץ.
 
צריך לבדוק את המצב במכשירים אחרים כמו ה pinephone  (אורן) וה pinephone pro (אורן מתקדם) ו FLX1.

נקודות לעתיד

בשיחה עם אנשים שאני מכיר שמשתמשים באיטליה וארה"ב הבהירו לי שהמצב שלהם עם החמישיה החופשית יותר טוב והם כן מצליחים לעשות שיחות במצב של 4G בלבד, אצל אחד הספקים בארה"ב נאמר לי שלמרות שרשמית ה VoLTE לא נבחר ניתן להשתמש במכשיר במישור הדאטא והסמס (כלומר המכשיר מצליח לעבור את ההרשמה).
 
לפי הדיון המצורף מטה , יכול להיות שBM818 אושר לשימוש של חלק מהרשתות אבל לא של כולם עבור VoLTE בעולם. מצאתי דיון ישן בנושא ה VoLTE באתר של פוריסם המתאר את מצב השמישות של VoLTE של מכשיר ה librem5 במקומות שונים בעולם, המדינה שלנו לא נמצאת ברשימה שם כלל.

על מנת לבדוק במכשיר שלכם בישראל ניתן להתקשר ל *235 בשביל לבדוק את מצב החיבור והאם מבחינת המכשיר זה נתמך.

מכיוון שבמקרה שלי אין צורך להשתמש ב APN אחר מהAPN שלי , לא הייתי צריך להתאים את הAPN לשימוש ב VoLTE.

לא עשיתי בדיקת רישום ב IMS עדיין, כי אני לא יודע איך עושים את זה במכשיר הזה. עכשיו הרישום לIMS הוא אחד הדברים החשובים ביותר, אבל מכיוון שאני אינני יודע איך עושים זאת לא עשיתי זאת עדיין.

אני כן ניסיתי להשתמש בפקדוה המגדירה APN בשם ims, אבל זה לא סייעה והשיחות נכשלו כאשר היה חיבור רק ב4G.

נקודות מעניינות חשובות לעתיד:

הפקודות AT+QMBNCFG לא נתמכת ע"י המודם (מקבלים שגיאה ERROR), ואין צורך להפעיל את AT+CGATT? כי אנחנו כבר יודעים כי יש לנו attach לרשת הדאטא.

לטוב ולרע ה mmcli מראה חיבור ל EPS :

   -----------------------------------
  3GPP EPS |    ue mode of operation: csps-1
           |     initial bearer path: /org/freedesktop/ModemManager1/Bearer/2
           |  initial bearer ip type: ipv4v6

 
ההודעה הבאה מראה שיש לי פירמוור שלדעתי הוא ישן יחסית, עברו מעל שלוש שנים מאז תאריך ההוצאה, ראיתי שהפרופיל שספק הטלפוניה שלי הוציא גרסה ב2024,  כאשר פניתי לשירת הלקוחות של פוריסם נאמר לי שזו הגרסה החדשה ביותר שהם "מספקים" (יכול להית שיש פירמוור אחר במקום אחר למדינות אחרות או ספקים אחרים), ההודעה הבאה גם אומרת  שהספק משתמש בחיבור גנרי מה שאומר שככל הנראה הספק לא דורש הגדרה מיוחדת מpurism בשביל לספק תמיכה בשבילם (כמו שעשו בpinephone עבור ספקים סויימים):

    -----------------------------------
  Hardware |            manufacturer: QUALCOMM INCORPORATED
           |                   model: 0
           |       firmware revision: MPSS.JO.2.0.2.c1.1-00032-9607_GENNS_PACK-1.351938.1  1  [Nov 26 2020 02:00:00]
           |          carrier config: ROW_Generic_3GPP
           | carrier config revision: 05010822
           |            h/w revision: 10000
           |               supported: gsm-umts, lte
           |                 current: gsm-umts, lte
           |            equipment id: XXXXXX
  -----------------------------------

 
כאשר בדקתי גרסת הפירמוור שלי באמצעות פקודת ה AT הבאה :
 echo  "AT+BMSWVER" | sudo socat -  /dev/ttyUSB2,crnl
+BMSWVER: M100E_YCSN0_1.0.0_220926,YCSN0_M100E_1BAD_3117_V1.0.0.2_20220930,M100E_1.0.4_200715

OK
למה זה שונה ? אני משער שאחת הגרסאות שם היא גרסת ה aDSP לעומת גרסת הקושחא המפעילה את ההתקן, מי זה מי ? לא יכול להגיד כרגע, אין תיעוד של פקודות ה AT של המודם bm818 בצורה פתוחה וחופשית.


הסבר קצר על מסלול השיחה בVoLTE :
https://www.3glteinfo.com/volte-call-flow-procedures/

הסבר על ה IMS :

https://www.3glteinfo.com/ims-volte-architecture/

עריכה:

שכחתי לציין שניסית את הפתרון שהוצע ב https://source.puri.sm/Librem5/OS-issues/-/issues/162#note_145859 אבל לצערי זה לסייע לאפשר לבצע שיחות תחת 4G בלבד.

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

שיהיה ברור, אני ממש לא מעביר ביקורת לא על purism ולא על ספקי הסלולאר לגבי הבעייה שקיימת פה עם ה VoLTE , מדובר בתהליך ארוך ומסורבל, ולא לחינם לקח שנים לקדם את התהליך של התמיכה בנושא, מדובר בתהליך טכני שדורש השקעת משאבי אנוש וכסף (חומרה ותוכנה לא באים בחינם בעולם האמיתי), אני מתאר את התהליך שאני עובר עם המכשיר הזה, ואולי בעתיד זה יעזור למישהוא, בנוגע לטענה שזו האחריות של purism לבחור במודם שיהיה יותר פתוח ויאפשר טעינת MBN או עדכונים מהמשתמשים, הרשו לי לומר, שהעולם האמיתי הרבה יותר מורכב, זה לא כזה פשוט לקבל אישור FCC ואם המודם שלכם היה כל כך פתוח כנראה לא היה עובר, יתרה מזאת ספקי המודמים עצמם לא כאלה פתוחים לגישת עבודה כזאת בדר"כ (יכולים להיות יוצאי דופן).

משהוא קטן שאני רוצה לציין, זה כיף בפן האישי, בסביבה עיסקית ? אלא אם החברה עוסקת במכישירם כאלה, עדיף יהיה שישתמשו במכשירים המתאימים לאקו-סיסטם של החברה, בעוד אני תומך נלהב בקוד פתוח, אני עובד תאגידי ויודע טוב מאוד שדברים כאלה לא יעבדו ויש אפילו דברים שעדיף לא להעלות כלל בשיהה תאגידית, זה לא המקום ולא המצב לדבר עליהם, אני אתן דוגמאות היו מקרים בהם הצעתי להשתמש במכשירים כמ ה pinephone כי היה למכישר ייתרון עבור פתרון בעייה ספציפית, במקרים אחרים אמרתי בצורה מפרושת שיילכו לאנדרוייד עם חומרה המתאימה לדרישות הלקוח, אין מכשיר אחד שיתיאם לכולם, לפעמים צריך מכשירים שהם rugged ובמקרים כאלה כיום זה מרבית הזמן פשוט אנדרויידים וואני עצמי רציתי לרכוש לעצמי את המכשיר של cat בזמנו בגלל היכולות שלו, או מכשירים עם מערכות הפעלה ייחודיות לעצמן, צריך להבין שהמכשירים צריכים להתאים למשימה ולאנשים תמיד.

ראיתי טענה ש bm818 מכיל את אותן הפקודות כמו ה EC25 של quectel, אני מצטער אבל זה לא המצב שאני ראיתי פקודות בדקה של EC25/EG25 לא עבדו.

מצאתי את הכלי https://github.com/Gbaby918/mbntool ועוד מספר כלים שבתאוריה יאפשרו טעינה של פרופילי mbn ל qualcom מה שיכול להיות יוכל להציל את המצב לטעון פרופילים אחרים, אני לא בטוח מספיק בדרך הזאת עדיין לביצוע, אני מאמין שהכלי הזה יכול לטעון דברים כמ https://xdaforums.com/t/modem-mbn-files-for-different-carriers-updated-2023-june.4626239/ והקבצים שהצליחו להוציא החוצה מתוך מכשירי קואלקום אחרים.

עדכון: דיברתי עם Purism והם אמרו שהם יוצרו קשר עם ספק המודם על מנת לסייע לפתור את הבעייה.

יום שני, דצמבר 06, 2021

אל תסמכו על berilios / github או sourceforge ועשו fork עצמאי

במשך שנים תמיד אמרתי לכולם לא למזלג ותמיד לעבוד עם ה upstream, אבל הפעם אני חייב לאכול את הכובע שלי , ולהודות בטעותי האסטרונומית.

הסיפור הוא בספריית GPL בשם OpenBlox, הספרייה הייתה קיימת בשנת 2008 ב sourceforge , עם השנים הפרוייקט נסגר וככל הנראה נמכר לחברה אחרת (F5), הפרוייקט המקורי והפתוח נסגר והוחלף בפרוייקט בשם אחר. 

במונחי אינטרנט מדובר כמעט בארכיולוגיה, במציאות אני לא מצליח למצוא את הקוד המקורי. 
קבצי קוד המקור הארוזים בzip יפה אינם , waybackmachine אינו מכיל את המידע שאני צריך (יש את דף הפרוייקט אבל לא את קוד המקור לצערי). 
 
הצלחתי בדרך לא דרך להשיג כמות גדולה של קבצי מקור (אבל רק קבצי header) של הפרוייקט אבל עדיין חסר לי את הרכיב שמייצר את tgl.lib (אם למישהוא יש את גרסת ה GPL באזור גירסה 2.7 יויכול לשתף אני אודה לו מאוד).

למדו מהכישלון שלי , וודאו שיש לכם מזלג/גיבוי של הפרוייקט שאתם צריכים.

יום שלישי, מרץ 06, 2018

מתקפת מניעת שירות

אני עוסק בתחום התקשורת תקופה מסויימת, ומעולם לא נתקלתי בסיפור כזה שעובר בשקט כמו שיש עכשיו.

בערך מה-20 לחודש פברואר 2018 התחילה מתקפת לוחמה אלקטרונית הפוגעת בשידור אלחוט שפוגע בשירותי 3G ו LTE.

בהתחלה עוד תיארו את זה כמתקפת סייבר אבל בהמשך נתנו עוד ועוד הסברים ועדיין שבועים אחרי תחילת ההתקפה עדיין קיימים שיבושים באזור. מתקפת מניעת השירות היא לא הרמטית לפעמים מרגישים ולפעמים לא.


מצד אחד אין שיחות או סמסים נכנסים (איזה כיף שלא מתקשרים אלינו עם הצעות לעבור להוט) אבל מצד שני לא ראיתי שום הודעה ע"י חברות כמו פלאפון/סלקום/אורנג' על איזה שהיא בעייה מערכתית.

מכייון שמצד המקבל כמעט ולא תהיה לנו אינדיקציה שיש בעיית שירות (הקליטה נמוכה אבל קיימת), די קשה להיות מודע שיש איזה בעייה.

שמתי לב שקיימים מספר אינדקטורים (פרט לכישלון שיחות נכנסות) ואני מציין אותם פה:

  • כישלון שיחות נכנסות:


זה כמעט בלתי אפשרי לזהות (אלא אם מודיעים לכם על הבעייה באמצעי אחר), אבל זה אינדיקטור.

  • בעיות גלישה כגון RTT מאוד גבוהה (זמן פינג?) :

למעשה כאשר אנו היינו במצב מחובר (ppp הצליח להתחבר ) אנו לא נידע שיש בעייה עד אשר התוכנות שהיו מחוברות ייכשלו.

לדוגמה הkeep alive שלי זיהה זמני RTT הזויים :

64 bytes from 8.8.8.8: icmp_seq=100 ttl=63 time=90147 ms
64 bytes from 8.8.8.8: icmp_seq=101 ttl=63 time=89123 ms
64 bytes from 8.8.8.8: icmp_seq=102 ttl=63 time=88128 ms
64 bytes from 8.8.8.8: icmp_seq=103 ttl=63 time=87109 ms
64 bytes from 8.8.8.8: icmp_seq=105 ttl=63 time=85121 ms
64 bytes from 8.8.8.8: icmp_seq=104 ttl=63 time=86145 ms
64 bytes from 8.8.8.8: icmp_seq=106 ttl=63 time=84109 ms
64 bytes from 8.8.8.8: icmp_seq=107 ttl=63 time=83095 ms
64 bytes from 8.8.8.8: icmp_seq=108 ttl=63 time=82106 ms
64 bytes from 8.8.8.8: icmp_seq=109 ttl=63 time=81086 ms
64 bytes from 8.8.8.8: icmp_seq=110 ttl=63 time=80061 ms
64 bytes from 8.8.8.8: icmp_seq=111 ttl=63 time=79090 ms
64 bytes from 8.8.8.8: icmp_seq=112 ttl=63 time=78089 ms
64 bytes from 8.8.8.8: icmp_seq=113 ttl=63 time=77064 ms
64 bytes from 8.8.8.8: icmp_seq=114 ttl=63 time=76046 ms
64 bytes from 8.8.8.8: icmp_seq=115 ttl=63 time=75024 ms


עריכה: כשאני חושב על מה ייקרה כשאפליקציות החירום המקומיות יצטרכו להודיע על סכנה, לפי מה שאני זוכר מזניחת המחקר על אפליקציה אחת - תתחילו לקרוא תהילים או לבשל פסטה אם זה יעזור לכם נפשית כי עד כמה שאני מבין התראה לא תקבלו או תקבלו באיחור מאוד גדול (כי ערוץ הדאטא בקושי מתפקד).

  • הודעות (SMS) :

הודעות SMS הגיעו בין 30 דקות לשעה ליעדן

נבדק ע"י :

שני קווים מאותה החברה ששולחים הודעה אחת לשני.

המכשירים נמצאים אחד ליד השני בשביל לבטל בעיות של handover או תקשורת בין ספקים. שליחת הודעה מקווים של חברות שונות - הודעה ממקום שאינו באזור ההתקפה למקום בו התקפה קיימת.

הודעה ממקום שנמצא באזור ההתקפה למקום בו התקפה לא קיימת.

  • הודעות (MMS) - MMS בדומה ל גלישת דאטא משתמש באפיק אחר מאפיק הקול (כאשר לא משתמשים ב VoLTE).

נבדק ע"י :

נבדקו שני חברות שונות , באחת היה איחור של 10 דקות בשני היה פשוט כישלון מוחלט לבצע שליחת MMS ליעד.

שליחת הודעות נבדקו גם באמצעות שליחה מהמכשיר וגם ע"י שימוש בסקריפט פייתון ישן


לסיכום  -

אילו חברות התקשורת היו מספקות אפשרות ANDSF למשתמשים שלהם היתה אפשרת להתחבר (כן אפילו מלינוקס !). או אפילו דואגות להציף את הבעיה מספיק גבוהה בשביל להקים שידור חזק יותר מאמצעי הלוחמה האלקטרונית.

יום רביעי, דצמבר 20, 2017

כיסוי אינטרנט

אני באמת צריך לקחת כמה שיעורים באיך לעשות עסקים מחברות התקשורת.
אני חייב להעריך את היכולות המופלאות שלהם למכור ושאנשים יקנו למרות כל מני דברים מעניינים.

ניקח למשל את מקרה ה LTE-M, בגדול מדובר על חברה בשם PHI (פרטנטר-הוט) שתספק תשתיות שיאפשרו תעבורת LTE-M. ע"פ דיווחים בתקשורת רכיבי תקשורת שיתחברו כ IoT (אם אני מבין נכון ככל הנראה לפי הקצאת מספרי טלפון ולא דווקא בדיקה של IMEI או בדיקת יכולת ) יקבלו תעדוף.

חברת פרטנר אף פרסמה כי תפרוס רשת שתאפשר חיבור ושימוש ע"י מכשירי IoT (פשוט מודמים שידברו באחד מהפרוטוקלים החביבים בשביל לדבר אחד עם השני).

אם להאמין לתחקיר שביצע TelecomNews, הרי שמדובר במהלך שלא פחות ממדהים ע"י חברת התקשורת.
הלקוחות (ע"פ התחקיר)  ישארו כלקוחות לשנים רבות ולא יעברו למתחרים.

הסיבות העיקריות הן אי יכולת החלפת ספק בגלל שיטת השידור ביחד עם הסרת הכיסויי הארצי (מספר רב של חברות פשוט מורידות את האנטנות מאזורים לא משתלמים ) גורמים לעבודה שאנשים פשוט יתקעו ללא כיסוי. אם זה נשמע כמו משהוא הזויי שאין סיכוי שיקרה - אני חותף את זה על תקן יומי בגלל שיש חור אי כיסוי רציני באזור קריית גת.

אני יודע שמה שאני הולך להגיד הוא מנוגד להרבה הצעות שהם מאוד מתאימות לשוק הבן לאומי (בהם אנו בונים מנגנון לעבודה בLTE וסומכים על ספקי התקשורת) המקרה פה טיפה שונה מהמצב הבן לאומי. נכון שמאוד מומלץ להסתקל על דברים כמו mangOh ולבנות מערכות שיודעות לדבר בצורה פתוחה עם רכיבי תקשורת שמדברים בתדרים מורשים.

כאשר יש לנו שימוש בחומרה מהסוג הזה יש לנו סיכוי מאוד גדול שנוכל להשתמש בכלים פתוחים וחופשים ע"ג מערכות AT/QMI/MBIM (תלויי בממשק) מה שבתלות בקודם יאפשר לנו ממשקים כמו ppp/qmi/mbim.

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

הבעיה אצלנו היא שלא רק שהכיסויי יכול להתעופף גם הנדידה בין הספקים עצמם יכולה להיות בעייתית - לדוגמה אני ינתקלתי בבאג מעצבן באזור עזריאלי לפני כשנה שדרשה ממני בסוף מעבר לספק 3G סלולאר אחר.

בנוגע למערכי חיישנים - אני לא אומר שצריך לעבור להשתמש ב E-Sim ונגזרות ה LTE (לא נתקלתי עדיין במימוש שעובד חלק עם E-Sim בדביאן) אבל כן ניתן היה להשתמש בשיטות כיסויי "פתוחות" שיאפשרו חיבור של הציוד למערכת מרכזית שיכולה לדבר עם מגוון רכב של כלים במקרה הצורך (הכל ב LORA דרך Wi-Fi ועד LTE רגיל ).

כאשר מדובר על ציוד קצה שנמצא ב"אתרים" (רדיוס קטן מ 50 מטר )  אני חושב שזה יהיה יותר בטוח להשתמש בדברים כמו  zigbee , וי-פי, SigFox מכיוון שמדובר על פתורונות פתוחים (חלק אפילו קוד חופשי) שימנעו נעילת ספק תשתי,כאשר הציוד שלנו מדבר בפרוטוקול / תוכנה חופשית זה מאפשר לנו להחליף ספקים ואף להיות ספק עצמי בעלות יחסית נמוכה.

פתרונות מבוססי תדר מורשה (LTE/3G/4G) בד"כ נועלים את המשתמש לספק כזה או אחר, ואם אתה כחברה צריך כיסוי אתה פונה לספק תקשורת ומדבר איתו באמצעות מודם כל שהוא.

מודמים סלולארים הם סגורים בהגדרה ואם אנו בונים מערכת שדורשת לעבוד עם רצועה אחת בלבד בתלות במספרי טלפון יש סיכוי טוב שמה שיעבוד ב PHI לא בהכרח יעבוד בסלקום.

יום ראשון, דצמבר 18, 2016

Huawei E8732

לאחרונה זכיתי בהזדמנות נפלאה בה אפשר לנסות להיות גיק באוף גריד, להתנסות בדברים כמו חוסר חשמל או מתח לא יציב, נפילות מתח שמונעות סינכרון ב VDSL (כי לספק התשתית החוטי יש נוהג מתח גיבויי מעניין) ועוד הרבה דברים נפלאים אחרים.

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

המצב כה קיצוני שבשיחה עם חברת החשמל המליצו לנתק מוצרי חשמל מהקיר במהלך חלק מהעבודות, ומכיוון שמחשב אחד נתן את נשמתו לבורא (עשן מהמחשב נייד) ולוח האם דיווח על תקלה בלוח אני מעדיף לסמוך על מה שהנציגים אומרים ;-).

מכיוון שחלק מהמחשבים במשרד עובדים עם Win10 ,לא ניתן פשוט להשתמש במודם 3G נורמאלי ;אז נאלצתי לרכוש מודם חדש ומכיוון שהיחיד בחנות שתמך ב"LTE" הוא Huawei  E8732 LTE Wingle הלכתי עליו.

תדרים:
LTE FDD 2600 MHz:
2500 MHz~2570 MHz(Uplink)/2620 MHz~2690 MHz(Downlink)
LTE FDD 1800 MHz:
1710MHz~1785 MHz(Uplink)/1805 MHz~1880 MHz(Downlink)
LTE FDD 700 MHz (B17)
704 MHz~716 MHz(Uplink)/ 734 MHz~746 MHz(Downlink)
LTE FDD 700 MHz (B28)
703 MHz~748 MHz(Uplink)/758 MHz~803 MHz(Downlink)
LTE FDD/DC-HSPA+/HSPA+/HSPA/UMTS 1900 MHz:
1850 MHz~1910 MHz(Uplink)/1930 MHz~1990 MHz(Downlink)
LTE FDD/DC-HSPA+/HSPA+/HSPA/UMTS 2100 MHz:
1920 MHz~1980 MHz(Uplink)/2110 MHz~2170 MHz(Downlink)
LTE FDD/DC-HSPA+/HSPA+/HSPA/UMTS 900 MHz:
880~915 MHz(Uplink)/925~960 MHz(Downlink)
LTE FDD/DC-HSPA+/HSPA+/HSPA/UMTS 850 MHz:
824 MHz~849 MHz(Uplink)/869 MHz~894 MHz(Downlink)
LTE FDD/DC-HSPA+/HSPA+/HSPA/UMTS AWS
1710MHz~1755MHz(Uplink)/2110MHz~2155MHz(Downlink)
LTE TDD 2300 MHz:
2300MHz~2400MHz(Uplink/Downlink)
GSM/GPRS/EDGE 850 MHz:
824 MHz~849 MHz(Uplink)/869 MHz~894 MHz(Downlink)
GSM/GPRS/EDGE 900 MHz:
880 MHz~915 MHz(Uplink)/925 MHz~960 MHz(Downlink)
GSM/GPRS/EDGE 1800 MHz:
1710 MHz~1785 MHz(Uplink)/1805 MHz~1880 MHz (Downlink)
GSM/GPRS/EDGE 1900 MHz:
1850 MHz~1910 MHz(Uplink)/1930 MHz~1990 MHz(Downlink)



בלינוקס כמו בלינוקס זה עבד מהקופסא ללא שום בעיות מיוחדות או דריברים והזדהה כך: 

[ 7139.260092] usb 1-1: new high-speed USB device number 10 using ehci-pci
[ 7139.393887] usb 1-1: New USB device found, idVendor=12d1, idProduct=1f01
[ 7139.393902] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 7139.393909] usb 1-1: Product: HUAWEI_MOBILE
[ 7139.393915] usb 1-1: Manufacturer: HUAWEI_MOBILE
[ 7139.393920] usb 1-1: SerialNumber: SOMELIE
[ 7139.445451] usb-storage 1-1:1.0: USB Mass Storage device detected
[ 7139.445777] scsi host6: usb-storage 1-1:1.0
[ 7140.209885] usb 1-1: USB disconnect, device number 10

ולאחר קסם ה usb_modeswitch הפך ל (אפס התערבות ממני פרט להכנת קפה):

[ 7141.128083] usb 1-1: new high-speed USB device number 11 using ehci-pci
[ 7141.270518] usb 1-1: New USB device found, idVendor=12d1, idProduct=14db
[ 7141.270533] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 7141.270541] usb 1-1: Product: HUAWEI_MOBILE
[ 7141.270547] usb 1-1: Manufacturer: HUAWEI_MOBILE
[ 7141.448708] cdc_ether 1-1:1.0 eth1: register 'cdc_ether' at usb-0000:00:13.2-1, CDC Ethernet Device, MYMAC
[ 7141.458747] usb-storage 1-1:1.2: USB Mass Storage device detected
[ 7141.459065] scsi host7: usb-storage 1-1:1.2
[ 7141.548519] cdc_ether 1-1:1.0 enxMYMAC: renamed from eth1
[ 7142.465769] scsi 7:0:0:0: Direct-Access     HUAWEI   TF CARD Storage  2.31 PQ: 0 ANSI: 2
[ 7142.469366] sd 7:0:0:0: Attached scsi generic sg1 type 0
[ 7142.488979] sd 7:0:0:0: [sdb] Attached SCSI removable disk

פלט ה lsusb הוא :


Bus 001 Device 011: ID 12d1:14db Huawei Technologies Co., Ltd. E353/E3131

לצערי הזיהוי שגויי אבל בשביל זה מספיק טוב (כי זה עובד !).

שימוש בקוד פתוח :

חיפוש מהיר בממשק הניהול מכריז כי במכשיר יש שימוש בקודGPLv2 , פרט לעובדה שיש שימוש ב GPLv2 לא הצלחתי לאתר את קוד המקור. לא על שום מדיה (לא היתה כזו) וגם לא באתר ממנו המכשיר נרכש. בשונה ממה שמתקיים אצל D-Link לא הצלחתי לאתר את קוד המקור והתיעוד באתר הייצרן או בחנות ממנה נרכש המוצר.

אני לא יודע אם זה נחשב או לא GPL Violation או לא אבל זה נראה מסריח.

ע"פ הרישיונות יש שימוש במקטעים מ :

Android
OpenSSL
SSLeay
BusyBox
libsepol
iproute
bridge-utils
libnl
Samba
siproxd
zlib
osip
cups
MiniUPnP
FUSE
ועוד ...

DNS שבור :

כאשר אין כרטיס סים זה שולח לדף הניהול, שזה לא ממש הרעיון הטוב ביותר שיכלתי לחשוב עליו (ניסיון גישה ל google.com מפנה ל 192.168.8.1) ולא מצאתי דרך לבטל זאת.

וי-פי :

סיסמת הויפי רשומה מתחת למכסה הדונגל, מאפייני ההתחברות לממשק הם admin/admin.

צריכת חשמל :

הרסברי פיי שלי נכשל כשלון חרוץ בהפעלתו (כנראה דורש מעל ה 500ma), עבודה ממחשב נייד הצליחה בלי שום בעייה.לצערי לא היה לי אמפרמטר (שמיש) לבדוק את הזרם באמת.

שימוש בWin10 :


Win10 זיהה את המכשיר והצליח להתחבר גם כethernet וגם ב WiFi.


שימוש בדביאן :


מהירות באחת מחברות האפ"ס (מדווח כ LTE) :
Monitoring wlan0...    (press CTRL-C to stop)

 wlan0  /  traffic statistics

                           rx         |       tx
--------------------------------------+------------------
  bytes                   264.80 MiB  |       10.04 MiB
--------------------------------------+------------------
          max           11.96 Mbit/s  |      403 kbit/s
      average            2.97 Mbit/s  |   112.71 kbit/s
          min               0 kbit/s  |        0 kbit/s
--------------------------------------+------------------
  packets                     196744  |          105121
--------------------------------------+------------------
          max               1061 p/s  |         575 p/s
      average                269 p/s  |         144 p/s
          min                  0 p/s  |           0 p/s
--------------------------------------+------------------
  time                 12.17 minutes


נמדד במרחק אווירי (ללא LOS) לאנטנה של כ400 מטרים, מדידה בוצעה בשטח פתוח מרחק לפי govmap.

אני מציין כי אין LOS כי אני רואה בערך איפה האנטנה אמורה להיות (לפי המיפוי היא נמצאת על גג המבנה)  אבל אני לא מצליח לזהות אותה על הגג המבנה.

יום שני, אוקטובר 17, 2016

מאפייני מיקום

כאשר אנו עובדים על תשתיות הרשת פעמים רבות אנו עובדים על נתוני המיקום של המשתמשים בשביל לאפשר שירותי IMS ובשביל לספק שירותים מבוססי מיקום. אחת מדרישות הבסיס היא לאפשר לזהות ולשלוח מאפייני מיקום במקרי חירום  7852.

את נתוני המיקום ניתן לקבל באמצעות בקשת HTTP[s] משרת ה Location Server (LS). נתוני המיקום מתקבלים גם מלקוח הקצה וגם מרשת הסלולאר עצמה.

הממשקים מוגדרים גם ברמת ה TS וגם באמצעות RFCים לדוגמה 6753 (HELD)

קיימים שני פלטים פופלארים.

פלט בינארי בו אנו מקבלים חבילה עם מספר בייתים ובחבילה יש את המיקום ומאפיין המיקום.
בפורמט זה קיימים מספר אפשרויות מיקום :

  • Ellipsoid Poin;
  • Ellipsoid point with uncertainty circle
  • Ellipsoid point with uncertainty ellipse
  • Polygon
  • Ellipsoid point with altitude
  • Ellipsoid point with altitude and uncertainty ellipsoid
  • Ellipsoid Arc
ב 23.032 TS הסוג מקודד ע"י הפורמט בו ה4 הבייטים העליונים ( 8,7,6,5) בבייט הראשון מאפיינים את סוג הצורה :
Bits
4 3 2 1 
0 0 0 0 Ellipsoid Point 
0 0 0 1 Ellipsoid point with uncertainty Circle 
0 0 1 1 Ellipsoid point with uncertainty Ellipse 
0 1 0 1 Polygon 
1 0 0 0 Ellipsoid point with altitude 
1 0 0 1 Ellipsoid point with altitude and uncertainty Ellipsoid 
1 0 1 0 Ellipsoid Arc 

ושאר הבייטים הבאים מכילים את המידע לפי סוג הצורה שנבחרה.

כאשר עובדים ב3G וGSM הדבר פשוט, המידע מתקבל דרך פעולות location update ושמירת המיקום בו בוצעה פעולה.

טווחי  האיכון  הם בערך כך :

מבוסס רשת האיכון הוא על בסיס  ה 300 מטר  (תלויי בפריסה ובציוד) , ה 300 מטר מגיע מדרישת ה FCC.
מבוסס מכשיר יכול להיות ברמת המטרים הבודדים.


פלט XMLי, מאופיין כ PIDF-LO.

בחלק משירותי ה WiFi יכולים לשלוח PIDF-LO (מהנתב עצמו) לפי גילוי משתמש, PIDF-LO למחשב שהזדהה כ USER-PC עבור המשתמש user יכול להיות מיוצג כך.



<presence entity="pres:user@subdomain.domain.com" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:gml="http://www.opengis.net/gml" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns="urn:ietf:params:xml:ns:pidf"> <dm:device id="USER-PC"> <gp:geopriv> <gp:location-info> <gml:point srsname="urn:ogc:def:crs:EPSG::4326"> <gml:pos>32.86726 -97.16054</gml:pos> </gml:point> <cl:civicaddress> <cl:flr>2</cl:flr> </cl:civicaddress> </gp:location-info> <gp:usage-rules> <gp:method>Wiremap</gp:method> </gp:usage-rules></gp:geopriv> <dm:deviceid>mac:123456789012</dm:deviceid> <dm:timestamp>2016-10-01T20:57:29Z</dm:timestamp> </dm:device> </presence>

אבל איך זה עובד אם אנחנו לא מסתמכים על הרשת ואין לנו רכיבי GPS או GSM (במקרה שלVoWiFi  למשל).

כשאנו עובדים ב data נקי, וה UE שלנו הוא למשל מחשב המערכות מתבססות על מספר לקוחות.

לקוח ה DHCP שלנו יאפשר שימוש ב4776 .

בנוסף כאשר ה UE זז הרבה או שאנחנו לא יכולים לסמוך על לקוח ה dhcp שיעשה את העבודה אנו משתמשים ב 6442 , ובלקוחות LIS/LoST/held בשביל לקבל מאפייני מיקום מצד שלישי.

בצורה כזאת נתוני המיקום שלנו עוברים תחת משאבי ה SIP כלפי הרשת. וה UE שלנו יוכל לעדכן את הרשת הייכן הוא נמצא.

בצורה כזאת לקוח הSIP שלנו ישלח ויוסיף את מאפייני המיקום שלנו ע"י שימוש ב PIDF-LO

INVITE sips:bob@biloxi.example.com SIP/2.0
   Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9
   Max-Forwards: 70
   To: Bob <sips:bob@biloxi.example.com>
   From: Alice <sips:user@atlanta.example.com>;tag=9fxced76sl
   Call-ID: 3848276298220188511@atlanta.example.com
   Geolocation: <cid:target123@atlanta.example.com>
   Geolocation-Routing: no
   Accept: application/sdp, application/pidf+xml
   CSeq: 31862 INVITE
   Contact: <sips:user@atlanta.example.com>
   Content-Type: multipart/mixed; boundary=boundary1
   Content-Length: ...

   --boundary1

   Content-Type: application/sdp

   ...Session Description Protocol (SDP) goes here

   --boundary1

   Content-Type: application/pidf+xml
   Content-ID: <target123@atlanta.example.com>
   <?xml version="1.0" encoding="UTF-8"?>
       <presence
          xmlns="urn:ietf:params:xml:ns:pidf"
          xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
          xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
          xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
          xmlns:gml="http://www.opengis.net/gml"
          xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
          entity="pres:user@atlanta.example.com">
        <dm:device id="target123-1">
          <gp:geopriv>
            <gp:location-info>
              <gml:location>
                <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
                  <gml:pos>32.86726 -97.16054</gml:pos>
                </gml:Point>
             </gml:location>
            </gp:location-info>
            <gp:usage-rules>
              <gbp:retransmission-allowed>false
              </gbp:retransmission-allowed>
              <gbp:retention-expiry>2010-11-14T20:00:00Z
              </gbp:retention-expiry>
            </gp:usage-rules>
            <gp:method>802.11</gp:method>
          </gp:geopriv>
          <dm:deviceID>mac:1234567890ab</dm:deviceID>
          <dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp>
        </dm:device>
      </presence>
   --boundary1--

מערכת יחיסית פופלארית מבצעת זאת כבר המון זמן, היא lync.

מיקום ב isc-dhcp-server

בפוסט שמדבר על קבלת מאפייני מיקום הזכרתי כי ניתן לשלוח את נתוני המיקום בבקשה עצמה, כברירת מחדל זה לא מופעל בisc-dhcp.

יש מספר RFCים שמתארים איך צריך לשלוח מאפיייני civic בבקשות DHCP.

העיקריים הם  :

4776
3825
6225
geopriv-dhcp-lbyr ביחד עם  dhcp-lci-option-03
held 


ב isc-dhcp-server בשביל להפעיל את העברת המידע צריך לאשר את הבקשה ברמת השרת לדוגמה עבור 4776 :

option unknown-99 code 99 = string;
option unknown-99 00:55:53:01:02:49:44:03:06:4D:6F:73:63:6F:77;
הקידוד לפורמט לפי RFC 4776.

את המיקום אפשר להגדיר פר שרת , או אפילו ברמת הsubnet. כמובן שבמקרה שאנו מספקים גישה ע"ג wifi צריך לתמוך ב 6224 ובגישה ל HELD ועדיפות שיהיה לקוח נוסף שיוכל לעדכן מיקום.

בשביל לדרוש לבקש את השדה יש להוסיף ב /etc/dhcp/dhclient.conf את הערך המתאים לפי השם הקנוני או unknown-code כאשר הcode הוא הערך מה RFC לדוגמה : unknown-99 (או geoconf-civic אם נתמך) תחת request או also request.

משום מה לא הצלחתי לראות למה unknown-123  ו 144 לא עבד (פשוט לא נשלח דרך הלקוח).

יום ראשון, אוקטובר 16, 2016

Wi-Fi calling

אז מה זה Wi-Fi Calling ולמה לנו כאנשי תוכנה חופשית זה כה חשוב  ?

מי שעוקב אחרי מה שהולך בתשתיות יכול להיות ששם לב שחברות סלולאר שרוצות להוזיל עלויות ולהגדיל פריסה מחפשות פתרונות חדשים. חלק מהפתרונות שלהם הוא מעבר לשימוש ב Offloading מסוגים שונים בין אם זה תחת VoLTE ובין אם זה תחת VoWiFi.


הרעיון אומר שרכיב התקשורת שלכם (UE) מתחבר לרשת הוי-פי ומשתמש בה כרכיב גישת הרדיו שלה. הדבר מאפשר למכשירי הקצה לקבל תמיכה ברכבות , תעלות, בנייני משרדים וכל מיני מקומות בהם כיסוי הרדיו הרגיל מתקשה ודורש התקנת רכיבים אחרים (GSM-R ברכבות , משדרים מיוחדים בנקודות גישה וכו').

דרישות הבסיס לטכנולגיה נמצאת בצד לקוחות הקצה כבר שנים,איפונים (מעל 5)  ואנדרויידים (4 ומעלה) אמורים לתמוך מהקופסה.

הדבר היחיד שאינו ממוש כמו שצריך ברכיבי הסלולאר הוא לקוח ה ipsec שיתאים בצורה טובה לדרישות ה VoWiFi.

השוני העיקר עבורנו המשתמשים של VoWi-Fi (או VoWiFi) מ VoLTE הוא הרמה בה מתחברים לרשת, לנו כלקוחות קצה קל יותר להשתמש ב VoWiFi בגלל הגישה בה כל לקוח (תאורתית) יוכל להפעיל נתב שמאפשר לטלפון הסלולארי שלו להתחבר לרשת במידה וספק השירות אישר את השיטה.


נניח ואתם חברת תקשורת שאין לה מספיק אנטנות אבל היא כן רוצה לפרוס תמיכה טובה מספיק או רשת אליה הלקוחות שלה יוכלו להתחבר, החברה יכולה לבחור לפרוס AP משלה או להשתמש בצד שלישי בשביל לספק את זה. למעשה זו אחת הסיבות בגללה חברות מפעילות תמיכה בטכנולוגיות, כמובן פרט לעובדה הקטנה שזה מוריד עלויות Roaming ושיחות בין לאומיות ומאפשר התמודדות מול שירותי OTT כמו skype.

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

אז איך זה עובד ?

לרעיון שימוש ב WiFi כרכיב התעבורה היו מספר גילגולים, הנושא הוצג גם ע"י GSMA וגם קיימים RFCים בדבר.

בגרסאות הישנות של הפתרון (לדוגמה ב WISPr) היו מגדירים שהטלפון שלכם יתחבר לרשתות בהם ה SSID הוא קבוע מראש (לדוגמה T-Mobile או tmobile) ואז מבצעים אימות EAP-SIM ומתקשרים ע"י SIP-IMS.

לאחר מספר גילגולים עברו לשימוש של גילוי דינאמי וקבלת הגדרות בזמן אמת ואז חיבור באמצעות רכיבי ה SIP ישירות לשרת (ספק השירות).שימוש בשירותי XCAP ועידכון מאפייני שיחה ע"י פעולות SIP.

ה RFCים מדברים על שלושה גישות :

גישת ה Trusted - בה אנו סומכים על הרשת המארחת (שלנו ), במצב כזה חברת השירות היא בעלת תשתיות ה AP. היא מבצעת את האימות קרוב לנתבים (היא גם יכולה לספק שירותי ANDSQ בשביל לגרום למערכת להתחבר בצורה פשוטה יותר).


                                                             +-------+
                                                             |  IMS  |
                                                             | Core  |
            +-------------+              +-----------+       +-------+
            |             |              |           |           |
            | +--------+  | Flow mapped  |           |           |
            | |IMS APN |  | to VMAC-01   |           |       +-------+
            | |        +-----------------+           |       |IMS APN|
            | |Client  |  |              |           +-------+ P-GW  |
            | +--------+  |              |           |       +-------+
            |             |              |           |
            |             |              |Release 12 |
            |             |              |  TWAG     |
            |             |              |           |       +-------+
            |             |              |           |       |Default|
            |             |              |           +-------+ APN   |
            | +--------+  | Flow mapped  |           |       | P-GW  |
            | |Default |  | to VMAC-02   |           |       +-------+
            | | APN    +-----------------+           |           |
            | |Client  |  |              |           |           |
            | +--------+  |              |           |           |
            +-------------+              +-----------+           |
                                                               XXXXXX
                                                             XX     XXX
                                                            XX        XX
                                                           X           X
                                                          X            X
                                                          X Internet   X
                                                          X            X
                                                          X           XX
                                                           X         XX
                                                            XX    XXXX
                                                             XXXXXX

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

      +--------------+            +----------+          +-------+
      | +----------+ |  IMS-APN   |          |          |       |
      | |    SWu   | |  Traffic   |          |          |       |
      | |  Client  +------------------------------------+       |
      | |          | | Other APN  |          |          | ePDG  |
      | |          | |  traffic   |          |          |       |
      | |          +------------------------------------+       |
      | |          | |            |          |          +-------+
      | +----------+ |            |          |            |  |
      |              |            |          |         S2b|  |S2b
      |     UE       |            |  WLAN    |            |  +---+
      |              |            | Access   |            |      |
      | +----------+ |  LBO       |          |    +-------+   +-------+
      | | Native   | |  Traffic   |          |    |IMS APN|   | Other |
      | |          | |            |          |    |  PGW  |   |  APN  |
      | | Client   +-------------------+     |    |       |   |  PGW  |
      | |          | |            |    |     |    +-------+   +-------+
      | +----------+ |            |    |     |         |          |
      +--------------+            +----------+         |          |
                                       |               |          |
                                       |           +-------+   +-------+
                                       |           |  IMS  |   |  App  |
                                       |           |       |   | Server|
                                       v           +-------+   +-------+


וגישה היברידת המשלבת את שני הדברים:

                                                  +------+   +---------+
                                                  | IMS  |   |  Other  |
                                                  | Core |   |Services |
                                                  +------+   +---------+
                                                     |           |
                                                  +------+   +-------+
       +--------------+      +-----------+        |IMS   |   | Other |
       | +----------+ |      |           |        |P-GW  |   | P-GW  |
       | |    SWu   | |      | +-------+ |        +------+   +-------+
       | |  Client  | |      | |SIPTO  | |           |           |
       | |          | |      | ++NAT   | |           |  +--------+
       | +----------+ |      | +-------+ |           |  |
       |              |      |           |        +------+
       |     UE       +------+   TWAG    |  S2b   | ePDG |
       |              |      |           +--------+      |
       | +----------+ |      |           |        +------+
       | | Native   | |      |           |
       | | Client   | |      |           |
       | |          | |      |           |  S2a   +-------+
       | +----------+ |      |           +--------+Default|
       +--------------+      +-----------+        | PGW   |
                                                  +-------+
                                                    |
                                                    |
                                                    +
                                                 XXXXXXXX
                                                XX      XX
                                                X        X
                                                XInternetX
                                                X        X
                                                XX      XX
                                                 XXXXXXX


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

בצורה כזאת חברות שמספקות MVNO (או ספקי תקשורת רגילים) יכולות להצהיר על הרשת שלהם תחת כתובות DNS, שמות השירותים מוגדרים מראש (כמו במקרה הENUM ).

GSMA הכריז על מספר שירותים אליהם ניתן להתחבר בשביל לקבל גישה לשירותים :

http://epdg.epc.mnc$(MNC).mcc$(MCC).pub.3gppnetwork.org

http://ss.epdg.epc.mnc$(MNC).mcc$(MCC).pub.3gppnetwork.org

http://rcs.mnc$(MNC).mcc$(MCC).pub.3gppnetwork.org

http://mnc$(MNC).mcc$(MCC).pub.3gppnetwork.org

http://bsf.ims.mnc$(MNC).mcc$(MCC).pub.3gppnetwork.org

http://xcap.ims.mnc$(MNC).mcc$(MCC).pub.3gppnetwork.org

http://andsf.ims.mnc$(MNC).mcc$(MCC).pub.3gppnetwork.org


כל אחת מהכתובת בעת משמעות משלה שמאפשרת שימוש במשאבים נוספים.

במהלך החיבור יקבל את המאפיינים של ה Evolved Packet Data Gateway  (ePDG)  שאיתם צריך להתחבר.

במקרה של רשת שאינה בטוחה נפתח ערוץ ipsec :

לקוח הקצה יפתח ערוץ IPSEC/IKEv2 ( 5996 ו 3GPP TS 33.402)   לשרת בשביל שנוכל להשתמש במשאבי הרשת. ההזדהות (NAI) תהיה במבנה של IMSI@Realm (או מזהה מכשיר תחת realm) וזה ימולא תחת ה IDi בשדה ה IDr נמלא את ה APN שצריך להתחבר בתוך ה ePDG .

לאחר שיבוצע אימות כלפי ה ePDG ונקבל אישור לפתיחת session לאחר מכן לקוח ה SIP-IMS שלנו יבצע invite לקבל שירות.

לצערי הרב על התהליך יש פטנט מה שבתאוריה יכול לפגוע בשימוש בזה בפתרונות קוד פתוח.

במקרה של רשת מאובטחת לא מקימים תעלה, האימות מתבצע קרוב ל חיבור ל AP ע"י אחד מאפשרויות האימות מבוססי ה EAP, לבסוף לקוח הסיפ יבצע register בשביל להתחיל להשתמש במשאבי הרשת.


הכתובת config.rcs.pub.3gppnetwork.org מאפשר ממשק HTTP לקבל את מאפייני החיבור (זה rcs רגיל) , xcap הוא אותו ה xcap שאנו משתמשים ברכיבי ה SIP כאשר אנו מדברים עם רשתות LTE ו 3G. לצערי הרב ktp ו linphone לא מציגים דרך קלה לעבוד עם xcap.


בצד הלקוח -

בשביל שנוכל להשתמש באפשרויות האלה אנו נצטרך לקוח wpa_suppliant עדכני , לקוח SIP ולקוח ipsec איתו נוכל להתחבר לרשת רכיב חומרה שיודע לקרוא כרטיסי SIM או פשוט מכשיר סלולאר שיודע לתמוך ב WiFi Calling ו LTE.

עבור שירותי IMS אחרים נצטרך להפעיל אפליקציות בהתאם לשירות אבל מכשיר הסלולאר שלנו עושה זאת עבורנו.

אני מאמין ש linphone ידע להתמודד טוב עם SIP-IMS  ב VoWiFi עם המגבלות הבאות :

אני חושב שהתמיכה ב SMS over IP תהיה לוקה בחסר (יש תמיכה ב 3428 ונראה לי גם ב 4976 אבל לא בטוח שיש תמיכה בכל מה שתחת TS.2431) , הודעות חירום לא יעבדו (כי זה לא מוגדר) אבל פעולות של USSD ככל הנראה כי יעבדו.

מפתחי אפליקציות קצה  יכולים לראות את דרישות ה IMS בRFC ולממש את IR.92 (מה שיאפשר לעבוד גם ב VoLTE וגם ב VoWifi).

בגלל קיום שלושת הגישות להודעות מיידיות ככל הנראה יהיו בעיות אבל אני מאוד מקווה שהכל יממוש.

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

רכיב התקשורת (UE) שלנו יחפש קודם כל רשתות שהוא מכיר (ויודע שניתן להתחבר אליהם אם הם trusted), יבצע זאת ע"י מעבר שמות או יחפש רשתות שמאשרות ביצוע הזדהות סים (EAP-AKA/SIM וכו'). אם זה לא עבר יעבור למוד ה untrstursted בו יחפש את הנקודה אליה צריך להתחבר (לפי רשת הסלולאר שלנו כמו t-mobile.com או לפי הכתובות הרשומות תחת 3gppnetwork).

האימות נכון להיום (שמאפשר את שימוש) כולל דברים מבוססי סים (EAP-AKA) אבל גם דברים שאינם דורשים סים (מה שמאפשר לטאבלט ולדביאן שלנו להתחבר לרשת האלחוט באמצעי EAP-TTLS ו EAP-TLS).

במידה וה AP שלנו דורש הזדהות (hybrid mode או Trusted Mode) את חותמות הלקוח שקיבלנו יש לשמור תחת etc/ssl/certs/  ולהתאים את wpa_supplicant והדפדנים לקרוא משם דוגמאות (כמובן לשנות את הערכים לפי מה שקיבלתם מהספק).


network={
      ssid="TRUSTED-GSM-SSID"
      scan_ssid=1
      key_mgmt=WPA-EAP
      pairwise=CCMP TKIP
      group=CCMP TKIP
      eap=TLS
      identity="$(nonuiccid)@blablagsm.tld"
      ca_cert="/etc/certs/cacert.pem"
      client_cert="/etc/certs/client_blablagsm.pem"
      #or 
      #private_key="client_blablagsm.pem"
      #private_key_passwd="secretuserpassword"
   }
או במקרה של TTLS :
network={
      ssid="UNTRUSTED-GSM-SSID"
      key_mgmt=WPA-EAP
      eap=TTLS
      scan_ssid=1
      pairwise=CCMP TKIP
      group=CCMP TKIP 
      anonymous_identity="anon@blablagsm.tld"
      identity="$(nonuiccid)@blablagsm.tld"
      ca_cert="/etc/certs/ca.pem"
      phase2="autheap=TLS"
      ca_cert2="/etc/certs/cacert.pem"
      client_cert2="/etc/certs/client_blablagsm.pem"
      private_key2="key_client_blablagsm.pem"
      private_key2_passwd="secretuserpassword"
   }


בדביאן על מנת לאפשר את האימות מחדש נצטרך להפעיל ע"י בנייה מחדש עם דגלי ה internetworking מופעלים.

לצערי הרב לא ראיתי פתרון IMS לדסקטופ שתומך בכל הדרישות מה שאומר שנצטרך להפעיל מספר שירותים ו"לנחש" מה חסר בשביל סיפוק השירות. 


אבל אני מאמין שלאחר שהשירות כבר קיים בארבעת הספקים הגדולים בארה"ב  ואורנג' העולמית משהוא כבר יתאים את אפליקציות ה GUI הקיימות היום.

בצד השרת -

בצד הePDG נוכל להשתמש במחשבי דביאן רגילים, שמריץ שירותים סטאנדרטיים כמו שרת דיאמטר, שירות DNS, שרת ipsec, שרת xcap, שרת איכון גאוגרפי, שירותי SIP ומחבר לשירותי ה IMS של הרשת או משתמש ב OpenIMSCore (או דומה לו) בשביל לספק את היכולות הנדרשות.


הרשתות שבוחרות בשיטת ה untrusted כמובן חשופות להתקופות רגילות (דוגמה T-Mobile) אבל ההוזלה והיכולת להשתמש בצד שלישי בקלות בשביל לספק שירות פותחת אפשרויות שעולות על הסכנה בהתקפות.

יום שישי, אפריל 29, 2016

יש בקהל משהוא שרוצה לשבור לאנשים את רשתות הסלולאר ?

    implementations derive the realm name from the IMSI by
    concatenating "mnc", the MNC digits of IMSI, ".mcc", the MCC digits
    of IMSI, and ".owlan.org".  For example, if the IMSI is
    123456789098765, and the MNC is three digits long, then the derived
    realm name is "mnc456.mcc123.owlan.org".  As there are no DNS servers
    running at owlan.org, these realm names can only be used with
    manually configured AAA routing
 
$whois owlan.org
NOT FOUND
>>> Last update of WHOIS database: 2016-04-29T13:44:05Z <<<
דרך 4186

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

VoLTE בקוד חופשי

כשאני חושב על האפשרוית שיש היום לגולן לצאת מהבעיה אליה נכנסה החברה אני חושב על פריסת נתבים  (או שימוש בנתבים של חברה מסויימת) ושימוש בנתבים כנקודות גישה ל LTE באמצעות מה שמכונה כ Offloading.

מדוע זה יענה על הצורך משרד התקשורת ? מכיוון ש EGAN מגדיר את ה WiFI כתשתית הרדיו שלו לאספקת שירות (RAN). הדרישה של משרד התקשורת לכיסויי ולאחזקה של אנטנות תענה. ועל הדרך גולן יקבל פריסת דור 4 ואפילו תמיכה ב VoLTE (שאני לא חושב שיש מישהוא שמספק את זה בארץ).

VoLTE הוא דרך (שיטה?) להעביר את המידע שבדר"כ עבר דרך circuit switch תחת תקשורת IP. כלומר דברים כמו קול , SMS ו הודעות broadcast עוברים באפיק הנתונים. כאשר עוברים להשתמש באפיק נתונים מקצה אל קצה הדבר מאפשר לתמוך באיכות קול גבוהה יותר (במקום להשתמש ב 3.5 קילו הרץ אנו משתמשים ב 16), לספק יותר שירותים חכמים ולייצר רווח על שירותים בהשקעה נמוכה.

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

לשם ההתחלה ספק הטלפוניה יצטרך להקים תמיכה ב VoLTE בצד השרת, להקים שרתי דיאמטר,שרתי DNS ,  SIP ו XCAP.

לקוחות הקצה יוכלו לרכוש מכשירי סלולאר שתומכים ב VoLTE וגיקים כמוני ינסו להשתמש בזה דרך הכלים הפתוחים שיש ברשותינו.

מה שנזדקק לו זה:

  1. משהוא שיודע לבצע EAP-AKA לקוח ההזדהות שאנו משתמשים לו wifi הידוע כ wpa_supplicant יודע לבצע את זה בלי שום בעייה.

    קובץ ההגדרות יכול את ההגדרה הבאה עבור הרשת GolanOverWifi אם היא תתמוך בהזדהות EAP-AKA:

    #this may be added into /etc/wpa_supplicant.conf
    network={
     ssid="GolanOverWifi"
     key_mgmt=WPA-EAP
     eap=AKA
     pin="1234"
     pcsc="" # define as empty to allow pcsc usage (you are allowed to add args inside)
    }
    

  2. רכיב תוכנה שיודע לבצע זיהוי על גבי UICC - שד ברירת המחדל pcscd יודע לעשות זאת מצויין.

    מה שיהיה צריך לעשות זה לקחת קורא כרטיסים שנתמך בלינוקס ולהשתמש ב pcscd לקרוא את הנתונים ממנו.

    לאחר שחיברנו את קורא הכרטיסים למחשב והפעלת pcsc_scan נוודא שהכרטיס זוהה (פלט לדוגמא) :

  3. PC/SC device scanner
    V 1.4.26 (c) 2001-2011, Ludovic Rousseau <ludovic.rousseau@free.fr>
    Compiled with PC/SC lite version: 1.8.15
    Scanning present readers...
    0: Gemalto PC Twin Reader (70D7E2EE) 00 00
    
    Fri Apl 29 11:47:42 2016
    Reader 0: Gemalto PC Twin Reader (70D7E2EE) 00 00
      Card state: Card inserted, 
      ATR: 3B 7E 13 00 00 00 6A 11 63 54 05 48 05 02 C6 01 22 90 00
    ATR: 3B 7E 13 00 00 00 6A 11 63 54 05 48 05 02 C6 01 22 90 00
    + TS = 3B --> Direct Convention
    + T0 = 7E, Y(1): 0111, K: 14 (historical bytes)
      TA(1) = 13 --> Fi=372, Di=4, 93 cycles/ETU
        43010 bits/s at 4 MHz, fMax for Fi = 5 MHz => 53763 bits/s
      TB(1) = 00 --> VPP is not electrically connected
      TC(1) = 00 --> Extra guard time: 0
    + Historical bytes: 00 6A 11 63 54 05 48 05 02 C6 01 22 90 00
      Category indicator byte: 00 (compact TLV data object)
        Tag: 6, len: A (pre-issuing data)
          Data: 11 63 54 05 48 05 02 C6 01
        Mandatory status indicator (3 last bytes)
          LCS (life card cycle): 22 (Proprietary)
          SW: 9000 (Normal processing.)
    
    Possibly identified card (using /home/user/.cache/smartcard_list.txt):
    3B 7E 13 00 00 00 6A 11 63 54 05 48 05 02 C6 01 22 90 00
    3B 7E 13 00 00 00 6A 11 63 54 05 48 .. .. .. 01 22 90 00
    




  4. לקוח SIP בעל הדרישות הבאות  :

    • לתמוך ב IPv4 ו IPv6
    • להחזיק לקוח XCAP  - לצערי linphone ו yate-qt אינם יודעים אבל jitsi יודע.
    • לקוח ה XCAP צריך לדעת לעבוד ללא chalange (לא יודע jitsi יודע או לא ) , לקוח ה SIP צריך לדעת להחליף את הזהות לזהות אותה קיבל לאחר ביצוע ה Register.

    • צריך לדעת לבצע register מחדש לאחר איבוד תקשורת (לא ראיתי את זה קורה ב yate-qt).
    • צריך לדעת לתמוך ב SIMPLE ו הודעות SM-IP  (למעשה מדובר על מקרה פרטי של 3428) )
    • צריך לדעת להוסיף את הכותרות  הבאות:

      phone-context  ו P-Aasserted-Identity ו P-Called-Party-ID. ולדעת להקים שיחה עם SIP-URI בצורה של MSISDN או של TEL.

      דוגמאות:

      sip:alphanumericusername@operator.tld

      sip:+33123456@free.fr;user=phone

      tel:+33123456;phone-context=free.fr

    • צריך לדעת להוסיף את ערך ה ICSI לשדה ה contact עם הכתובת הנגישה לרשת הסלולאר.דוגמא:

      Contact:sip:<+33123456@172.16.10.1:5060&gt
      ;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gppservice.ims.icsi.mmtel"
      


    • צריך לדעת לתמוך בשירותים הבאים (מינימום) :

      Originating Identification Presentation 3GPP TS 24.607 [23]
      Terminating Identification Presentation 3GPP TS 24.608 [24]
      Originating Identification Restriction 3GPP TS 24.607 [23] (Note 1)
      Terminating Identification Restriction 3GPP TS 24.608 [24] (Note 1)
      Communication Forwarding Unconditional 3GPP TS 24.604 [20] (Note 1)
      Communication Forwarding on not Logged in 3GPP TS 24.604 [20] (Note 1)
      Communication Forwarding on Busy 3GPP TS 24.604 [20] (Note 1)
      Communication Forwarding on not Reachable 3GPP TS 24.604 [20] (Note 1)
      Communication Forwarding on No Reply 3GPP TS 24.604 [20] (Note 1)
      Barring of All Incoming Calls 3GPP TS 24.611 [26] (Note 1)
      Barring of All Outgoing Calls 3GPP TS 24.611 [26] (Note 1)
      Barring of Outgoing International Calls 3GPP TS 24.611 [26] (Note 2)
      Barring of Outgoing International Calls – ex Home Country 3GPP TS 24.611 [26] (Note 2)
      Barring of Incoming Calls - When Roaming 3GPP TS 24.611 [26] (Note 1)
      Communication Hold 3GPP TS 24.610 [25]
      Message Waiting Indication 3GPP TS 24.606 [22] (Note 1)
      Communication Waiting 3GPP TS 24.615 [27] (Note 1)
      Ad-Hoc Multi Party Conference 3GPP TS 24.605 [21] (Note 1)
      

      למרות  שאני לא מכיר לקוחות SIP חופשיים שתומכים ב Bearing , אני לא חושב שזה יהיה נורא אם תהיה הצגה לא טובה של שם המשתמש המתקשר או אני אקבל הודעה שגויה אם לא הצלחתי להתקשר.

    • לקוח ה SIP צריך לדעת לתמוך בזימון אנשים להוסיף לשיחת וועידה (כבר קיים היום ) ב yate-qt לא יודע לגבי אחרים.

    • לקוח ה SIP רצוי שיידע לבצע פעולות כמו העברת שיחה ו History-Info.

    • לקוח ה SIP צריך לדעת לתמוך ב DTMF לפי נספח G
    • לקוח SIP שיודע לעבוד עם הקודקים AMR (כולל wideband).

אני לא מזכיר לקוח ANDSF מכיוון שאנחנו כבר מתחברים לרשת ידוע אז אין צורך לדרוש מהמשתמש שיעבור לרשת כיסויי אחרת.

ואם אני מבין נכון אז זה הכל, ככל אנדרויד עדכני תומך כמעט בהכול פה במידה ויהיה ביצוע offload כמו שצריך (עם כיסוי עירוני) אני מאמין שזה יענה על הצורך של גולן בכיסוי אנטנות (כי נתב מכיל אנטנות) ואם בזק תאפשר לנצל את משתמשיה שמפיצים גם ככה את הרשת Bezeq_Free יהיה כיסויי יחסית יפה.


שיטת ההזדהות לא שונה ממה שיש כיום והיא תראה בערך כך :



UE                   Bezeq Free Access Point     Bezeq Radius server              Translator        GT HSS
|<----WLAN registration--->|                            |                              |                 |
|                          |                            |                              |                 |
| --------EAP-AKA-------------------------------------->|                              |                 |
|                          |                            | ---Radius proxy the request->|                 |
|                          |                            |                              | ---Rad2Diam---->|
|                          |                            |                              |<--USIM register-|
|                          |                            |<--- USIM registration request|                 |
| <-------EAP-AKA---AUTH ACTIONs----------------------> |                              |                 |


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

הסיבה שצריך מתרגם , היא שככל הנראה פפקי תשתית הויפי מפעילים רדיוס אבל ב LTE אנו משתמשים בדיאמטר. ועל מנת להפוך הודעות מרדיוס ל דיאמטר צריך להשתמש ביישות שנקראת Diameter Translator.

יום חמישי, אפריל 28, 2016

המלצות פריסת שרתי Diameter לנדידה

GSMA ממליץ שכאשר בונים מערכת שתתמוד בנדידה יש להתקין סוכני דיאמטר (diameter agent) בכל קצה של Public Mobile Network (שמכונים כ DEA).

ישנם מספר סוגים של Diameter Agents שאשר להתקין אבל תחת הדומיין של נדידה מה שיעניין זה Relay ו Proxy.

כאשר Relay אינו בודק תוכן אלא מעביר אותו בהתאם ל Application Id  ו Destination -Realm/
ו Proxy מכיל פונקציונאל שמטפל ב AVP שאינם קשורים לניתוב, יכול לבצע טיפול בהודעות להפעיל policy  ולהוסיף עוד AVPים.

בהתאם לטבלת הניתוב (Realm routing table), סוכן הקצה (DEA) ישמש כפרוקסי במקרה מסויים בעוד במקרים אחרים יתפקד כRelay בלבד.

כל מופע של סוכן מחוג יכול להיות רק מסוג אחד (פרוקסי או relay), לכן קיימת המלצה שעבור לקוחות חיצונים לרשת יפורסם כ Relay בעוד בתוך הרשת יעבוד כפרוקסי. בצורה כזאת פעולות הניתוב הפנימיות לרשת אינן קשורות לאפליצקיות הפנימיות שרצות בתוך הרשת.

כמו כן קיימת המלצה להחזיק פרוקסי עובר כל אפליקציה.



דוגמאת תצורה  : 

 --- VPMN -----     -  --- HPMN -----
|  MME  --- DEA+|++++++|+DEA---HSS   |
| SSGN  --- DEA+|++++++|+DEA----|    |
|               |      |             |
| vPCRF --- DEA+|++++++|+DEA-- hPCRF |
---------------         -------------

ה HPMN ו VPMN הם רשת הבית והרשת המארחת , HSS הוא Home Subscriber Server ו PCRF זה Policy and Charging Rules Function.


זיהוי התחנה הבא (next hop)  יתבצע דרך RFC3588 שעבר שינוי:
עוברים על רשימת השרתים הקיימת בהתחלה.

שולחים בקשת NAPTR לRealm המתאים. (זה מבוצע ע"י בחירת השרת בעל הערך AAA+D2S , ואם אין רשומת NAPTR מנסים לאתר את _diameter._sctp.REALMNAME).

ממולץ להגדיר את ה TC ל 30 שניות

כמה מילים על צורת החיבור שלנו בLTE

אז איך בערך נראה החיבור שלנו כשאנו גולשים ברשת ה LTE ?

הציוד שלנו (UE) מתחבר לרשת ה Evolved UMTS Terrestrial Radio Access Network אל תוך ה Evolved Packet Core (EPC) ומשם לשירותים.

בתוך ה E-UTRAN זה נראה בערך כך:

 UE<--------> eNodeB <----S1 -----> EPC
 
 

במבט על ב eNodeB (השם המלאה הוא E-UTRAN-Nodb-B מסומל גם כ eNB) זה נראה בערך כך :
      S1....EPC...S1....
     .                  .
    .                    .
   .
eNodeB ------ x2 ------ eNodeB
   \                     /
    \                   /
     \                 / 
      x2             x2
       \             /
        \           /
         \  eNodeB /

המסלול בין ה eNodeB  מול ה EPC נקרא  S1 , והמסלול בין eNodeB אחד למשנהוא נקרא X2.


ה UE שלנו מזוהה מול ה EPC שבתורו מזהה את המשתמש דרך ה Home Subscriber Server (בדומה ל AuC), את השירות הוא יקבל מהeNodeB עליו חובר.

הEPC בתורו מורכב מרכיבים כמו ה Home Subscriber Server , Mobility Mangment Entity ,Packet Data Network Gateway (P-GW) ו Servicing Gateway

ה MME מתפקד כVLR בעוד P-GW  מחליף את הGGSN.

האחריות של ה eNodeB  היא :

הצפנת התעבורה
בחירת MME מתאים ל UE
ניתוב התעבורה ל Serving Gateway
העברת הודעות מה MME לUE
העברת Broadcast כלפי ה UE.
העברת הודעות חירום על ה UE.

האחריות של ה MME היא:

זיהוי ה UE כלפי ה HSS (איומות והרשאה) לעבודה בPLMN.
תקשור NAS.
המקום בו נבצע האזנה ללקוחות .
אחרי על מעקב ומשלוח חוזר של הודעות כלפי ה UE.
הפעלה וכיבוי של שירותים (Barrer Actviation/deactivtion)
ניהול ניידות (Mobility) עבור UE.
רגל ב handoffs.
יצרת מזהה אירעי GUTI (המקבילה ל T-IMSI)
ניתוב וקישור במקרה של נדידה.


כאשר אנו מתחברים לרשת יתבצע תהליך של זיהוי האם אנו שייכים לרשת או שצריך לבצע נדידה.
במקרה של נדידה ה MME של הרשת אליה התחברנו יתקשר ל HSS שלנו (הרשת אליה ה סים שלנו שייך) ה Servicing Gateway יוצא תקשורת ל P-GW ברשת שלנו (הקו בין ה Servicing Gateway של המארחים ל P-GW שלנו יקרא S8).

ה HSS יכול לדבר באמצעות פרוטקול דיאמטר (ב LTE עברו מ רדיוס לדיאמטר) אל מול שירות ה AAA של הרשת שלנו.

למידע נוסף ETSI TS 136 300 (הקישור הראשון בדף)

offloading

שמתי לב למשהוא יחסית מעניין, למרות שהביקוש לגלישה גדל ואף חלק מחברות נותנות חבילות של 2-4 ג"ב /לחודש כמעט ולא נתקלתי בספקים שנתנו תמיכה ב Offloading (פרט לצרפת אבל שם זה מקרה מיוחד).

בשונה מ3G/UMTS קלאסי, הקמה של רשתות אלחוט על  בסיס WLan זול בסדר גודל (פשוט תשוו מחיר של נתב  (כ 100 דולר) כעמדת שידור לעומת BSS (כ 4000-5000 אלף דולר להקמה) .

הרעיון של ה I-Wlan מציע העברת צרכני Data ל שימוש ברשתות האלחוט וחיבור בו זמני גם לאספקת שיחות / SMS וגם לגלישת נתונים. פרוטוקול נוסף ה EGAN (specs) מאפשר העברת כול פעולות הרשת ע"ג ה Wi-Fi ובכך לאפשר שימוש ברכיבים קיימים כספקי שירות.

ההבדלים העיקרים  (שאני חושב לציין ) בין EGAN ל I-Wlan הוא שב EGAN יש Tight coupling ורשת ה WiFi משמשת כ RAN, בעוד ב I-Wlan יש loose coupling ותקשורת הנתונים יכולה (אבל לא חייבת) לעבור דרך רשת ה WiFi אבל יש חיבור לשני ההתקנים בו זמנית.

נניח ואני חברת תשתית ואני רוצה לחסוך הקמת אנטנות, שימוש ב EGAN ו I-Wlan יאפשר לי להשתמש בפריסת הנתבים שלי אצל המשתמשים (אהם .. bezeqfree אהםם ... ) בשביל לספק תשתית לכל המשתמשים.  מכיוון שעמדות Wi-Fi אינו דורש התרי בנייה הדבר הופך לפתרון זמין לחברות. חשוב לציין שאם חברות שפרשו רשתות אלחוט היו דואגות לשים התקן נוסף בנתבים הם היו יכולות לקבל femocells בחינם אבל מכיוון שהם לא עשו זאת ולבקש מהלקוחות להחליף נתב זה לא אופציה אני לא מכסה את האפשרות הזאת פה.

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

מכיוון שספק התשתית רוצה להמליץ דרך איזו תשתית להשתמש (בשביל שהוא יוכל לייצר חיוב) המציאו שיטה הנקראת ANDSF.

נכון להיום איתור התמיכה בשיטות (Access network discovery and selection function) קיים כבר במספר מימושים (כולל תכונות קוד פתוח ). הרעיון ב ANDSF לצורתיו מתכונן ע"י ה TSים הבאים : 
TS-23402
TS-24302
TS-24312

מאוד בגודל ANDSF מאפשר לרכיב הלקוח (UE), לאתר יכולת רשת חיצוניות ולרשת לספק יכולות אלו.
צורת העבודה היא שה UE ניגש לספקANDSF ומדבר ב S14. וזה עונה לו עם מיקום (או אף מקשר ) של ספקי השירות אותם הוא צריך (לדוגמה ע"י SMS). אחת השיטות שה UE מגלה התקן ANDSF היא באמצעות בקשת DHCP (6153) מיוחדת.

לאחר איתור המזההים ההתקן מתחבר לספקי השרות לקבלת השירות.

אחת הצורות לעבודה ב I-WLAN נראת בערך כך :
 
UE                            Acess Point (WiFi)     Network Core (AAA) 
<----EAP-SIM (ipsec tunnel) -------><-----Operator tunnel------------->


אני הפשטתי את הדיאגרמה (והסרתי נושאים כמו GTP ו GRE ואימות בצד הרשת כי הם מחוץ לסקופ של הפוסט) .

ואם נראה לכם מוכר ואתם שאולים את עצמכם האם אני כמתמש לינוקס אוכל להתחבר לשירותי ספק הסלולאר שלי ? אז כן זה אפשרי (עקום אבל עובד) צריך להתקין את pscd ואת wpa_supplicant ולהגדיר את wpa_supplicant_eap_sim.conf ואם ספק הסלולאר שלכם פרס נקודות wifi במקום בו אין קליטה לרשת הסלולאר תהיה לכם גישה לשירותים המתקדמים של הרשת דרכו.

לדוגמה קובץ ההגדרות עבור Free Telecom נראה כך :
network={
    ssid="FreeWifi_secure"
    key_mgmt=WPA-EAP IEEE8021X
    eap=SIM
    priority=1
    pin="9999"
}

מרבית הכרטיסים יתמכו ע"י libccid ואחרים (יהיה צריך לכוון את קורה ה SIMים שלך להתקן ttyusb הנכון).

מפה עולה השאלה האם נוכל באמצעי תוכנה חופשית להשתמש בשני המסלולים בו זמנית  (WiFi ו LTE) ?
לצערי נכון להיות הפתרון הידוע בשם MAPCON רשום כפטנט ולכן ככל הנראה לא נוכל להשתמש בו.

יום שני, אפריל 25, 2016

PCRF/PCEF/PCC

ב UMTS ו LTE יש לנו מספר מודלים לבצע חיוב, בחירת אופן החיוב והpolicy שלו מבוצע ע"י מה שמכונה Policy and Charing  Center (PCC).

ה PCC הוא יישות (אפשר להגיד מערכת שלמה) שיכולה לבצע החלטות ברשתות 3GPP (למשל UTMS ו LTE) וגם מערכות שהם לא בדיוק 3GPP (למשל כאשר יש שימוש ב I-WLAN).

ככל יש 5 מודלים של עבודה :
  1. חיוב לפי כמות שימוש.
  2. חיוב לפי זמן שימוש.
  3. חיוב לפי זמו וכמות שימוש.
  4. חיוב לפי אירוע.
  5. אי חיוב כלל
חיוב לפי כמות שימוש נמדד ביחידות (למשל KB ) וחיוב לפי זמן שימוש נמדד לפי זמן (לדוגמה גלשתי במשך שעה) .

מערכות ה PCC תבצע חיוב שונה כאשר קיימת נדידה, בהתאם למיקום (LAI , GeoFence) , בהתאם לסוג ה CSG (קבוצת מאפיינים ללקוח) של הלקוח ,  בהתאם לסוג השירות הנצרך בהתאם לזמן השימוש.

בצורה כזאת ניתן לחייב תושבי צפון תל אביב יותר מאשר למשל תושבי דרום תל אביב על אותו השירות, או להגיד שכל מי שיש לו איפון נשייך אותו לקבוצות חיוב גבוהה יותר (כי אני לא אוהב איפונים :) ).

כמו כן ניתן להגדיר כי כל מי שמתחבר לשירות הזרמת וידאו של Binge-On לא ישלם על השירות אבל אם יתחבר לצפות ב youtube הוא יחוייב בתשלום מלא.

המערכת יודעת לשלוח ל Policy and Charging Enforcement Function
 (PCEF) הודעות של כמה נשאר (זמן וכמות) לביצוע מעקב.

במידה ואנו עובדים במצב של חיוב בזמן אמת, ה PCEF יזהה מתי המשתמש חרג מהכמות המותרת וכאשר זה יקרה הוא ישלח הודעה ל Online Charging System (OCS) לזיהוי מחדש וקבלת משאבים (לדוגמה לשלם על עוד חבילת גלישה).

דרישות המינימום לאופן החיוב הן :

IP Connectivity Access Network  ברשת הביתית או המארחת.
מאפייני CSG של המשתמש.
QOS.
זמן ביממה.
מאפיני  IP Connectivity Access Network.



המארחת מחזיקה מערכת תעריפים והתעריפים יכולים להשתנות בהתאם לאירועי מערכת (למשל התחברות מחדש).

דוגמא קלאסית היא חיוב לשימוש בשירותי המייל של חברה מסויימת, ב uplink אנו מגדירים את שכל מה נשלח לפורט 80 ו 443 לחברה (בהתאם למשפחת כתובות מקור) וכל מה שמגיע מפורט 443 ו 80 ב downloing מהחברה.

השימוש ימדד על ידי ה Policy and Charging Rules Function (PCRF). שיקבל מידע פר משתמש ופר session זה נועד בשביל להפעיל החלטות בצורה דינאמית לפי אופן השימוש. ה PCRF שמבצע החלטות ישלח את הכמויות ה מותרות ל PCEF ו ה PCEF ישלח ל PCRF מתי משתמש מסויים הגיע לכמות שימוש מסויימת וידווח את כמות השימוש מאז הדיווח הקודם.

ה PCRF יבצע מעקב ברמת שירות , קבוצות שימושים ואף session בתוך IP-CAN.

למידע נוסף TS 23.203