NO318974B1 - Distribuert MCU - Google Patents

Description

Introduksjon/teknisk felt

Den foreliggende oppfinnelsen omhandler generelt videokonferanse-nettverksenheter, og mer spesifikt en fremgangsmåte og en innretning for automatisk generering og allokering av et optimalisert oppsett av multiple endepunkter til en multisite (multisted) forbindelsesenhet i en fordelt videokonferanse.

Oppfinnelsen omhandler videre en fremgangsmåte og innretning for fremvisning og administrering av et konsept med en fordelt MCU, innbefattet en master MCU og én eller flere slave MCU'er, forbundet sammen i en samtale i en distribuert videokonferanse.

Video- og audio konferering er en teknologi brukt for kommunikasjon over lange avstander. På grunn av mange problemer som oppstår under samtaleoppsett og samtalehåndtering, krever flere løsninger konferanseadministratorer for å sette opp og administrere konferansen. For å lette jobben med samtaleoppsett og konferanseadministrering, bruker mange store organisasjoner og tjenestetilbydereen sentralisert server kalt en multipunktkontrollenhet (MCU, Multi-point Control Unit). En MCU er en server brukt for å håndtere samtaler med multiple deltakere, eller å tillate en sentral samtalehåndtering av samtaler fra 2 til n deltakere.

Administrering av samtalen ved kun å ha tilgang til endepunkter (EP'er) er ikke en god løsning på grunn av nettverkstilgangsbegrensning, opplæring og utdannelse som er nødvendig for å forstå utstyr fra multiple produsenter og ulike versjoner fra

samme produsent. Et endepunkt (EP) er definert som video/audio terminal/telefon eller gateway brukt i en videokonferanse.

Ved å ha en sentralisert server (f.eks. MCU), kan konferanseadministratorer styre de fleste aspektene ved en samtale fra ett enkelt grensesnitt. Ettersom de fleste MCU'er tillater multiple konferanser, kan administratorene også monitorere multiple samtaler fra "det samme grensesnittet.

I dag finnes det systemer som letter håndtering av endepunkter og MCU'er slik som Polycom GMS, Polycom Conference Suite (også kjent som Applied Global Technologies (AGT) VCAS) og Forgent VNP - imidlertid løser de ikke problemet med et enkelt samtaleoppsett og håndteringsgrensesnitt. De krever fremdeles at en administrator forstår de ulike innretningene på nettverket.

Polycom GMS tillater monitorermg av samtaler mellom kun endepunkter. Polycom Conferance Suite (AGT VCAS) tillater monitorering av samtaler ved et system på systemnivå.

Forgent VNP tillater monitorering av samtaler og samtaleoppsett av et system på systemnivå.

TANDERG Management Suite tillater monitorering av samtaler ved et system ved systemnivå.

Som et eksempel kan det nevnes at eksisterende video- og audiokonferansesystemer tillater en å gå inn i systemet og fremvise/editere samtaler. TMS, Forgent VNP og Polycom Conference Suite tillater også at en kan gjøre samtaleoppsett, men håndterer ikke kaskade MCU-forbindelser, eller fremviser konferansen som én enhet - kun som et system ved systemnivå.

Det finnes et flertall problemer ved å bruke sentraliserte servere (MCU'er). De kan ha store størrelser og kostnader på grunn av behovene for å håndtere topphendelser. For å håndtere de fleste hendelsene er ofte MCU'ene overdimensjonert sammenlignet med gjennomsnittelig bruk og konferanseantall. Dette er en nødvendighet for å håndtere topphendelser som typisk oppstår i hovedarbeidstimene. Dette problemet er typisk ikke på grunn av størrelsen av en enkelt konferanse, men på grunn av mengden av konferanser som foregår. Ettersom punkt-til-punkt samtaler også krever håndtering, må disse også bli rutet gjennom en sentralisert server, som krever ressurser.

Økte samtalekostnader på grunn av plassering av server er en viktig faktor. Ettersom det er typisk å ha kun et fåtall store sentraliserte servere (MCU'er) må alle samtaler settes opp for å gå til og fra en sentralisert server. F.eks. dersom et selskap har en MCU lokalisert i London, England - dersom en samtale skal utføres mellom en lokasjon i Sverige og Norge, må en samtale bli gjort mellom siten i Sverige og MCU'en i London, og en annen samtale må settes opp mellom siten i Norge og MCU'en i London. Dersom det ikke var noen sentraliserte håndteringsbehov, kunne denne samtalen blitt utført med kun én samtale direkte mellom sitene i Norge og Sverige.

En sentralisert video- og audiokonferanseserver er ikke noe forskjellig fra andre servere, ved at dersom serveren feiler, vil alle samtaler rutet gjennom serveren også feile, dvs. ett enkelt punkt for feiling (eng: single point of failure).

Med hensyn til problemene beskrevet over har løsningen i henhold til den foreliggende oppfinnelsen følgende fordeler: Stor størrelse og kostnader på grunn av behov for å håndtere topphendelser minimaliseres mye. Ettersom ingen enkel konferansesenter (MCU) er nødvendig, kan multiple mindre enheter, eller MCU'er tilgjengelig direkte i et endepunkt bli brukt. Det er heller ikke noe behov for å overdimensjonere mengden av MCU'er ettersom det er mye mindre administrasjonskostnader for å håndtere mange konferanser siden punkt-til-punkt samtaler vil bli opprettet direkte mens samtaler som krever mange deltakere som ingen enkle MCU'er kan håndtere vil bli splittet mellom mange mindre MCU'er.

Ettersom det ikke lenger er nødvendig for et enkelt punkt med administrering som krever en stor MCU, kan mange mindre MCU'er bli plassert i forretningsområdene til et selskap, og dermed redusere samtalekostnadene på grunn av plassering av servere. Siden mange endepunkter har interne MCU-rriuligheter, eller samtaler kun er mellom to systemer, er det ikke behov for en ekstern MCU, noe som tillater at samtalen kan utføres direkte mellom systemene i konferansen.

Siden løsningen vil virke selv om noen av MCU'ene ikke er tilgjengelige eller nede, er det ingen "single point of failure".

Sammendrag av oppfinnelsen

En hensikt med den foreliggende oppfinnelsen er å tilveiebringe en fremgangsmåte og innretning som nevnt i introduksjonen som overvinner de beskrevne ulempene til tidligere kjent teknikk.

Et første aspekt ved oppfinnelsen er derfor å tilveiebringe en fremgangsmåte og innretning for automatisk generering og allokering av optimalisert oppsett av multiple endepunkter (EP'er) til multi site forbindelsesenheter (MCU'er) i et distribuert videokonferansesystem. Fremgangsmåten omfatter et første trinn med estimering av antall MCU'er nødvendig, basert på antall EP'er som er nødvendig for å bli forbundet i en videokonferansesesjon, etterfulgt av et andre trinn, hvor det sjekkes at det er tilstrekkelig antall av MCU'er tilgjengelig i henhold til estimeringen ved å allokere hver EP til en MCU, og til slutt optimalisere trinnet med en endelig allokering av EP'er til MCU'er, ved å forbinde EP'er til MCU'er i henhold til en vektefunksjon.

Når et planlagt møte inneholder flere konferansesystemer enn de tilgjengelige ressursene på enhver enkel MCU på nettverket, er det nødvendig å kaskadere (eng: cascade) MCU'ene. Den oppfmneriske fremgangsmåten vil automatisk sette opp kaskaderte MCU-samtaler.

EP'ene og MCU'ene kan i noen tilfeller være de samme fysiske innretningene.

Et annet aspekt ved den foreliggende oppfinnelsen er å tilveiebringe en fremgangsmåte og innretning for fremvisning og administrering av mange videokonferanseinnretninger innenfor et nettverk. Fremgangsmåten omfatter et første trinn med innsamling og sammenslåing av samtaleinformasjon slik som protokoller og varighet fra innretningene i samtalen, etterfulgt av å sjekke om masterinnretningen er i stand til å utføre en spesifikk kommando ved mottak av en administrasjonsfunksjon, etterfulgt av å sjekke om en slaveinnretning er i stand til å utføre en spesifikk kommando dersom masterinnretningen ikke er i stand til å utføre nevnte kommando, etterfulgt av å sjekke om endepunktet (EP) som kommandoen f

skal utføres på er i stand til å utføre den spesifikke kommandoen dersom master-eller slaveinnretninger ikke er i stand til å utføre denne kommandoen. Det siste trinnet er å utføre kommandoen på innretningen som er i stand til å utføre den spesifikke kommandoen.

En innretning kan være ethvert element brukt i samtaleoppsettet av to eller flere videokonferanser, dvs. MCU, Gateway (som forbinder ulike nettverk sammen, f.eks. 1P og ISDN), Gatekeeper (opptrer som et sentralt kontrollpunkt og tilveiebringer samtalekontrolltjenester til registrerte endepunkter), og EP etc.

Hensiktene beskrevet over blir oppnådd ved hjelp av en fremgangsmåte og en innretning som er fremsatt i det vedlagte kravsettet.

Detaljert beskrivelse av en foretrukket utførelse

Oppfinnelsen vil bli beskrevet videre i detalj med henvisning til figurene, hvor: Fig. 1 er et skjematisk blokkskjema som illustrerer et samtaleoppsett mellom grupper av systemer. Fig. 2 er et skjematisk blokkdiagram som illustrerer et samtaleoppsett mellom to tilgjengelige MCU'er. Fig. 3A er et flytskjema som illustrerer en implementering av en distribuert samtaleløsning i henhold til den oppfinneriske fremgangsmåten.

Fig. 3B er den optimaliserte delen av flytskjemaet illustrert i fig. 3A.

Fig. 1 viser et eksempel på hvordan en samtale kan bli satt opp mellom en gruppe av systemer. Øverst til venstre er det tre systemer som er forbundet til en ekstern MCU A. Øverst til høyre er det tre andre systemer som er forbundet til en ekstern MCU B. Det er også en samtale mellom MCU A og B som overfører informasjon mellom de to. Nederst på figuren, har et endepunkt med en innebygd MCU to andre systemer forbundet til seg. Dette gir en total på ni endepunkter forbundet til en enkelt konferanse.

Den første delen av denne oppfinnelsen er å rute samtalen på en slik måte at alle systemene forbindes automatisk. Dette kan gjøres med hensyn til ulike faktorer (samtalekostnader, kvalitet, muligheter, etc). Denne fremgangsmåten tillater samtalen å bli satt opp uten å ha en sentralisert lokasjon.

Den andre og unike delen av denne oppfinnelsen er å ha én eller flere tjenester som aktivt administrerer og monitorerer systemene i konfigurasjonene. Administratoren blir da gitt et enkelt grensesnitt for å sette opp, monitorere og håndtere samtalen. F.eks. for å forandre personen som har gulvet (engelsk: floor) (som har sin lyd og/eller video matet til alle andre deltakere) til konferansen, må en forespørsel bli sendt til MCU A, MCU B og den interne MCU'en. I stedet for løsningen brukt i dag

- hvor administrator må gå inn i hver av disse enhetene for å forandre sarntaleflyten, forandrer administratoren denne settingen på én lokasjon, noe som besørger at en kjede av handlinger utføres på de nødvendige enhetene i samtalen - på en slik måte at det for sluttbrukerne ser ut som om samtalen var administrert fra en sentralisert

MCU.

Fig. 2 illustrerer et eksempel på et samtaleoppsett med to tilgjengelige MCU'er. Den viser hvordan den oppfinneriske fremgangsmåten setter opp en distribuert samtale. Dette eksemplet involverer en samtale med 14 videokonferansesystemer. 1 stedet for at en bruker må sette opp en hel distribuert konferanse manuelt, genererer den oppfinneriske fremgangsmåten automatisk en optimalisert kaskadet multi-MCU-løsning hvor det er flere konferansesystemer enn tilgjengelige ressurser på en enkel MCU.

Anta at vi har 14 videokonferansesystemer, hvor 7 er lokalisert i Dallas, Texas, USA, 4 er lokalisert i New York City, New York, USA og 3 er lokalisert på Lysaker, Oslo, Norge. Vi har også to MCU'er, én i Dallas og én på Lysaker. MCU'en i Dallas har nok ressurser til å holde ti av systemene mens MCU'en på Lysaker har nok ressurser til å holde 8 systemer.

Siden ingen MCU'er har nok ressurser til å holde alle 14 systemene må vi kaskadere to MCU'er sammen. Vi plasserer alle 7 systemene fra Dallas på Dallas-MCU'en fordi de er nærmest og plasserer også to systemer fra New York på samme MCU. Den resterende tiende ressursen blir brukt til å linke opp den andre MCU'en i Norge. Siden Dallas-MCU'en nå er full, plasserer vi de tre systemene på Lysaker på Lysaker-MCU'en og gjenstående to systemer fra New York på denne MCU'en også.

Fig. 3A viser prosessen involvert i å lage en distribuert MCU-samtale. Fremgangsmåten for automatisk generering og allokering av optimalisert oppsett av multiple endepunkter (EP'er) til multiforbindelsesenheter (MCU'er) i et distribuert videokonferansesystem omfatter følgende trinn.

Det første trinnet 100 er å generere en MCU prioritetsliste av tilgjengelige MCU'er basert på en vektefunksjon som i sin tur er basert på enhver ønskelig karakteristikk eller egenskap av MCU'ene og antall EP'er. Dette kan være størrelsen på tilgjengelige prosesseringsressurser i MCU'ene, og båndbredden som ressursene krever for at MCU'en forbindes til EP'ene. Fra denne liste blir MCU'ene med den beste vekten valgt som masteT MCU.

Det neste trinnet 110 er å estimere antall av MCU'er som er nødvendig, basert på antall av EP'er som er nødvendig for å bli forbundet i foreliggende videokonferanseseksjon. Fra dette blir det i trinn 120 sjekket om det er nok MCU'er. Dersom dette ikke er tilfelle, blir en feilmelding fremvist 140, og prosessen med å lage en distribuert MCUrsamtale vil stoppe. Dersom det er nok MCLPer, vil prosessen fortsette med flere undertrinn.

Det første undertrinnet 130 er å legge til nødvendige MCl<T>er fra prioritetslisten generert i trinn 100 til en database "valgt" liste som inneholder de valgte MCU'ene.

Neste undertrinn 160 er å beregne nødvendige linker fra master-MCU til de andre MCU'ene i MCU-databaselisten"generert i trinn 130.

Dette blir etterfulgt av undertrinn 170 hvor master MCU'en blir allokert til EP'en til videokonferanseledereh (dersom denne finnes). Videokonferanselederen er EP'en som mater audio og/eller video, til alle andre deltakere.

I trinn 180, blir neste MCU i "valgt" liste generert i trinn 130 prosessert. Den første gangen vil dette være master-MCU, den andre gangen vil det være MCU'en med den andre beste vektfunksjonen etter master-MCU'en etc.

I trinn 190 blir en beregning utført, av samtalevekt for hver EP hvor kostnadene til en samtale mellom EP og MCU er blant faktorene som innbefattes i vektingen. Dette blir etterfulgt av trinn 200 hvor en EP prioritetsliste for hver MCU blir generert, dvs. en samtalevekt for hver EP til de forskjellige MCU'ene i den "valgte" listen generert i trinn 130.

I trinn 210 blir det sjekket om det eT gjenværende EP'er i EP-prioritetslisten generert i trinn 200. Dersom dette ikke er tilfelle, har alle endepunktene i EP-prioritetslisten blitt prosessert, og en optimaliseringsrutine blir initiert i trinn 300. Dersom denne er vellykket, vil alle systemene i den foreliggende videokonferansen bli forbundet sammen på en optimalisert måte. Optimaliseirngsrutinen er beskrevet i detalj med henvisning til fig. 3B i det følgende.

Dersom det er gjenværende EP'er i EP-prioritetslisten, blir en ny test utført i trinn 220, som sjekker om den foreliggende MCU'en prosessert i henhold til trinn 180 er full. Dersom den ikke er dette, blir den første EP'en i EP-prioritetslisten generert i trinn 200 allokert til den foreliggende MCU'en. Dette blir utført i trinn 230 etterfulgt av trinn 240 hvor den første EP'en blir fjernet fra EP-prioritetslisten. Løkken omfattende trinnene 210, 220, 230 og 240 blir utført inntil alle EP'ene har blitt allokert til en MCU, eller inntil foreliggende MCU er full, dvs. dens ressurser har blitt brukt opp. Dersom dette er tilfelle vil trinn 250 bli utført.

1 trinn 250, blir det utført en test om "valgt" liste generert i trinn 130 er tom. Dersom dette ikke er tilfelle, vil trinn 180 beskrevet over entres igjen, etterfulgt av 190, 200, etc. Dersom "valgt" liste er tom, blir en sjekk utført i trinn 230 om en ny MCU er tilgjengelig. Dersom dette er tilfelle, blir alle allokerte EP'er utført i trinn 230 deallokert i trinn 280, og prosessen starter på nytt fra trinn 160 etter å ha lagt til den nye MCU'en til den "valgte" listen. Dette blir utført i trinn 150. Dersom en ny MCU ikke er tilgjengelig, vil en feilmelding bli generert i trinn 270.

Det er ønskelig å optimalisere forbindelsen/allokeringen av EP'er og MCU'er utført i de tidligere trinnene. Dette fordi det i.noen tilfeller kan være ressurser som er mye bedre enn nødvendig og derfor dyrere.

Fig. 3B viser prosessen involvert i optimalisering av den endelige distribuerte MCU-ruten. Fremgangsmåten for optimalisering blir utført når alle EP'er har blitt allokert til en MCU, dvs. ingen feilmeldinger har oppstått.

Optimaliseringsfremgangsmåten starter i trinn 400 ved å deallokere EP'er fra alle bortsett fra master-MCU'en. Deallokeringslister blir generert fra den genererte prioritetslisten til allokerte EP'er til MCU'er utført i trinn 230.

I trinn 410, blir den neste EP'en i den deallokerte listen lokalisert, og i trinn 430 blir den neste MCU'en i den deallokerte listen lokalisert: I trinn 430 blir en rute mellom EP'en og MCU<*>en laget. Dette blir etterfulgt i trinn 440 ved å legge til en rute til samlingen av ruter.

I trinn 450 blir det sjekket om slutten åv den deallokerte MCU-listen har blitt nådd, dersom dette ikke er tilfelle, vil trinn 420 entres igjen, og trinnene 420, 430, 440 og 450 vil bli utført inntil en rute mellom den foreliggende EP'en og MCU'ene i den ■ deallokerte listen har blitt laget. Dersom slutten av den deallokerte MCU-listen har blitt nådd, blir en ny test utført i trinn 460. I dette trinnet blir det undersøkt om slutten av EP-listen har blitt nådd. Dersom dette ikke er tilfelle blir MCU-deallokert listen resatt til første posisjon i trinn 470, og neste EP fra den EP-deallokerte listen blir lokalisert etterfulgt av trinnene 420-460 som beskrevet over. I trinn 460 blir det rapportert at slutten av EP-listen har blitt nådd, og trinn 480 påbegynnes.

I trinn 480 blir samlingen av ruter oppnådd i de foregående trinnene 400-460 sortert etter laveste vekt.

I trinn 490 blir neste rute mellom et EP og MCU i den sorterte samlingen av ruter lokalisert, og i trinn 500 blir det undersøkt om det er flere ressurser på en spesifikk MCU. Dersom dette ikke er tilfelle feilet, optimaliseringsprosessen og den opprinnelige løsningen som presentert før en gikk inn i trinn 300 blir presentert og eksekvert. Dersom det er nok ressurser på en spesifikk MCU vil trinn 520 påbegynnes.

I trinn 520 blir EP'en inneholdt i ruten allokert til MCU'en. Dette blir etterfulgt av trinn 530 hvor denne ruten blir fjernet fra samlingen.

En sjekk blir utført i trinn 540 på om det er noen flere ruter i samlingen av ruter. Dersom dette er tilfelle, vil trinn 490 igjen bli påbegynt, og de følgende trinnene 500-530 vil bli utført inntil alle rutene har blitt vurdert.

Optimaliseringsprosessen vil avslutte i trinn 500.

Den beskrevne fremgangsmåten tillater samtaler mellom videokonferansesystemer til å bli satt opp på en kostnadseffektiv måte og uten å ha en sentralisert lokasjon.

Fremgangsmåten beskrevet over med henvisning til tegningene 3A og 3B er vurdert1 å være den. beste moden, og innbefatter dermed de foretrukne trinnene. Avvik fra fremgangsmåten er mulig og vil være innenfor omfanget av oppfinnelsen.

Oppfinnelsen omhandler også en innretning for å utføre den automatiske genereringen og allokeringen av optimalisert oppsett av multiple EP'er til MCU'er i et distribuert videokonferansesystem i henhold til fremgangsmåten beskrevet over.

En annen hensikt med den foreliggende oppfinnelsen er å tilveiebringe en fremgangsmåte og innretning for å fremvise og administrere flere videokonferanseinnretninger innenfor nettverket. En videokonferanseinnretning kan være enhver innretning innbefattet i oppsettet av videokonferansen, f.eks. et endepunkt uten eller med intern MCU, gateway, gatekeeper, MCU, etc.

Monitorering: å se informasjonen om samtalen, deltakere og deres status.

Administrering: å være i stand til å forandre deltakernes status, legge til deltakere,

-fjerne deltakere, etc.

Monitorering og administrering av en videokonferanse blir utført etter vellykket avslutning av oppsett av innretningene som deltar i en videokonferanse.

Fremgangsmåten omfatter et første trinn med innsamling og sammenslåing av samtaleinformasjon slik som protokoller og varighet fra innretningene i samtalen. Dette blir gjort ved å la hver videokonferanseinnretning gjøre sitt supportnivå for ulike funksjoner tilgjengelig til et mellomlager for å øke prosesseringshastigheten. Dette trinnet blir etterfulgt av å sjekke om masterinnretingen (typisk en MCU - masterinnretningen i denne løsningen er enten master-MCU'en i kaskadede samtaler, MCU'en i ikke-kaskadede samtaler (intern eller ekstern MCU) eller endepunktet med flest muligheter i punkt-til-punkt samtale) er i stand til å utføre en spesifikk kommando (f.eks. muting, floor, volum, etc.) ved mottak av en administratorfunksjon. Dette blir etterfulgt av trinnet med å undersøke om slaveinnretningene er i stand til å utføre en spesifikk kommando dersom masterinnretningen ikke er i stand til å utføre nevnte kommando, etterfulgt av å sjekke om endepunktet som kommandoen skal bli utført på er i stand til å utføre den spesifikke kommandoen dersom master- eller slaveinnretningen ikke er i stand til å utføre denne kommandoen. Sluttrinnet er å eksekvere kommandoen på innretningene som er i stand til å utføre den spesifikke kommandoen.

I henhold til oppfinnelsen, er monitorering og administreringsbrukergrensesnittet operativt forbundet til videokonferanseinnretningene, dvs. at det ikke er nødvendig å utføre disse oppgavene fra en sentralisert server.

I de etterfølgende tre eksemplene blir utnyttelse av den oppfinneriske fremgangsmåten for fremvisning og administrering beskrevet. Det er antatt at systemene er forbundet og i samtale.

1 de forskjellige tilfellene, ønsker en ett grensesnitt for monitorering og håndtering

av alle samtaler. Beskrivelsen under viser hvordan dette blir gjort i henhold til fremgangsmåten beskrevet over.

Eksempel 1: Punkt-til-punkt

Monitorering: samtal einformasjon blir samlet fra ett av systemene i punkt-til-punkt konferansen. Dette systemet blir automatisk valgt av systemet med flest muligheter (MultiSite, ISDN-båndbredde). Dette systemet blir kalt MASTER-systemet. Denne informasjonen inneholder informasjon om protokoller, varighet, etc. Dersom det ene systemet er et utenfor-huset-system (eng: out-of-house system), blir systemet i-huset (eng: in-house) brukt for å samle denne informasjonen.

Administrasjon: Når en administratorfunksjon blir utført på konferansen, blir, avhengig av mulighetene til systemet, MASTER-systemet først sjekket. Dersom funksjonen ikke kan bli utført på det systemet blir det andre systemet brukt for å eksekvere funksjonen. Dersom det andre systemet ikke er in-house, feiler funksjonen (ingen systemer med mulighet for å eksekvere valgt funksjon). Volum og muting blir typisk kontrollert ved endepunktene som en ønsker å kontrollere, mens å legge til/fjerne deltakere og floor-kontroll blir utført på MASTER-systemet.

Eksempel 2: MCU (intern eller ekstern).

Monitorering: samtaleinformasjon blir samlet fra systemet i MCU-konferansen som er MCU'en. Dette systemet er kalt MASTER-systemet. Denne informasjonen inneholder informasjon om protokoller, varighet, etc.

Administrerasjon: Når en administratorfunksjon blir utført på konferansen - avhengig av mulighetene til systemet, blir MASTER-systemet først sjekket (MCU). Dersom funksjonen ikke kan bli utført på MASTER-systemet, blir systemet som funksjonen skal bli utført på undersøkt (f.eks. dersom MCU ikke støtter mutefunksjon, vil mute bli eksekvert på stedet hvor mutingen skal bli utført). Dersom andre systemer ikke er in-house, feiler funksjonen (ingen systemer med mulighet for å eksekvere funksjonen på). Typisk volum, mute (med intern MCU) blir kontrollert ved de individuelle endepunktene som en ønsker å kontrollere, mens å legge til/fjerne deltakere, mute (med ekstern MCU) og floor-kontroll blir utført på MASTER-systemet (MCU - enten internt eller eksternt).

Eksempel 3: Kaskadert/distribuert MCU (intern eller ekstern).

Monitorering: samtal einformasjon blir samlet og slått sammen fra alle systemene som opptrer som MCU'er i konferansen. Ett system vil være på toppen av kaskadering/distribusjon, dette systemet er kalt MASTER-systemet. Denne sammensatte informasjonen inneholder informasjon om protokoller, varighet, etc.

Administrasjon: Når en administrasjonsfunksjon blir utført på konferansen, avhengig av mulighetef til systemet, blir MASTER-systemet først undersøkt (master MCU). Dersom funksjonen ikke kan bli utført på MASTER-systemet, vil hver av de andre MCU'ene bli undersøkt (slave-MCU'er), dersom slave-MCU'er heller ikke ' understøtter funksjonen, blir systemet som funksjonen skal utføres på sjekket (f.eks. dersom master MCU og slave MCU ikke støtter mute, vil mute bli utført på stedet som skal mutes istedenfor). Dersom andre systemer ikke er in-house, feiler funksjonen (ingen systemer med mulighet for eksekvering av funksjonen). Typisk blir volum, mute (med intern MCU) kontrollert ved de individuelle endepunktene som en ønsker å kontrollere, mens å legge til/fjerne deltakere og mute (med ekstern MCU) blir utført på master- eller slave-MCU'er, mens floor-kontroll blir utført på MASTER-systemet (MCU - enten internt eller eksternt). -

Hvordan fremgangsmåtene og det faktiske systemet blir kontrollert vil variere fra system til system. TANDBERG-systemer støtter administrasjon på andre måter enn konkurrenter (RadVision, Polycom, Ezenia). Hovednøkkelen er at hvert system gjør sitt støttenivå tilgjengelig for ulike funksjoner, for innsamling av samtaleinformasjon blir en union av statusene til de individuelle systemene utført (for å optimalisere, i de fleste tilfellene kun ved å spørre MASTER-systemet for slik informasjon). For administrasjon vil imidlertid, i henhold til løsningen presentert her, en først prøve å eksekvere funksjonen på MASTER-systemet, deretter på slave-MCU'er (dersom de er brukt) og til slutt på det individuelle systemet.

Resultatet er at i de fleste tilfellene og de fleste oppsett, trenger kun MASTER-systemet å bli aksessert, noe som resulterer i mindre sannsynlighet for å miste forbindelsen på grunn av IP-nettverkshendelser. Siden en konstant forbindelse kan bli åpnet med Master-systemet, vil de fleste funksjonene bli aksessert, og det er ikke behov å forbinde seg til alle systemene.

Den presenterte løsningen gir administratorer én skjerm og én måte å kontrollere alle konferanser på, enten de er punkt-til-punkt, intern MCU, ekstern MCU eller distribuerte/kaskaderte konferanser. Dette vil da hindre behovet for store MCU'er som alle samtalene må gå gjennom for å være i stand til å ha samme mengde med monitorering og administreringsmuligheter.

Claims (23)

1. Fremgangsmåte for automatisk generering og allokering av optimalisert oppsett av multiple.endepunkter (EP'er) til multiple siteforbindelsesenheter (MCU'er) i et distribuert videokonferansesystem, karakterisert ved at fremgangsmåten omfatter trinnene: å estimere antall MCl<T>er nødvendig, basert på antall av EP'er som er nødvendig for å bli forbundet i videokonferansesesjonen; å sjekke om det er tilstrekkelig antall MCl<T>er tilgjengelig i henhold til estimeringen ved å allokere hver EP til en MCU; å optimalisere allokeringen åv EP'er til MCU'er ved å forbinde EP'er til MCU'er i henhold til en yektefunksjon.

2. Fremgangsmåte i henhold til krav 1, hvor estimeringen av antall MCU'er nødvendig videre omfatter undertrinnene: å generere en MCU-prioirtetsliste av tilgjengelige MCU'er basert på vektefunksjonen, basert på enhver ønsket karakteristikk eller egenskap av MCU'er og antall av EP'er; å velge MCU'en med best vekting som master-MCU.

3. Fremgangsmåte i henhold til krav 1, hvor sjekking av estimert antall av MCU'er nødvendig videre omfatter undertrinnene: å beregne nødvendige linker fra master-MCU til andre MCU'er i MCU-prioritetslisten; å allokere master-MCU til EP til videokonferanselederen (dersom noen); å beregne samtalevekt for hver EP hvor kostnaden for hver samtale mellom EP og MCU er blant faktorene innbefattet i vektingen; å generere en EP-prioritetsliste for hver MCU; å allokere hver EP til en MCU i henhold til den genererte prioritetslisten for EP'ene og MCU'ene.

4. Fremgangsmåte i henhold til krav 1, hvor optimalisering av allokering av EP'er til MCl<T>er videre omfatter undertrinnene: å generere en deallokert liste, fra den genererte prioritetslisten til allokerte EP'er til MCl<T>er, av EP'er fra alle bortsett fra master-MCU'en; å lage ruter mellom hver EP og hver MCU i MCU-deallokeringslisten; å addere disse rutene til en liste med en samling av ruter; . å sortere listen med samling av ruter etter laveste vektingssamtale; å allokere hver EP inneholdt i samlingen av ruter til den mest ønskelige MCU'en, dersom tilstrekkelige ressurser er tilgjengelig på MCU'en, og fjerning av alle andre ruter i den sorterte listen hvor denne EP'en er tilstede.

5. Fremgangsmåte i henhold til krav 2, hvor den genererte MCU-prioritetslisten er sortert etter lokasjon, båndbredde og kanaler på tidspunktet til det oppsatte ■ møtet.

6. Fremgangsmåte i henhold.til krav 3, hvor beregningen av samtalevekt videre innbefatter faktorer som båndbredde.

7. Fremgangsmåte i henhold til krav 3; hvor den genererte EP-prioritetslisten blir sortert etter ulike vektefaktorer hvor kostnader og båndbredde er blant faktorene prioritert.

8. Fremgangsmåte i henhold til krav.3, hvor allokeringen av hver EP til en MCU blir utført i henhold til en sortert liste av tilgjengelige MCU'er.

9. Fremgangsmåte i henhold til krav 3, hvor allokeringen av hver EP til en MCU blir utført inntil alle EP'er er allokert til en MCU.

10. Fremgangsmåte i henhold til krav 3, hvor hver allokert EP blir deallokert dersom én eller flere EP'er ikke blir allokert på grunn av mangel på ressurser på MCU'en i EP-prioritetslisten.

11. Fremgangsmåte i henhold til krav 3, hvor EP'er er allokert til den neste MCU'en på prioritetslisten når den forrige MCU'en er opptatt.

12. Fremgangsmåte i henhold til krav 4, hvor allokeringen av EP'en innbefattet i samlingen av ruter til dens MCU blir avbrutt og den allokerte ruten før optimaliseringstrinnet blir valgt dersom det er utilstrekkelige ressurser på den aktuelle MCU'en.

13. Fremgangsmåte i henhold til krav 7, hvor den genererte EP-prioritetslisten blir sortert av én av vektingsfaktorene.

14. Fremgangsmåte i henhold til krav 7, hvor den genererte EP-prioritetslisten blir sortert av en vektingsfaktor.

15. Fremgangsmåte i henhold til krav 10, hvor de deallokerte EP'ene blir reallokert etter å ha lagt til en ny MCU til MCU-prioritetslisten.

16. Innretning for automatisk generering og allokering av optimalisert oppsett av multiple endepunkter (EP'er) til multisiteforbindelsesenheter (MCU'er) i et distribuert videokonferansesystem karakterisert ved at innretningen omfatter:. en beregnings enhet, arrangert for beregning av antall MCU'er nødvendig, basert på antall av EP'er som kreves for å bli forbundet i videokonferansesesjonen; en sjekkeenhet arrangert for å sjekke om det er i det minste nok MCU'er. som kreves i henhold til estimeringen av allokerte EP'er til MCU'ene, og en optimaliseringsenhet arrangert for optimalisering av allokeringen av EP'er til MCU'ene, ved å forbinde EP'er til MCU'er i henhold til en vektefunksjon.

17. Innretning i henhold til krav 16, hvor beregningsenheten, sjekkeenheten og optimaliseringsenheten videre omfatter midler for å utføre fremgangsmåten i henhold til kravene 2-15.

18. Fremgangsmåte for å monitorere og administrere mange videokonferanseinnretninger innenfor et nettverk karakterisert ved at fremgangsmåten omfatter trinnene: å samle inn og slå sammen samtaleinformasjon slik som protokoller og varighet fra innretningene i samtalen; å sjekke om en innretning er i stand til å utføre en spesifikk kommando ved mottak av en administrasjonsfunksjon; å eksekvere kommandoen på innretningen som er i stand til å utføre den spesifikke kommandoen.

19. Fremgangsmåte i henhold til krav 18, hvor trinnet med å sjekke innbefatter: å sjekke om masterinnretningen er i stand til å utføre en spesifikk kommando ved mottak av en administrasjonsfunksjon; å sjekke om slaveinnretningene er i stand til å utføre den spesifikke kommandoen dersom masterinnretningen ikke er i stand til å utføre nevnte kommando; å sjekke om endepunktet (EP) som kommandoene skal utføres på er i stand til å utføre den spesifikke kommandoen dersom master- eller slaveinnretningene ikke er i stand til å utføre denne kommandoen; å eksekvere kommandoen på innretningene som er i stand,til å utføre den spesifikke kommandoen.

20. Fremgangsmåte i henhold til krav 18, hvor innsamlingen og sammenslåingen av samtaleinformasjonen blir utført ved å la hver videokonferanseinnretning gjøre sitt supportnivå for ulike funksjoner tilgjengelige til et mellomlager for å øke prosesseringen.

21. Fremgangsmåte i henhold til krav 18, hvor monitorering og administreringsbrukergrensesnittet er operativt forbundet til videokonferanseinnretningene.

22. Innretning for å monitorere og administrere mange videokonferanser innenfor et nettverk karakterisert ved at innretningen omfatter: mottakingsmidler for å samle og slå sammen samtaleinformasjon slik som protokoller og varighet fra alle de kaskadede MCU'ene; midler for å sjekke om en innretning er i stand til å utføre en spesifikk kommando ved mottak av en administrasjonsfunksjon; midler for å eksekvere kommandoen pa MCU'en som er i stand til å utføre den spesifikke kommandoen.

23. Innretning i henhold til krav 22, hvor midlene for å sjekke innbefatter: midler for å sjekke om master-MCU er i stand til å utføre en spesifikk kommando ved mottak av en administrasjonsfunksjon; midler for å sjekke om slave-MCU'en er i stand til å utføre den spesifikke kommandoen dersom master-MCU ikke er i stand til å utføre denne kommandoen; midler for å sjekke om endepunktet (EP) som kommandoen skal utføres på er i stand til å utføre den spesifikke kommandoen dersom master-eller slave-MCU'er ikke er i stand til å utføre denne kommandoen.