--- title: 'جلسات طولانی' description: گره‌های ناوگان که جلسات ارتباطی آن‌ها نسبت به هنجار اختصاصی خودشان به‌طور غیرعادی طولانی است، با آستانه‌های IQR برای هر گره، یک امتیاز شدت و تحلیل علت ریشه‌ای بر پایهٔ حوادث. section: AI Analytics weight: 7 related: - ai-analytics/fleet-reports/events-explorer --- import Alert from '@/components/docs/Alert.astro'; import Image from '@/components/docs/Image.astro'; گزارش **جلسات طولانی** جلسات ارتباطی تله‌متری را در کل ناوگان گره‌های اندازه‌گیری تحلیل می‌کند و دستگاه‌ها، موقعیت‌ها، روزها و انواع مصحح‌هایی را شناسایی می‌کند که در آن‌ها ارتباط ناپایدار کار می‌کند یا برای انتقال داده‌ها زمان بیش از حد می‌برد. سرصفحهٔ گزارش با هفت KPI سرصفحهٔ گزارش هفت KPI دارد: شرکت، پوشش ناوگان، آمادگی داده‌ها، تعداد گره‌های دارای ناهنجاری، تعداد جلسات غیرعادی، حداکثر مدت یک جلسه، تعداد کل حوادث ساعتی و بازهٔ تحلیل. عدد اصلی، شمار گره‌های دارای ناهنجاری از کل ناوگان است؛ حوادث، خوشه‌های ساعتی‌ای هستند که در آن‌ها پنج گره یا بیشتر به‌طور هم‌زمان جلسات طولانی دارند. گزارش به پرسش‌های عملی بهره‌برداری پاسخ می‌دهد: - کدام گره‌ها جلسات ارتباطی بسیار طولانی دارند؛ - کدام جلسات برای همین گره مشخص غیرعادی محسوب می‌شوند؛ - کجا مشکل محلی است: آنتن، سیم‌کارت، تغذیه، مودم، محل نصب؛ - کجا مشکل شبیه حادثهٔ ایستگاه پایه یا اپراتور تلفن همراه است؛ - آیا حوادث ساعتی گسترده در سراسر ناوگان وجود دارد؛ - کدام روزها مشکل‌سازترین بوده‌اند؛ - کدام انواع مصحح‌ها بیشتر در جلسات طولانی قرار می‌گیرند؛ - چه میزان انرژی تقریباً برای انتقال‌های تکراری یا طولانی‌شده مصرف شده است؛ - کدام گره‌ها به بازرسی میدانی با آنتن خارجی، تکرارگر یا بررسی سیم‌کارت نیاز دارند؛ - کجا باید اپراتور تلفن همراه یا کیفیت پوشش در یک موقعیت مشخص بررسی شود. گزارش درستی اندازه‌گیری تجاری گاز را ارزیابی نمی‌کند و گزارشی forensic دربارهٔ دور زدن اندازه‌گیری نیست. تنها جلسات ارتباطی را تحلیل می‌کند: مدت، تکرار ناهنجاری‌ها، گستردگی حوادث، کیفیت سیگنال و علت احتمالی جلسات طولانی. ## جایگاه گزارش در سامانه گزارش به تشخیص عملیاتی تله‌متری تعلق دارد. نباید دو وضعیت متفاوت را با هم اشتباه بگیرد: 1. **اصلاً هیچ ارتباطی وجود ندارد.** گره متصل نمی‌شود، داده‌ای موجود نیست. 2. **ارتباط هست، اما جلسات بسیار طولانی هستند.** گره داده منتقل می‌کند، اما این کار را کند، ناپایدار یا با تلاش‌های مکرر انجام می‌دهد. این گزارش وضعیت **دوم** را تحلیل می‌کند. جایی که اصلاً ارتباط، آرشیو یا داده‌ای وجود ندارد، از گزارش گره‌های مشکل‌دار برتر استفاده کنید؛ جایی که باید بررسی کنید آیا داده‌های یک گره منفرد برای اندازه‌گیری مناسب است، از تحلیل مصرف استفاده کنید. ## این گزارش برای کیست | نقش | آنچه از گزارش به دست می‌آورد | | ------------------ | ----------------------------------------------------------------- | | مدیر بهره‌برداری | تصویر کلی ناوگان، تعداد گره‌های دارای ناهنجاری، حوادث گسترده | | مهندس ارتباطات | فهرست گره‌های با RSSI ضعیف، جلسات طولانی و مشکلات محلی | | دیسپچر | فهرست اولویت‌بندی‌شدهٔ درخواست‌ها و روزهای مشکل‌دار | | اکیپ اعزامی | گره‌های برتر برای بررسی آنتن، سیم‌کارت، تغذیه و محل نصب | | مهندس یکپارچه‌سازی | تشخیص آمادگی داده‌ها، پوشش API و موارد فقدان دادهٔ جلسه | | کارشناس خرید | تحلیل مقایسه‌ای بر اساس نوع مصحح | | تحلیلگر ناوگان | فرضیه‌های علت ریشه‌ای: ایستگاه پایه، اپراتور، سفت‌افزار، گره محلی | ## آنچه گزارش انجام نمی‌دهد گزارش نباید: - بدون بازرسی میدانی، خرابی یک مودم مشخص را اثبات کند؛ - جلسهٔ طولانی را دلیل مستقیم بد بودن دستگاه در نظر بگیرد؛ - به‌طور خودکار سرور یا اپراتور تلفن همراه را مقصر بداند؛ - «فقدان داده» را با «فقدان ناهنجاری» اشتباه بگیرد؛ - مدت جلسات همهٔ گره‌ها را با یک آستانهٔ کلی واحد مقایسه کند؛ - دورهٔ کوتاه با تعداد کم جلسات را از نظر آماری معتبر در نظر بگیرد؛ - بدون توجه به تعداد دستگاه‌های نمونه، دربارهٔ کیفیت مدل دستگاه نتیجه‌گیری کند؛ - جایگزین بررسی رادیویی محل نصب شود؛ - برآورد تلفات باتری را اندازه‌گیری دقیق در نظر بگیرد؛ - از نظرات AI به‌عنوان منبع تشخیص استفاده کند. ## اصطلاحات اصلی | اصطلاح | معنا | | ---------------- | ------------------------------------------------------------------------- | | جلسهٔ ارتباطی | یک اپیزود از اتصال دستگاه به سامانهٔ انتقال داده | | مدت جلسه | زمان از شروع تا پایان جلسه | | جلسهٔ عادی | جلسه‌ای که مدت آن در هنجار اختصاصی گره قرار دارد | | جلسهٔ طولانی | جلسه‌ای که مدت آن از آستانهٔ IQR اختصاصی گره فراتر می‌رود | | `IQR` | دامنهٔ میان‌چارکی: `Q3 − Q1` | | `Q1` | چارک اول مدت‌های جلسات | | `Q3` | چارک سوم مدت‌های جلسات | | `UpperFence` | حد بالای هنجار: `Q3 + 1.5 × IQR` | | `RSSI` | سطح سیگنال رادیویی، dBm | | `CSQ` | شاخص کیفیت سیگنال GSM که می‌تواند به dBm تبدیل شود | | `Btm` | ولتاژ باتری یا شاخص تغذیهٔ دستگاه | | `Long share` | سهم جلسات طولانی از کل جلسات گره | | `Severity score` | ارزیابی نهایی سطح مشکل‌داری گره از منظر جلسات طولانی | | حادثه | خوشهٔ ساعتی که در آن جلسات طولانی به‌طور هم‌زمان نزد چند گره ظاهر شده‌اند | | `RCA` | تحلیل علت احتمالی: ایستگاه پایه، شبکه، سرور، سفت‌افزار، گره محلی | | `Battery loss` | برآورد تقریبی انرژی صرف‌شده بر افزایش مدت انتقال | ## منطق کلی گزارش گزارش به‌عنوان یک تحلیل ناوگانی از جلسات ارتباطی ساخته می‌شود. ```text فهرست گره‌های ناوگان → دریافت جلسات ارتباطی → بررسی آمادگی داده‌ها → هنجار اختصاصی جلسه برای هر گره → جست‌وجوی جلسات طولانی از طریق IQR → محاسبهٔ score برای هر گره → گروه‌بندی جلسات طولانی در حوادث ساعتی → تعیین علت احتمالی RCA → توزیع فرضیه‌ها بر روی گره‌ها → گره‌های مشکل‌دار برتر → تحلیل بر اساس نوع مصحح → تحلیل بر اساس روزها و ماه‌ها → توصیه‌ها برای بهره‌برداری ``` اصل اصلی: ```text جلسهٔ طولانی نسبت به هنجار یک گره مشخص تعریف می‌شود، نه نسبت به یک آستانهٔ ثابت کلی برای کل ناوگان. ``` این مهم است، زیرا دستگاه‌ها، مناطق، اپراتورهای تلفن همراه و حالت‌های استعلام مختلف می‌توانند مدت‌های عادی متفاوتی برای جلسات داشته باشند. ## پارامترهای اجرا | پارامتر | معنا | | ------------------------------- | ---------------------------------------------------------------------- | | از تاریخ / تا تاریخ | مرزهای پنجرهٔ تحلیل | | پنجرهٔ تحلیل، روز | پنجرهٔ جایگزین که هنگام خالی بودن تاریخ‌ها استفاده می‌شود (پیش‌فرض ۳۰) | | گره برای هر نوع مصحح | اندازهٔ نمونه برای هر نوع؛ `0` یعنی همهٔ گره‌های ناوگان | | حداقل جلسه روی گره برای IQR | حداقل تعداد جلساتی که گره برای واجد شرایط شدن نیاز دارد (پیش‌فرض ۳۰) | | تعداد گره‌های مشکل‌دار در گزارش | اندازهٔ جدول N برتر (پیش‌فرض ۵۰) | | تحلیل LLM | روایت اختیاری AI که نتایج را توضیح می‌دهد | | شرکت خدماتی | تحلیل را به ناوگان یک تأمین‌کننده محدود می‌کند | ## داده‌های ورودی ### داده‌های اصلی | داده | برای چه چیزی نیاز است | | --------------- | ---------------------------------------------- | | فهرست گره‌ها | تعیین ناوگان تحلیل | | نوع مصحح | ساخت تحلیل بر اساس مدل | | `Equipment ID` | دریافت جلسات یک دستگاه مشخص | | جلسات ارتباطی | پایهٔ گزارش | | زمان شروع جلسه | گروه‌بندی بر اساس روزها، ماه‌ها و ساعت‌ها | | مدت جلسه | شاخص اصلی تحلیل‌شده | | `RSSI` / `CSQ` | ارزیابی کیفیت سیگنال رادیویی | | `Btm` / باتری | ارزیابی تأثیر تغذیه | | سازمان / موقعیت | انتساب حادثه: مشتری محلی، ایستگاه پایه، ناوگان | ### حداقل مجموعهٔ مورد نیاز برای تحلیل صحیح یک گره، موارد زیر نیاز است: - شناسهٔ دستگاه؛ - دست‌کم حداقل تعداد جلسات؛ - مدت هر جلسه؛ - برچسب زمانی هر جلسه. اگر مدت جلسه موجود نباشد، آن جلسه در تحلیل IQR شرکت داده نمی‌شود. ## آمادگی داده‌ها: دروازهٔ داده تشخیص آمادگی داده‌ها پیش از محاسبهٔ ناهنجاری‌ها، گزارش بررسی می‌کند که آیا اساساً انجام تحلیل ممکن است یا نه. بلوک آمادگی داده‌ها اندازهٔ ناوگان، اندازهٔ آن پس از فیلتر شرکت، تعداد گره‌هایی که دادهٔ جلسه برگردانده‌اند و تعداد آن‌هایی را که حداقل جلسات برای IQR را عبور کرده‌اند نشان می‌دهد. این تشخیص **بسیار حیاتی** است — بدون آن به‌راحتی می‌توان «هیچ ناهنجاری وجود ندارد» را با «هیچ داده‌ای برای تحلیل وجود ندارد» اشتباه گرفت. ### شاخص‌های اصلی آمادگی | شاخص | فرمول / مقدار | | ---------------------------------------- | -------------------------------- | | گره‌ها در ناوگان | `N_park` | | گره‌ها در نمونه | `N_sampled` | | گره‌های دارای دادهٔ جلسه | `N_with_data` | | گره‌هایی که حداقل جلسات را عبور کرده‌اند | `N_qualified` | | کل جلسات | `N_sessions` | | فراخوانی‌های API | `N_calls` | | خطاهای API | `N_errors` | | نرخ خطای API | `N_errors / N_calls × 100%` | | پوشش داده | `N_with_data / N_sampled × 100%` | | پوشش نمونهٔ IQR | `N_qualified / N_sampled × 100%` | ### نرخ خطای API $$ APIErrorRate = \frac{N_{errors}}{N_{calls}} \times 100\% $$ ### پوشش داده $$ Coverage_{with\_data} = \frac{N_{with\_data}}{N_{sampled}} \times 100\% $$ ### پوشش بر اساس گره‌های مناسب برای IQR $$ Coverage_{qualified} = \frac{N_{qualified}}{N_{sampled}} \times 100\% $$ ### وضعیت‌های آمادگی | وضعیت | شرط | معنا | | -------------- | ----------------------------------------- | ------------------------------------------- | | `OK` | نمونهٔ کافی برای IQR وجود دارد | گزارش را می‌توان به‌عنوان گزارشی کاری خواند | | `DEGRADED` | نمونه کوچک است، اما تحلیل ممکن است | نتیجه‌گیری‌ها محتاطانه‌اند | | `INCONCLUSIVE` | خطاها زیاد یا پوشش به‌طور حیاتی پایین است | نتیجه‌گیری‌های ناهنجاری معتبر نیستند | | `NO_DATA` | دادهٔ جلسه وجود ندارد | تحلیل ممکن نیست | | `NO_FLEET` | پس از فیلتر، گره‌ای باقی نمانده است | چیزی برای تحلیل نیست | ### شرایط بحرانی تحلیل ناممکن تلقی می‌شود اگر: $$ APIErrorRate \ge 50\% $$ یا: $$ Coverage_{with\_data} < 5\% $$ یا: $$ N_{qualified} = 0 $$ «هیچ ناهنجاری وجود ندارد» و «هیچ داده‌ای برای تحلیل وجود ندارد» دو وضعیت متفاوت هستند. اگر دادهٔ جلسه موجود نباشد، گزارش نباید اعلام کند که ناهنجاری‌ای یافت نشد. ## حداقل جلسات روی گره برای تحلیل IQR قابل اعتماد، هر گره باید تعداد کافی جلسه داشته باشد. ### آستانهٔ حداقل به‌طور پیش‌فرض: $$ N_{sessions,station} \ge 30 $$ اگر گره جلسات کمتری داشته باشد، هنجار اختصاصی از نظر آماری غیرقابل اعتماد در نظر گرفته می‌شود و گره فیلتر IQR را عبور نمی‌کند. ### چرا حداقل لازم است IQR از برآوردهای چارکی استفاده می‌کند. با تعداد کم مشاهدات، چارک ناپایدار می‌شود: - یک جلسهٔ طولانی تصادفی می‌تواند آستانه را بالا ببرد؛ - یک دورهٔ کوتاه ارتباطی می‌تواند آستانه را پایین بیاورد؛ - تشخیص هنجار گره از تصادف ناممکن می‌شود. ## هنجار اختصاصی مدت جلسه ### چرا هنجار اختصاصی است نمی‌توان یک آستانهٔ کلی واحد برای کل ناوگان به کار برد، مثلاً «همهٔ جلسات بیش از ۱۰ دقیقه بد هستند». گره‌های مختلف شرایط ارتباطی متفاوتی دارند: - انواع مصحح متفاوت؛ - اپراتورهای تلفن همراه متفاوت؛ - RSSI متفاوت؛ - حجم‌های آرشیو متفاوت؛ - برنامه‌های استعلام متفاوت؛ - محل‌های نصب متفاوت؛ - آنتن‌های متفاوت. به همین دلیل، برای هر گره هنجار آماری اختصاصی محاسبه می‌شود. ### انتخاب مدت‌های معتبر برای هر گره، فقط مدت‌های مثبت گرفته می‌شوند: $$ D = \{d_i \mid d_i > 0\} $$ که در آن: - `d_i` — مدت جلسهٔ i‌اُم به ثانیه. ### چارک‌ها مدت‌ها به‌صورت صعودی مرتب می‌شوند. $$ D_{sorted} = sort(D) $$ چارک اول: $$ Q1 = percentile(D, 25\%) $$ میانه: $$ Q2 = median(D) $$ چارک سوم: $$ Q3 = percentile(D, 75\%) $$ ### دامنهٔ میان‌چارکی $$ IQR = Q3 - Q1 $$ ### حد بالای هنجار بر اساس حصار Tukey برای هر گره، یک حد بالای اختصاصی هنجار محاسبه می‌شود: $$ UpperFence = Q3 + 1.5 \times IQR $$ این قاعدهٔ کلاسیک حصارهای Tukey برای شناسایی داده‌های پرت است. ### جلسهٔ طولانی جلسه‌ای طولانی و غیرعادی محسوب می‌شود اگر: $$ d_i > UpperFence $$ که در آن: - `d_i` — مدت جلسه؛ - `UpperFence` — آستانهٔ اختصاصی این گره. اگر جلسات یک گره معمولاً کوتاه باشند، آستانهٔ آن پایین خواهد بود. اگر جلسات یک گره معمولاً طولانی‌تر باشند، آستانهٔ آن بالاتر خواهد بود. گزارش، ناهنجاری را **نسبت به هنجار خود گره** شناسایی می‌کند. ## شاخص‌های پایهٔ گره برای هر گره، شاخص‌های زیر محاسبه می‌شوند. ### تعداد کل جلسات $$ N_{total} = count(D) $$ ### تعداد جلسات طولانی $$ N_{long} = count(d_i > UpperFence) $$ ### سهم جلسات طولانی $$ Pct_{long} = \frac{N_{long}}{N_{total}} \times 100\% $$ ### میانگین مدت همهٔ جلسات $$ AvgDuration = \frac{\sum d_i}{N_{total}} $$ ### میانگین مدت جلسات طولانی $$ AvgLongDuration = \frac{\sum_{d_i > UpperFence} d_i}{N_{long}} $$ ### حداکثر مدت $$ MaxLongDuration = max(d_i \mid d_i > UpperFence) $$ ### میانگین RSSI $$ RSSI_{avg} = \frac{\sum RSSI_i}{N_{RSSI}} $$ که در آن `N_RSSI` تعداد جلسات با مقدار RSSI در دسترس است. ## امتیاز مشکل‌داری گره ### معنای امتیاز امتیاز نشان می‌دهد که گره از منظر جلسات طولانی چقدر مشکل‌دار است. سه بعد را در نظر می‌گیرد: 1. **سهم جلسات طولانی**؛ 2. **میزان فراتر رفتن جلسات طولانی از هنجار**؛ 3. **تعداد مطلق جلسات طولانی**. این رویکرد از بیش‌برآورد یک پرت تکی جلوگیری می‌کند و در عین حال از کم‌برآورد گره‌ای با تعداد زیادی جلسهٔ نسبتاً طولانی نیز جلوگیری می‌کند. ### مؤلفهٔ A — سهم جلسات طولانی $$ A = min(100,\;4 \times Pct_{long}) $$ تفسیر: | سهم طولانی | A | | ---------: | --: | | 5% | 20 | | 10% | 40 | | 25% | 100 | | >25% | 100 | ### مؤلفهٔ B — مدت نسبی $$ B = min \left( 100,\; 8 \times \frac{AvgLongDuration}{max(1, MedianDuration)} \right) $$ که در آن `MedianDuration` مدت میانهٔ جلسهٔ گره است. تفسیر: | AvgLong / Median | B | | ---------------: | --: | | 2× | 16 | | 5× | 40 | | 10× | 80 | | 12.5× | 100 | ### مؤلفهٔ C — تعداد جلسات طولانی $$ C = min(100,\;N_{long}) $$ یعنی ۱۰۰ جلسهٔ طولانی یا بیشتر، حداکثر سهم را از این مؤلفه می‌دهد. ### امتیاز نهایی $$ Score = 0.5 \times A + 0.3 \times B + 0.2 \times C $$ که در آن: - `A` — سهم جلسات طولانی؛ - `B` — مدت نسبی جلسات طولانی؛ - `C` — تعداد مطلق جلسات طولانی. امتیاز نهایی به این بازه محدود می‌شود: $$ 0 \le Score \le 100 $$ ### تفسیر امتیاز | Score | سطح | | ----: | ---------------------------- | | ≥ 80 | گره ارتباطی بحرانی | | 60–80 | اولویت بالا | | 40–60 | اولویت متوسط | | 20–40 | پایش / بررسی برنامه‌ریزی‌شده | | < 20 | سیگنال ضعیف | امتیاز، علت را اثبات نمی‌کند. امتیاز بالا می‌گوید گره به‌طور مکرر و/یا شدید از هنجار مدت جلسات خود فراتر می‌رود. **علت به‌طور جداگانه از طریق RCA تعیین می‌شود.** ## برآورد تلفات باتری در جلسات طولانی ### معنا جلسهٔ طولانی زمان انتقال را افزایش می‌دهد و ممکن است باتری را به‌طور اضافی مصرف کند. گزارش یک برآورد **تقریبی** از مصرف اضافی انرژی ارائه می‌دهد. این اندازه‌گیری دقیق باتری نیست، بلکه یک برآورد عملیاتی است. ### زمان اضافی انتقال برای هر جلسهٔ طولانی، فراروی از هنجار میانهٔ گره محاسبه می‌شود: $$ ExtraTime_i = max(0,\;d_i - MedianDuration) $$ زمان اضافی کل: $$ ExtraTime_{total} = \sum_{i \in LongSessions} ExtraTime_i $$ ### جریان انتقال برای برآورد تقریبی، از یک جریان انتقال پایه استفاده می‌شود: $$ I_{TX} = 340 \; mA $$ ### تلفات باتری $$ BatteryLoss_{mAh} = \frac{I_{TX} \times ExtraTime_{total}}{3600} $$ که در آن: - `ExtraTime_total` — به ثانیه؛ - `I_TX` — جریان به میلی‌آمپر؛ - نتیجه — به mAh. برای نمایش به Ah: $$ BatteryLoss_{Ah} = \frac{BatteryLoss_{mAh}}{1000} $$ ### محدودیت این برآورد موارد زیر را در نظر نمی‌گیرد: - پروفایل جریان واقعی مدل مشخص؛ - حالت خواب؛ - تلاش‌های مکرر در سطح مودم؛ - توان فرستنده؛ - دما؛ - عمر باتری؛ - ظرفیت باتری؛ - کیفیت شبکه در لحظهٔ انتقال. بنابراین باید آن را به‌عنوان **برآورد در حد مرتبهٔ بزرگی** خواند، نه اندازه‌گیری آزمایشگاهی. ## RSSI و CSQ ### RSSI `RSSI` سطح سیگنال رادیویی را به dBm نشان می‌دهد. هرچه مقدار به صفر نزدیک‌تر باشد، سیگنال قوی‌تر است. تفسیر تقریبی: | RSSI | ارزیابی | | ----------: | ---------- | | ≥ −65 dBm | سیگنال خوب | | −65…−75 dBm | قابل‌قبول | | −75…−85 dBm | ضعیف | | < −85 dBm | بسیار ضعیف | ### CSQ برخی دستگاه‌ها به‌جای RSSI به dBm، مقدار `CSQ` — شاخص کیفیت سیگنال GSM — را ارسال می‌کنند. اگر مقدار شبیه CSQ به نظر برسد، می‌توان آن را تبدیل کرد: $$ RSSI_{dBm} = -113 + 2 \times CSQ $$ مثال: $$ CSQ = 29 $$ $$ RSSI = -113 + 2 \times 29 = -55 \; dBm $$ ### سیگنال ضعیف محلی اگر: $$ RSSI_{avg} < -85 \; dBm $$ و ناهنجاری‌های گره با حوادث گستردهٔ ناوگان همخوانی نداشته باشد، علت می‌تواند به این صورت طبقه‌بندی شود: ```text سیگنال ضعیف در محل نصب ``` ## گروه‌بندی جلسات طولانی در حوادث رجیستر حوادث ناهنجاری‌ها در پنجره‌های ساعتی گروه‌بندی می‌شوند. اگر چند گره در یک ساعت یکسان جلسات طولانی دریافت کرده باشند، این **مشکل محلی گره نیست**، بلکه حادثهٔ شبکه، سرور یا اپراتور است. فرضیه به‌صورت خودکار بر اساس گستردگی پوشش تعیین می‌شود — تعداد گره‌ها، مدل‌ها و مشتریان در پنجره. ### چرا گروه‌بندی لازم است اگر در یک ساعت یکسان جلسات طولانی نزد چند گره ظاهر شوند، به احتمال زیاد این مشکل محلی یک دستگاه نیست. می‌تواند باشد: - مشکل ایستگاه پایه؛ - بار اضافی محلی اپراتور؛ - حادثهٔ گستردهٔ شبکه‌ای؛ - عملیات منظم سرور؛ - ویژگی سفت‌افزار یک مدل مشخص. ### سطل ساعتی هر جلسهٔ طولانی در یک سطل ساعتی قرار می‌گیرد: $$ Bucket(t) = floor\left( \frac{t}{1h} \right) \times 1h $$ یعنی همهٔ رویدادهای درون یک ساعت در یک سطل قرار می‌گیرند. ### حادثه یک سطل ساعتی حادثه محسوب می‌شود اگر دست‌کم: $$ N_{stations,bucket} \ge 5 $$ گره تحت تأثیر قرار گرفته باشند. ### شاخص‌های حادثه برای هر حادثه، موارد زیر محاسبه می‌شوند: | شاخص | فرمول | | ------------------------- | -------------------------------- | | تعداد گره‌ها | `count(unique station_id)` | | تعداد مدل‌ها | `count(unique equipment_type)` | | تعداد مشتریان / موقعیت‌ها | `count(unique customer_id)` | | تعداد جلسات | `count(long sessions in bucket)` | | میانگین RSSI | `average(RSSI)` | | مدل‌های برتر | `top equipment types by count` | ## RCA: انتساب علت حادثه خلاصهٔ بررسی علت ریشه‌ای خلاصهٔ ناوگان، مقصر اصلی را تعیین می‌کند — برج ایستگاه پایه، سرور، شبکه، سفت‌افزار یا گره محلی — انتساب مقصر را برای گره‌های دارای ناهنجاری انجام می‌دهد و برنامهٔ عمل را تشکیل می‌دهد. یک روایت اختیاری AI در پایین، اعداد را به زبان ساده توضیح می‌دهد، اما آن‌ها را تغییر نمی‌دهد. RCA، طبقه‌بندی علت احتمالی جلسات طولانی است. ### فرضیه‌های ممکن | فرضیه | معنا | | ----------------- | ------------------------------------ | | `Server driver` | اختلال گستردهٔ درایور جمع‌آوری | | `Server routine` | عملیات منظم سرور یا نگه‌داری | | `Network outage` | اختلال شبکهٔ اپراتور تلفن همراه | | `Cell tower` | مشکل یک ایستگاه پایهٔ مشخص یا موقعیت | | `Firmware` | مشکل مدل دستگاه / سفت‌افزار | | `Local signal` | سیگنال ضعیف در محل نصب | | `Battery low` | تغذیهٔ پایین / تخریب باتری | | `Isolated device` | خرابی محلی یک گره مشخص | | `Mixed causes` | علل ترکیبی | ### حادثهٔ گستردهٔ سرور حادثه به‌عنوان حادثهٔ سرور طبقه‌بندی می‌شود اگر هم‌زمان گره‌های زیاد، مدل‌های زیاد و مشتریان زیاد تحت تأثیر قرار گرفته باشند. به‌صورت قراردادی: $$ N_{stations} \ge ServerWideStations $$ $$ N_{models} \ge ServerWideModels $$ $$ N_{customers} \ge ServerWideCustomers $$ در گزارش، این به معنای: ```text حادثهٔ گستردهٔ ناوگان است، که شبیه مشکل محلی یک گره منفرد نیست. ``` ### اختلال شبکهٔ اپراتور اگر چند مدل و چند مشتری تحت تأثیر قرار گرفته باشند، اما مقیاس به اختلال سرور نرسد: $$ N_{models} \ge 3 $$ و: $$ N_{customers} \ge 3 $$ آنگاه فرضیه این است: ```text اختلال شبکهٔ تلفن همراه / حادثهٔ اپراتور ``` ### مشکل ایستگاه پایه اگر تعداد زیادی گره تحت تأثیر باشند، اما به یک یا دو موقعیت / مشتری تعلق داشته باشند: $$ N_{customers} \le 2 $$ و: $$ N_{stations} \ge CellMinStations $$ آنگاه فرضیه این است: ```text مشکل ایستگاه پایه یا مشکل پوشش محلی ``` ### مشکل سفت‌افزار یا مدل اگر یک مدل تحت تأثیر قرار گرفته باشد، اما نزد مشتریان مختلف: $$ N_{models} = 1 $$ و: $$ N_{customers} \ge 3 $$ آنگاه فرضیه این است: ```text سفت‌افزار / ویژگی مدل دستگاه ``` ### علل ترکیبی اگر شرایط به یک طبقه‌بندی قطعی نینجامند، حادثه این وضعیت را می‌گیرد: ```text علل ترکیبی ``` ## روتین تکراری سرور گاهی حوادث گستردهٔ سرور در همان ساعت روز اتفاق می‌افتند. ### شرط اگر دست‌کم سه حادثهٔ گستردهٔ سرور در همان ساعت روز وجود داشته باشد: $$ N_{server\_incidents,same\_hour} \ge 3 $$ می‌توان آن‌ها را به این صورت طبقه‌بندی کرد: ```text server routine ``` ### معنا این می‌تواند نشان‌دهندهٔ یک کار شبانهٔ منظم، نگه‌داری آرشیو، یک فرایند دسته‌ای یا یک عملیات گسترده باشد که بر مدت جلسات تأثیر می‌گذارد. ## انتساب علت برای هر گره پس از جست‌وجوی حوادث ناوگان، گزارش تعیین می‌کند که نزد هر گره چه چیزی غالب است: حوادث خارجی یا یک مشکل محلی. ### سهم ناهنجاری‌های گره که در حوادث ناوگان قرار می‌گیرند $$ InIncidentPct = \frac{N_{long,in\_incidents}}{N_{long}} \times 100\% $$ ### اگر بیشتر ناهنجاری‌ها با حوادث ناوگان همخوانی داشته باشند اگر: $$ InIncidentPct \ge 70\% $$ آنگاه علت غالب گره از حادثهٔ ناوگان گرفته می‌شود: ```text network_outage / cell_tower / firmware / server ``` این به معنای: ```text دستگاه احتمالاً مقصر اصلی نیست؛ همراه دیگران آسیب دیده است. ``` ### بررسی باتری پایین اگر ناهنجاری‌ها با حوادث ناوگان توضیح داده نشوند، تغذیه بررسی می‌شود. فرض کنیم: $$ Btm_{first} $$ اولین مقدار در دسترس باتری در جلسات طولانی باشد، و: $$ Btm_{last} $$ آخرین مقدار در دسترس باشد. افت: $$ BtmDrop = Btm_{first} - Btm_{last} $$ فرضیهٔ `battery_low` ممکن است اگر: $$ Btm_{first} < 3500 \; mV $$ و: $$ BtmDrop > 200 \; mV $$ ### بررسی سیگنال ضعیف محلی اگر: $$ RSSI_{avg} < -85 \; dBm $$ آنگاه فرضیه این است: ```text سیگنال ضعیف در محل نصب ``` ### خرابی منزوی گره اگر: - ناهنجاری‌ها با حوادث ناوگان همخوانی ندارند؛ - باتری تصویر را توضیح نمی‌دهد؛ - RSSI به‌طور بحرانی ضعیف نیست؛ آنگاه علت به این صورت طبقه‌بندی می‌شود: ```text خرابی محلی گره ``` ## توزیع فرضیه‌ها در ناوگان توزیع فرضیه‌ها برای هر گره، علت غالب انتخاب می‌شود. وقتی بیشتر گره‌ها از حوادث ناوگان آسیب دیده‌اند، خود گره مقصر نیست؛ تنها اقلیتی مشکل محلی منزوی دارند. این برنامهٔ عمل را تغییر می‌دهد: تلاش اصلی به ایستگاه‌های پایه و اپراتور معطوف می‌شود، نه به اعزام گستردهٔ اکیپ به هر گره دارای ناهنجاری. گزارش نشان می‌دهد چند گره به هر علت غالب نسبت داده شده است. ### فرمول سهم فرضیه $$ Share_{hypothesis} = \frac{N_{stations,hypothesis}}{N_{stations,with\_anomalies}} \times 100\% $$ ### گروه‌های علل برای خلاصهٔ مدیریتی، می‌توان فرضیه‌ها را گروه‌بندی کرد: | گروه | شامل | | --------------------- | ----------------------------------------------------------------- | | شبکه / سرور | `server_driver`, `server_routine`, `network_outage`, `cell_tower` | | مشکلات محلی دستگاه‌ها | `isolated_device`, `local_signal`, `battery_low` | | مدل / سفت‌افزار | `firmware` | | ترکیبی | `mixed` | ### تفسیر | غالب | چه باید کرد | | ----------------- | ------------------------------------------------------ | | `Cell tower` | بررسی پوشش، اپراتور و آنتن‌های خارجی نزد مشتریان متأثر | | `Local signal` | بازرسی میدانی گره مشخص، آنتن، تکرارگر، محل نصب | | `Isolated device` | تشخیص مودم، سیم‌کارت، تغذیه، سفت‌افزار | | `Firmware` | بررسی نسخهٔ نرم‌افزار و تماس با تأمین‌کننده | | `Server routine` | بررسی فرایندهای منظم پلتفرم | | `Network outage` | استعلام از اپراتور تلفن همراه بر اساس زمان و منطقه | ## گره‌های مشکل‌دار برتر گره‌های مشکل‌دار برتر جدول گره‌های مشکل‌دار برتر، گره‌ها را بر اساس یک امتیاز ترکیبی (۰–۱۰۰) رتبه‌بندی می‌کند که از سهم جلسات طولانی، میانگین مدت آن‌ها و تعدادشان ساخته شده است. کلیک روی یک ردیف، طولانی‌ترین جلسات گره را همراه با مقادیر RSSI و `Btm` باز می‌کند — که برای برنامه‌ریزی بازرسی میدانی استفاده می‌شود. ### هدف جدول نشان می‌دهد کجا باید رفت یا چه چیزی را در اولویت بررسی کرد. ### ستون‌های جدول | ستون | معنا | | -------------- | -------------------------- | | گره | نام و شناسهٔ گره | | مصحح | نوع دستگاه | | جلسات | تعداد کل جلسات معتبر | | طولانی | تعداد جلسات طولانی غیرعادی | | سهم | درصد جلسات طولانی | | میانگین طولانی | میانگین مدت جلسات طولانی | | حداکثر جلسه | بدترین جلسهٔ یافت‌شده | | میانگین `RSSI` | کیفیت سیگنال رادیویی | | تلفات باتری | انرژی اضافی برآوردشده | | Score | امتیاز ترکیبی مشکل‌داری | ### چگونه جدول برتر را بخوانیم امتیاز بالا می‌تواند به دلایل مختلفی ایجاد شود: - سهم بزرگی از جلسات طولانی؛ - جلسات منفرد بسیار طولانی؛ - تعداد مطلق بزرگی از جلسات طولانی؛ - ترکیبی از این عوامل. برای برنامه‌ریزی بازرسی میدانی، نه‌فقط امتیاز، بلکه موارد زیر را هم بخوانید: - `RSSI`؛ - فرضیهٔ RCA؛ - تلفات باتری؛ - حداکثر جلسه؛ - آیا در حوادث ناوگان قرار می‌گیرد؛ - نوع مصحح. ## روزهای مشکل‌دار برتر روزهای مشکل‌دار برتر همهٔ جلسات غیرعادی بر اساس روز تقویمی گروه‌بندی می‌شوند. روزی که بیشترین تعداد ناهنجاری را دارد، به احتمال زیاد روزی است که حادثهٔ ناوگان در آن رخ داده است. هر روز به فهرست گره‌ها همراه با ناهنجاری‌هایشان، حداکثر جلسه و لینک‌ها باز می‌شود. این برای تحلیل رویدادهای گسترده و بررسی تکرار مفید است. ### هدف تحلیل بر اساس روزها، روزهایی را نشان می‌دهد که جلسات طولانی به‌طور گسترده در سراسر ناوگان ظاهر شده‌اند. ### شاخص‌های روز | شاخص | معنا | | -------------- | -------------------------------- | | تاریخ | روز تقویمی | | جلسات طولانی | تعداد جلسات طولانی در روز | | گره‌ها | چند گره تحت تأثیر قرار گرفته‌اند | | میانگین طولانی | میانگین مدت جلسات طولانی | | حداکثر جلسه | بدترین مورد روز | | بدترین گره | گره با حداکثر جلسه | ### تفسیر | تصویر | علت احتمالی | | ---------------------------------- | ---------------------------------------------- | | گره‌های زیاد در یک روز واحد | حادثهٔ شبکه‌ای یا ناوگانی | | یک گره در هر روز | مشکل محلی | | افزایش ناگهانی در تعطیلات آخر هفته | شبکهٔ اپراتور / کارهای فنی | | افزایش‌های ناگهانی در زمان یکسان | کار منظم یا برنامه | | رشد ماهانه | تخریب شبکه، بار اضافی فصلی، تغییر حالت استعلام | ## تحلیل بر اساس نوع مصحح پوشش بر اساس نوع مصحح بلوک پوشش نشان می‌دهد برای هر نوع مصحح چه چیزی از ناوگان بررسی شده است: چند گره در نمونه است، چند گره داده برگردانده‌اند، چند گره IQR را عبور کرده‌اند و چند گره ناهنجاری نشان می‌دهند. اگر یک نوع «هنجار» نشان دهد، داده‌ها رسیده‌اند اما ناهنجاری‌ای یافت نشده است. «داده‌ای نیست» یعنی این نوع، مدت جلسه را در API برنمی‌گرداند — برای برخی مدل‌ها این طبیعی است. تحلیل مفصل بر اساس نوع مصحح یک نوع را باز کنید تا همهٔ گره‌های دارای ناهنجاری آن را ببینید؛ یک گره را باز کنید تا جلسات طولانی مشخص آن را همراه با زمان، مدت، RSSI و `Btm` ببینید. رنگ هایلایت جلسه به این بستگی دارد که جلسه چقدر از هنجار گره طولانی‌تر است. ### هدف تحلیل بر اساس نوع مصحح نشان می‌دهد کدام مدل‌ها بیشتر در جلسات طولانی غیرعادی قرار می‌گیرند. ### شاخص‌ها بر اساس نوع | شاخص | معنا | | ----------------- | -------------------------------- | | در نمونه | چند گره از این نوع در ناوگان است | | با داده | چند گره دادهٔ جلسه برگردانده‌اند | | IQR را عبور کردند | چند گره حداقل جلسات را دارند | | ناهنجاری‌ها | تعداد جلسات طولانی | | وضعیت | هنجار / ناهنجاری / داده‌ای نیست | ### محدودیت مهم **نمی‌توان انواع مصحح را مستقیماً تنها بر اساس تعداد ناهنجاری‌ها مقایسه کرد.** باید موارد زیر را در نظر گرفت: - چند دستگاه از این نوع در ناوگان است؛ - چند تای آن‌ها داده برگردانده‌اند؛ - چند تا حداقل جلسات را عبور کرده‌اند؛ - کجا نصب شده‌اند؛ - در چه شبکه‌هایی کار می‌کنند؛ - آیا برنامهٔ استعلام یکسانی دارند؛ - آیا نزد یک مشتری واحد متمرکز هستند. ### سهم ناهنجاری نرمال‌شده بر اساس نوع برای مقایسهٔ صحیح، می‌توان استفاده کرد: $$ TypeAnomalyRate = \frac{N_{long,type}}{N_{sessions,type}} \times 100\% $$ یا: $$ TypeAffectedRate = \frac{N_{stations\_anomalous,type}}{N_{stations\_qualified,type}} \times 100\% $$ ## تحلیل بر اساس زمان: دینامیک و ماه‌ها دینامیک جلسات طولانی بر اساس روزها نمودار دینامیک روزانه نشان می‌دهد چه تعداد جلسهٔ غیرعادی در هر روز از پنجره در سراسر ناوگان رخ داده است. «شعله‌ها» دیده می‌شوند — روزهای ارتباط بد در کل شبکه. اوجی که با رجیستر حوادث همخوانی دارد، معمولاً یک سری مشکل ایستگاه پایه در یک موقعیت واحد است. تحلیل بر اساس ماه‌ها تحلیل بر اساس ماه‌های تقویمی به دیدن فصلی بودن یا روند بلندمدت کمک می‌کند. یک اوج ماهانهٔ گسترده با همان سری حوادثی که در دینامیک روزانه دیده می‌شود متناظر است؛ رشد تدریجی در طول زمان، کاندیدای تخریب ارتباط یا باتری است. ### هدف تحلیل بر اساس ماه‌ها، فصلی بودن یا روند بلندمدت جلسات طولانی را نشان می‌دهد. ### شاخص ماه $$ N_{long,month} = count(long\_sessions \; in \; month) $$ ### سهم ماه اگر لازم باشد سهم نشان داده شود: $$ Share_{month} = \frac{N_{long,month}}{\sum N_{long,all\_months}} \times 100\% $$ ### تفسیر | تصویر | توضیح احتمالی | | --------------------- | ----------------------------------- | | اوج ماهانهٔ شدید | تغییر شبکه، اختلال گسترده، بار فصلی | | رشد تدریجی | تخریب ارتباط یا باتری | | اوج زمستانی | شرایط جوی، بار شبکه، تغذیه | | اوج پس از به‌روزرسانی | سفت‌افزار، تنظیمات، برنامهٔ استعلام | ## رنگ‌آمیزی هر جلسه طولانی‌ترین جلسات یک گره هنگام باز شدن یک گره، جلسات طولانی منفرد آن بر اساس قدرت فراروی از آستانهٔ اختصاصی هایلایت می‌شوند و مقادیر دقیق RSSI و `Btm` در لحظهٔ هر جلسهٔ طولانی نمایش داده می‌شوند. این‌ها همان چیزهایی است که اکیپ میدانی به آن نیاز دارد: RSSI پایین به مشکل سیگنال رادیویی اشاره می‌کند، در حالی که ولتاژ باتری عادی، باتری را از فهرست علل خارج می‌کند. ### نسبت فراروی $$ Ratio_i = \frac{d_i}{UpperFence} $$ ### تفسیر | Ratio | رنگ / سطح | | ----: | ------------ | | 1–2× | فراروی ضعیف | | 2–5× | فراروی متوسط | | ≥5× | فراروی قوی | این به تمایز سریع جلسات نسبتاً طولانی از جلسات افراطی کمک می‌کند. ## بر اساس نتایج گزارش چه باید کرد ### اگر علت یک ایستگاه پایه است بررسی کنید: - کیفیت پوشش در موقعیت؛ - یک اپراتور تلفن همراه جایگزین؛ - یک آنتن خارجی؛ - یک تکرارگر؛ - تکرار حوادث بر اساس روز؛ - گره‌های مجاور در همان موقعیت؛ - بار اضافی شبکه در ساعت‌های مشخص. ### اگر علت یک گره محلی است بررسی کنید: - آنتن؛ - سیم‌کارت؛ - مودم؛ - تغذیه؛ - باتری؛ - اتصال‌دهنده‌ها؛ - محل نصب؛ - پارازیت؛ - نسخهٔ سفت‌افزار؛ - تنظیمات برنامهٔ ارسال. ### اگر علت یک سیگنال ضعیف است اقدامات: - اندازه‌گیری RSSI در محل؛ - تلاش برای جابه‌جایی آنتن؛ - بررسی جهت‌گیری آنتن؛ - بررسی یک اپراتور جایگزین؛ - نصب یک آنتن خارجی یا تکرارگر. ### اگر علت باتری است اقدامات: - بررسی `Btm` در محل؛ - در صورت نیاز، تعویض باتری؛ - بررسی جریان مصرف؛ - بررسی تکرار تلاش‌های مکرر؛ - بررسی اینکه آیا دستگاه شبکه را با تلاش‌های مکرر بار اضافی می‌کند یا نه. ### اگر علت مدل / سفت‌افزار است اقدامات: - گروه‌بندی گره‌ها بر اساس نسخهٔ نرم‌افزار؛ - بررسی یادداشت‌های انتشار تأمین‌کننده؛ - درخواست مشکلات شناخته‌شده؛ - مقایسه با مدل‌های دیگر در همان موقعیت‌ها؛ - آزمایش حالت ارتباط در آزمایشگاه. ## نظرات AI طرح بازرسی میدانی AI نظرات اختیاری AI، RCA را می‌خواند و یک طرح بازرسی میدانی کوتاه و خوانا برای اکیپ می‌نویسد. این یک **توضیح زبانی است، نه منبع تشخیص** — همهٔ اعداد و علل توسط فرمول‌ها و قوانین بالا تعیین می‌شوند. ### آنچه AI می‌تواند انجام دهد - خلاصهٔ کوتاه RCA؛ - توضیح مقصر اصلی احتمالی؛ - برجسته کردن گره‌های برتر؛ - تنظیم طرح بازرسی میدانی؛ - توضیح تحلیل بر اساس مدل. ### آنچه AI نمی‌تواند انجام دهد AI **نمی‌تواند**: - آستانهٔ IQR را تغییر دهد؛ - فهرست جلسات طولانی را تغییر دهد؛ - امتیاز را تغییر دهد؛ - علت واقعی را بدون داده تعیین کند؛ - جایگزین بررسی رادیویی شود؛ - جایگزین بازرسی میدانی شود؛ - پایهٔ اثباتی باشد. تحلیل قطعی است. نظرات AI باید فقط به‌عنوان متن توضیحی خوانده شوند — همهٔ نتیجه‌گیری‌های عددی توسط فرمول‌ها و قوانین تعیین می‌شوند. ## خطاهای رایج در تفسیر ### خطا: جلسهٔ طولانی = دستگاه بد نادرست. جلسهٔ طولانی می‌تواند ناشی از شبکه، ایستگاه پایه، سیگنال ضعیف، روتین سرور، آنتن محلی، سیم‌کارت یا باتری باشد. ### خطا: ناهنجاری‌های زیاد برای یک مدل = مدل بد است نادرست. باید بر اساس تعداد دستگاه‌ها، تعداد جلسات، موقعیت‌ها و اپراتورهای تلفن همراه نرمال‌سازی شود. ### خطا: هیچ ناهنجاری وجود ندارد = همه چیز خوب است نادرست، اگر دادهٔ جلسه وجود نداشته باشد یا پوشش بسیار پایین باشد. ### خطا: RSSI بالا مشکل ارتباط را رد می‌کند همیشه این‌طور نیست. ممکن است مشکلات اپراتور، بار اضافی، سفت‌افزار، دریافت سمت سرور، تلاش‌های مکرر یا خطاهای پروتکل وجود داشته باشد. ### خطا: تلفات باتری = مصرف دقیق باتری نادرست. این برآوردی است که بر اساس زمان اضافی انتقال و یک جریان قراردادی ساخته شده است. ### خطا: یک جلسهٔ بسیار طولانی، گره را به مشکل‌دارترین گره تبدیل می‌کند همیشه این‌طور نیست. امتیاز نه‌فقط حداکثر، بلکه سهم، میانگین مدت و تعداد جلسات طولانی را نیز در نظر می‌گیرد. ## حداقل معیارهای یک گزارش کامل گزارش از نظر روش‌شناختی کامل محسوب می‌شود اگر شامل موارد زیر باشد: - بازهٔ تحلیل؛ - پوشش ناوگان؛ - وضعیت دروازهٔ داده؛ - تعداد گره‌های ناوگان؛ - تعداد گره‌های استعلام‌شده؛ - تعداد گره‌های دارای دادهٔ جلسه؛ - تعداد گره‌هایی که آستانهٔ IQR را عبور کرده‌اند؛ - تعداد جلسات در نمونه؛ - تعداد جلسات طولانی؛ - تعداد گره‌های دارای ناهنجاری؛ - حداکثر مدت جلسه؛ - تعداد حوادث ساعتی؛ - توزیع فرضیه‌های RCA؛ - فرمول آستانهٔ IQR؛ - فرمول امتیاز گره؛ - فرمول تلفات باتری؛ - قوانین طبقه‌بندی RCA؛ - جدول گره‌های مشکل‌دار برتر؛ - تحلیل بر اساس روزها؛ - تحلیل بر اساس نوع مصحح؛ - تحلیل بر اساس ماه‌ها؛ - سلب‌مسئولیت دربارهٔ تقریبی بودن تلفات باتری؛ - سلب‌مسئولیت دربارهٔ نقش AI؛ - توصیه‌ها برای اقدامات. ## فرمول خلاصهٔ گزارش برای هر گره: $$ D = \{d_i \mid d_i > 0\} $$ $$ IQR = Q3(D) - Q1(D) $$ $$ UpperFence = Q3(D) + 1.5 \times IQR $$ $$ LongSessions = \{d_i \mid d_i > UpperFence\} $$ $$ Pct_{long} = \frac{|LongSessions|}{|D|} \times 100\% $$ $$ A = min(100,\;4 \times Pct_{long}) $$ $$ B = min \left( 100,\; 8 \times \frac{AvgLongDuration}{max(1, MedianDuration)} \right) $$ $$ C = min(100,\;|LongSessions|) $$ $$ Score = 0.5A + 0.3B + 0.2C $$ برآورد مصرف اضافی باتری: $$ ExtraTime_{total} = \sum_{d_i \in LongSessions} max(0,\;d_i - MedianDuration) $$ $$ BatteryLoss_{mAh} = \frac{340 \times ExtraTime_{total}}{3600} $$ گروه‌بندی حوادث: $$ Bucket(t) = floor(t / 1h) \times 1h $$ $$ Incident = Bucket \; where \; N_{unique\_stations} \ge 5 $$ ## سلب‌مسئولیت پیشنهادی ```text The report detects abnormally long communication sessions relative to each node's individual norm. The result is used for prioritising diagnostics of communications, antennas, SIM cards, power, carriers and base stations. The report is not proof of a specific device's malfunction without a field visit and does not assess the correctness of commercial gas metering. ``` ## ارتباط با گزارش‌های دیگر | اگر لازم است بفهمید | استفاده کنید | | ----------------------------------------------------------------- | --------------------- | | کدام گره‌ها ارتباط را طولانی نگه می‌دارند و باتری را مصرف می‌کنند | این گزارش | | کدام گره‌ها ارتباط یا آرشیو ندارند | گره‌های مشکل‌دار برتر | | آیا می‌توان بازه را برای یک گره مشخص بست | تحلیل مصرف | | آیا ظن کم‌شماری وجود دارد | گره‌های مشکوک | | چرا یک گره مشخص مشکوک است | دور زدن اندازه‌گیری | | چه زمانی باتری‌ها را تعویض کنیم | پیش‌بینی باتری | این تفکیک مانع از آن می‌شود که جلسات ارتباطی طولانی با نتیجه‌گیری‌های تجاری، مترولوژی و forensic مخلوط شوند.