تست مصرف اینترنت ردیاب؛ بدون داده خام عدد قطعی نداریم

نتیجه فعلی: برای RG‑X3 عدد اندازه‌گیری‌شده و قابل حسابرسی از مصرف اینترنت در بازه‌های ارسال مختلف در دسترس نیست؛ بنابراین این صفحه نباید وانمود کند آزمون انجام شده است. مصرف واقعی فقط با لاگ خام اپراتور یا شمارنده شبکه، تنظیمات دقیق دستگاه و چند دوره کنترل‌شده قابل گزارش است.

فاصله ارسال مهم است، اما تنها عامل نیست. اندازه هر رکورد، تعداد پارامترها، بسته‌بندی چند رکورد در یک Packet، TCP یا UDP، رمزنگاری، Keep-alive، قطع و وصل شبکه، ارسال مجدد، Firmware و فرمان‌های ورودی هم روی حجم نهایی اثر دارند. در نتیجه تبدیل ساده «یک پیام × تعداد پیام» معمولاً فقط کف نظری مصرف را می‌دهد.

اول تعریف کنید دقیقاً چه چیزی اندازه‌گیری می‌شود

سه عدد ممکن است با هم فرق کنند: حجم Payload کاربردی، بایت‌های دیده‌شده روی رابط شبکه و حجم صورتحساب‌شده توسط اپراتور. Payload فقط داده موقعیت و ورودی‌هاست؛ لایه شبکه Header، تأیید دریافت، برقراری اتصال و رمزنگاری را اضافه می‌کند. اپراتور نیز ممکن است روش حسابداری، گردکردن یا زمان ثبت متفاوتی داشته باشد.

برای پاسخ به سؤال هزینه، عدد اپراتور مرجع نهایی است؛ برای عیب‌یابی، Capture شبکه و لاگ سرور لازم می‌شود. هر دو را با زمان یکسان و شناسه همان سیم‌کارت تطبیق دهید.

بازه نمونه‌برداری با بازه ارسال یکی نیست

ردیاب ممکن است هر ۱۰ ثانیه یک رکورد بسازد، اما چند رکورد را هر یک دقیقه در یک Packet بفرستد. در این حالت تعداد موقعیت‌ها ثابت است ولی سربار اتصال و Packet می‌تواند کمتر از ارسال تک‌تک باشد. برعکس، اگر هر رکورد فوری ارسال شود، تأخیر کم می‌شود اما تعداد ارتباط‌ها بالا می‌رود.

مستند AVL Protocols تل‌تونیکا ساختار Codec 8 را شامل Header، تعداد رکورد، داده AVL و CRC نشان می‌دهد و تصریح می‌کند Packet می‌تواند چند رکورد داشته باشد. مستند Data Sending Protocols همان سازنده نیز حداقل و حداکثر اندازه را وابسته به دستگاه و عناصر I/O می‌داند. این اسناد فقط نمونه پروتکل یک سازنده‌اند و مصرف یا پروتکل RG‑X3 را اثبات نمی‌کنند.

فرمول نظری را فقط برای طراحی آزمون استفاده کنید

اگر اندازه متوسط هر ارسال را از Capture واقعی داشته باشید، برآورد ساده چنین است:

حجم روزانه تقریبی = تعداد ارسال روزانه × میانگین مجموع بایت رفت و برگشت هر ارسال + ترافیک اتصال، Keep-alive، فرمان و ارسال مجدد

تعداد ارسال روزانه برای بازه ثابت برابر است با ثانیه‌های فعال روز تقسیم بر فاصله ارسال. اما این فرمول وقتی خودرو خاموش است، دستگاه وارد Sleep می‌شود، رویداد فوری رخ می‌دهد یا داده‌ها Batch می‌شوند تغییر می‌کند. عدد «ماهانه» نیز باید بر تعداد روز فعال و الگوی واقعی شیفت بنا شود، نه ضرب کورکورانه یک روز آزمایش.

چه چیزهایی مصرف را بالا یا پایین می‌برند؟

قطع و وصل شبکه، آزمون را پیچیده می‌کند

وقتی پوشش ضعیف است، دستگاه ممکن است دوباره متصل شود، Packet را تکرار کند یا داده ذخیره‌شده را یکجا بفرستد. بنابراین مصرف یک مسیر کم‌پوشش می‌تواند با همان فاصله ارسال از مسیر شهری متفاوت باشد. راهنمای بهره‌وری اتصال IoT از GSMA بر تعادل میان ترافیک و Signalling و بازیابی منطقی از شکست ارتباط تأکید دارد.

الزامات کاربرد IoT GSMA پیشنهاد می‌کند تعداد اتصال‌ها کم و داده‌های تأخیرپذیر تا حد امکان تجمیع شوند. این اصل عمومی است؛ پیاده‌سازی روی ردیاب خاص باید از مستند Firmware تأیید شود. برای طراحی مسیر آزمون، صفحه تست پوشش شبکه ردیاب را جدا ببینید.

Keep-alive و تأیید دریافت هم بایت مصرف می‌کنند

پروتکل‌های IoT برای زنده نگه‌داشتن نشست، تأیید پیام یا بازیابی قطع ارتباط تبادل‌های اضافی دارند. مستند MQTT در AWS IoT Keep-alive، نشست پایدار و QoS 0/1 را توضیح می‌دهد؛ در QoS 1 پیام تا دریافت PUBACK می‌تواند تکرار شود. ردیاب موردنظر ممکن است MQTT استفاده نکند، اما مثال نشان می‌دهد Payload تنها جزء مصرف نیست.

راهنمای امنیت AWS IoT نیز اثر حجم و فرکانس داده، اتصال مجدد و Backoff را در پایداری سامانه مطرح می‌کند. رمزنگاری را برای کم‌کردن چند بایت حذف نکنید؛ امنیت، احراز هویت و محرمانگی داده موقعیت باید جزء الزام طراحی بماند.

پروتکل آزمون کنترل‌شده برای چهار بازه ارسال

1. یک دستگاه، Firmware، سیم‌کارت، APN، سرور و فهرست I/O ثابت انتخاب کنید.
2. شمارنده اپراتور و شمارنده شبکه را صفر یا نقطه شروع آن‌ها را ثبت کنید.
3. چهار فاصله نمونه مانند ۱۰، ۳۰، ۶۰ و ۳۰۰ ثانیه را پیش از آزمون تعریف کنید؛ این‌ها سناریوی آزمایش‌اند، نه توصیه عمومی.
4. برای هر فاصله، یک مسیر و مدت مشابه با زمان حرکت، توقف و خاموشی یکسان اجرا کنید.
5. فرمان از راه دور، به‌روزرسانی و استفاده اپ را در دوره پایه متوقف یا دقیق ثبت کنید.
6. یک دور کم‌پوشش را جدا اجرا کنید تا اتصال مجدد و ارسال انباشته دیده شود.
7. آزمون هر سناریو را حداقل در چند روز تکرار و میانگین، دامنه و داده خام را نگه دارید.
8. نتیجه را به بایت بر ساعت فعال، بایت بر کیلومتر و حجم روزانه اپراتور گزارش کنید.

بازه‌ها باید با نیاز عملیاتی سازگار باشند. ارسال سریع‌تر ممکن است برای هشدار یا مانیتورینگ زنده لازم باشد؛ ارسال کندتر ممکن است برای دارایی کم‌تحرک کافی باشد. هدف آزمون یافتن تعادل است، نه اثبات اینکه کمترین مصرف همیشه بهترین تنظیم است.

جدول داده خام باید چه ستون‌هایی داشته باشد؟

خطاهای رایج در گزارش مصرف اینترنت

• انتشار عدد ماهانه بدون نمایش داده خام اپراتور.
• یکی‌گرفتن فاصله ثبت موقعیت با فاصله ارسال.
• محاسبه فقط Payload و نادیده‌گرفتن ترافیک رفت‌وبرگشت.
• مقایسه دو Firmware، Codec یا فهرست I/O متفاوت.
• آزمون یک‌روزه و تعمیم آن به همه مسیرها و اپراتورها.
• حذف روز کم‌پوشش یا Retryهای ناموفق از میانگین.
• مخلوط‌کردن مصرف ردیاب با اپ موبایل کاربر.
• اعلام قیمت بسته یا تعرفه بدون تاریخ و استعلام جاری.

چه نتیجه‌ای اکنون می‌توان منتشر کرد؟

تا وقتی داده اپراتور، تنظیمات و Capture کنترل‌شده برای RG‑X3 موجود نیست، تنها نتیجه معتبر این است که عدد نهایی اندازه‌گیری نشده است. این محدودیت ضعف مقاله نیست؛ جلوگیری از ساخت عدد است. پس از آزمون، باید فایل خام، روش، تاریخ، نسخه Firmware، شرایط شبکه و دامنه عدم‌قطعیت کنار جدول نتیجه منتشر شود.

برای تفاوت ارتباط آنلاین و مسیر جایگزین، راهنمای ردیاب آنلاین و آفلاین/SMS را ببینید. تعریف پایه دستگاه در ردیاب خودرو چیست و اثر تنظیمات در مقیاس ناوگان در مدیریت ناوگان پوشش داده می‌شود.

جمع‌بندی؛ عدد واقعی از صورتحساب و آزمون می‌آید

کاهش فاصله ارسال معمولاً تعداد رکورد یا ارتباط را بیشتر می‌کند، اما نسبت خطی و ثابت تضمین‌شده نیست. اندازه رکورد، Batch، پروتکل، Keep-alive، قطع شبکه و Retry نتیجه را تغییر می‌دهند. روش درست این است که یک متغیر را تغییر دهید، بایت شبکه و اپراتور را هم‌زمان بخوانید، چند روز تکرار کنید و تا پیش از آن هیچ عددی را به RG‑X3 نسبت ندهید.