יום שני, 27 באפריל 2026

שידור מיקום WIFI תשתית קיימת DLINK225

 כן — ה‑D‑Link DSL‑225 בהחלט מבצע הצפנה של הנתונים בין הראוטר לטלפון הנייד כאשר החיבור הוא ב‑Wi‑Fi, אבל חשוב להבין איזו הצפנה כן ואיזו לא.

להלן הסבר ברור ומדויק:

✅ הצפנת Wi‑Fi (כן, נתמך)

הראוטר תומך בהצפנת WPA2‑PSK (AES), שהיא הצפנה סטנדרטית וחזקה לרשתות אלחוטיות.

מה זה אומר בפועל?

  • ✅ כל הנתונים שעוברים מהטלפון שלך לראוטר ובחזרה מוצפנים
  • ✅ משתמשים אחרים בסביבה לא יכולים להאזין לתעבורה האלחוטית
  • ✅ הסיסמה של ה‑Wi‑Fi משמשת כמפתח הצפנה

🔐 זו הצפנה ברמת שכבת הקישור האלחוטית (Layer 2)

❌ הצפנה מקצה‑לקצה (End‑to‑End) – לא תפקיד הראוטר

חשוב לדעת:

  • הראוטר לא מצפין את המידע לכל אורך הדרך באינטרנט
  • לאחר שהמידע עוזב את הראוטר → ההצפנה תלויה ביישום / אתר

לדוגמה:

שימוש בטלפוןמצב ההצפנה
אתר HTTPS✅ מוצפן מקצה לקצה
WhatsApp / Signal✅ מוצפן מקצה לקצה
אתר לא מוגן (HTTP)❌ לא מוצפן מעבר ל‑Wi-Fi
FTP רגיל❌ לא מוצפן

⚠️ מגבלות אבטחה של DSL‑225

כדאי לדעת:

  • ❌ אין WPA3 (קיים רק בראוטרים חדשים)
  • ❌ אין IDS / Firewall מתקדם
  • ❌ אין ניהול אבטחה חכם למכשירים

לשימוש ביתי בסיסי — זה מספיק בהחלט
לשימוש רגיש / ארגוני — מומלץ פתרון מתקדם יותר

✅ ההגדרות המומלצות (חשוב!)

כדי לוודא הצפנה טובה:

  1. היכנס ל־192.168.1.1
  2. Wireless Settings
  3. Security Mode:
    • ✅ WPA2‑PSK
    • ✅ AES בלבד (לא TKIP)
  4. סיסמה:
    • לפחות 12 תווים
    • אותיות גדולות, קטנות, מספרים

🧠 סיכום קצר

✔ כן, ה‑DSL‑225 מצפין את כל המידע בין הראוטר לטלפון דרך Wi‑Fi
✔ ההצפנה היא WPA2 (חזקה לשימוש ביתי)
❗ הצפנה מעבר לראוטר תלויה באפליקציה/אתר (HTTPS, VPN וכו')

אם תרצה:

  • 🔐 הסבר על VPN מעל הראוטר
  • 🔍 בדיקת רמת אבטחה של הרשת שלך
  • 🔄 המלצה לראוטר מאובטח יותר

אשמח להמשיך 👍


בקצרה:
כן – מתחזה יכול לחקות MAC Address ו‑SSID,
אבל – הוא לא יכול “לחקות” או לנחש את מפתח ההצפנה בפועל בלי מתקפה קריפטוגרפית, ואם ההצפנה טובה – זה קשה מאוד.
ועוד חשוב: אם יש הצפנה חזקה באפליקציה עצמה – זה מגן עליך גם במקרה של רשת עוינת.

להלן ההסבר המלא, בשכבות:

1️⃣ חיקוי MAC Address – ✅ אפשרי וקל

  • MAC Address לא נועד להיות סוד
  • ניתן לשנות MAC בכל כרטיס רשת
  • תוקף יכול:
    • להאזין
    • לראות MAC
    • לשכפל אותו תוך שניות

🔴 לכן סינון לפי MAC ≠ אבטחה

2️⃣ חיקוי SSID – ✅ אפשרי וקל (Evil Twin)

  • SSID משודר “באוויר”
  • תוקף יכול להקים:
    • רשת עם אותו שם
    • אפילו בעוצמה חזקה יותר

כך נוצר Evil Twin Attack
הטלפון עלול להתחבר בלי שהמשתמש ישים לב

3️⃣ חיקוי מפתח הצפנה (WPA2) – ❌ לא באמת

כאן ההבדל הקריטי:

🔐 מה באמת קורה ב‑WPA2?

  • הסיסמה לא משודרת
  • מתבצע 4‑Way Handshake
  • המפתח הסופי:
    • נגזר מהסיסמה
      • MAC
      • Nonces אקראיים

מה תוקף כן יכול לעשות?

  • להקליט Handshake
  • לנסות ניחוש Offline
    • רק אם הסיסמה חלשה

מה הוא לא יכול?

  • ❌ “להתחברות” בלי הסיסמה
  • ❌ לשחזר את המפתח האמיתי
  • ❌ לפענח תעבורה קיימת אם ההצפנה חזקה

✅ סיסמה ארוכה ואקראית = הגנה מצוינת

4️⃣ ומה לגבי הצפנה בתוך האפליקציה? ✅✅✅

זה החלק החשוב ביותר:

אם האפליקציה משתמשת ב־

  • HTTPS
  • TLS 1.2 / 1.3
  • End‑to‑End Encryption (WhatsApp, Signal)

🔒 אז:

  • גם אם:
    • התחברת בטעות לרשת מזויפת
    • מישהו מאזין
    • יש MITM על ה‑WiFi

❗ הוא לא יכול לקרוא או לשנות את התוכן

האפליקציה:

  • מאמתת שרת
  • בודקת תעודה
  • מצפינה מקצה‑לקצה

5️⃣ מתי כן יש סיכון?

יש סיכון בעיקר אם מתקיים שילוב של:

  • ❌ Wi‑Fi פתוח / סיסמה חלשה
  • ❌ אפליקציה ישנה / HTTP
  • ❌ אין אימות תעודה (Certificate Pinning)

במצב כזה – רשת מתחזה יכולה:

  • ליירט
  • לשנות תוכן
  • לגנוב מידע

✅ סיכום חד וברור

רכיבניתן לחיקוי?
MAC Address✅ כן
SSID✅ כן
מפתח WPA2❌ לא (רק ניחוש אם סיסמה חלשה)
תוכן אפליקציה מוצפן❌ לא

אם:

  • WPA2 עם סיסמה חזקה
  • אפליקציה עם TLS / E2EE

👉 גם תוקף מתוחכם לא יוכל לקרוא את הנתונים שלך

אם תרצה, אוכל:

  • 🔍 לנתח תרחיש איום ספציפי
  • 🔐 להמליץ על הגדרות אבטחה אופטימליות
  • 🧠 להסביר איך Evil Twin נראה בפועל ואיך מזהים אותו

תגיד 👍


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

עכשיו הפירוט המדויק, בלי “אזורי אפור”:

❌ Wi‑Fi פתוח = אין הצפנת קו

ברשת אלחוטית ללא סיסמה:

  • ❌ אין הצפנה בין הטלפון לראוטר
  • ❌ כל אחד יכול:
    • להאזין
    • להקים רשת זהה (SSID)
    • לבצע Evil Twin / MITM
  • ❌ אין אימות שהראוטר “האמיתי” הוא זה שאתה מחובר אליו

Captive Portal (“דף התחברות”) לא מצפין Wi‑Fi – הוא רק דף WEB מעל רשת פתוחה.

✅ מה כן נשאר מוגן?

אם האפליקציה בנייד משתמשת ב:

  • HTTPS (TLS 1.2 / 1.3)
  • Certificate validation תקין
  • או הצפנה מקצה‑לקצה (E2EE)

🔐 אז:

  • התוכן עצמו מוגן
  • סיסמאות / הודעות / מידע לא נחשף

אבל ⚠️:

  • התוקף עדיין יכול:
    • לזהות שאתם מחוברים
    • לנתק / לעכב
    • להפנות (DNS spoofing)
    • לחקות רשת

❗ נקודה קריטית: “ללא יכולת התחזות”

זו הדרישה שלך – והיא לא אפשרית ב‑Wi‑Fi פתוח.

כדי למנוע התחזות חייבים לפחות אחד מאלה:

✅ אפשרויות תקינות (קריפטוגרפית)

פתרוןדורש סיסמה?מונע התחזות?
WPA2‑PSK✅ כן✅ כן
WPA3‑SAE✅ כן✅ כן
WPA3‑OWE (Enhanced Open)❌ לא✅ כן
802.1X (EAP‑TLS)תעודות✅✅

⚠️ חשוב: ה‑DSL‑225 שלך

ה‑D‑Link DSL‑225:

  • ✅ תומך WPA2‑PSK
  • ❌ לא תומך WPA3
  • ❌ לא תומך OWE
  • ❌ אין אימות תעודות ב‑Wi‑Fi

➡️ המשמעות: אין שום מצב שבו הרשת פתוחה וה‑Wi‑Fi עצמו עדיין מאובטח

✅ אז איך כן להשיג את מה שאתה רוצה (בפועל)?

אם הדרישה היא:

“משתמשים לא יקלידו סיסמה,
אבל תהיה הצפנה ואי‑התחזות”

✅ פתרונות מעשיים:

  1. WPA2 עם סיסמה אחת משותפת

    • המשתמש כן מקליד פעם אחת
    • הכי פשוט
    • הכי בטוח עם הציוד שלך

  2. אפליקציה + VPN אוטומטי

    • ה‑Wi‑Fi פתוח
    • האפליקציה מקימה VPN מיד
    • מגן על תוכן, לא מונע Evil Twin

  3. שדרוג ראוטר ל‑WPA3‑OWE

    • Wi‑Fi פתוח
    • הצפנה פר‑משתמש
    • מניעת MITM
    • ✅ זה הפתרון היחיד שעונה לדרישה שלך באמת

🔍 סיכום חד וברור

❌ רשת פתוחה = אין אבטחת Wi‑Fi ואין מניעת התחזות
✅ הצפנה בתוך האפליקציה מגינה על התוכן בלבד
✅ כדי למנוע התחזות חייבים WPA2/3 או OWE
❌ DSL‑225 לא תומך ב‑OWE

אם תרצה:

  • 💡 להציע ארכיטקטורה נכונה למוצר/מערכת
  • 🔄 להמליץ על ראוטר מתאים (OWE / WPA3)
  • 🧠 לנתח Threat Model של מקרה שימוש ספציפי

רק תגיד 👍

ב- אין תגובות:

יום שלישי, 21 באפריל 2026

חיפוש פתרון אבטחה לשידור מיקום ע"י WIFI

 עכשיו הבנתי אותך לגמרי ✅

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

בוא נעשה סדר מדויק לפי מה שאתה בונה, בלי פילוסופיה ובלי “אבל גוגל”.

✅ מה המערכת שלך עושה (בדיוק)

אתה בונה מערכת שבה:

  • 📡 ראוטרים / משדרים משדרים:
    • MAC
    • SSID
  • 📱 הטלפון:
    • קולט
    • ומתרגם לפי טבלה שאתה בנית:
MAC / SSID  →  מיקום
AABBCCDD    →  תחנה X
11223344    →  תחנה Y

זו עובדה, וזה עובד.

🚨 מה הפחד שלך – ומדוע הוא נכון

אתה מפחד מ־2 תרחישים:

1️⃣ מישהו ישדר את אותו MAC שלך

(Cloning / Spoofing)

2️⃣ מישהו ישדר:

  • MAC ששייך למיקום אחר בטבלה
  • אבל פיזית בתחנה שלך → ויבלבל את הטלפונים

✅ שני התרחישים אפשריים לחלוטין טכנית
✅ וזה איום ידוע בעולם Wi‑Fi / BLE / RFID

🎯 בוא נקרא לילד בשמו

זה נקרא:

Identity Spoofing / Location Spoofing

והבעיה היא:

❗ MAC ו‑SSID אינם זהות מאובטחת
הם רק מזהה טכני שניתן לזיוף.

❌ מה לא פותר את הבעיה (חשוב!)

  • ❌ הצפנה של WPA
  • ❌ הצפנה של האפליקציה
  • ❌ “להסתיר SSID”
  • ❌ לסמוך רק על MAC

כל אלה לא מונעים מאדם לשדר MAC מזויף

✅ אז מה כן פותר? (פתרון נכון, מדורג)

✅ עיקרון מפתח (תשמור אותו):

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

צריך גורם אימות נוסף.

✅ פתרון 1 – חתימה קריפטוגרפית (הנכון ביותר)

במקום:

MAC → מיקום

עוברים ל:

MAC + חתימה → מיקום

איך זה עובד – פשוט:

  • לכל ראוטר יש:
    • מפתח סודי ייחודי (KEY)
  • הוא משדר:
    • MAC
    • Timestamp / Counter
    • Signature = HMAC(KEY, data)

📱 הטלפון:

  • יודע את המפתח הציבורי / הסודי
  • מאמת:
    • ❌ משדר מזויף → אין חתימה נכונה
    • ✅ משדר אמיתי → מתקבל

✅ גם אם מישהו ישדר את אותו MAC
❌ הוא לא יוכל לזייף את החתימה

✅ פתרון 2 – קוד מתחלף (Rolling ID)

בדומה ל־Car Key / BLE Beacons מתקדמים:

  • הראוטר לא משדר ID קבוע
  • אלא:
ID(t) = AES(KEY, time_slot)

📱 הטלפון:

  • מחשב אותו ID בעצמו
  • אם זה תואם → מיקום חוקי

✅ זיוף הופך לכמעט בלתי אפשרי
✅ אין תלות ב‑MAC אפילו

✅ פתרון 3 – אימות הקשר פיזי (Location Consistency)

חיזוק חשוב:

הטלפון בודק:

  • RSSI
  • רציפות זמן
  • תנועה

לדוגמה:

  • MAC של “תחנה בירושלים”
  • אבל:
    • מופיע רק 2 שניות
    • RSSI לא הגיוני → נפסל

✅ מסנן התקפות “רעש”

✅ פתרון 4 – White List + Rate Limit

פשוט אבל חשוב:

  • מזהה מופיע:
    • יותר מדי
    • או בכמה מיקומים → נחסם

🔴 מה קורה אם לא תעשה כלום?

בוא נהיה ישירים:

  • כל אדם עם:
    • Laptop
    • ESP32
    • SDR
  • יכול:
    • לשדר MAC שאתה בחרת
    • לשדר “תחנה אחרת”
    • לשבש מיקום

📌 זו חולשה מובנית בלי שכבת אימות.

✅ מסקנה חד‑משמעית

החשש שלך מוצדק ב‑100%
מערכת שממפה מיקום לפי MAC/SSID בלבד
פגיעה לזיוף

אבל:

✅ הפתרון לא מסובך
✅ והוא סטנדרטי בעולם מערכות מיקום רציניות

✅ אם תרצה – השלב הבא

אני יכול:

  • לבנות לך ארכיטקטורה מלאה:
    • איזה נתון משדרים
    • איזה מפתח
    • איך הטלפון מאמת
  • להתאים פתרון:
    • Wi‑Fi
    • BLE
    • או שילוב
  • לכתוב לך פסאודו‑פרוטוקול ברור

רק תגיד: 👉 “תן לי פתרון מינימלי”
או
👉 “אני רוצה פתרון צבאי / חזק”


כן — אפשר, ואתה חושב בכיוון הנכון ✅
אבל צריך לדייק איך עושים את זה נכון, ומה זה כן פותר ומה עדיין לא ב־100%.

אני אענה קצר‑ברור, ואז אפרט טכני.

✅ תשובה קצרה וישירה

כן, אתה יכול להתקין באפליקציה של הנוסעים KEY מסונכרן עם הראוטרים,
וכך למנוע ממישהו זר לזייף מיקום או לשדר MAC “על שמך”.

✅ זו גישה מקובלת
✅ זה פותר את בעיית הזיוף שציינת
⚠️ בתנאי שעושים את זה נכון

🔐 העיקרון (בלי מושגים כבדים)

במקום לסמוך על:

MAC / SSID בלבד

אתה עובר לסמוך על:

MAC + הוכחת ידיעה של סוד (KEY)

מי שאין לו את ה‑KEY → לא מתקבל, גם אם שידר MAC זהה.

🧩 איך זה עובד בפועל (שלב‑שלב)

🟥 בלי KEY (המצב המסוכן)

תוקף יכול:

  • לשדר MAC/SSID שלך
  • להופיע “כמו תחנה אחרת”
  • להטעות טלפונים

✅ עם KEY מסונכרן (הפתרון)

מה יש בראוטר:

  • DEVICE_ID (יכול להיות MAC או מזהה לוגי)
  • SECRET_KEY (סודי, לא משודר)

מה משודר באוויר:

לא רק MAC, אלא למשל:

DEVICE_ID
COUNTER או TIME
SIGNATURE

כאשר:

SIGNATURE = HMAC(SECRET_KEY, DEVICE_ID + TIME)

מה יש באפליקציה של הנוסע:

  • עותק של SECRET_KEY
  • או מפתח לאימות (תלוי מימוש)

📱 האפליקציה:

  • מחשבת מה החתימה התקינה
  • משווה למה שנקלט
  • ✅ תואם → מיקום חוקי
  • ❌ לא תואם → מתעלם

🔴 למה תוקף לא יצליח?

גם אם הוא:

  • 📡 משדר MAC שלך
  • 📡 משדר SSID שלך
  • 📡 מעתיק חבילות

❌ בלי ה‑KEY הוא לא יכול לייצר חתימה נכונה

וזה:

  • ❌ לא ניתן לניחוש
  • ❌ לא ניתן לשכפול פשוט
  • ✅ סטנדרט אבטחתי

✅ האם מותר לשים KEY בתוך אפליקציה?

כן — אבל עם זהירות.

✅ זה מקובל:

  • תחבורה ציבורית
  • BLE Beacons
  • NFC Ticketing
  • Car Keys
  • Access Control

⚠️ הסיכון:

  • אפליקציה יכולה לעבור:
    • Reverse Engineering
    • Root
    • Memory Dump

✅ לכן עושים אחד מאלה (או שילוב):

🔐 שיטות בטוחות יותר (בסדר עולה)

1️⃣ KEY אחיד לכל האפליקציות (הכי פשוט)

  • ✅ קל למימוש
  • ❌ אם האפליקציה נפרצה → כולם בסיכון

✔ מתאים לפיילוט / POC

2️⃣ KEY שונה לכל גרסת אפליקציה

  • אפליקציה v1 → KEY A
  • אפליקציה v2 → KEY B

✅ אפשר לבטל גרסאות ישנות

3️⃣ Rolling Key / Time‑based

  • ה‑KEY משתנה כל:
    • דקה
    • 5 דקות
  • לפי אלגוריתם ידוע בלבד

✅ גם אם נחשף → זמני מאוד

4️⃣ מפתח לא ישירות בקוד (מומלץ)

  • KEY מוטמע:
    • ב‑Android Keystore
    • Split Keys (חלק בקוד, חלק מחושב)
  • קשה מאוד לחילוץ

✅ זה כבר פתרון רציני

🧠 נקודה חשובה (מאוד)

אתה לא צריך להסתיר את ה‑MAC
אתה צריך להבטיח שרק משדר “אמיתי” יוכר

וזה בדיוק מה שה‑KEY עושה.

✅ מתי התוקף עדיין בעייתי?

רק אם:

  • יש לו:
    • אפליקציה מפורקת
    • KEY אמיתי
    • ציוד רציני
  • ואז:
    • הוא כמעט “פנימי”

📌 זה כבר איום High‑End, לא נוסע מזדמן.

✅ סיכום חד וברור

  • ✔ כן — מותר ואפשר לשים KEY באפליקציה
  • ✔ כן — זה פותר זיוף MAC/מיקום
  • ✔ לא — תוקף רגיל לא יצליח
  • ⚠️ צריך לממש נכון (לא מחרוזת בקוד וזהו)

אם תרצה, אני יכול:

  • להציע לך פרוטוקול מינימלי (קל וזול)
  • או ארכיטקטורה חזקה מאוד
  • או לעזור לך לבחור:
    • Wi‑Fi מול BLE
    • זמן מול אבטחה

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

מצוין. אני אסביר לך מהיסוד, לאט, עם דוגמאות, בלי לקפוץ שלבים.
בסוף ההסבר אתה אמור להבין בדיוק:

  • מה זה KEY
  • מה זה SIGNATURE / חתימה
  • מה זה RSSI
  • איך הם עובדים יחד
  • ואיך מיישמים בפועל במערכת שלך (ראוטר + אפליקציה)

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

חלק א׳ – התמונה הגדולה (לפני פרטים)

הבעיה שאתה פותר היא:

איך טלפון ידע שמשדר מסוים הוא “אמיתי”,
ולא מישהו שמתחזה לו

ולשם כך אתה עושה: 🔒 אימות זהות – לא רק זיהוי.

חלק ב׳ – מושג בסיסי 1: KEY (מפתח)

מה זה KEY?

KEY הוא סוד משותף
משהו ש־✅ רק המערכת שלך יודעת, ❌ והציבור לא יודע.

דוגמא פשוטה:

KEY = "X9a#72Lm!"

אבל:

  • ❗ KEY הוא לא:
    • MAC
    • SSID
    • סיסמת Wi‑Fi
  • ✅ KEY הוא משהו פנימי, שלא משודר כמו שהוא.

למה צריך KEY?

כי:

  • MAC = כל אחד יכול לזייף
  • SSID = כל אחד יכול לזייף

אבל:

אי‑אפשר לזייף הוכחת ידע של סוד,
אם אתה לא יודע את הסוד

זה הבסיס של קריפטוגרפיה.

מי מחזיק את ה‑KEY?

במקרה שלך:

✅ הראוטר / המשדר
✅ האפליקציה בטלפון הנוסע
❌ אף אחד אחר

חלק ג׳ – מושג בסיסי 2: SIGNATURE (חתימה)

מה זה “חתימה”?

חתימה היא:

מחרוזת מחושבת, שמוכיחה: “אני יודע את ה‑KEY”

בלי לחשוף את ה‑KEY עצמו.

איך יוצרים חתימה? (רעיון, לא קוד)

יש:

  • KEY (סודי)
  • DATA (מידע גלוי)

מפעילים:

SIGNATURE = פונקציה קריפטוגרפית(KEY + DATA)

הפונקציה הנפוצה:

  • HMAC‑SHA256 (סטנדרט תעשייתי)

דוגמה מוחשית

מידע שהראוטר רוצה לשדר:

DEVICE_ID = STATION_12
TIME      = 10:03:21

ה‑KEY הסודי:

KEY = AbC9!Qr@7

הראוטר מחשב:

SIGNATURE = HMAC(KEY, "STATION_12|10:03:21")

ומה משודר באוויר?

✅ זה:

STATION_12
10:03:21
4F9B8C2A...

❌ לא זה:

AbC9!Qr@7   ← אף פעם לא!

מה עושה האפליקציה?

האפליקציה:

  1. קולטת את הנתונים
  2. מחשבת בעצמה:
HMAC(KEY, "STATION_12|10:03:21")

3. משווה לתוצאה שהגיעה

  • ✅ זהה → משדר אמיתי
  • ❌ שונה → זיוף / מתעלמים

למה תוקף לא יכול לזייף?

כי:

  • הוא רואה את ה‑DATA
  • אבל אין לו את ה‑KEY
  • בלי KEY → לא יוצאת חתימה נכונה

גם אם:

  • הוא משדר MAC זהה
  • הוא משדר SSID זהה

חלק ד׳ – מושג בסיסי 3: RSSI

מה זה RSSI?

RSSI = עוצמת הקליטה

כלומר:

כמה חזק האות ששמעתי

נמדד ב‑dBm (מספר שלילי):

  • ‎‑30 dBm → ממש קרוב
  • ‎‑60 dBm → סביר
  • ‎‑90 dBm → רחוק מאוד / גבולי

למה RSSI חשוב לביטחון?

RSSI לא מזהה זהות, אבל הוא: ✅ מזהה היגיון פיזי

דוגמאות סינון עם RSSI

זיוף קלאסי:

  • משדר “תחנה A”
  • אבל:
    • RSSI חלש מדי
    • או קופץ פתאום

→ האפליקציה אומרת:

זה לא הגיוני → מתעלם

בדיקה נפוצה:

  • תחנה אמיתית:
    • RSSI יציב
    • יורד/עולה בהגיון לפי תנועה
  • תוקף:
    • קפיצות
    • הופעות קצרות

חשוב לדעת:

❗ RSSI לא מספיק לבד,
אבל הוא שכבת הגנה משלימה מצוינת.

חלק ה׳ – איך הכל עובד ביחד (החלק החשוב)

במערכת שלך, טלפון מקבל:

  1. ✅ MAC / ID
  2. ✅ DATA (זמן / מונה)
  3. ✅ SIGNATURE
  4. ✅ RSSI

והוא בודק:

בדיקהמטרה
חתימהמי אתה
זמן / מונהנגד Re‑play
RSSIהאם פיזית הגיוני
רציפותשלא קפצת ממקום למקום

רק אם הכול עובר → מיקום מתקבל.

חלק ו׳ – איך מיישמים KEY בפועל (חשוב)

אפשרות 1 – הכי פשוטה (POC)

  • KEY אחד לכל המערכת
  • מוטמע באפליקציה
  • מוטמע בראוטר

✅ פשוט
❌ אם נפרץ – כולם בסיכון

אפשרות 2 – KEY ייחודי לכל תחנה (מומלץ)

KEY_station_12
KEY_station_13

האפליקציה:

  • מכירה את כולם
  • או טוענת קובץ מעודכן

✅ פריצה לתחנה אחת ≠ כולם

אפשרות 3 – KEY מתחלף בזמן (חזק)

ה‑KEY עצמו:

  • מתעדכן כל X דקות
  • לפי נוסחה ידועה

גם אם דלף: → תקף לזמן קצר בלבד

איפה לשים את ה‑KEY באפליקציה?

❌ לא כמחרוזת גלויה בקוד
✅ ב‑Android:

  • Android Keystore
  • או פיצול KEY:
    • חצי בקוד
    • חצי מחושב בזמן ריצה

חלק ז׳ – סיכום קצר וברור

  • KEY = סוד משותף
  • SIGNATURE = הוכחה שאתה יודע את הסוד
  • RSSI = בדיקת היגיון פיזי
  • שילוב של כולם = מערכת עמידה לזיוף

בלי KEY – המערכת שבירה
עם KEY + חתימה – התוקף בחוץ

אם תרצה בהמשך:

  • אני יכול לצייר לך זרימת הודעות
  • או לכתוב פסאודו‑פרוטוקול
  • או להמליץ בדיוק:
    • גודל KEY
    • אלגוריתם
    • תזמון

תגיד לאן אתה רוצה להעמיק.


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

✅ KEY שונה לכל תחנה
✅ KEY מתחלף בזמן
✅ גם אם פורצים לאפליקציה – לא ניתן לחלץ את ה‑KEY

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

🧠 עיקרון־על (חשוב להבין לפני הכל)

❗ אסור שה‑KEY עצמו יהיה קיים באפליקציה בצורה שניתנת לקריאה

במקום זאת:

  • האפליקציה מסוגלת לאמת חתימה
  • אבל לא יודעת לייצר אותה לבד

זה ההבדל בין:

  • 🔓 “יש לי סוד”
  • 🔐 “אני יודע לזהות מי שיש לו סוד”

✅ הפתרון הנכון: Public Verification + Rotating Secrets

הארכיטקטורה הנכונה שלך מורכבת מ־4 שכבות:

[ תחנה ]
  ├─ Root Secret (לא יוצא מהחומרה)
  ├─ Key Generator (מבוסס זמן)
  ├─ Signer (יוצר חתימה)
  └─ Wi‑Fi Broadcast

[ אפליקציה ]
  ├─ Public Verifier בלבד
  ├─ Time Sync
  ├─ RSSI Logic
  └─ Anti‑Replay

1️⃣ Root KEY לכל תחנה (סודי לנצח)

לכל תחנה יש Root Key ייחודי, למשל:

ROOT_KEY_station_17 = 256bit random

מאפיינים:

  • ✅ ייחודי לכל תחנה
  • ✅ לא משתנה
  • ❌ לעולם לא נשלח
  • ❌ לא קיים באפליקציה

איפה הוא נמצא?

  • בראוטר / בקר
  • עדיף:
    • Secure Element
    • או לפחות Flash מוגן

2️⃣ KEY מתחלף בזמן (Session Key)

התחנה לא משדרת לעולם את ה‑Root Key.
היא רק מייצרת ממנו מפתח זמני על בסיס זמן.

נוסחה עקרונית:

SESSION_KEY = HMAC(
    ROOT_KEY,
    TimeSlot
)

דוגמא:

TimeSlot = floor(UnixTime / 60)

⬅️ כלומר: מפתח חדש כל דקה

תוצאה:

  • גם אם מישהו מצליח לגלות SESSION_KEY
    • הוא תקף דקה אחת בלבד
    • ולא חושף את ROOT_KEY

3️⃣ חתימה דיגיטלית (Signature)

התחנה משדרת חתימה, לא KEY.

הנתונים שנחתמים:

Station_ID
TimeSlot
Optional: Channel / Nonce

החתימה:

SIGNATURE = HMAC(SESSION_KEY, DATA)

ומה משודר באוויר:

Station_ID
TimeSlot
SIGNATURE

🔒 ה־KEY עצמו לא משודר, אף פעם

4️⃣ מה יש באפליקציה? (החלק הקריטי)

האפליקציה לא מכילה KEYS, אלא:

✅ רק חומר אימות (Verifier):

אפשרות A – מפתח ציבורי (הכי בטוח)

  • התחנה חותמת עם Private Key
  • האפליקציה מכירה רק Public Key

אפשרות B – נגזרת חד־כיוונית (קל יותר)

  • האפליקציה מכירה: VERIFY_KEY = HASH(ROOT_KEY)
  • אך לא את ROOT_KEY

📌 בשני המקרים:

גם אם פורצים לאפליקציה –
אי‑אפשר לגזור ממנה KEY שימושי לשידור

🔐 למה תוקף לא יכול לזייף (אפילו עם APK מפורק)

תקיפה 1: שידור MAC זהה

❌ חתימה לא תואמת

תקיפה 2: שידור Station אחרת

❌ TimeSlot לא תואם

תקיפה 3: Replay

❌ TimeSlot ישן → נפסל

תקיפה 4: Reverse Engineering APK

  • לא קיים ROOT_KEY
  • לא קיים SESSION_KEY ✅ אין מה לגנוב

📡 תפקיד ה‑RSSI (שכבת הגנה משלימה)

RSSI לא מזהה זהות – הוא מזהה פיזיקה.

האפליקציה בודקת:

  • רציפות RSSI
  • קפיצות לא הגיוניות
  • הופעה/היעלמות

כלומר גם אם:

  • החתימה נכונה
  • אבל האות מתנהג “לא טבעי” → מתעלמים

זה חשוב נגד:

  • Repeater
  • SDR מרוחק
  • התקפות חיזוק אות

🧩 איך זה נראה בפועל – זרימה מלאה

  1. תחנה:

    • מחשבת TimeSlot
    • מייצרת SESSION_KEY
    • חותמת
    • משדרת

  2. טלפון:

    • קולט
    • מחשב TimeSlot מקומי
    • מאמת חתימה
    • בודק RSSI
    • ✅ מאשר מיקום

✅ עמידה מלאה בדרישות שלך

דרישהמצב
KEY שונה לכל תחנה✅
KEY מתחלף בזמן✅
KEY לא קיים באפליקציה✅
זיוף MAC/SSID❌
Replay❌
Reverse Engineering❌ (ברמה מעשית)

🟢 רמות מימוש (לבחירתך)

POC מהיר

  • HMAC
  • TimeSlot = 60 שניות

Production

  • Secure Element
  • TimeSlot = 10–30 שניות
  • Anti‑Replay buffer

High Security

  • חתימה אסימטרית
  • Multiple RSSI checks
  • Key revocation

אם תרצה בשלב הבא:

  • אני יכול לכתוב לך פסאודו‑פרוטוקול מלא
  • או להמליץ בין סימטרי / אסימטרי
  • או לשרטט Threat Model רשמי

רק תגיד:
➡️ “POC”, “Production” או “High‑Security”



הסבר כללי ופתרון מעשי 


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

1️⃣ הגדרת הבעיה (Problem Statement)

יש מערכת שבה:

  • ראוטרים/משדרים משדרים Wi‑Fi
  • טלפונים של נוסעים קולטים את השידור
  • בטלפון קיימת טבלת המרה ייעודית: מזהה משדר (MAC / ID) → מיקום פיזי (תחנה)

האיומים:

  1. תוקף משדר MAC זהה לראוטר חוקי (Cloning)
  2. תוקף משדר MAC של תחנה אחרת במיקום שגוי (Location Spoofing)
  3. תוקף מקליט שידור תקין ומשדר אותו מחדש (Replay)
  4. גם אם האפליקציה נפרצת –
    אסור שתיווצר יכולת לשדר תחנה מזויפת

2️⃣ עיקרון על (Principle)

לעולם לא סומכים על MAC / SSID בלבד
הם מזהים – לא זהות מאובטחת.

הפתרון חייב:

  • לזהות תחנה אמיתית
  • למנוע זיוף גם עם ציוד רגיל
  • להיות חסין גם כשאפליקציה נפרצת

3️⃣ הפתרון האידאלי (High‑Level Architecture)

הפתרון מבוסס על 4 שכבות אבטחה משלימות:

┌─────────────┐
│  Root Key   │   ← סודי, בתחנה בלבד
└─────┬───────┘
      ↓
┌─────────────┐
│ Session Key │   ← מתחלף בזמן
└─────┬───────┘
      ↓
┌─────────────┐
│ Signature   │   ← משודרת באוויר
└─────┬───────┘
      ↓
┌─────────────┐
│ App Verify  │   ← אימות + RSSI
└─────────────┘

4️⃣ תת‑מערכת 1: המפתחות (KEYs)

🔐 Root Key (לכל תחנה)

  • מפתח סודי ייחודי לכל תחנה
  • אורך: 256 ביט
  • נוצר אקראית בעת התקנה

מאפיינים:

  • ✅ לא משתנה
  • ✅ לא משודר
  • ✅ לא קיים באפליקציה
  • ✅ דליפה מאפליקציה ≠ סיכון

🔄 Session Key (מתחלף בזמן)

בכל תחנה:

SessionKey = HMAC(RootKey, TimeSlot)

מאפיינים:

  • משתנה כל הזמן
  • גם אם נחשף → תקף לזמן קצר
  • אי‑אפשר לגזור ממנו Root Key

5️⃣ תת‑מערכת 2: חלון הזמן (Time Slot)

❌ למה לא 10ms “אמיתי”?

  • Wi‑Fi לא דטרמיניסטי
  • טלפונים סובלים מדיליי Scheduler
  • גורם לפסילות שווא

✅ הפתרון הנכון: Time Slot קריפטוגרפי

הגדרה:

  • Crypto Time Slot:
    10ms (דרישתך – מתקיימת)

  • Broadcast Interval (השידור בפועל):
    100ms

חישוב:

CryptoSlot = floor(UnixTime / 10ms)

מה משודר:

  • לא 10 חתימות בשנייה
  • אלא חתימה אחת כל 100ms
  • שכוללת בתוכה את ה‑CryptoSlot

✅ חלון זמן מומלץ באפליקציה

האפליקציה תאמת:

CryptoSlot_now ± 3

כלומר:

  • חלון של ±30ms
  • מספיק לספוג:
    • סטיית שעון
    • דיליי קל
  • קטן מספיק כדי:
    • לחסום Replay

📌 זה האיזון האופטימלי

6️⃣ תת‑מערכת 3: החתימה (Signature)

✅ סוג חתימה מומלץ לראוטר

🔐 HMAC‑SHA256 ✅ (מומלץ)

למה:

  • מהיר
  • מוכח
  • נתמך בכל Embedded / Router
  • לא דורש ספריות כבדות

אופן החתימה:

Signature = HMAC(
   SessionKey,
   StationID + CryptoSlot
)

מה משודר באוויר:

StationID
CryptoSlot
Signature

❌ לא משודר:

  • Root Key
  • Session Key

למה לא חתימה אסימטרית?

  • כבד יותר
  • גדול יותר באוויר
  • לא נדרש לאיום שלך

HMAC הוא ה‑Sweet Spot.

7️⃣ תת‑מערכת 4: האפליקציה (טלפון הנוסע)

מה יש באפליקציה:

  • קוד אימות בלבד
  • לוגיקת זמן
  • RSSI

מה אין באפליקציה:

  • Root Key
  • Session Key
  • יכולת לחתום

📌 גם אם:

  • פורצים
  • מפרקים APK

❌ לא ניתן לשדר תחנה מזויפת

8️⃣ תת‑מערכת 5: RSSI (בדיקת היגיון פיזי)

RSSI משמש שכבת אבטחה משלימה:

האפליקציה בודקת:

  • רציפות עוצמה
  • קפיצות חשודות
  • הופעה/היעלמות חריגה

כלומר:

  • חתימה תקינה ✅
  • אבל RSSI לא הגיוני ❌
    → נפסל

זה חוסם:

  • Repeater
  • SDR מרוחק
  • Injection מרוחק

9️⃣ סיכום – למה זה הפתרון האידאלי

איוםנחסם
זיוף MAC✅
זיוף תחנה✅
Replay✅
פריצת אפליקציה✅
שידור מתחזה✅
עבודה בזמן אמת✅

📌 החלטות סופיות (One‑Page)

  • KEY לכל תחנה: Root Key ייחודי
  • KEY מתחלף: Session Key לפי Time Slot
  • Time Slot:
    • קריפטוגרפי: 10ms
    • שידור בפועל: 100ms
    • חלון אימות: ±3 slots
  • חתימה: HMAC‑SHA256
  • RSSI: סינון רציפות


ב- אין תגובות:

יום שלישי, 14 באפריל 2026

סיכום מסמך – TEMS™ Sense 8.2

 להלן סיכום מנהלים ברור ומובנה של מסמך

TEMS™ Sense 8.2 – Technical Product Description, כפי שעולה ישירות מהמסמך שצירפת.
הסיכום כתוב כך שאפשר להבין מה זה המוצר, מה הוא עושה, למי הוא מתאים, ומה המגבלות שלו – בלי להיכנס לפרטים מיותרים. [TEMS Sense...escription | PDF]

📘 סיכום מסמך – TEMS™ Sense 8.2

1️⃣ מה זה TEMS Sense?

TEMS Sense הוא פתרון Carrier‑Grade לניטור קצה‑לקצה (End‑to‑End) של איכות רשת סלולרית ושירותים, המבוסס על:

  • טלפונים חכמים מסחריים (Android)
  • הרצה אוטונומית 24/7
  • ניהול מרכזי מלא

המוצר מיועד לאפשר למפעילים סלולריים לראות את הרשת מנקודת מבט של משתמש אמיתי, כולל Voice, Data, Video, ו‑OTT, בלי צורך בשינויים בצד הרשת. [TEMS Sense...escription | PDF]

2️⃣ הארכיטקטורה של המערכת

רכיבי ליבה:

  1. TEMS Sense Probe

    • סמארטפון מסחרי
    • מותקן בתוך מארז ייעודי (TEMS Remote)
    • רץ אוטונומית (stationary או נייד)

  2. TEMS Director (Fleet)

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

  3. Script Designer

    • בניית תרחישי בדיקה (Drag & Drop)
    • בדיקות קול, דאטה, וידאו, OTT

  4. Backend Data Store

    • אחסון מרכזי של מדידות ו‑KPIs
    • מיועד לסקייל של מאות probes

[TEMS Sense...escription | PDF]

3️⃣ עקרון העבודה (Concept)

  • המערכת מחקה התנהגות משתמש
  • כל בדיקה רצה על הטלפון עצמו (On‑device)
  • אין יירוט, אין Core Network, אין שינוי בקונפיגורציית הרשת
  • כל הנתונים נאספים ונשלחים ל‑TEMS Director לניתוח ודיווח

✅ המדידות מייצגות QoE אמיתי
❌ לא ניתוח ספקטרום גולמי (לא SDR)

[TEMS Sense...escription | PDF]

4️⃣ יכולות עיקריות

📡 רדיו וניידות

  • RAT: GSM / UMTS / LTE / 5G NR / Wi‑Fi
  • RSRP / RSSI / Cell ID / PCI
  • Handover, Drops, Attach failures
  • GPS מלא

📞 קול (Voice)

  • CS, VoLTE, VoWiFi, VoNR
  • מדידת איכות קול:
    • POLQA (ITU‑T P.863)
    • sQLEAR (Machine Learning)
  • MOS Score אמיתי

🌐 דאטה ושירותים

  • HTTP / FTP / iPerf / Ping
  • Throughput, Latency, Failures
  • YouTube Streaming + PEVQ‑S
  • OTT App Testing (Facebook, Instagram, Netflix וכו’)
  • SMS, Email, Messaging

📦 IP Capture

  • הקלטת PCAP
  • סנכרון זמן עם RF ו‑KPIs
  • ניתוח ב‑Wireshark

[TEMS Sense...escription | PDF]

5️⃣ אוטומציה וניהול

סקריפטים:

  • רציפים או מקביליים
  • מבוססי Triggers (זמן, אירוע)
  • Guard Times אוטומטיים

ניהול מרכזי:

  • Remote control מלא של הטלפון
  • Live view של המסך
  • עדכוני תוכנה OTA
  • ניהול SIMs
  • ניטור “בריאות” הפרוב

עמידות:

  • Watchdog חומרתי
  • שחזור אוטומטי
  • פעולה ללא מגע אדם 24/7

[TEMS Sense...escription | PDF]

6️⃣ דשבורדים ודיווח

  • Device Overview Dashboard
  • Event & Map View
  • Reporting KPI dashboards
  • Analytics מתקדמים (בתוספת רישוי)

מיועד ל:

  • RF Engineers
  • NOC
  • Planning
  • Management
  • Customer Care

[TEMS Sense...escription | PDF]

7️⃣ חומרה – TEMS Remote Probe

  • מארז חזק, נעול
  • PoE+
  • בקרת טמפרטורה
  • Ignition Control (רכב)
  • SIM Switch
  • GPS חיצוני (אופציונלי)

⚠️ אין חיבור אנטנת RF חיצונית
⚠️ אין יכולות SDR

[TEMS Sense...escription | PDF]

8️⃣ ייעוד ושימושים עיקריים

  • ✅ End‑to‑End Network Monitoring
  • ✅ Regression Testing לפני/אחרי שינויים
  • ✅ Roaming Testing (Inbound / Outbound)
  • ✅ SLA Monitoring
  • ✅ Benchmarking בין מפעילים

[TEMS Sense...escription | PDF]

9️⃣ מה TEMS Sense כן ומה לא

✅ כן

  • QoE / QoS אמיתי
  • ניהול גדול של פרובים
  • פתרון מסחרי יציב
  • אוטומציה מלאה

❌ לא

  • לא SDR
  • לא ניתוח ספקטרום
  • לא זיהוי הפרעות RF פיזיקליות
  • לא שימוש מחקרי פתוח

🔚 סיכום חד‑משמעי

TEMS Sense הוא פתרון תפעולי‑מסחרי לניטור איכות רשת מנקודת מבט משתמש, ברמה של מפעיל סלולר.

הוא לא כלי חקירה הנדסי של שכבת RF
והוא לא מחליף SDR
אלא משלים אותו בארגונים גדולים

אם תרצה, בשלב הבא אוכל:

  • להשוות TEMS Sense מול פתרון מבוסס טלפונים + SDR
  • לבנות טבלת ROI
  • להגדיר מתי כן / לא להצדיק TEMS
  • או לנסח One‑Pager החלטה להנהלה

רק תגיד.

ב- אין תגובות:
תוויות:

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

 אבי, השאלה שלך מצוינת – אבל חשוב לעשות הפרדה ברורה בין ניטור חוקי (מדידות RF / איכות רשת) לבין יירוט או מעקב אסור. אענה בצורה מקצועית, “תעשייתית”, בלי להיכנס לשיטות בעייתיות.

קודם כל – מסגרת חוקית (מאוד חשוב)

בישראל:

  • ניטור RF פסיבי (מדידת תדרים, עוצמות, איכות קליטה, KPI רדיו) – ✔️ מותר
  • איסוף מידע מהרשת הסלולרית עצמה (Core, IMSI, תוכן, מיקום מנוי) – ❌ אסור ללא רישוי ממשלתי מפורש
  • יירוט, דמודולציה, זיהוי משתמשים, התחזות לתא – ❌ עבירה פלילית (Wiretap Law, Communications Law)

לכן כל המוצרים החוקיים עובדים באחת משתי גישות:

  1. 📡 מדידת אוויר (Over‑The‑Air, RF only)
  2. 📱 מדידה מתוך UE לגיטימי (טלפון / מודם מורשה)

✅ מוצרים קיימים לניטור רשת סלולרית (חוקי)

1️⃣ מערכות מדידה מקצועיות (Telecom Drive Test / Monitoring)

🟢 Keysight / Anite NEMO (סטנדרט תעשייתי)

  • מה הם עושים
    • ניטור LTE / 5G / NR
    • RSRP, RSRQ, SINR, PCI, EARFCN, QoS
    • Drop calls, throughput, latency
  • איך עובדים
    • משתמשים בטלפונים מסחריים “נעולים” למדידה
    • בלי יירוט, בלי התחזות
  • חיבור לרשת
    ✔ כן, כ-UE רגיל עם SIM

טווח מחיר

🟢 Rohde & Schwarz (Network Testing)

  • Spectrum monitoring
  • LTE/5G demodulation (metrics בלבד)
  • שילוב עם סורקי RF

מחיר:

  • Handheld: 20,000–50,000$
  • Benchtop מתקדם: 80,000–250,000$ [keysight.com]

🟢 PCTEL / VIAVI

  • סורקי תאים
  • ניטור רציף לנקודות קבועות (גגות, תחנות)

מחיר:

2️⃣ סורקי RF / Spectrum Analyzer (ללא התחברות לרשת)

✅ מה הם כן עושים:

  • זיהוי תדרים פעילים
  • מדידת עוצמה, רוחב ערוץ
  • זיהוי הפרעות / עומסים

❌ מה הם לא:

  • לא יודעים IMSI
  • לא יודעים משתמשים
  • לא יודעים תוכן

דוגמאות:

✅ האם מוצר כזה יכול להתחבר לרשת כדי “לאסוף נתונים”?

✔ כן – רק כ־מנוי רגיל
לדוגמה:

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

❌ לא:

  • Core network
  • Signaling פנימי
  • נתוני מנויים אחרים

✅ האם טלפון נייד רגיל יכול לשמש כסנסור?

כן – ובאופן מפתיע, די חזק

📱 טלפון כסנסור רשת:

אפשר לאסוף:

  • Cell ID / PCI
  • Band / EARFCN
  • RSRP / RSRQ / SINR
  • Handover events
  • Throughput / Latency

באמצעות:

  • אפליקציות מדידה (או SDK)
  • Android diagnostic APIs
  • Qualcomm field test / Samsung Shannon

❗ מגבלות:

  • אין Raw I/Q
  • אין גישה ל-L1/L2 מלא
  • דיוק נמוך מסנסור RF ייעודי

📌 זה בדיוק מה שעושה NEMO Handy – אפליקציה על טלפון רגיל [keysight.zinfi.net]

✅ סיכום השוואתי קצר

פתרוןחוקירמת עומקמחיר
טלפון + אפליקציה✔בינוניתנמוך
NEMO / VIAVI✔גבוהה$$
Spectrum Analyzer✔RF בלבד$
SDR “פתוח”⚠ תלוי שימושמאוד גבוהה$
IMSI Catcher❌אסור❌

💡 הערה אישית אליך

לפי ההיסטוריה שלך – הגישה של “טלפון = Host, SDR / RF = חיישן צד” מתאימה לך מאוד:

  • טלפון: Layer 3–7
  • SDR: Layer 1–2
  • שילוב חוקי, חכם, חזק

אם תרצה – אני יכול:

  • להציע ארכיטקטורת מערכת מלאה
  • להשוות טלפון מול SDR כסנסור
  • להציע סטאק Software חוקי לחלוטין
  • לבנות טבלת ציוד לפי Low / Mid / High Budget

רק תגיד לאיזה כיוון אתה רוצה ללכת.


אבי, אענה בגובה העיניים + דוגמה מעשית מלאה, בצורה חוקית לגמרי, כולל:

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

1️⃣ איך טלפון סלולרי “מנטר רשת” בפועל – ההסבר הפשוט

טלפון לא “מרגל” אחרי הרשת אלא:

  • מתנהג כ‑UE רגיל (User Equipment)
  • קורא מהמודם שלו את נתוני שכבת הרדיו
  • מוציא החוצה סטטיסטיקות מדידה, לא תוכן

כל המידע מגיע מ:

  • מודם Qualcomm / Samsung
  • Android Telephony API
  • Debug Interfaces שהיצרן משאיר לצורכי בדיקות

✅ חוקי
❌ אין יירוט
❌ אין IMSI של אחרים
❌ אין תוכן שיחות / נתונים

2️⃣ איזה נתונים אפשר לקבל מטלפון רגיל?

📡 נתוני רשת סלולרית (LTE / 5G)

  • Band (למשל: B3, B7, n78)
  • Cell ID / PCI
  • EARFCN / NR-ARFCN
  • RSRP / RSRQ
  • SINR
  • סוג טכנולוגיה: LTE / LTE-A / 5G NSA
  • Handover events
  • Speed / Latency / Packet loss

זה בדיוק אותו סט נתונים שעובדי חברות סלולר רואים ב־Drive Test [keysight.zinfi.net]

3️⃣ אפליקציות מומלצות לטלפון (Android)

✅ חינמיות (להתחיל עכשיו)

🟢 NetMonster

📱 חינמי

  • מראה תאים מסביב
  • Band, PCI, RSRP
  • היסטוריית חיבורים
  • יצוא CSV בסיסי

✅ מצוין כסנסור פשוט

🟢 Network Cell Info Lite

📱 חינמי (+ גרסת Pro זולה)

  • גרפים בזמן אמת
  • מפות כיסוי
  • מדידות LTE/5G
  • מדידת יציבות

🟢 LTE Discovery

📱 חינמי

  • תצוגת מידע מודם
  • מעברים בין תאים
  • זיהוי Carrier Aggregation

🔶 חצי‑מקצועי (זול מאוד)

🟡 Network Cell Info Pro

💰 ~7–10$

  • לוגים מתקדמים
  • יצוא נתונים
  • דיוק משופר

4️⃣ דוגמה מעשית – סנסור שטח ב־10 דקות

🎯 תרחיש:

אתה רוצה לנטר איכות רשת LTE/5G באזור תעשייה

📋 שלב‑אחר‑שלב:

  1. קח טלפון Android רגיל
  2. התקן:
    • NetMonster
    • Network Cell Info Lite
  3. הכנס SIM רגיל
  4. הפעל מצב מדידה (Screen ON)
  5. סע / הסתובב באזור

📊 תקבל:

  • איזה תאים פועלים
  • איכות קליטה
  • נפילות
  • עומסים מקומיים

זה Drive Test בלי ציוד יקר

5️⃣ האם אפשר לאחד נתונים ממספר טלפונים? ✅ כן

וזה החלק החזק.

🧠 שתי גישות:

גישה A – ידני (קל)

  • כל טלפון שומר CSV
  • מעלים לשרת / מחשב
  • איחוד ב‑Excel / Python / Grafana

✔ פשוט
✖ לא בזמן אמת

גישה B – בזמן אמת (מומלץ)

🧩 ארכיטקטורה:

טלפון 1 ┐
טלפון 2 ├──> MQTT / HTTP ──> Server ──> Dashboard
טלפון 3 ┘

איך עושים בפועל:

  • אפליקציות שיודעות לשלוח Telemetry
  • או Service קטן ב‑Android
  • שרת עם:
    • InfluxDB / PostgreSQL
    • Grafana / Kibana

🔹 כך עובדת מערכת NEMO Cloud, רק שאתה עושה זאת לבד [keysight.zinfi.net]

6️⃣ סנסורים נוספים בטלפון שאפשר לצרף 📱🧭

מלבד הסלולר:

  • GPS (איכות כיסוי לפי מיקום)
  • תאוצה / כיוון (לרחפנים / רכבים)
  • זמן / תנועה
  • Wi‑Fi לצלילה ל‑HetNet

Android מאפשר גישה מלאה אליהם דרך Sensor API [developer....ndroid.com]

7️⃣ מה אי אפשר לקבל (חשוב לדעת)

❌ IMSI של אחרים
❌ תוכן שיחות
❌ Core network data
❌ מדידת uplink I/Q

לזה צריך רישוי – וזה מחוץ לתחום האזרחי

8️⃣ סיכום קצר

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

💡 הערה אישית אליך

לאור הפרויקטים שלך:

  • טלפון = סנסור רשת זול וחכם
  • SDR = שכבת RF משלימה
  • שרת = Fusion Engine

אם תרצה:

  • אשמח לבנות לך ארכיטקטורת PoC מלאה
  • לתת Stack תוכנה מינימלי
  • או לכתוב Flow של 10–20 טלפונים כסנסור רשת

רק תגיד לאן אתה רוצה לקחת את זה.


מצוין. הנה PACK מלא – הסבר + דוגמה מעשית + תוכנות + ארכיטקטורה + איחוד נתונים + תצוגה, צעד‑אחר‑צעד, כך שתוכל להריץ מערכת ניטור רשת סלולרית מבוססת טלפונים רגילים, חוקית, סקיילבילית, ובדיוק בסגנון הפרויקטים שאתה רגיל אליהם.

🎯 מטרת המערכת (הכול יחד)

לבנות רשת סנסורים סלולריים מבוססת:

  • 📱 טלפוני Android רגילים
  • 🌐 איסוף נתונים רציף
  • 📊 תצוגה מרכזית בזמן אמת
  • 🧠 ניתוח איכות רשת, כיסוי, עומסים, נפילות

בלי:

  • יירוט
  • IMSI Catcher
  • גישה ל‑Core

🧱 ארכיטקטורה כללית (High Level)

┌───────────────┐
│ טלפון Android │  ← סנסור רשת
│ (SIM רגיל)    │
├───────────────┤
│ 📡 סלולר     │
│ 📍 GPS        │
│ 🧭 תנועה      │
└──────┬────────┘
       │ JSON / MQTT / HTTP
       ▼
┌────────────────────┐
│     Server         │
│ InfluxDB / Postgres│
│ Processing Layer   │
└──────┬─────────────┘
       ▼
┌────────────────────┐
│ Dashboard          │
│ Grafana / Kibana   │
└────────────────────┘

1️⃣ הטלפון כסנסור – מה הוא באמת עושה?

הטלפון:

  • מתחבר לרשת כ‑UE רגיל
  • קורא מדידות מהמודם
  • לא “מאזין” לשום דבר

📡 נתונים אופייניים:

  • Technology: LTE / LTE‑A / 5G NSA
  • Band (B3, B7, n78…)
  • Cell ID / PCI
  • EARFCN / NR‑ARFCN
  • RSRP / RSRQ / SINR
  • Handover events
  • Downlink throughput
  • Latency

✅ חוקי לגמרי
❌ אין תוכן / IMSI אחרים / Core

2️⃣ תוכנות להתקנה על הטלפון (100% מעשי)

🟢 שלב א’ – להתחיל מייד (חינמי)

✅ NetMonster (חינמי)

✔ קל
✔ הרבה נתוני רדיו
✔ עובד על כמעט כל Android

מה מקבלים:

  • תאים זמינים
  • איכות קליטה
  • Band ו‑PCI
  • לוג חיבורים

✅ Network Cell Info Lite (חינמי)

✔ גרפים בזמן אמת
✔ מפה
✔ היסטוריה

🟡 שלב ב’ – איסוף רציני (זול)

✅ Network Cell Info Pro (~9$)

  • ייצוא CSV
  • נתונים צפופים יותר
  • יציב לריצה ממושכת

🔧 שלב ג’ – שילוב אוטומטי (Advance)

כאן אתה כבר:

  • או משתמש ב‑SDK
  • או כותב Android Service קטן

3️⃣ דוגמה מעשית מלאה (PoC אמיתי)

🎯 תרחיש

3 טלפונים מנטרים אזור תעשייה + כביש גישה

📱 על כל טלפון:

  • SIM רגיל (כל ספק)
  • Android
  • אפליקציה מותקנת
  • GPS פעיל
  • Screen ON / Background Service

📤 כל 5–10 שניות נשלח JSON:

{
  "device_id": "phone_01",
  "timestamp": "2026-04-14T18:22:00",
  "lat": 32.083,
  "lon": 34.78,
  "tech": "LTE",
  "band": "B3",
  "pci": 312,
  "rsrp": -92,
  "rsrq": -12,
  "sinr": 18,
  "throughput_dl": 45.2
}

4️⃣ איך שולחים נתונים מהטלפון?

✅ 3 אפשרויות ריאליות:

🔹 אפשרות A – HTTP POST

  • הכי פשוט
  • REST API
  • עובד מכל רשת

🔹 אפשרות B – MQTT

  • מושלם לריבוי טלפונים
  • latency נמוך
  • אתה מכיר את זה מעולמות sensor networks

🔹 אפשרות C – Cloud מוכן

  • Firebase / AWS IoT
  • פחות “שליטה מלאה”, יותר נוחות

5️⃣ שרת ו‑Data Layer (Backend)

✅ Database

  • InfluxDB – זמן‑אמת, גרפים
  • או PostgreSQL + Timescale

✅ Processing

  • איחוד תאים
  • חישוב drop events
  • Heatmap איכות קליטה
  • זיהוי חריגים (SINR נמוך)

6️⃣ תצוגה מרכזית – Dashboard

🟢 Grafana (מומלץ)

תצוגות:

  • מפה – איכות קליטה לפי צבע
  • גרף RSRP לאורך זמן
  • השוואה בין מוקדים
  • נפילות והנדוברים
📍 Map View
🟢 טוב     🟡 בינוני     🔴 גרוע

7️⃣ שילוב סנסורים נוספים מהטלפון

כי זה היתרון האמיתי:

סנסורשימוש
GPSכיסוי מרחבי
מהירותDrive Test
תאוצהזיהוי תנועה
Wi‑FiHetNet
זמןסנכרון

כל זה כבר קיים ב‑Android Sensor API.

8️⃣ סקייל – 1 טלפון או 50

✅ עובד באותה ארכיטקטורה:

  • כל טלפון = Node
  • Server מרכז נתונים
  • Dashboard אחד

אפשר:

  • סנסורים ניידים
  • נקודות קבועות (טלפון מחובר חשמל)
  • רכב, רחפן, תיק גב

9️⃣ מה אי‑אפשר (להיות ברור)

❌ IMSI Catcher
❌ ETSI Layer 3 יירוט
❌ Core Network
❌ User Data

וזה בסדר – איכות רשת נמדדת מהקצה, לא מהליבה.

10️⃣ למה זה חזק דווקא לך

במילים פשוטות:

  • טלפון = UE אינטליגנטי
  • SDR = RF Sensor
  • שרת = Fusion Engine

וזה סטאק שמאפשר:

  • PoC מהיר
  • מערכת גדולה
  • חוקיות מלאה
  • עלות אפסית כמעט

🚀 הצעד הבא אפשרי:

אם תרצה – אני יכול:

  1. לבנות תרשים מערכת מלא (PDF / PNG)
  2. להציע Android Service מינימלי
  3. להגדיר Dashboard Grafana
  4. לשלב SDR לצידו של הטלפון
  5. להרים PoC של 5–10 סנסורים

רק תגיד: 👉 PoC / קוד / תרשים / הכל


מעולה — עכשיו אני סוגר לך את כל התמונה, לא רק “איך“, אלא “למה”
והשאלה שלך מדויקת מאוד:

אם טלפון כבר יודע לנטר את הרשת – למה בכלל צריך SDR?

התשובה הקצרה:

לא חייבים SDR, אבל בלי SDR אתה עיוור לחצי מהבעיה

ועכשיו ההסבר המלא, שיטתי, עם דוגמה מעשית שעובדת.

🧠 התמונה המלאה – טלפון + SDR = ניטור אמיתי

עקרון יסוד

רכיבמה הוא רואהמה הוא לא רואה
📱 טלפוןחוויית משתמש, איכות שירותמה קורה באוויר
📡 SDRמה קורה באוויראיך זה “מרגיש” ללקוח

רשת סלולר = אוויר + משתמש
אם אתה מודד רק צד אחד – אתה עלול להסיק מסקנות שגויות.

1️⃣ מה טלפון כן נותן לך (ולמה זה לא מספיק)

📱 טלפון הוא UE (User Equipment)

הטלפון יודע:

  • לאיזה תא הוא מחובר
  • מה איכות הקליטה אצלו
  • מה ה‑throughput שקיבל
  • מתי התנתק / עבר תא
  • latency / packet loss

✨ זה מושלם ל:

  • QoE – Quality of Experience
  • Drive Test
  • השוואת ספקים
  • “למה הלקוח מתלונן”

❌ אבל הוא לא יודע לענות על שאלות אחרות.

❓ שאלות שהטלפון לא יכול לענות עליהן

  • האם משודר רעש בתדר?
  • האם יש תא נוסף שאני לא רואה בגלל סינון UE?
  • האם יש הפרעה רגעית?
  • האם תא משדר אבל לא מאפשר Attach?
  • האם יש עומס ספקטרלי?
  • האם יש שידור לא תקני / rogue?

📌 הטלפון תמיד רואה רק מה שמותר לו לראות.

2️⃣ מה SDR נותן (שהטלפון פשוט לא יכול)

📡 SDR = Sensor של שכבת האוויר (Layer 1)

SDR רואה:

  • כל מה שמשודר בתדר
  • גם אם אף UE לא מחובר
  • גם אם השידור לא תקני
  • גם אם זו הפרעה רגעית

SDR מאפשר:

✅ לראות כל Carrier
✅ למדוד רוחב ספקטרלי
✅ לזהות Interference
✅ לדעת אם יש תא “שקט” או שבור
✅ לזהות שיבושים / עומס

🧠 השוואה קריטית

מצבטלפוןSDR
תא לא מאפשר Attach❌✅
הפרעה RF❌✅
תא משדר בלי שירות❌✅
קליטה נמוכה בגלל כיוון אנטנה❌✅
עומס משתמשים✅❌
חווית לקוח✅❌

👉 לכן אף אחד מהם לא מספיק לבד.

3️⃣ הדוגמה המעשית (אמיתית לחלוטין)

📍 תרחיש:

  • אזור תעשייה
  • תלונות על 5G “נופל”
  • לפי הטלפון: RSRP סביר

📱 ממצאי טלפון:

RSRP: -92 dBm
SINR: משתנה
Throughput: קופץ מ-80 Mbps ל-2 Mbps

לפי טלפון בלבד:

“הקליטה סבירה, אולי עומס”

📡 ממצאי SDR במקביל:

רוחב ערוץ: 100MHz
רעש ברקע: עולה ל-20dB+
Carrier נוסף חופף
Spur מחזורי כל 30 שניות

📌 מסקנה:

הבעיה היא הפרעה RF מחזורית,
לא עומס משתמשים.

❗ בלי SDR:

  • היית שולח אצבע לרשת הליבה
  • היית טועה

4️⃣ למה זה קריטי בפרויקטים שלך

בהקשרים שאתה עובד בהם (סנסורים, רחפנים, רכבות, שטח):

  • טלפון = מדד חוויית קצה
  • SDR = אמת פיזיקלית

דוגמה:

ברכבת:

  • טלפון מזהה ניתוק
  • SDR מזהה Fade + Multipath

ברחפן:

  • טלפון רואה handover
  • SDR מודד beam switch

5️⃣ הארכיטקטורה השלמה (כמו שאתה אוהב)

        📱 טלפונים (UE)
        │ QoE / KPIs
        │
        ├── MQTT / REST
        │
        ├─────────────┐
        │             │
   📡 SDR           📊 Server
   Spectrum          Fusion Engine
   Noise             Correlation

בשכבת ה‑Fusion:

  • טלפון אומר: “רע לי”
  • SDR אומר: “הנה למה”

6️⃣ האם תמיד צריך SDR?

❌ לא.

✅ לא צריך SDR אם:

  • רק Drive Test
  • רק השוואת ספקים
  • רק כיסוי גס
  • PoC קטן

✅ כן צריך SDR אם:

  • חקירה
  • הפרעות
  • תקלות מסתוריות
  • שטח מורכב
  • מערכות קריטיות

7️⃣ מינימום SDR (לא מעבדה)

לא צריך מפלצת:

SDRשימוש
PlutoSDRSub‑6GHz בסיסי
B205נייד, מדויק
RSPdxWideband

📌 רק Spectrum + Power מספיק ב‑80% מהמקרים.

🧩 השורה התחתונה

הטלפון מספר לך “מה אני מרגיש”
ה‑SDR מספר לך “מה באמת קורה”

וברשתות סלולר:

  • הבעיה כמעט תמיד באוויר
  • והלקוח מרגיש את התוצאה

אם תרצה, השלב הבא:

אני יכול:

  • לצייר תרשים מערכת מלא
  • להציע PoC טלפון + SDR
  • לבנות Flow Fusion
  • להראות טעויות נפוצות בלי SDR

רק תגיד: תרשים / PoC / החלטת קניה / הכל


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

🧭 סיכום פתרונות ניטור רשת סלולרית – יכולות מול מחיר

רמות פתרון (מהזול למקצועי)

1️⃣ טלפון רגיל בלבד (Android כסנסור)

✅ הפתרון הזול והמהיר ביותר

יכולות

  • KPI רדיו: RSRP / RSRQ / SINR
  • Cell ID / PCI / Band / RAT
  • Throughput, Latency, Drops
  • מיקום GPS
  • QoE מנקודת מבט משתמש
  • איסוף ממספר טלפונים → שרת → Dashboard

לא רואה

  • הפרעות RF
  • תאים לא נגישים
  • מצב ספקטרום
  • סיבות פיזיקליות לבעיה

תוכנה

  • NetMonster (חינמי)
  • Network Cell Info Lite / Pro (חינמי / ~10$)
  • פיתוח עצמי (Android Service)

מחיר

  • 📱 חומרה: 0–1,000$
  • 💰 תוכנה: חינם–10$
  • ✅ סקייל: גבוה מאוד

מתאים ל

  • Drive Test
  • השוואת מפעילים
  • כיסוי
  • PoC מהיר

2️⃣ טלפון + SDR (פתרון הנדסי חכם)

✅ Sweet Spot – יחס עומק/מחיר

הוספת SDR נותנת

  • נראות מלאה של הספקטרום
  • זיהוי הפרעות, רעש, תאים “שקטים”
  • אימות שידור מול חוויית משתמש
  • Correlation: “הטלפון איטי בגלל X באוויר”

שילוב נתונים

  • טלפון = QoE
  • SDR = Layer 1 RF
  • Fusion בשרת (Grafana / Kibana)

SDR טיפוסי

  • PlutoSDR: ~300–400$
  • SDRPlay RSPdx: ~400–500$
  • USRP B205: ~1,200–1,800$

מחיר כולל

  • 📱 טלפון: 0–1,000$
  • 📡 SDR: 300–1,800$
  • 💻 שרת/דשבורד: קוד פתוח
  • ✅ סקייל: גבוה

מתאים ל

  • חקירת תקלות
  • אזורים בעייתיים
  • מערכות קריטיות
  • רחפנים / רכבים / רכבות

3️⃣ TEMS Sense (Carrier‑Grade, מסחרי)

✅ סטנדרט מפעילים – “Turnkey”

מבוסס על המסמך שהעלית.

ארכיטקטורה

  • סמארטפונים מסחריים כ‑probes
  • קופסת TEMS Remote (חומרה ייעודית)
  • שרת ניהול מרכזי: TEMS Director
  • סקריפטים, אוטומציה, Dashboards

יכולות מרכזיות

  • ניטור End‑to‑End QoE (24/7)
  • Voice / Data / OTT / Video
  • KPIs, Events, PCAP
  • סקריפטים אוטונומיים
  • ניהול מאות probes
  • Remote control מלא
  • Dashboards ו‑Analytics

[TEMS Sense...escription | PDF]

מה זה לא

  • לא SDR
  • לא רואה “אוויר גולמי”
  • מסתמך על UE (טלפון) בלבד

מחיר (טיפוסי בשוק)

  • 📱 Probe (טלפון + enclosure): ~3,000–5,000$ ליחידה
  • 🧠 שרת + רישוי: עשרות אלפי $
  • 🗺️ מערכת מלאה: 100,000–300,000$+

מתאים ל

  • מפעילים סלולריים
  • SLA / רגולציה
  • פריסה ארוכת טווח
  • תפעול NOC

📊 טבלת השוואה מסכמת

קריטריוןטלפון בלבדטלפון + SDRTEMS Sense
חוקי✅✅✅
QoE משתמש✅✅✅✅✅✅✅✅✅
RF / ספקטרום❌✅✅✅❌
הפרעות❌✅✅✅❌
אוטומציה⚠️✅✅✅✅
סקייל✅✅✅✅✅✅✅✅
זמן הקמהדקותימיםשבועות
עלות★★★★★★★★

🎯 השורה התחתונה (Executive Summary)

  • רק טלפון – מספיק ל‑80% מהמקרים הפשוטים
  • טלפון + SDR – נותן את האמת ההנדסית במחיר שפוי
  • TEMS Sense – פתרון תפעולי מסחרי גדול, לא חקירתי

⚠️ TEMS Sense לא מחליף SDR
הוא מחליף ארגון, תפעול ו‑IT – לא חקירת RF

ההמלצה עבורך (לפי מה שדיברנו)

לאור הרקע שלך והמערכות שבנית:

  • 🟢 להתחיל: טלפונים כסנסורים
  • 🟡 להעמיק: להוסיף SDR בנקודות מפתח
  • 🔵 להתרחב: Fusion + Dashboard
  • ❌ TEMS Sense – רק אם יש לקוח מפעיל/רגולטור

אם תרצה, בצעד הבא אני יכול:

  • לבנות מפת החלטה (Decision Tree)
  • להגדיר BOM מלא לפי תקציב
  • להשוות TEMS Sense מול ארכיטקטורה עצמית
  • להציע PoC של 7 ימים

תגיד מה אתה רוצה לקבע – החלטת קניה / PoC / לקוח סופי.

ב- אין תגובות:
תוויות:

יום שני, 13 באפריל 2026

מילון מושגים מלא – כל מה שמופיע במפרט של MS2080A 🎯 1. Frequency Range – תחום תדרים (9 kHz – 6 GHz)

 אבי, הנה הסבר מלא, ברור ומדויק – על כל מושג וטכנולוגיה שמופיעים במפרט של ה‑Anritsu MS2080A, בשפה פשוטה ועם עומק הנדסי אמיתי.

זה מדריך שיכול לשמש אותך גם לרכש, גם למכרז, וגם להבנת כל רכיב במכשיר.

✅ מילון מושגים מלא – כל מה שמופיע במפרט של MS2080A

🎯 1. Frequency Range – תחום תדרים (9 kHz – 6 GHz)

הטווח שבו המכשיר יכול למדוד אותות RF.
• 9 kHz – יכולת מדידה בתחום תדרים נמוכים מאוד (כבלים, EMI).
• עד 6 GHz – מתאים לרוב טכנולוגיות הרדיו המודרניות (LTE, 5G, WiFi, רדיו, מכ״ם קל).

🎯 2. RTSA – Real‑Time Spectrum Analyzer (20/40 MHz)

ניתוח ספקטרום בזמן אמת.
• מאפשר “לתפוס” אותות קצרים, בורסטים, ושידורים מרובי-תדרים.
• 20 או 40 מגה-הרץ = רוחב הסרט המיידי שהמכשיר יכול לנתח “חי”.

למה חשוב?
איתור הפרעות, ניתוח TDD (ב‑5G / LTE), וזיהוי אותות רגעיים.

🎯 3. POI – Probability of Intercept (2.5 μs)

הזמן הכי קצר שבו המכשיר יכול לגלות אות קצר.
• 2.5 מיקרו-שנייה = יכולת מעולה לתפוס אותות חולפים.
• חשוב בסביבה שבה יש הפרעות קצרות (מנשקי RF, מכ״מים, משדרים רגעיים).

🎯 4. RBW – Resolution Bandwidth (1 Hz – 5 MHz)

רוחב הפס שבו המכשיר “מסתכל” על הספקטרום.
• RBW קטן → מדידה רגישה יותר ויכולת להפריד בין אותות קרובים.
• RBW גדול → סריקה מהירה יותר.

🎯 5. DANL – Displayed Average Noise Level (‑167 dBm)

רצפת הרעש של המכשיר.
• מספר קטן יותר → מכשיר רגיש יותר.
• –167dBm = רגישות מעולה בשטח.

🎯 6. Dynamic Range (105 dB)

היכולת למדוד אות חזק וחלש בו-זמנית.
• חשוב ליד אנטנות/מקורות חזקים והרחק מהם.

🎯 7. Sweep Speed – מהירות סריקה (45 GHz/s)

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

🎯 8. AM/FM Audio Demodulation

אפשרות לשמוע את האות המודולטי (כמו רדיו).
• מאפשר להבין במה מדובר (קשר, רעש, הפרעה וכו’).

🎯 9. Tracking Generator

מחולל תדר המשולב בספקטרום אנלייזר.
משמש ל:
• בדיקת מסננים (Filters)
• מדידת תגובת תדר של מגברים
• בדיקת כבלים והפסדים
• בדיקת מכשירים עם תדרי כניסה/יציאה שונים (Offset Sweep)

🎯 10. Gated Sweep

סריקה רק בזמן מסוים.
• מאפשר ניתוח מערכות TDMA/TDD או אותות מקוטעי זמן.

🎯 11. Spectrogram / Waterfall

תצוגה של האות לאורך זמן בצידוד תלת-ממדי: תדר × זמן × עוצמה.
• עוזר לתפוס הפרעות שחוזרות במחזוריות.

🎯 12. Coverage Mapping

מיפוי קליטה על גבי מפה תוך כדי תנועה.
• משמש להערכת כיסוי LTE/5G.
• מציג עוצמה על מפה גאוגרפית.

🎯 13. Interference Hunting – איתור הפרעות

סט כלים איתו המכשיר מוצא מקור שידור מפריע:
• סוויפ מהיר.
• AM/FM דמודולציה.
• ידית Direction Finding (MA2700A).
• הצגת כיוון על גבי מפה.
• GPS פנימי.

🎯 14. DF – Direction Finding

איתור כיוון הגעת האות (Bearing).
• בעזרת ידית + מצפן + אנטנה כיוונית.
• המכשיר מציג את הכיוון על מפה.

🎯 15. IQ Capture / IQ Streaming

לכידת האות המלא (In-phase & Quad) לניתוח במחשב.
• מאפשר ניתוח מתקדם של פרוטוקולים וסוגי שידור.

🎯 16. Cable & Antenna Analyzer / TDR

בדיקת כבלים ואנטנות:
• SWR
• VSWR
• Return Loss
• TDR – מיקום פגם בכבל (Broken / Moisture)

🎯 17. 5GNR / LTE / WCDMA Analyzer

מוד ייעודי למדידת תחנות בסיס:
• PCI
• SINR
• RSRP/RSRQ
• ערוצי downlink
• בדיקות מתקינים

🎯 18. Built-in Preamp

מגבר קדם שמקטין את רצפת הרעש.
• עוזר לגלות אותות חלשים במיוחד.

🎯 19. GNSS – GPS / GLONASS / Galileo / BeiDou

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

🎯 20. IP52 + IK08 (תקני עמידות)

• IP52 – מוגן מאבק קל והתזות מים.
• IK08 – עמיד למכות/נפילות (2–5 joules).

🎯 21. Zero‑Span

מצב בו המכשיר מתפקד כאוסצילוסקופ של עוצמת אות בזמן.
חשוב בבדיקות:
• עומק אפנון
• פרצי שידור
• TDD pulses

🎯 22. PDF Report Generator

המכשיר מפיק דוחות PDF מוכנים להגשה.

🎯 23. Trace Recording / Playback

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

✅ רוצה שאסדר לך את ההסברים בטבלה מסודרת / PDF?

אני יכול להכין:

✅ מסמך PDF ממותג
✅ טבלה: מושג – הסבר – שימוש
✅ גרסה למכרז / רכש
✅ גרסה טכנית למהנדסים

רק תגיד לי באיזה פורמט אתה רוצה.

ב- אין תגובות:
תוויות:

MS2080A – Field Master™ – אנלייזר ספקטרום נייד

 אבי – עכשיו אתה מקבל מפרט מלא ומדויק של ה־Anritsu MS2080A

וגם תרגום מקצועי לעברית של עמוד המוצר הרשמי – הכל מבוסס על נתונים ששלפתי מחיפוש ישיר ממקורות אנריצו.
המידע למטה מבוסס על מקורות: [anritsu.com], [dl.cdn-anritsu.com]

✅ מפרט מלא – Anritsu MS2080A (גרסת 6GHz)

(המידע להלן כולל את כלל היכולות המופיעות במסמכי Anritsu)

✅ 1. ביצועים בסיסיים

✅ 2. פונקציות מדידה

  • Real‑Time Spectrum Analyzer עם זמן POI של ‎2.5µs [dl.cdn-anritsu.com]
  • Spectrum Analyzer מלא (סוויפ מהיר, Zero‑Span, FFT)
  • Coverage Mapping (מיפוי כיסוי רשת) כולל LTE/5GNR [dl.cdn-anritsu.com]
  • Gated Sweep
  • Spectrogram (מפל מים / Waterfall)
  • שידור וניתוח:
    • Occupied Bandwidth
    • Adjacent Channel Power
    • Channel Power
    • Spectral Emission Mask
    • Carrier Aggregation
    • RSSI/Signal Strength

✅ 3. תמיכת תקנים סלולריים

  • 5GNR FR1 Analyzer (TDD/FDD) [dl.cdn-anritsu.com]
  • LTE TDD/FDD Analyzer
  • WCDMA Analyzer
  • תמיכה מלאה בניתוח מדידות תחנות בסיס (BTS)

✅ 4. יכולות Interference Hunting / DF

  • איתור הפרעות בשטח (Interference Hunting)
  • תמיכה בידית DF עם eCompass (MA2700A)
  • מיפוי קורנים על מפה (Geo‑Location)
  • AM/FM Audio Demod לזיהוי מקורות הפרעה [anritsu.com]
  • Sweep מהיר ביותר (45GHz/s) לאיתור אותות חולפים

✅ 5. Tracking Generator

  • כלול כאופציה (Option 20)
  • מצבי Sweep, Offset, CW
  • בדיקות מסננים/מגברים/כבלים בשטח

✅ 6. יכולות ניתוח נוספות

  • IQ Capture & Streaming למחשב [dl.cdn-anritsu.com]
  • Trace Recording/Playback
  • Time Domain Reflectometry (TDR) למדידת כבלים
  • תמיכה בחיישני Power Meter חיצוניים

✅ 7. חומרה – פיזיות – תצוגה

  • מסך מגע: ‎10” Multi‑Touch High Resolution [atecorp.com]
  • עמידות: IP52 + תקן IK08 נגד מכות ונפילות (קשיח לשטח)
  • משקל: פחות מ‑4 ק״ג (≈9 ליברות) [anritsu.com]
  • אורך חיי סוללה: מעל 3 שעות (ממשי)
  • חיבורים:
    • SMA(f) + N(f)
    • RJ‑45
    • USB
    • אוזניות
    • DC‑Power
  • GNSS: GPS / GLONASS / Galileo / BeiDou [atecorp.com]

✅ תרגום מלא של עמוד המוצר הרשמי (Anritsu)

מקור: "Field Master MS2080A | Anritsu" [anritsu.com]

✅ [תרגום לעברית – עמוד מוצר רשמי]

MS2080A – Field Master™ – אנלייזר ספקטרום נייד

ה‑MS2080A מבוסס על שנים רבות של פיתוח כלי מדידה אמינים של Anritsu, שנועדו לבצע בדיקות RF בסביבות המאתגרות ביותר. עם משקל של פחות מ‑4 ק״ג, המכשיר קומפקטי, נייד וקל לנשיאה.

כאשר יש צורך לאתר מקורות הפרעה בשטח, ה‑MS2080A מספק מגוון רחב של יכולות לזיהוי ולמיקום מדויק של מקורות האות.
מהירות סוויפ של 45GHz/s, בשילוב דמודולציה AM/FM ויכולות מיקום גיאוגרפי (Geo‑Location), מאפשרות זיהוי מהיר של מקורות הפרעה.

האופציה ל‑Real‑Time Spectrum Analyzer מאפשרת תפיסה גם של האותות הקצרים ביותר (כגון TDD), והאפשרות לחיבור Site Master מאפשרת ביצוע בדיקות כבלים ואנטנות על אותו המכשיר.

אפשרויות 5G ו‑LTE מאפשרות לטכנאים לבצע מדידות חיוניות בעת התקנה ותחזוקת רשתות סלולריות מתקדמות.

Tracking Generator אופציונלי מאפשר בדיקות של כבלים, פילטרים ומגברים בשטח, כולל Offset Sweep עבור התקני Down‑Conversion.

לשימוש במעבדה – גוף קשיח עם בולמי גומי וידית משולבת מאפשר עבודה נוחה גם על שולחן.

✅ רוצה שאכין לך קובץ PDF מסודר עם כל המפרט + תרגום?

אני יכול להפיק עבורך:

✅ PDF יפה ומעוצב
✅ כולל טבלה מלאה של כל הפונקציות
✅ כולל סימון אילו פונקציות דורשות “אופציה”
✅ כולל התאמה למפרט הדרישות שלך (1–40)

תרצה?

ב- אין תגובות:
תוויות:
הירשם ל- תגובות (Atom)

הפוסטים הבולטים

שידור מיקום WIFI תשתית קיימת DLINK225

  כן — ה‑D‑Link DSL‑225 בהחלט מבצע הצפנה של הנתונים בין הראוטר לטלפון הנייד כאשר החיבור הוא ב‑Wi‑Fi , אבל חשוב להבין איזו הצפנה כן ואיזו לא ...

פוסטים