SE534032C2 - Metod och apparat för bestämning av prestanda hos tjänster. - Google Patents

Description

534 032

[0004] Bevakning av prestanda hanteras vanligtvis i mobila nät av en funktion som kallas OSS (Operation & Support System), exempelvis för att stödja felhantering. Så gott som alla noder i mobilnätet, exempelvis basstationer, MSC (Mobile Switching Centre) och RNC (Radio Network Controller), kan konfigureras att tillhandahålla information mer eller mindre relaterad till prestanda, till OSS eller andra liknande system över specifika gränssnitt. Olika sensorer och räknare installeras således i de olika nätnoderna, för att samla in mätningar av relevanta parametrar relaterade till prestanda, i varje nod vid drift av nätet. I detta sammanhang brukar man ofta kalla en till prestanda relaterad parameter för KPl (Key Performance lndicator). Datagenomströmning och andelen av framgångsrik etablering av radiobärare är vanliga exempel på sådana till nätprestanda relaterade parametrar eller KPlzer.

[0005] Sensorerna och räknarna i nätnoderna kan konfigureras att med jämna mellanrum skicka mätresultat, det vill säga uppmätta KPI-värden, till OSS. Så kallade ”aktiva prober" kan också installeras som sensorer/ räknare i olika gränssnitt, för att tillhandahålla KPl-mätningar. En lämplig mjukvara i OSS är konfigurerad att ta fram relevant information frän de mottagna mätningarna, för att skapa en allsidig överblick av aktuell nätprestanda. l praktiken behövs ett relativt stort antal sensorer och räknare i ett flertal noder och gränssnitt, för att uppnå en tillfredställande överblick av nätet. Sådana sensorer, räknare och aktiva prober installeras vanligen på basis från fall till fall, för att undersöka ett visst problem i nätet, exempelvis när dålig prestanda har observerats för en specifik tjänst, så att operatören har möjlighet att bevaka en viss del av nätet.

[0006] Den utveckling som nämnts ovan i riktning mot lP- och IMS-baserade multimediatjänster, hädanefter helt enkelt kallat "lP-tjänster", kommer troligtvis att kräva ytterligare funktionalitet för de nya tjänsterna i systemen för bevakning av prestanda, för att utvärdera och reglera tjänsternas prestanda på bra sätt. Den totala prestandan för sådana tjänster beror vanligtvis på prestandan i flera 534 032 individuella tiänstenoder och enheter som används utöver accessnätet, såsom noder associerade med IMS-systemet samt eventuellt utnyttjade applikationsservrar eller funktioner.

[0007] Systemen av idag för övervakning av prestanda, är huvudsakligen utformade för att bevaka specifika noder, delar och delsystem i kretskopplade accessnät såsom mobilnät. Detta kan skapa relativt noggrann utvärdering av nätens prestanda eftersom nätrelaterade KP|:er är vanligtvis beroende av sensorer/ räknare i en enda nod, såsom vid fallet med datagenomströmning, och andelen lyckade etableringar av radiobärare. Rapporterad KPI kan då betraktas som en mer eller mindre korrekt indikation av nätprestandan med avseende på tillgänglig bandbredd respektive möjligheten att erhålla radioresurser.

[0008] För kretskopplade nät där kontrollsígnaleríng och datatrafik hanteras mer eller mindre på samma sätt av samma noder, har således ett antal KP|:er definierats noggrant. l ett paketkopplat nät är emellertid kontrollsignaleringen avskilid från data trafiken, vilka hanteras av olika noder, och många paketbaserade lP-tiänster kommer dessutom även att utföras på flera plattformar. Dessa omständigheter ökar komplexiteten vid användning av sensorer och räknare i de olika trafiknoderna, och det blir även mer komplext att samla KP|:er för lP-tiänster på traditionellt sätt.

[0009] Idag är således räknarna/sensorerna samt väldefinierade KP|:er utformade för klassiska kretskopplade nät vilka erbiuder den primära rösttiänsten.

Om räknarna/sensorerna och KP|:erna skulle användas för lP-tiänster i den paketkopplade domänen, är det ett problem att hitta sessioner och ta fram data från de olika räknarna/sensorerna i de noder som berörs, samt att rapportera resultaten i det aggregerade KPI-format som skapats för den kretskopplade domänen. [000l0] Vidare är det önskvärt att definiera ”tiänsteorienterade” KP|:er för specifika lP-tiönster, som speglar prestandan eller kvaliteten såsom den upplevs av tiänsteanvändaren, som kontrast mot de "nätorienterade" lösningarna ovan. Dä 534 032 prestandan av dessa lP-tiönster vanligtvis ör beroende av en kombination av noder, funktioner och element i nötet, ör det ett problem att komplexitet måste tillföras för att kunna aggregera och kombinera KPI-mötningar från flera sensorer och röknare vid olika platser för de ínblandande noderna.

[OOOl l] Att ta fram relevanta tiönsterelaterade KPl:er för ett flertal olika lP-tiönster, ör således verkligen en svår uppgift som också kröver omfattande mängder av kapacitet för behandling och signalering, speciellt eftersom nya tiönster ofta introduceras. Vissa lP-tiönster kan också utnyttja en kombination av flera undertjönster och/eller olika mediakomponenter, vilka kan vara mer eller mindre kortlivade och varierande. Det ör också ett problem att öven om mötningar från sensorer och röknare uppsamlas från flera noder och element såsom beskrivits ovan, kommer den resulterande totala KP|:n att oftast bara ge en grov uppskattning av användarens verkliga upplevelse.

Sammanfattning

[00012] Det ör ett syfte med föreliggande uppfinning att hantera de problem som presenterats ovan. Det ör vidare ett syfte att åstadkomma en lösning för att bestömma indikatorer av prestanda för lP-tiönster med minskat komplexitet, och som tillåter enkel introducering av nya IP-tiönster. Dessa syften och andra kan uppnås genom att åstadkomma en metod och apparat enligt de siölvstöndiga kraven som bifogas nedan.

[00013] Enligt en aspekt tillhandahålls en metod för att möta en prestandaindikator som speglar prestandan hos en lP-tiönst i ett kommunikatíonsnöt nör den konsumeras eller anropas av en anvöndarterminal i en tiönstesession.

[00014] Nör man detekterar tiönsterelaterade meddelanden som kommuniceras med en policykontrollnod för nömnda tiönstesession, loggas en meddelandetyp med en tidsstömpel för varje detekterat tiönsterelaterat meddelande som rådata i en 534 032 sessionspost, för att därmed skapa en sekvens av meddelandehåndelser i sessionsposten. Tidsståmpeln indikerar tiden för kommunikation av meddelandet.

[OOOl 5] Sedan våljs ett fördefinierat prestandafilter associerat med prestandaindikatorn, baserat på information i sessionsposten. Det valda prestandafiltret appliceras på nämnda rådata i en filtermaskin, och prestandaindikatorn beräknas från den filtrerade datan enligt en fördefinierad algoritm som motsvarar det applicerade prestandafiltret.

[00016] Enligt en annan aspekt tillhandahålls en apparat för att möta en prestandaindikator som speglar prestandan hos en lP-tjånst i ett kommunikationsnöt nör den konsumeras eller anropas av en anvöndarterminal i en tjönstesession.

Apparaten innefattar en meddelandedetektor konfigurerad att detektera tjånsterelaterade meddelanden som kommuniceras med en policykontrollnod för tjönstesessionen.

[00017] Apparaten innefattar vidare en sessionsdatabas konfigurerad att logga en meddelandetyp med en tidsståmpel för varje detekterat tjånsterelaterat meddelande som rådata i en sessionspost, för att dårmed skapa en sekvens av meddelandehåndelser i sessionsposten.

[OOOi 8] Apparaten innefattar öven en filtermaskin konfigurerad att välja ett fördefinierat prestandafilter associerat med prestandaindikatorn, baserat på information i sessionsposten, applicera det valda prestandafiltret på nåmnda rådata, samt beräkna prestandaindikatorn från den filtrerade datan genom att använda en förbeståmd algoritm som motsvarar det applicerade prestandafiltret.

[00019] Olika utföringsformer ör möjliga i metoden och apparaten ovan.

Exempelvis kan filtermaskin innefatta en identifieringsenhet konfigurerad att ta emot nåmnda rådata från sessionsdatabasen, identifiera lP-tjönsten samt åven en eller flera prestandaindikatorer som ör relevanta för den lP-tjönsten, och att vålja ut ett 534 032 fördefinierat prestandafilter frän en uppsättning filter för varie prestandaindikator som är relevant för den identifierade lP-tiänsten. Filtermaskinen kan vidare innefatta en filtreringsenhet konfigurerad att applicera det utvalda prestandafiltret pä nämnda rädata, samt en beräkningsenhet konfigurerad att beräkna prestandaindikatorn frän den filtrerade datan genom att använda den fördefinierade algoritmen.

[00020] Prestandafiltret kan väljas ut baserat pä en lP-tiänstidentifierare som är inkluderad i sessionsposten, eller baserat pä sekvensen av meddelandehändelser i sessionsposten.

[00021] Policykontrollnoden kan kommunicera de tiänsterelaterade meddelandena med en gatewaynod i accessnätet eller med en applíkationsfunktion som tillhandahåller den begärda lP-tiänsten. De tiänsterelaterade meddelandena kan sen detekteras av policykontrollnoden eller av aktiva prober installerade vid gränssnitt med gatewaynoden respektive applikationsfunktionen.

[00022] Applicering av det utvalda prestandafiltret kan tillhandahålla ett tidsstämplat första tiänsterelaterat meddelande som en starttrigger och ett tidsstämplat andra tiänsterelaterat meddelande som en stopptrigger, för mätning av prestandaindikatorn.

[00023] Den beräknade prestandaindikatorn kan rapporteras till en funktion för utvärdering av tjänster, eller läggas i ett lagringsorgan för senare användning.

[00024] Ett flertal prestandaindikatorer kan mätas samtidigt genom att applicera olika associerade presta ndafilter pä samma rädata och beräkna prestanda- indikatorerna frän den filtrerade datan genom att använda motsvarande algoritmer.

[00025] En eller flera specifika prestandaindikatorer kan ha valts ut i förväg för var och en av ett flertal olika lP~t|änster säsom varande relevant för den tjänsten, och ett fördefinierat prestandafilter och motsvarande algoritm kan ha förberetts i 534 032 filtermaskinen för varie specifik prestandaindikator. Flera prestandaindikatorer kan också aggregeras över tiden för att uppdaga trender.

[00026] Ytterligare tönkbara egenskaper och fördelar med denna uppfinning kommer att presenteras i den detaljerade beskrivningen nedan.

Kortfattad beskrivnina av ritninqarna

[00027] Uppfinningen kommer nu att förklaras mer i detali med hiölp av utföringsexempel och med hänvisning till de bifogade ritníngarna, i vilka: [O0028] Figur l ör en schematisk vy som illustrerar övervakningen av tiönsteprestanda för en lP-tiönst som anvönds av en anvöndarterminal, enligt en utföringsform.

[00029] Figur 2 ör ett flödesschema som illustrerar en procedur för att tillhandahålla en mötning av en indikator av prestanda för en lP-tiönst, enligt en annan utföringsform.

[00030] Figur 3 ör ett signaleringsschema som illustrerar ett första exempel för att logga rödata nör en lP-tiönst anvönds, enligt en annan utföringsform. [0003 l] Figur 4 ör ett signaleringsschema som illustrerar ett andra exempel för att logga rödata nör en lP-tiönst anvönds, enligt ytterligare en utföringsform.

[OOO32] Figur 5 ör ett signaleringsschema som illustrerar ett tredie exempel att logga rödata nör en lP-tiönst anvönds, enligt ytterligare en utföringsform.

[00033] Figur 6 ör ett blockschema som illustrerar en filtreringsmaskin vid mötning av en eller flera indikatorer av prestanda, enligt ytterligare en utföringsform. 534 032 Detaljerad beskrivning

[00034] I korthet kan föreliggande uppfinning användas för att mäta, uppskatta eller utvärdera prestandan hos lP-tjänster som används eller konsumeras i ett accessnät med hjälp av en användarterminal, vilket vanligen omfattar medgivande och etablering av en mediasession vid nägon tidpunkt efter nätanslutning.

Accessnätet kan vara ett mobilt eller fast accessnät, och IP-tjänsten kan möjliggöras genom exempelvis lMS eller TISPAN (Telecom and Internet Services and Protocols for Advanced Networks) som använder SIP (Session lnitiation Protocol) eller RTSP (Real Time Streaming Protocol). Föreliggande uppfinning är emellertid inte begränsad till nägra specifika nätarkitekturer eller protokoll.

[00035] Man har funnit att en policykontrollnod som vanligtvis är associerad med accessnätet, kan faktiskt användas för att erhålla relevanta mätningar avseende prestanda av lP-tjänst, huvudsakligen representativt för det totala nätet, genom att logga tjänsterelaterade meddelanden till och frän policykontrollnoden.

Policykontrollnoden häller således information som kan användas för att mäta eller aggregera parametrar eller indikatorer avseende tjänsteprestanda, hädanefter kallat "prestandaindikatorer" i korthet, i stället för att vara beroende av mätningar i flera olika nätnoder pä det sätt som beskrivits ovan. (00036) Uttrycket "prestandaindikator" används i denna beskrivning för att allmänt representera varje mätbar parameter som är relaterad till tjänsteprestanda vilket pä nägot sätt speglar användarens upplevelse vid konsumering eller åtminstone vid päkallande av en IP-tjänst, säsom de ovan nämnda KP|:erna. En prestandaindikator i detta sammanhang kan exempelvis avse väntetid vid uppsättning av session, andelen framgångsrika uppsättningar av session, tillgänglighet av tjänst, väntetid för media, uppfyllelse av förväntad datagenomströmning, med mera. Även om följande exempel och utföringsformer mestadels avser endast en prestandaindikator, är 534 032 föreliggande uppfinning inte begränsad till detta utan kan innefatta mätning av valfritt antal prestandaindikatorer. (00037) Den utnyttjade policykontrollnoden ör huvudsakligen ansvarig för att auktorisera och tillåta kommunikationssessianer för terminaler anslutna till accessnåtet, baserat på diverse förutbestämda riktlinjer och regler. Enligt 3GPP opererar policykontrollnoden enligt en funktion PCRF (Policy and Charging Rule Function), ibland alternativt kallad PDF (Policy Decision Function). Liknande funktioner och protokoll för policykontroll finns också tillgängliga för andra nöt som använder exempelvis konceptet TISPAN.

[OOO38] Nör en session etableras för en anvåndarterminal enligt en begörd IP- tiönst, kommunicerar policykontrollnoden vissa standardiserade meddelanden, i denna beskrivning kallade "tiönsterelaterade meddelanden", med en gatewaynod i accessnötet och med en applikationsfunktion som åstadkommer den begörda IP- flönsten. Enligt SGPP utvöxlar PCRF sådana tiönsterelaterade meddelanden med nötnoden GGSN (Gateway GPRS Support Node) över ett Gxgrånssnitt, och med en applikationsfunktion över ett Rx-grönssnitt, dör båda grönssnitten vanligen anvönder det protokoll som kallas "D|AMETER" (enligt standarddokumentet RFC 3588). Dessa meddelanden behandlas av PCRF baserat på abonnentinformatíon som lagras i en databas SPR (Subscription Profile Repository). I TlSPAN kallas motsvarande gränssnitt för Gq' och Rq'. Denna uppfinning kan emellertid tillömpas för alla sådana gränssnitt vid policykontrollnod dör tiånsterelaterade meddelanden kommuniceras.

[00039] De standardiserade tiönsterelaterade DlAMETER-meddelandena som vanligen utvåxlas med applikationsfunktionen över Rx-grönssnittet innefattar: AAR (Authentication Authorization Request), AAA (Authentication Authorization Answer), STR (Session Terminatian Request), och STA (Session Terminatian Request). Vidare innefattar de standardiserade tiånsterelaterade DlAMETER-meddelanden som 534 032 10 utvöxlas med GGSN-noden över Gx-grönssnittet: CCR (Credit Control Request), CCA (Credit Control Answer), RAR (Re-Authorization Request), och RAA (Re- Authorization Answer). Dessa meddelanden och andra ör völkönda inom området och ör inte nödvändiga att beskriva vidare för att förstå följande utföringsformer.

[00040] För att bestämma och möta relevanta prestandaindikatorer loggas de tiönsterelaterade meddelandena av policykontrollnoden i form av meddelandehöndelser försedda med tidsstömplar och meddelandeidentifierare.

Dessa meddelandehöndelser bildar en meddelandesekvens för en konsumerad eller påkallad lP-tiönst, och lagras som rådata i en sessionspost som dessutom innehåller åtminstone en tiönsteidentifierare, samt eventuellt öven annan tiönste- eller sessionsrelaterad information som kan användas för att filtrera information av speciellt intresse, vilket kommer att beskrivas mer i detal) nedan.

[00041] Med hänvisning till figur 1 kommer nu ett exempel på en procedur och arrangemang att beskrivas för att bevaka tiönsteprestandan för en lP-tjönst som konsumeras med hiölp av en mobilterminal 100. Terminal 100 ör ansluten till ett mobilnöt som innehåller en GGSN-nod 102 för kommunikation av media, och anropar lP-tiönsten från en applikationsfunktion 104 som kan vara belägen i en server i ett IMS-nöt eller liknande. Ett schematískt steg 1:1a illustrerar att terminal 100 etablerar en tiönstesession med applikationsfunktion 104, och ett annat schematískt steg 1:1b illustrerar att terminal 100 och GGSN-nod 102 etablerar resurser för mediatransport i accessnötet för sessionen.

[00042] Applikationsfunktionen 104 och GGSN-noden 102 är båda anslutna till en policykontrollnod 106, vilken har tillgång till abonnentinformatíon lagrad i en SPR 108 för att genomföra sin konventionella policyfunktion såsom beskrivits ovan.

Ett schematískt steg 1:20 illustrerar att tiönsterelaterade meddelanden utvöxlas mellan applikationsfunktion 104 och policykontrollnod 106 över ett Rx-grönssnitt. På 534 032 11 samma sött illustrerar ett schematiskt steg l:2b att tiönsterelaterade meddelanden utvåxlas mellan GGSN-nod 102 och policykontrollnod iOó över ett Gx-grönssnitt.

[00043] Når de kommuniceras detekteras dessa tiånsterelaterade meddelanden såsom meddelandehöndelser av policykontrollnoden 106, eller alternativt av aktiva prober (ei visade) installerade vid respektive gränssnitt Rx och Gx. Typen av varje detekterat tiånsterelaterat meddelande loggas tillsammans med en tidsståmpel, det vill såga tidpunkten för når meddelandet kommunicerades, som rådata i en sessionspost lagrad i en sessionsdatabas l lO, såsom visas av ett ytterligare steg 1:3. Således kommer sessionsposten att innehålla en sekvens av meddelandehöndelser för den åberopade lP-tiönsten, innefattande meddelandetyper och tidsståmplar.

[00044] En fackman inom området kan lått inse att meddelandehåndelser kan loggas på huvudsakligen samma sött åven för andra typer av accessnåt och terminaler, exempelvis sådana som anvander fast access. Den illustrerade GGSN- noden 102 representerar således allmönt vilken nötfunktion som helst som år ansvarig för att etablera nåtresurser för lP-tiånsten når den konsumeras e||er åberopas av anvåndarterminalen, och för att kommunicera tiånsterelaterade meddelanden med policykontrollnoden lOó.

[00045] l ett nösta steg 1:4 matas den i sessionsposten loggade rådatan till en filtermaskin i 12 som år utformad att applicera ett relevant prestandafilter på rådatan och att beräkna en associerad prestandaindikator från den filtrerade datan enligt följande: först identifieras lP-tiönsten och/eller meddelandesekvensen i sessionsposten, och sedan bestäms och vålis prestandafíltret baserat på tiönsten och/eller meddelandesekvensen i sessionsposten. Slutligen appliceras det utvalda filtret på meddelandehåndelserna med rådatan i sessionsposten, och en prestandaindikator associerad med filtret beröknas från den filtrerade rådatan 534 032 12 genom att använda en motsvarande algoritm sam har fördefinierats för denna prestandaindikator.

[00046] Olika prestandafilter och motsvarande algoritmer har således under en förberedelsefas fördefinierats för olika prestandaindikatorer i filtermaskinen l 12, vilken kan filtrera data och använda den filtrerade datan på olika sött. Exempelvis kan två specifika filtrerade tidsstämplade meddelanden användas som triggers för att starta respektive stanna en mätning, vilket kommer att beskrivas mer i detalj nedan med hiälp av exempel. Det bör noteras att den loggade rådatan inte förvanskas av filtreringsprocessen, och ytterligare prestandafilter kan appliceras på samma rådata, exempelvis samtidigt, för att beräkna flera olika prestandaindikatorer som vidare kan aggregeras i olika kombinationer. Ytterligare filterkriteria kan också ha definierats i prestandafiltren beroende pä ytterligare information i sessionsposten, såsom identiteter för användaren och terminalen.

[00047] Ett sista steg l:5 illustrerar att den beräknade prestandaindikatorn rapporteras till en OSS-nod l 14, eller till en liknande funktion konfigurerad att använda prestandaindikatorn för att utvärdera, uppskatta eller bedöma prestandan för den konsumerade IP-tiänsten. Alternativt kan den beräknade prestandaindikatorn helt enkelt läggas i ett lämpligt lagringsorgan l ló för framtida användning, såsom visas genom ett valfritt steg 1:50. Även om de här visas som separata element, kan den beskrivna sessionsdatabasen l lO, filtermaskinen l 12 och lagringsorganet l ló implementeras i policykontrollnoden lOó eller i nära anslutning till denna.

[00048] På detta sätt kan tiänsterelaterade prestandaindikatorer kontinuerligt mätas för sessionsposter med loggade meddelandehändelser med hiälp av mekanismen ovan, vilken kan implementeras huvudsakligen i en enda nod: policykontrollnoden.

Såsom nämnts ovan är det möjligt att samtidigt mäta ett flertal olika prestandaindikatorer från samma sessionspost, genom att applicera olika prestandafilter och motsvarande algoritmer på samma rådata som loggats. 534 032 13 Exempelvis kan en tiänsteuppsättningstid och ett mått på tiänstetillgänglighet härledas från samma sessionspost, genom att använda olika lämpliga prestandafilter och algoritmer. Därmed kan man uppnä en avsevärd minskning av komplexitet samt ökad flexibilitet, och ändå uppnå prestandaindikatorer som är relevanta för användarens upplevelse, vid iämförelse med de traditionella lösningar som beskrivits i bakgrundsavsnittet.

[00049] l figur 2 finns ett flödesschema som illustrerar en procedur för att tillhandahålla en mätning av prestandaindikator för en speciell lP-tiänst när den konsumeras av en användare, i enlighet med en annan utföringsform. Den visade proceduren utförs i en policykontrollnod som använder en sessionsdatabas och en filterrnaskin, såsom elementen lOó, l lO och l 12 som beskrivits ovan för figur l. I ett första steg 200 detekteras tiänsterelaterade meddelanden till/ från policykontrollnoden som meddelandehändelser för en session som involverar en terminal vilken används för att konsumera och/eller anropa lP-tjänsten. I ett nästa steg 202 loggas rådata för de detekterade meddelandehändelserna i sessionsdatabasen, så att man skapar en sessionspost innefattande typ av meddelanden och den tid då varje meddelande detekterades, det vill säga deras tidsstämplar.

[00050] När sessionsposten har skapats i sessionsdatabasen, identifieras den konsumerade lP-tiänsten samt sekvensen av meddelandehändelser i sessionsposten, i ett ytterligare steg 204. Sedan bestämmer och välier filtermaskinen ett prestandafilter som är associerat med en viss prestandaindikator, från en uppsättning av fördefinierade prestandafilter, baserat på den identifierade tiänsten och/eller meddelandesekvensen, i ett föliande steg 206. Den prestandaindikator som skall mätas ges således av den identifierade tjänsten och/eller meddelandesekvensen. Det utvalda prestandafiltret appliceras sedan på rådatan i sessionsposten för att ta fram information om de meddelandehändelser som är relevanta för prestandaindikatorn, i ett nästa steg 208. 534 032 14

[00051] Prestandaindikatorn beräknas slutligen frän den filtrerade datan genom att använda en motsvarande fördefinierad algoritm, i ett ytterligare steg 210, och kan rapporteras nägon tiänsteutvärderande funktion säsom OSS, i ett valfritt streckat steg 212. Alternativt kan den uppmätta prestandaindikatorn helt enkelt läggas i ett lämpligt lagringsorgan, exempelvis i policykontrollnoden. Pä ett eller annat sätt kan mätresultaten användas för att uppskatta eller utvärdera prestandan hos den konsumerade IP-tiänsten. Ett flertal liknande mätningar av prestandaíndikatorer i samband med olika tiänstesessioner, kan således användas för att utvärdera IP- tiänsten som helhet. Att ”mäta” en prestandaindíkator involverar i detta sammanhang i allmänhet stegen 200 - 210 ovan.

[00052] Föliade figurer 3 ~ 5 illustrerar hur olika meddelandehändelser kan loggas som rädata i sessionsdatabasen l lO i figur l, för nägra exempel pä konventionella signaleringsprocedurer som involverar en policykontrollnod associerad med ett mobilt accessnät. Därutöver visar vardera av figurerna 3 - 5 huvudsakligen hur steg 200 och 202 i figur 2 kan genomföras i dessa tre exempel, i det fall dä en mobilterminal används. Exemplen hänvisar till, utan att vara begränsande, nägra typiska procedurer för att åstadkomma en lP-tiänst: figur 3 illustrerar ett exempel pä nätanslutning, figur 4 illustrerar ett exempel pä av terminalen initierat PDP-kontext (Packet Data Protocol), och figur 5 illustrerar ett exempel pä av nätet initierat PDP- kontext.

[00053] Att skapa ett PDF-kontext för en mobilterminal innebär huvudsakligen att nätresurser allokeras för kommunikation i en kommande session, som allmänt involverar etablering av en RAB (Radio Access Bearer). Ett primärt PDP-kontext används för att transportera signaleringsmeddelanden, och kan även användas för att transportera media i en tiänstesession i vissa fall. Annars etableras ett sekundärt PDP-kontext för att transportera media i tiänstesessionen, 534 032 15

[00054] l figur 3 utför en användarterminal 300 anslutning till nätet genom att kommunicera med en GGSN 302 i accessnätet, vilken i sin tur kommunicerar över ett Gx-gränssnitt med en PCRF 304 som utgör policykontrollnod i detta exempel. l ett första steg 3:1, skickar terminal 300 en anslutningsbegäran till GGSN 302 som då avger ett CCR-meddelande till PCRF 304 enligt gällande rutiner, i ett föliade steg 3:2. När detta tiänsterelaterade meddelande detekteras av PCRF 304, eller av en aktiv prob på Gxgränssnittet, loggas meddelandetyp CCR och en aktuell tid T] som en meddelandehändelse i en sessionsdatabas (ei visad), såsom schematiskt indikeras i figuren.

[00055] Efter att ha behandlat CCR-meddelandet, vilket eventuellt involverar framtagning av abonnentinformation från en SPR och tillämpning av gällande tillträdesregler, svarar PCRF 304 med ett CCA-meddelande tillbaks till GGSN 302, i ett steg 3:3. Detta meddelande loggas på samma sätt som en meddelandehändelse i sessionsdatabasen, inklusive mediatyp CCA och en aktuell tid T2. Slutligen skickar GGSN 302 ett svarsmeddelande för anslutning till terminal 300, i ett steg 3:4.

Således har två tiänsterelaterade meddelanden detekterats och loggats som rådata i sessionsdatabasen: CCR (TI) och CCA (Tz).

[00056] l det exempel som visas i figur 4 initierar en mobil användarterminal 400 en mediasession genom att åberopa en lP-tiänst i en applikationsfunktion, indikerad som AF 406, vilken kan vara belägen i ett IMS-nät eller liknande. På samma sött som i det föregående exemplet kommunicerar en GGSN 402 som tiänar terminal 400, över ett Gxgränssnitt med en PCRF 404 som utgör policykontrollnod. Vidare kommunicerar applikationsfunktion 406 över ett Rx-gränssnitt med PCRF 404.

[00057] I ett första steg 4:1 etableras allmänt en SIP-session mellan terminal 400 och applikationsfunktion 406. Enligt gällande rutiner skickar sedan applikationsfunktion 406 ett AAR-meddelande till PCRF 404, i ett nästa steg 4:2, huvudsakligen för att begära auktorisering av terminal 400. När detta 534 032 16 tiänsterelaterade meddelande detekteras av PCRF 404, eller av en aktiv prob pä Rx- gränssnittet, loggas meddelandetyp AAR och aktuell tid T, som en meddelandehändelse i en sessíonsdatabas (ei visad), vilket schematiskt indikeras i figuren.

[00058] l detta signaleringsexempel initierar terminalen 400 ett PDP-kontext för den kommande mediasessionen. Vid någon tidpunkt skickar således terminalen 400 en begäran om PDP-kontext till GGSN 402, i ett ytterligare steg 4:3, vilket i sak är en begäran om nätresurser för en kommande mediasession reglerad av applikationsfunktion 406.

[00059] GGSN 402 skickar sedan ett CCR-meddelande till PCRF 404 enligt gällande rutiner, i ett nästa steg 4:4. När detta tiänsterelaterade meddelande detekteras av PCRF 404, eller av en aktiv prob pä Gx-gränssnittet, loggas meddelandetyp CCR och en aktuell tid T, som en meddelandehändelse i sessionsdatabasen. Efter behandling av CCR-meddelandet skickar PCRF 404 ett CCA-meddelande tillbaka till GGSN 402, i ett steg 4:5. Detta meddelande loggas på samma sätt som en meddelandehändelse i sessionsdatabasen, inklusive meddelandetypen CCA och en aktuell tid T3. Ett föliade steg 4:6 illustrerar ett svarsmeddelande till terminal 404 frän GGSN 402 som indikerar att ett PDP-kontext har etablerats.

[00060] l ett ytterligare steg 4:7 skickar PCRF 404 ett AAA-meddelande till applikationsfunktion 406, som svar pä AAR-meddelandet enligt gällande rutiner.

När detta tiänsterelaterade meddelande detekteras, loggas meddelandetypen AAA och en aktuell tid T, som ännu en meddelandehändelse i sessionsdatabasen. l sak godkänner detta meddelande terminal 400 mot applikationsfunktion 406, och mediasessionen kan sedan genomföras enligt ett steg 4:8.

[00061] Detta exempel fortsätter med avslutning av mediasessionen med hjälp av en metod som kallas "SlP BYE", i ett steg 4:9. Applikationsfunktionen 406 skickar 534 032 17 sedan ett STR-meddelande till PCRF 404 i ett steg 4: l 0, för att där avsluta sessionen. Når detta ticinsterelaterade meddelande detekteras, loggas meddelandetypen STR och en aktuell tid T5 som önnu en meddelandehåndelse i sessionsdatabasen.

[OOO62] PCRF 404 tar vidare emot ett CCR-meddelande från GGSN 402 enligt gällande rutiner, i ett nåsta steg 4:1 l. Vid någon tidpunkt avaktiveras också PDP- kontext i ett steg 4: l 2, vilket i praktiken faktiskt involverar ett begörande meddelande från terminal 400 och ett svarsmeddelande från GGSN 402. PCRF 404 svarar på CCR-meddelandet genom önnu ett CCA-meddelande tillbaka till GGSN 402, i ett ytterligare steg 4zl3. Såsom indikeras i figuren, når dessa tiönsterelaterade meddelanden detekteras, loggas meddelandetyperna CCR och CCA samt aktuella motsvarande tidsståmplar Tó respektive T7, som ytterligare meddelandehöndelser i sessionsdatabasen.

[00063] Slutligen svarar PCRF 404 på det STR-meddelande som mottogs i steg 4: l O, genom att skicka ett STA-meddelande tillbaka till applikationsfunktionen 406, i ett steg 4:14, för att bekräfta att sessionen har avslutats på rått sött. Når detta tiönsterelaterade meddelande detekteras, loggas också meddelandetypen STA och en aktuell tid Ta som en meddelandehöndelse i sessionsdatabasen.

[00064] Således har icke mindre ön åtta tiånsterelaterade meddelanden detekterats och loggats som rådata i sessionsdatabasen under det ovan beskrivna exemplet i figur 4: AAR (L), CCR (TQ), CCA (Ta), AAA (TÅ), STR (Ts), CCR (Tó), CCA (Ty), och STA (TB). Föliaktligen har en sessionspost skapats i sessionsdatabasen som inkluderar åtminstone ovanstående sekvens av meddelandehåndelser med tidsstömplar, vilken åven kan inkludera en tiönsteidentifierare och eventuellt annan tiönste- eller sessionsrelaterad information. Exempelvis kan sessionsposten ytterligare inkludera identiteter för användare, terminalen, och för Gx- och Rx-sessionerna. 534 032 18 Denna ytterligare information kan sedan användas för att ta fram statistik om tjänsteprestandan för olika användargrupper, utrustningstyper, och så vidare.

[00065] Dessutom kan Gx- och Rx-protokollen i PCRF 404 innehålla övervakningstidtagare och en tillståndshanteringsfunktion, för att detektera huruvida en oväntad signal anländer i ”fel” tillstånd, eller om en förväntad signal inte lyckas anlända inom en viss tidsperiod. I så fall bör också sådan information inkluderas i sessionsposten.

[00066] l det tredje signaleringsexemplet som visas i figur 5, återigen involverande en mobil användarterminal 500, en GGSN 502, en PCRF 504 och en applikationsfunktion 506, antas att terminal 500 redan har etablerat ett PDF-kontext för en viss pågående mediasessíon. Såsom kommer att beskrivas nedan initierar accessnätet ett nytt PDP-kontext när sessionen modifieras på något sätt, exempelvis då andra nätresurser erfordras. Terminalen har således ett aktivt PDP-kontext, till exempel ett primärt PDP-kontext för SlP-signalering, vilket betyder att en IP-session är aktiv. Det är också möjligt att en mediasessíon även är aktiv. [000ó7] I ett första steg 5:1 modifieras mediasessíonen för en pågående lP-tjänst i en SIP-dialog mellan terminal 500 och applikationsfunktion 506. Exempelvis kan IP- tjänsten involvera en eller flera "deltjänster" som kan aktiveras och avaktiveras för att stödja den totala IP-tjänsten, vilket därmed kräver modifiering av den pågående sessionen, eller nya mediasessioner, etc. Detta resulterar i att applikationsfunktion 506 sedan skickar ett AAR-meddelande till PCRF 404 i ett nästa steg 5:2, vilket huvudsakligen begär en auktorisering av terminal 500. När detta meddelande detekteras, loggas meddelandetypen AAR och en aktuell tid T, som en meddelandehändelse i en sessionsdatabas. Vidare utlöser detta meddelande ett RAR-meddelande från PCRF 504 till GGSN 502, i ett följande steg 5:3, vilket i sak begär en ny auktorisering av terminalen. För denna meddelandehändelse loggas meddelandetypen RAR och en aktuell tid Tz i sessionsdatabasen. 534 032 19

[00068] RAR-meddelandet ör i siölva verket en begöran till GGSN 502 att installera nya regler för hantering av den nya eller modifierade mediasessionen.

RAR-meddelandet i steg 5:3 triggar GGSN 502 att initiera ett nytt PDP-kontext för terminalen 500 enligt den modifierade mediasessionen, i ett ytterligare steg 5:4. Ett föliande steg 5:5 illustrerar helt enkelt att nytt PDF-kontext etableras i en kommunikation mellan terminal 500 och GGSN 502. GGSN 502 skickar sedan ett RAA-meddelande till PCRF 504, i ett nästa steg 5:6, och bekröftar dörmed ny auktorisering av terminal 500, som svar på det Föregående RAR-meddelandet i steg 5:3. Nör detta meddelande detekteras loggas meddelandetypen RAA och en aktuell tid 13 som önnu en meddelandehöndelse i sessionsdatabasen.

[00069] PCRF 504 har nu möilighet att svara till applikationsfunktion 506 genom att skicka ett AAA-meddelande i ett steg 5:7, vilket loggas som en meddelandehöndelse i sessionsdatabasen innehållande meddelandetypen AAA och aktuell tid TA. Den modifierade mediasessionen kan sedan genomföras enligt ett steg 5:8.

[00070] Därefter avslutas mediasessionen med hiölp av metoden "SlP BYE", i ett steg 5:9. Applikationsfunktionen 506 skickar sedan ett STR-meddelande till PCRF 404 i ett steg 5:10, för att i denna avsluta sessionen. Når detta tiönsterelaterade meddelande detekteras, loggas meddelandetypen STR och en aktuell tid 15 som önnu en meddelandehöndelse i sessionsdatabasen. [00O7l] PCRF 504 tar vidare emot ett RAR-meddelande från GGSN 502 i detta fall, i ett nösta steg 5:1 1. PDP-kontext avaktiveras sedan i ett steg 5:12. PCRF 504 svarar på RAR-meddelandet genom ännu ett RAA-meddelande tillbaka till GGSN 502, i ett ytterligare steg 5:13. Såsom indikeras i figuren, och nör dessa tiönsterelaterade meddelanden detekteras, loggas meddelandetyperna RAR och RAA samt aktuella motsvarande tidsstömplar Tó respektive T7, som ytterligare meddelandehöndelser i sessionsdatabasen. 534 032 20

[00072] Slutligen svarar PCRF 504 på det i steg 5: l 0 mottagna STR-meddelandet, genom att skicka ett STA-meddelande tillbaka till applikationsfunktionen 506, i ett steg 5:14, för att bekräfta att sessionen har avslutats på rött sätt. När detta tjänsterelaterade meddelande detekteras, loggas också meddelandetypen STA och en aktuell tid TS som en meddelandehändelse i sessionsdatabasen.

[00073] Således har åtta tjänsterelaterade meddelanden detekterats och loggats som rådata i sessionsdatabasen under det ovanbeskrivna tredje exemplet i figur 5: ÅÅR (Tj), RÅR (Tz), RÅÅ (T3), ÅÅÅ (L), STR (T5), RÅR (n), RÅÅ (T7), och STA (Ta).

Som ett resultat av detta har en sessionspost skapats i sessíonsdatabasen som inkluderar åtminstone ovanstående sekvens av meddelandehändelser med tidsstämplar, och eventuellt också en tjänsteidentifierare.

[00074] Figur 3 - 5 illustrerar således tre olika exempel vid utnyttjande av tjänst där prestandaindíkatorer kan mötas med hjälp av de loggade tjänsterelaterade meddelanden som kommuniceras med policykontrollnoden. Naturligtvis kan ett flertal andra signaleringsprocedurer utnyttjas för olika situationer vid användning av tjänster, för vilka tjönsterelaterade meddelanden till/från policykontrollnoden kan loggas på detta sätt, och föreliggande uppfinning är inte begränsad till de tre ovan beskrivna exemplen.

[OOO7 5] Det kommer nu att beskrivas hur olika exempel på prestandaindikatorer A) - G) kan mätas genom filtrering av loggad rådata, exempelvis enligt signaleringsexemplet i figur 4 ovan och genom att använda motsvarande fördefinierade algoritmer, som huvudsakligen implementerar steg 208 och 2lO i proceduren i figur 2.

[OOO76] Prestandaindikator Al: ”Andelen av tillqänqliqhet för tjänster”. Denna prestandaindikator kan användas för att beskriva sannolikheten för att få kontakt med en mobil IP-telefontjänst när den begärs. A) mäts upp som antalet framgångsrika uppkopplingsförsök i relation till det totala antalet 534 032 21 uppkopplingsförsök. Frän den initierande användarens synvinkel, efter att ha tryckt på en skicka-knapp på sin terminal, anses uppkopplingsförsöket ha lyckats när en kopplingston hörs som indikerar att den motstående terminerande terminalen ringer.

[OOO77] Genom att använda föreliggande lösning för exemplet i figur 4, kan prestandaindikator A) mötas vid policykontrollnoden PCRF 404 genom att applicera ett motsvarande prestandafilter som tillhandahåller meddelandet AAR (TI) mottaget av PCRF 404 i steg 4:2 som en starttrigger och meddelandet AAA (L) skickat av PCRF 404 i steg 4:7 som en stopptrigger, eftersom det sistnämnda meddelandet bekräftar att uppkopplingsförsöket har lyckats.

[OOO78] Prestandaindikator Bl: ”ugrgättninqflzl av tiänst”. Denna prestandaindikator kan användas för att mäta den tid det tar att för att sätta upp en session, exempelvis ett MMTel-samtal. Bl mäts som tiden mellan en starttrigger för uppsättningen när den initierande användaren begär tjänsten, och en stopptrigger för uppsättningen när den terminerande användaren erhäller en ringsignal. Frän den initieranden användarens synvinkel är tiden för uppsättning av tiänst perioden mellan den tid dä skicka-knappen trycks ned och tidpunkten då en ringsignal hörs vid den motstående terminalen.

[00079] I exemplet i figur 4 kan prestandaindikator B) mätas som tiden mellan de filtrerade meddelanden då PCRF 404 tar emot meddelandet AAR (TI) och skickar meddelandet AAA (L), det vill säga T, - TI.

[00080] Prestandaindikator Cl: ”Andelen avbrutna tiänstesessioner". Denna prestandaindikator kan användas för att beskriva sannolikheten att en med framgång initierad session avslutas oavsiktligt. C) mäts som antalet oavsiktligt avslutade sessioner i förhållande till antalet med framgäng initierade sessíoner. Ur användarens synvinkel är en startrigger för denna prestandaindikator när en ring- eller upptagetton hörs från den motstående terminerande parten vid den initierande terminalen, och en stopptrigger är när sessionen avslutas av antingen den 534 032 22 initierande parten eller den terminerande parten, som bekröftar att sessionen har avslutats avsiktligt. lOOOßl) l exemplet i figur 4 kan prestandaindikator C) mötas genom att applicera ett prestandafilter som tillhandahåller meddelandet AAA (Td) skickat från PCRF 404 i steg 4:7 som en starttrígger, och meddelandet STR (T5) mottaget av PCRF 404 i steg 4: l O som en stopptrigger, eftersom det sistnämnda meddelandet indikerar att sessionen har avslutats på rött sött vid applikationsfunktionen 406. Följaktligen har den med framgång initierande sessionen avslutats oavsiktligt om det sistnömnda meddelandet inte har loggats.

[OOO82] Prestandaindikator Dl: ”Andelen fullbordade flönstesessioner”. Denna prestanda indikator kan anvöndas för att beskriva hur ofta en med framgång initierad session, som upprätthålls under en viss tid, avslutas med avsikt av antingen den initierande parten eller den terminerande parten. D) möts som antalet oavsiktligt avslutade sessioner i förhållande till det totala antalet med framgång initierade sessioner. Ur anvöndarens synvinkel ör start- och stopptriggers för denna prestanda indikator desamma som för prestandaindikator C) ovan.

[OOO83] På samma sött med hönvisning till figur 4, kan prestandaindikator D) mötas från meddelandet AAA (L) som utgör en starttrígger och meddelandet STR (T5) som utgör en stopptrigger, precis som för C). Således har den med framgång initierade sessionen avslutats avsiktligt om meddelandet STR (TS) har loggats.

[00084] Prestandaindikator El: ”Tiden för nedtaqninq av tiönst”. Denna prestanda- indikator kan anvöndas för att möta den tid det tar att avsluta en tiönstesession. E) möts som tiden mellan en starttrígger för nedtagningen då en av anvöndarna avslutar sessionen, och en stopptrigger för nedtagningen då sessionen har frigjorts i nötet. Från anvöndarens synvinkel ör en starttrígger för denna prestandaindikator nör någon av anvöndarna trycker på en knapp för att avsluta sessionen, och en stopptrigger ör nör sessionen har frigiorts. 534 032 23

[00085] I exemplet i figur 4 kan prestandaindikator E) mätas genom att applicera ett prestandafilter som tillhandhäller meddelandet STR (T 5) mottaget av PCRF 404 i steg 4:10 som en starttrigger, och meddelandet STA (Ta) skickat av PCRF 404 i steg 4:14 som en stopptrigger, där det sistnämnda meddelandet indikerar att sessionen avslutas vid applikationsfunktionen 406. Således kan prestandaindikator E) mötas som tiden mellan meddelandena STR (T5) och STA (TB), det vill säga Ta - TS.

[OOO86] Prestandaindikator Fl: ”Medelhälltid för tiänst". Denna prestandaindikator kan användas för att mäta medelvärdet för hela sessionens varaktighet, det vill säga den tidsperiod dä nätresurser erfordras. F) mäts som tiden mellan en starttrigger för uppsättningen dä den initierande användaren begär tjänsten, och en stopptrigger för nedtagningen dä sessionen har frigiorts i nätet.

[00087] I exemplet i figur 4 kan prestandaindikator F) mätas genom att applicera ett prestandafilter som tillhandahåller meddelandet AAR (T,) mottaget av PCRF 404 i steg 4:2, som en starttrigger och meddelandet STA (TS) skickat av PCRF 404 i steg 4:I4 som en stopptrigger. Således kan prestandaindikator F) mätas som tiden mellan meddelandena AAR (TI) och STA (Tal, det vill säga Te - TI.

[OOO88] Prestandaindikator Gl: ” Medelsessionstid för tiänst", Denna prestandaindikator kan användas för att beskriva medelvärdet av tiden för den konkreta delen av mediakommunikation i sessionen, det vill säga tiden för att konsumera tiänsten för vilken användaren huvudsakligen kan debiteras. G) mäts som tiden mellan en starttrigger för uppsättningen när den initierande användaren begär tiänsten, och en stopptrigger för nedtagningen när sessionen har frigiorts i nätet.

[00089] I exemplet i figur 4 kan prestandaindikator G) mätas genom att applicera ett prestandafilter som tillhandahåller meddelandet AAA (TÅ) skickat av PCRF 404 i steg 4:7 som en starttrigger, och meddelandet STR (TS) mottaget av PCRF 404 i steg 4: I O som en stopptrigger. AAA-meddelandet är det sista PCRF-meddelandet innan 534 032 24 mediasessionen kan utföras i steg 4:8, och STR-meddelandet är det första PCRF- meddelandet efter avslutning av sessionen av en användare i steg 4:8. Således kan prestandaindikator G) mötas som tiden mellan meddelanden AAA (TA) och STR (T5), det vill säga T5 - T,,.

[00090] De ovan beskrivna exemplen på prestandaindikatorer A) - G) kan mätas för ett flertal sessioner när lP-tjånster konsumeras eller anropas av olika användare, för att samla statistik och tillhandahålla relevant information om prestanda hos de aktuella IP-tjänsterna. Således kan ett utvärderingssystem för prestanda utformas så att en eller flera specifika prestandaindikatorer har valts ut på förhand för varje lP- tjänst, vilka år relevanta för den tjänsten. De tjånsterelaterade meddelandena detekteras vid policykontrollnoden varje gång en sådan IP-tjänst anropas, och de detekterade meddelandena loggas med tidsståmplar som rådata i en sessionspost.

För varje sessionspost applicerar sen filtermaskinen ett motsvarande prestandafilter på rådatan och beräknar prestandaindikatorn/indikatorerna från den filtrerade datan, till exempel på samma sätt som i exemplen ovan.

[OOO9l] På detta sätt kan prestandan hos IP-tjänsterna utvärderas med stor noggrannhet och relevans för användarens upplevelser, eftersom prestandaindikatorerna kan ”förfinas” på det beskrivna sättet. En enda IP- tjänstsession kan kräva ett flertal mediakomponenter, medan accesssnötet kommer att betrakta varje mediakomponent som en separat tjänst som kräver en specifik QOS. Om till exempel prestandaindikatorer mäts för både en initierande part och en terminerande part, kan prestandaindikatorer aggregeras som en kombination av dessa, för att möjliggöra utvärdering ”ände till ände”. Flera prestandaindikatorer kan också aggregeras över tiden för att uppdaga trender eller liknande.

[00092] Figur 6 illustrerar mer i detalj hur en filtermaskin óOO kan utformas för att åstadkomma den ovan beskrivna funktionaliteten, enligt en annan utföringsform.

Filtermaskinen 600 kan implementeras huvudsakligen som den filtermaskin l l2 som 534 032 25 beskrivs för figur l , innefattande en identifieríngsenhet 600a, en filtreringsenhet 600b, och en berökningsenhet 600c.

[00093] Filtermaskinen håller också en uppsöttning fördefinierade prestandafilter óOOd och motsvarande algoritmer 600e, vilka har förberetts i filtermaskinen 600 för olika prestandaindikatorer som kan mötas för olika lP-tjönster på ovan beskrivna sött. Det ör relativt enkelt att möjliggöra mötningar av prestandaindíkator för eventuella nya introducerade lP-tjönster, genom att förbereda nya filter och motsvarande algoritmer för tjänsterna i filtermaskinen.

[00094] Det bör noteras att denna figur endast illustrerar olika funktionella enheter i filtermaskínen 600 på ett logiskt sött, medan fackmannen ör fri att implementera dessa funktioner i praktiken genom att anvönda någon lömplig mjukvara och hårdvara. Således ör föreliggande uppfinning inte allmönt begrönsad till den visade konstruktionen av filtermaskínen 600.

[00095] Figur 6 illustrerar vidare en sessionsdatabas 602 (liknande databas l l0 i figur l) och en meddelandedetektor 604 för detektering av tjönsterelaterade meddelanden som kommuniceras med en policykontrollnod för tjönstesessioner.

Meddelandedetektorn 604 kan befinna sig i policykontrollnoden eller i aktiva prober installerade vid grönssnitt mellan policykontrollnoden och en gatewaynod i accessnötet och en applikatíonsfunktion som möjliggör den begörda lP-tjönsten.

Meddelandedetektor 604 tillhandahåller således tidsstömplade tjönsterelaterade meddelanden MlT) vilka loggas som rådata i sessionsdatabasen 602.

[00096] Under drift ör identifieringsenheten 600b utformad att mottaga rådata ”RD” för varje anropad lP-tjönst frön sessionsdatabas 602, inklusive tjönsterelaterade meddelanden och deras tidsstömplar, som meddelandehöndelser i en sessionspost som vidare kan innehålla en tjönsteidentífierare. Genom att lösa tjönsteidentifieraren, i förekommande fall, eller genom att analysera sekvensen av meddelandehöndelser i sessionsposten, kan identifieríngsenheten 600a identifiera 534 032 26 den lP-tjönst som har anropats och öven en eller flera prestandaindikatorer KPIA, KPIB, KPIC som ör relevanta för den IP-tjönsten.

[00097] ldentifieringsenheten óOOa ör också utformad att völja ett fördefinierat prestandafilter frön uppsöttningen av filter óOOd, för varje prestandaindikator som ör relevant för den identifierade tP-tjönsten eller identifierat flöde av tjönsterelaterade meddelanden. Varje prestandaindikator KPIA, KPIB, KPIC ör associerad med ett prestandafilter FA, FB, Fc samt motsvarande algoritm AA, AB, AC Eftersom flera prestandaindikatorer kan vara relevanta för en viss IP-tjönst, ör det möjligt att völja mer ön ett filter för samma sessíonspost, vilket illustreras av de streckade pilarna.

[00098] Filtreringsenheten óOOb ör utformad att applicera ett eller flera utvalda prestandafilter FA, FB, Fc på rådatan RC från identifieringsenheten óOOa, vilket illustreras med pilar från de fördefinierade filtren óOOd, för att dörmed skapa en eller flera uppsättningar filtrerat rådata RDlFAj, RD(FB), RDjfcl från varje filter.

Såsom nömnts ovan har olika fördefinierade prestandafilter óOOd och motsvarande algoritmer ó0Oe förberetts i filtermaskinen 600 för olika prestandaindikatorer.

Såsom nömnts ovan kan filtret också völjas endast från det identifierade flödet av tjönsterelaterade meddelande. Emellertid kan meddelandeflödet för en IP-tjönst variera, och i vissa fall kan meddelandeflödet vara förvanskat på grund av något nötfel eller förlorad kontakt. I sö fall kan identifieringsenheten óOOa vara utformad att könna igen det felaktiga meddelandet/ meddelandena och völja filter utifrön detta.

[00099] Berökningsenheten óOOd ör utformad att applicera en motsvarande algoritm AA, AB, AC pö varje uppsöttning med filtrerad data RDjFA), RDlFßl, RD(FC) frön filtreringsenhet óOOb, vilket visas med pilar från de fördefinierade algoritmerna 600e, för att dörmed skapa en eller flera prestanda indikatorer KPlA, KPIB, KPIC relevanta för den konsumerade eller anropade lP-tjönsten. Dessa 534 032 27 prestandaindikatorer kan sedan levereras till en funktion för utvärdering av tjänsteprestanda, såsom OSS l 14 i figur l, eller läggas i ett lämpligt lagringsorgan för senare användning.

[OOOl OO] Prestandafiltren 600d kan ha definierats med ytterligare kriteria, såsom användargrupp, tjänsteklass, område med IP-adresser för användarterminaler, nuvarande position, och så vidare, för att filtrera ut vissa tjänstesessioner av speciellt intresse enligt filterkriterierna. För att möjliggöra sådana ytterligare filtreringskriteria när man möter prestandaindikatorer, kan denna typ av tillagd information inkluderas i den sessionspost som loggas i sessionsdatabasen 602, eller skulle kunna tas fram från en SPR eller liknande, exempelvis baserat på identiteter för användaren eller terminalen, vilka tillhandahålls i sesstonsposten. Det kan exempelvis vara av intresse att utvärdera tjänsteprestandan för användare av en speciell tjänsteklass, till exempel "platinaanvändare", eller användare som tar emot en viss media, eller användare som befinner sig inom ett speciellt område eller som har en speciell typ av terminal, etc. Denna lösning medgör sådan ytterligare förfining av de uppmätta prestandaindikatorerna.

[OOOlOl] Det bör noteras att beskrivningen ovan av utföringsexempel avser allmänt mätning av en prestandaindikator för en enskild mediasession, för enkelhet skull. Emellertid involverar ofta en IP-tjänst ett flertal mediasessioner av varierande l varaktighet för olika mediakomponenter, vilka även aktiveras och avslutas vid olika tidpunkter när IP-tjänsten konsumeras. l så fall kan en prestandaindikator mätas på det ovan beskrivna sättet för varje mediakomponent, och de uppmätta prestandaindikatorerna skulle sedan kunna betraktas på lämpligt sätt vid utvärdering av den totala tjänsten. Varje prestandaindikator kan således mer eller mindre bidra till den totala prestandan för IP-tjänsten. [0OOlO2] Genom att implementera föreliggande uppfinning, exempelvis enligt någon av ovanbeskrivna utföringsformer, kan prestandaindikatorer som är relevanta 534 032 28 för vilka lP-tjänster som helst som involverar mediasessioner, enkelt erhållas från meddelanden som kommuniceras med en enda nod: policykontrollnoden. Denna lösning har ingen inverkan på nätets verkställande och kräver ett minimum av komplexitet för att användas. Exempelvis kan också värdefull information som normalt inte finns tillgänglig för IMS-nätet, användas för att mäta prestanda- indikatorer, såsom aktuell position, terminaltyp, uppkopplingstyp, och så vidare.

[000103] Vidare kan prestandaindikatorerna erhållas utan att ansluta till IMS- nätet eller de applikatíonsfunktioner som används, vilket gör att operatören av uppkopplingsnötet kan bevaka tjänsteprestanda även när IMS-nätet eller applikationsfunktionen befinner sig i en annan operatörsdomän. Denna lösning möjliggör också snabb och enkel användning av nya lP-tjänster. Prestanda- indikatorerna kan också genereras med stor flexibilitet exempelvis för olika mediakomponenter (såsom video och röstj, och beroende av eventuella fördefinierade filterkriteria.

[000104] Prestandaíndikatorerna kan genereras kontinuerligt i den mån som IP- tjänsterna konsumras av olika användare. Olika prestandaindikatorer kan också aggregeras över tiden för att uppdaga trender eller liknande. Samma rådata kan användas för att beräkna flera olika prestandaindikatorer, och prestandafiltrena kan anpassas för lP-tjänsterna på vilket sätt som helst. Specifika filter kan också väljas ut för varje utförd tjänstesession.

[000105] Medan uppfinningen har beskrivits med hänvisning till vissa utföringsexempel, är beskrivningen i allmänhet endast avsedd att illustrera uppfinningstanken och skall inte anses begränsa uppfinningens omfattning. Medan koncepten IMS, SIP, GGSN och PCRF har använts för att beskriva utföringsformerna ovan, kan vilka andra liknande lämliga standarder, protokoll och nätelement som helst huvudsakligen användas på det sätt som här beskrivits. Föreliggande uppfinning definieras allmänt av de följade självständiga patentkraven.

Claims (21)

1. 534 032 29 Patentkrav i . En metod att mäta en prestandaindikator som speglar prestandan hos en lP-tiänst i ett kommunikationsnöt när den konsumeras eller anropas av en användarterminal (100) i en tiänstesession, innefattande följande steg: detektera tiönsterelaterade meddelanden som kommuniceras med en policykontrollnod (106) för nämnda tiänstesession, - logga en meddelandetyp med en tidsstömpel tör varie detekterat tiänsterelaterat meddelande som rådata i en sessionspost, lör att därmed skapa en sekvens av meddelandehändelser i sessionsposten, dör nämnda tidsstämpel indikerar tiden För kommunikation av meddelandet. - välja ett tördetinierat prestandatilter associerat med prestandaindikatorn baserat på information i sessionsposten, - applicera det valda prestandatiltret på nämnda rådata i en tíltermaskin (i 12), och - beräkna prestandaindikatorn från den filtrerade datan enligt en törbestömd algoritm som motsvarar det applicerade prestandatiltret.

2. En metod enligt krav i, varvid prestandatiltret välis ut baserat på en IP- tiönstidentitierare som är inkluderad i sessionsposten.

3. En metod enligt krav l, varvid prestandatiltret välis ut baserat på sekvensen av mecldelandeliändelser i sessionsposten.

4. En metod enligt något av kraven 1-3, varvid policykontrollnoden kommunicerar nämnda tjänsterelaterade meddelanden med en gatewaynod i accessnätet eller med en applikationstunktion som tillhandahåller den begärda lP-tiånsten. 534 032 30

5. En metod enligt krav 4, varvid de tjänsterelaterade meddelandena detekteras av policykontrollnoden eller av aktiva prober installerade vid gränssnitt med gatewaynoden respektive applikationsfunktíonen.

6. En metod enligt krav 4 eller 5, varvid de tjänsterelaterade meddelandena är DlAMETER-meddelanden som kommuniceras över ett Gx-gränssnitt med gatewaynoden eller kommuniceras över ett Rx-gränssnitt med applikationsfunktionen.

7. En metod enligt något av kraven 1-6, varvid applicering av det utvalda prestandafiltret tillhandahåller ett tidsstämplat första tjänsterelaterat meddelande som en starttrigger och ett tidsstämplat andra tjänsterelaterat meddelande som en stopptrigger, för mätning av prestandaindikatorn.

8. En metod enligt något av kraven 1-7, varvid den beräknade prestandaindikatorn rapporteras till en funktion för utvärdering av tjänster, eller läggs i ett lagringsorgan för senare användning.

9. En metod enligt något av kraven 1-8, varvid ett flertal prestandaindikatorer mäts samtidigt för nämnda tjänstesession, genom att applicera olika associerade prestandafilter på samma rådata och beräkna prestandaindikatorerna från den filtrerade datan genom att använda motsvarande algoritmer.

10. En metod enligt något av kraven 1-9, varvid en eller flera specifika prestandaindikatorer har valts ut i förväg för var och en av ett flertal olika lP- tjänster som varande relevant för den tjänsten, och ett fördefinierat prestandafilter och motsvarande algoritm har förberetts i filtermaskinen för varje specifik prestandaindikator. 534 032 31

11. 1 1. En metod enligt något av kraven 1-10, varvid ytterligare kriteria har definierats i prestanda filtren, inklusive minst en av: anvöndargrupp, tiönsteklass, terminaltyp, mediatyp, område med IP-adresser för anvöndarterminalen samt aktuell position, för att Filtrera ut vissa tiönstesessioner av speciellt intresse enligt nämnda ytterligare filterkriteria.

12. En metod enligt krav 1 1, varvid nämnda ytterligare filterkriteria reagerar på information i sessionsposten eller på information som tas fram från en SPR baserat på identiteter för användaren eller terminalen som tillhandahålls i sessionsposten.

13. En metod enligt något av kraven 1-12, varvid flera prestandaindikatorer aggregeras över tiden för att uppdaga trender.

14. En apparat för att möta en prestandaindikator som speglar prestandan hos en lP-tiönst i ett kommunikationsnåt når den konsumeras eller anropas av en anvöndarterminal i en tiånstesession, innefattande: - en meddelandedetektor (604) konfigurerad att detektera tiönsterelaterade meddelanden som kommuniceras med en policykontrollnod för nömnda tiönstesession, - en sessionsdatabas (602) konfigurerad att logga en meddelandetyp med en tidsstömpel för varie detekterat tiönsterelaterat meddelande som rådata i en sessionspost, för att därmed skapa en sekvens av meddelandehöndelser i sessionsposten, dör nömnda tidsstömpel indikerar tiden för kommunikation av meddelandet, och - en filtermaskin (600) konfigurerad att vålia ett fördefinierat prestandafilter associerat med prestandaindikatorn baserat på information i sessionsposten, applicera det valda prestandafiltret på nämnda rådata, 534 032 32 samt beräkna prestandaindikatorn frän den filtrerade datan genom att använda en förbestämd algoritm som motsvarar det applicerade prestandafiltret. l5.

15. En apparat enligt krav 14, varvid nämnda filtermaskin innefattar: - en identifieringsenhet jóOOa) konfigurerad att ta emot nämnda rödata från sessionsdatabasen, identifiera nämnda IP-tjänst samt även en eller flera prestandaindikatorer som är relevanta lör den lP-tjänsten, och att välja ut ett fördefinierat prestandafilter frön en uppsättning filter jóOOd) för varje prestandaindikator som är relevant för den identifierade lP-tjänsten, - en filtreringsenhet (óOOb) konfigurerad att applicera det utvalda prestandafiltret pä nämnda rödata, och - en beräkningsenhet (óOOc) konfigurerad att beräkna prestandaindikatorn frän den filtrerade datan genom att använda nämnda fördefinierade algoritm. ló.

16. En apparat enligt krav 15, varvid identifieringsenheten är vidare konfigurerad att välja ut prestandafiltret baserat pä en IP-tjänstidentifierare som är inkluderad i sessionsposten.

17. l7. En apparat enligt krav 15, varvid identifieringsenheten är vidare konfigurerad att välja ut prestandafiltret baserat pä sekvensen av meddelandehändelser i sessionsposten.

18. l8. En apparat enligt nägot av kraven l4-l7, varvid meddelandedetektorn befinner sig i policykontrollnoden eller i aktiva prober installerade vid gränssnitt mellan policykontrollnoden och gatewaynoden respektive en applikationsfunktion som möjliggör den begärda lP-tjönsten. 534 032 33

19. En apparat enligt krav l5, varvid filtreringsenheten är vidare konfigurerad att tillhandahålla ett tidsstämplat första tiänsterelaterat meddelande som en starttrigger och ett tidsstämplot andra tiänstereloterat meddelande som en stopptrigger, för mätning av prestandaindikatorn.

20. En apparat enligt något av kraven l4-l 9, varvid filtermaskinen är vidare konfigurerad att rapportera den beräknade prestandaindikatorn till en funktion för utvärdering av tjänster, eller lägga den i ett lagringsorgan för senare användning.

21. . En apparat enligt nägot av kraven 14-20, varvid filtermaskinen är vidare konfigurerad att mäta ett flertal prestandaindikatorer samtidigt för nämnda tiänstesession, genom att applicera olika associerade prestandafilter på samma rädata och beräkna prestandaindikatorerna frän den filtrerade datan genom att använda motsvarande algoritmer.