\documentclass[11pt,twoside]{article}\makeatletter

\IfFileExists{xcolor.sty}%
  {\RequirePackage{xcolor}}%
  {\RequirePackage{color}}
\usepackage{colortbl}
\usepackage{wrapfig}
\usepackage{ifxetex}
\ifxetex
  \usepackage{fontspec}
  \usepackage{xunicode}
  \catcode`⃥=\active \def⃥{\textbackslash}
  \catcode`❴=\active \def❴{\{}
  \catcode`❵=\active \def❵{\}}
  \def\textJapanese{\fontspec{Noto Sans CJK JP}}
  \def\textChinese{\fontspec{Noto Sans CJK SC}}
  \def\textKorean{\fontspec{Noto Sans CJK KR}}
  \setmonofont{DejaVu Sans Mono}
  
\else
  \IfFileExists{utf8x.def}%
   {\usepackage[utf8x]{inputenc}
      \PrerenderUnicode{–}
    }%
   {\usepackage[utf8]{inputenc}}
  \usepackage[english]{babel}
  \usepackage[T1]{fontenc}
  \usepackage{float}
  \usepackage[]{ucs}
  \uc@dclc{8421}{default}{\textbackslash }
  \uc@dclc{10100}{default}{\{}
  \uc@dclc{10101}{default}{\}}
  \uc@dclc{8491}{default}{\AA{}}
  \uc@dclc{8239}{default}{\,}
  \uc@dclc{20154}{default}{ }
  \uc@dclc{10148}{default}{>}
  \def\textschwa{\rotatebox{-90}{e}}
  \def\textJapanese{}
  \def\textChinese{}
  \IfFileExists{tipa.sty}{\usepackage{tipa}}{}
\fi
\def\exampleFont{\ttfamily\small}
\DeclareTextSymbol{\textpi}{OML}{25}
\usepackage{relsize}
\RequirePackage{array}
\def\@testpach{\@chclass
 \ifnum \@lastchclass=6 \@ne \@chnum \@ne \else
  \ifnum \@lastchclass=7 5 \else
   \ifnum \@lastchclass=8 \tw@ \else
    \ifnum \@lastchclass=9 \thr@@
   \else \z@
   \ifnum \@lastchclass = 10 \else
   \edef\@nextchar{\expandafter\string\@nextchar}%
   \@chnum
   \if \@nextchar c\z@ \else
    \if \@nextchar l\@ne \else
     \if \@nextchar r\tw@ \else
   \z@ \@chclass
   \if\@nextchar |\@ne \else
    \if \@nextchar !6 \else
     \if \@nextchar @7 \else
      \if \@nextchar (8 \else
       \if \@nextchar )9 \else
  10
  \@chnum
  \if \@nextchar m\thr@@\else
   \if \@nextchar p4 \else
    \if \@nextchar b5 \else
   \z@ \@chclass \z@ \@preamerr \z@ \fi \fi \fi \fi
   \fi \fi  \fi  \fi  \fi  \fi  \fi \fi \fi \fi \fi \fi}
\gdef\arraybackslash{\let\\=\@arraycr}
\def\@textsubscript#1{{\m@th\ensuremath{_{\mbox{\fontsize\sf@size\z@#1}}}}}
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\def\abbr{}
\def\corr{}
\def\expan{}
\def\gap{}
\def\orig{}
\def\reg{}
\def\ref{}
\def\sic{}
\def\persName{}\def\name{}
\def\placeName{}
\def\orgName{}
\def\textcal#1{{\fontspec{Lucida Calligraphy}#1}}
\def\textgothic#1{{\fontspec{Lucida Blackletter}#1}}
\def\textlarge#1{{\large #1}}
\def\textoverbar#1{\ensuremath{\overline{#1}}}
\def\textquoted#1{‘#1’}
\def\textsmall#1{{\small #1}}
\def\textsubscript#1{\@textsubscript{\selectfont#1}}
\def\textxi{\ensuremath{\xi}}
\def\titlem{\itshape}
\newenvironment{biblfree}{}{\ifvmode\par\fi }
\newenvironment{bibl}{}{}
\newenvironment{byline}{\vskip6pt\itshape\fontsize{16pt}{18pt}\selectfont}{\par }
\newenvironment{citbibl}{}{\ifvmode\par\fi }
\newenvironment{docAuthor}{\ifvmode\vskip4pt\fontsize{16pt}{18pt}\selectfont\fi\itshape}{\ifvmode\par\fi }
\newenvironment{docDate}{}{\ifvmode\par\fi }
\newenvironment{docImprint}{\vskip 6pt}{\ifvmode\par\fi }
\newenvironment{docTitle}{\vskip6pt\bfseries\fontsize{22pt}{25pt}\selectfont}{\par }
\newenvironment{msHead}{\vskip 6pt}{\par}
\newenvironment{msItem}{\vskip 6pt}{\par}
\newenvironment{rubric}{}{}
\newenvironment{titlePart}{}{\par }

\newcolumntype{L}[1]{){\raggedright\arraybackslash}p{#1}}
\newcolumntype{C}[1]{){\centering\arraybackslash}p{#1}}
\newcolumntype{R}[1]{){\raggedleft\arraybackslash}p{#1}}
\newcolumntype{P}[1]{){\arraybackslash}p{#1}}
\newcolumntype{B}[1]{){\arraybackslash}b{#1}}
\newcolumntype{M}[1]{){\arraybackslash}m{#1}}
\definecolor{label}{gray}{0.75}
\def\unusedattribute#1{\sout{\textcolor{label}{#1}}}
\DeclareRobustCommand*{\xref}{\hyper@normalise\xref@}
\def\xref@#1#2{\hyper@linkurl{#2}{#1}}
\begingroup
\catcode`\_=\active
\gdef_#1{\ensuremath{\sb{\mathrm{#1}}}}
\endgroup
\mathcode`\_=\string"8000
\catcode`\_=12\relax

\usepackage[a4paper,twoside,lmargin=1in,rmargin=1in,tmargin=1in,bmargin=1in,marginparwidth=0.75in]{geometry}
\usepackage{framed}

\definecolor{shadecolor}{gray}{0.95}
\usepackage{longtable}
\usepackage[normalem]{ulem}
\usepackage{fancyvrb}
\usepackage{fancyhdr}
\usepackage{graphicx}
\usepackage{marginnote}

\renewcommand{\@cite}[1]{#1}


\renewcommand*{\marginfont}{\itshape\footnotesize}

\def\Gin@extensions{.pdf,.png,.jpg,.mps,.tif}

  \pagestyle{fancy}

\usepackage[pdftitle={Headlight Prefetching for Cooperative Media Streaming in Mobile Environments},
 pdfauthor={}]{hyperref}
\hyperbaseurl{}

	 \paperwidth210mm
	 \paperheight297mm
              
\def\@pnumwidth{1.55em}
\def\@tocrmarg {2.55em}
\def\@dotsep{4.5}
\setcounter{tocdepth}{3}
\clubpenalty=8000
\emergencystretch 3em
\hbadness=4000
\hyphenpenalty=400
\pretolerance=750
\tolerance=2000
\vbadness=4000
\widowpenalty=10000

\renewcommand\section{\@startsection {section}{1}{\z@}%
     {-1.75ex \@plus -0.5ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large\bfseries}}
\renewcommand\subsection{\@startsection{subsection}{2}{\z@}%
     {-1.75ex\@plus -0.5ex \@minus- .2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large}}
\renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}%
     {-1.5ex\@plus -0.35ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\large}}
\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}%
     {-1ex \@plus-0.35ex \@minus -0.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\normalsize}}
\renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}%
     {1.5ex \@plus1ex \@minus .2ex}%
     {-1em}%
     {\reset@font\normalsize\bfseries}}


\def\l@section#1#2{\addpenalty{\@secpenalty} \addvspace{1.0em plus 1pt}
 \@tempdima 1.5em \begingroup
 \parindent \z@ \rightskip \@pnumwidth 
 \parfillskip -\@pnumwidth 
 \bfseries \leavevmode #1\hfil \hbox to\@pnumwidth{\hss #2}\par
 \endgroup}
\def\l@subsection{\@dottedtocline{2}{1.5em}{2.3em}}
\def\l@subsubsection{\@dottedtocline{3}{3.8em}{3.2em}}
\def\l@paragraph{\@dottedtocline{4}{7.0em}{4.1em}}
\def\l@subparagraph{\@dottedtocline{5}{10em}{5em}}
\@ifundefined{c@section}{\newcounter{section}}{}
\@ifundefined{c@chapter}{\newcounter{chapter}}{}
\newif\if@mainmatter 
\@mainmattertrue
\def\chaptername{Chapter}
\def\frontmatter{%
  \pagenumbering{roman}
  \def\thechapter{\@roman\c@chapter}
  \def\theHchapter{\roman{chapter}}
  \def\thesection{\@roman\c@section}
  \def\theHsection{\roman{section}}
  \def\@chapapp{}%
}
\def\mainmatter{%
  \cleardoublepage
  \def\thechapter{\@arabic\c@chapter}
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \pagenumbering{arabic}
  \setcounter{secnumdepth}{6}
  \def\@chapapp{\chaptername}%
  \def\theHchapter{\arabic{chapter}}
  \def\thesection{\@arabic\c@section}
  \def\theHsection{\arabic{section}}
}
\def\backmatter{%
  \cleardoublepage
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \setcounter{secnumdepth}{2}
  \def\@chapapp{\appendixname}%
  \def\thechapter{\@Alph\c@chapter}
  \def\theHchapter{\Alph{chapter}}
  \appendix
}
\newenvironment{bibitemlist}[1]{%
   \list{\@biblabel{\@arabic\c@enumiv}}%
       {\settowidth\labelwidth{\@biblabel{#1}}%
        \leftmargin\labelwidth
        \advance\leftmargin\labelsep
        \@openbib@code
        \usecounter{enumiv}%
        \let\p@enumiv\@empty
        \renewcommand\theenumiv{\@arabic\c@enumiv}%
	}%
  \sloppy
  \clubpenalty4000
  \@clubpenalty \clubpenalty
  \widowpenalty4000%
  \sfcode`\.\@m}%
  {\def\@noitemerr
    {\@latex@warning{Empty `bibitemlist' environment}}%
    \endlist}

\def\tableofcontents{\section*{\contentsname}\@starttoc{toc}}
\parskip0pt
\parindent1em
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\newenvironment{reflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemsep}{0pt}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\itshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{sansreflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\itemsep}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\upshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{specHead}[2]%
 {\vspace{20pt}\hrule\vspace{10pt}%
  \phantomsection\label{#1}\markright{#2}%

  \pdfbookmark[2]{#2}{#1}%
  \hspace{-0.75in}{\bfseries\fontsize{16pt}{18pt}\selectfont#2}%
  }{}
      \def\TheFullDate{2011-12-12 (revised: 12 December 2011)}
\def\TheID{\makeatother }
\def\TheDate{2011-12-12}
\title{Headlight Prefetching for Cooperative Media Streaming in Mobile Environments}
\author{}\makeatletter 
\makeatletter
\newcommand*{\cleartoleftpage}{%
  \clearpage
    \if@twoside
    \ifodd\c@page
      \hbox{}\newpage
      \if@twocolumn
        \hbox{}\newpage
      \fi
    \fi
  \fi
}
\makeatother
\makeatletter
\thispagestyle{empty}
\markright{\@title}\markboth{\@title}{\@author}
\renewcommand\small{\@setfontsize\small{9pt}{11pt}\abovedisplayskip 8.5\p@ plus3\p@ minus4\p@
\belowdisplayskip \abovedisplayskip
\abovedisplayshortskip \z@ plus2\p@
\belowdisplayshortskip 4\p@ plus2\p@ minus2\p@
\def\@listi{\leftmargin\leftmargini
               \topsep 2\p@ plus1\p@ minus1\p@
               \parsep 2\p@ plus\p@ minus\p@
               \itemsep 1pt}
}
\makeatother
\fvset{frame=single,numberblanklines=false,xleftmargin=5mm,xrightmargin=5mm}
\fancyhf{} 
\setlength{\headheight}{14pt}
\fancyhead[LE]{\bfseries\leftmark} 
\fancyhead[RO]{\bfseries\rightmark} 
\fancyfoot[RO]{}
\fancyfoot[CO]{\thepage}
\fancyfoot[LO]{\TheID}
\fancyfoot[LE]{}
\fancyfoot[CE]{\thepage}
\fancyfoot[RE]{\TheID}
\hypersetup{citebordercolor=0.75 0.75 0.75,linkbordercolor=0.75 0.75 0.75,urlbordercolor=0.75 0.75 0.75,bookmarksnumbered=true}
\fancypagestyle{plain}{\fancyhead{}\renewcommand{\headrulewidth}{0pt}}

\date{}
\usepackage{authblk}

\providecommand{\keywords}[1]
{
\footnotesize
  \textbf{\textit{Index terms---}} #1
}

\usepackage{graphicx,xcolor}
\definecolor{GJBlue}{HTML}{273B81}
\definecolor{GJLightBlue}{HTML}{0A9DD9}
\definecolor{GJMediumGrey}{HTML}{6D6E70}
\definecolor{GJLightGrey}{HTML}{929497} 

\renewenvironment{abstract}{%
   \setlength{\parindent}{0pt}\raggedright
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
   \textcolor{GJBlue}{\large\bfseries\abstractname\space}
}{%   
   \vskip8pt
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
}

\usepackage[absolute,overlay]{textpos}

\makeatother 
      \usepackage{lineno}
      \linenumbers
      
\begin{document}

             \author[1]{M.  Divya}

             \affil[1]{  Sri Chaitanya College of Engineering, karimnagar}

\renewcommand\Authands{ and }

\date{\small \em Received: 10 November 2011 Accepted: 2 December 2011 Published: 12 December 2011}

\maketitle


\begin{abstract}
        


Multimedia information services in mobile environments are becoming more and more important with the proliferation of technologies. Media streaming, in particular, is a promising technology for providing services such as news clips, live sports. To avoid service interruption when the users keep moving, proper data management strategies must be employed. We propose a new headlight prefetching technique for the streaming access points to deal with the uncertainty of client movement and the requirement of seamless service handoff. For each mobile client, we maintain a virtual fan shaped prefetching zone along the direction of movement similar to the headlight of a moving vehicle. The overlapping area and the accumulated virtual illuminance of the headlight zone on a particular cell determines the degree and volume of prefetching to be made by the streaming access point of that cell. Headlight prefetching solves the issues of identifying the streaming access points responsible for prefetching, the timing and the amount of data to prefetch in a single mechanism which is simple and effective. Simulation results demonstrate that our techniques can significantly decrease streaming disruptions, reduce bandwidth consumption, increase cache utilization and improve service response time.

\end{abstract}


\keywords{Headlight, consumption, bandwidth, streaming.}

\begin{textblock*}{18cm}(1cm,1cm) % {block width} (coords) 
\textcolor{GJBlue}{\LARGE Global Journals \LaTeX\ JournalKaleidoscope\texttrademark}
\end{textblock*}

\begin{textblock*}{18cm}(1.4cm,1.5cm) % {block width} (coords) 
\textcolor{GJBlue}{\footnotesize \\ Artificial Intelligence formulated this projection for compatibility purposes from the original article published at Global Journals. However, this technology is currently in beta. \emph{Therefore, kindly ignore odd layouts, missed formulae, text, tables, or figures.}}
\end{textblock*}


\let\tabcellsep& 	 	 		 
\section[{INTRODUCTION}]{INTRODUCTION}\par
edia streaming is a promising technology for providing multimedia information services such as news clips, live sports, and hot movies in mobile environments. Effective data management for media streaming is naturally the key to the successfulness of such services. Since many users may request the same media, traditional client server model can easily result in server bottleneck, bandwidth waste, poor cache utilization and longer delay. Furthermore, the mobility of mobile users raise the issue of seamless service hand off. To avoid service interruption, proper data management strategies must be employed. In this paper, we propose a new technique named headlight prefetching for media streaming in mobile environments.\par
The technique is designed for the streaming access points to deal with the uncertainty of client movement, the unpredictability of request pattern and the requirement of seamless service handoff. For each mobile client, we maintain a virtual fan shaped prefetching zone along the direction of movement similar to the headlight of a moving vehicle. The overlapping area and the accumulated virtual illuminance of the headlight zone on a particular cell determines the degree and volume of prefetching to be made by the streaming access point of that cell. When a mobile user makes an unexpected sharp turn, the headlight shifting technique is used such that all the previously prefetched media segments can be easily shifted to accommodate the new direction of movement. For users requesting the same media at around the same time, the headlight sharing technique is developed for sharing the headlight zones to avoid repeated prefetching. The set of techniques solve the issues of identifying the streaming access points responsible for prefetching, the timing and the amount of data to prefetch in a single mechanism which is simple, intuitively appealing and effective.\par
To evaluate the effectiveness of our techniques, we construct a Java based simulation environment and compare the performance of different combinations of our schemes with on demand techniques. Simulation results demonstrate that, for streaming media services in mobile environments, headlight prefetching, shifting and sharing are simple and effective techniques which can significantly decrease streaming disruptions, reduce bandwidth consumption, increase cache utilization and improve service response time.\par
The rest of the paper provides a survey of related issues and research work and presents the media streaming system infrastructure we assume and characterize the challenges of dynamic data management in such environments. We also introduces the idea of headlight prefetching and the associated data management techniques. we outline the simulation environment for experimenting with our ideas and present the results of performance evaluation on different aspects of the prefetching techniques. For media streaming services in mobile environments, we assume a system architecture. The multimedia information are provided by streaming media servers(SMSs). All cells have corresponding streaming access points(SAPs) connected with each other through traditional fixed link networks. Each SAP provides wireless media services for mobile users within that cell. Users not reachable from any SAP are disconnected. In general, let the local wireless access cost between a mobile user and an SAP be L, and the remote access cost of requesting the unit from an SMS be R. Then, based on the nature of the architecture and service charge, we assume that L is larger than R since wireless access cost is usually larger than that of fixed link. However, if a media segment is available locally on an SAP, then it only takes a local access cost of L to service the segment. If the segment is not available on the SAP cache, then a remote access cost of R must be added in addition to the local access cost. Therefore, a remote access is always more expensive than a local access. Since intermittent disconnection is unavoidable in mobile environments, effective data management strategies must be employed to conserve access cost and reduce play interruption. 
\section[{II.}]{II.} 
\section[{STREAMING MEDIA SERVICE ARCHITECTURE}]{STREAMING MEDIA SERVICE ARCHITECTURE}\par
A streaming media is usually considered as a sequence of media segments. Because of the streaming nature, it is not necessary to provide the entire media all at once. A media request from a mobile client can therefore be treated as the starting request of a sequence of media segments. There are several data management challenges for streaming media services in mobile environments:\par
? A mobile user can request any media from any location at any time. On a request, the SAP of the cell where the user resides must locate and send the first segment as soon as possible to reduce service delay. Our goal is to develop effective dynamic data management techniques to answer the challenges of streaming media services in mobile environments. In particular, the headlight prefetching and associated techniques are designed to solve the problems of identifying responsible SAPs, determining prefetching segment assignment and handling the dynamic data management issues in a simple and unified framework. Our schemes are unique in several respects:\par
? The idea of virtual fan shaped headlight prefetching zone is simple, intuitive appealing and efficient. We can use the headlight coverage area to identify the prefetching SAPs and the virtual illuminance to determine the look ahead window for each SAP.\par
Both are straightforward and easy to compute. ? Headlight prefetching is flexible and dynamic adjustable. We can use the shape and size of the virtual fan to control the range and degree of prefetching. For mostly straight and fast moving users (eg. vehicles on a freeway, passengers on a train, ...), we can have a smaller central angle and longer radius. For slow moving clients that tend to wonder around, a larger central angle and smaller radius allow more neighboring SAPs to be prepared for serving the clients. ? Should a mobile user make an unexpected sharp turn, we provide the headlight shifting technique such that all the previously prefetched segments can be easily shifted to the SAPs along the new direction. ? To efficiently reuse prefetched segments, the headlight sharing technique is developed to coordinate neighboring SAPs on media services and to avoid repeated segment prefetching. streaming media services in mobile environments entail significant challenges on highly dynamic and efficient data management. The mobile and streaming characteristics of the services also provide a window of opportunity for information system designers. We take on this opportunity to provide simple and effective dynamic data management techniques that adhere closely to the movement patterns of mobile users. It turns out that high quality streaming media services in mobile environments can indeed be achieved with proper coordinations of SAPs and right strategies for data management.  
\section[{HEADLIGHT PREFETCHING}]{HEADLIGHT PREFETCHING}\par
As stated earlier, an important characteristic of streaming media is the continuous playing requirement. Once a media is started, the requesting user expects a smooth and seamless viewing experience. Fetching a segment upon its request is not likely to catch up with the playing speed. Prefetching and buffering are almost a must in such case. Traditional prefetching is simply done by maintaining a sliding window immediately ahead of the current segment by the SAP in charge of the media service. This is only satisfactory when the user is moving in a straight ahead pattern. For irregular moving patterns, the traditional approach may fail miserably. The problem is that if the user changes direction and moves toward a new SAP, the later may not have anything prepared for the user. The uncertainty of user movement can easily result in frequent disruption and unpleasant viewing experience. To have all surrounding SAPs prefetch the needed segments for the user is clearly not cost effective. We therefore need a good mechanism to continuously identify the proper set of prefetching SAPs for a moving client. Those SAPs that are more likely to be visited next should be selected with higher probability. Even if the set of prefetching SAPs is successfully identified, we still have another important problem of determining the right media segments for each SAP to prefetch. The simplest approach of having all selected SAPs prefetch the same set of media segments is certainly not satisfactory. To save processing and communication costs, the ideal case is to prefetch just the segments needed to keep the media viewing smooth. Similar to the previous issue, we need to cope with the uncertainty of user's moving speed and pattern by dynamically determining the prefetching segments assignment. Those SAPs that are more likely to be visited next should be assigned more segments to prefetch. In addition to the prefetching SAPs identification and segment assignment problems, we also need to determine the right timing for the SAPs to start or stop prefetching. Otherwise the prefetched segments may either arrive too early or too late.\par
The idea of headlight prefetching is to have a simple and unified mechanism for solving the issues discussed above. A headlight prefetching zone is a virtual fan shaped area along the direction of user movement similar to the headlight of a moving vehicle. All SAPs of the cells touched by the headlight zone are selected as the prefetching SAPs for the user. The overlapping area and the accumulated virtual illuminance of the head light zone on a particular cell determines the degree and volume of prefetching to be made by the SAP of the cell.\par
Headlight prefetching solves the issues of prefetching SAPs identification, segment assignment and the prefetch timing in a single mechanism which is simple and intuitive appealing.\par
The headlight prefetching zone.\par
The headlight model.\par
The headlight prefetching zone is modeled by two parameters. The radius r determines the extent of look ahead for prefetching. The angle ? is used to control the span of coverage. Both are dynamically adjustable. In general, faster moving users need longer radiuses. Users that tend to wonder around need larger ?s to have more SAPs ready to carry on the services when a user changes direction unexpectedly. The headlight zone serves as a prediction of possible future interaction of the user with neighboring cells. By using such a simple and intuitive appealing metaphor, we can easily identify the set of SAPs that need to prefetch media segments for the user.\par
Once the prefetching SAPs identification problem is solved, we still need to take on the segment assignment problem. The head light metaphor gives us yet another simple way to handle this problem. A basic characteristic of a vehicle headlight is that the farther away from the vehicle the lower the illuminance. The area immediately in front of the vehicle has the highest brightness. This characteristic matches exactly the requirement of the segment assignment problem. Since a user can change direction at any time, the media segments prefetched by the SAPs farther away from the user are less likely to be actually used. They should be assigned fewer segments to save the cost. On the other hand, the SAPs closer to the user are more likely to be responsible for providing the media services. They undesirable disruption. Due to such a close resemblance, we use the accumulated virtual illuminance of the cell area covered by the headlight zone as the weight for segment assignment. In this way, we solve both problems in a unified framework.\par
The headlight zone and the computation of virtual illuminance.\par
The problem is in determining the cell area covered by the headlight zone since the intersected area could be in any shape. To avoid the costly computation of the covered area, we use a much simpler approach to approximate the virtual illuminance. More specifically, we partition the headlight zone into smaller grids and precompute the virtual illuminance as well as the center of each grid. Since each grid is in a regular shape, the virtual illuminance can be easily computed by the following formula.\par
On the need to determine the segment assignment of a particular cell, we simply add up the illuminance of all grids whose centers fall inside the cell. Since the granularity of the grids can be changed easily, we can have higher level of precision at any time by using finer partitioning. 
\section[{a) Prefetching Segment Assignment}]{a) Prefetching Segment Assignment}\par
To determine the segment assignment, we need to consider both the user movement and media playing speed. Therefore the number of segments that should be handled by the current cell is tP . If the current media segment being played is Si ,then SAPC must prefetch the segments Si+1, Si+2, . . . , Si+tP .The first segment that need to be prefetched by SAPC? is Si+tP +1. The expected number of segments to be handled is t?P . The starting segment and the total number of segments to prefetch for all other SAPs within the headlight zone can be determined in a similar way. Since it is clearly not cost worthy for all such SAPs to prefetch the full range of segments, therefore we use the virtual illuminance as a weighting factor to determine the actual number of segments to prefetch. More specifically, the exact segment assignment for SAPC'' to prefetch is Parameters for determining the segment assignment b) Headlight shifting Headlight prefetching is quite effective for largely stable moving users. However, if the user makes a sharp turn, then most or even all of the prefetching done on the previous headlight zone may be completely useless since the user is no longer heading toward the predicted direction. We can of course start a new round of head light prefetching for the new situation. However, this will double the prefetching cost. Since the media stream is played continuously, the segments needed for the new headlight zone overlap significantly with that of the old zone. Therefore the better way is to shift these segments to the new zone. We call the idea headlight shifting. For efficient headlight shifting, we need to solve at least two problems:\par
? Since the same media segment may be available on more than one SAPs, how to choose or map the shifting source and target? ? Different SAPs may have different number of prefetched segments available for shifting, how do we distribute and balance the shifting load?\par
We propose three strategies for headlight shifting. The simplest and most intuitive way is to map the grids of the new zone to corresponding grids of the old zone with possible offset based on user's current position. This is called direct mapping. More specifically, let the old and new grids be Gi,j and G?i,j respectively. Also assume that the position where the user makes the turn is in grid Gx,y . Then we simply map G?i,j to Gi+x,j . In other words, the SAP whose cell covers G?i,j can simply request the media segments to be directly shifted from the SAP whose cell covers Gi+x,j .\par
Direct mapping works fine if the user is at a position close to the entrance of a grid since most of the segments are not yet played and therefore the mapping is useful and efficient. However, the problem with direct mapping is that if the user is at a position about to leave a grid then the mapping is likely to be off by one grid since most of the segments have already been played. The problem can be easily solved by the second strategy named overlapped mapping. Instead of mapping the grids onetoone, we extend the mapping into a one-to-many overlapped mapping. More specifically, a parameter called overlapped length(OL) is defined to denote the degree of overlapping. Now the new grid G?i,j is mapped to the old grids from Gi+x,j to Gi+x+OL,j .\par
The most distinctive benefit of both direct and overlapped mapping strategies is that all shifting sources and targets can be easily computed without any search. However, the resulting mapping may not be optimal in terms of shifting cost since the same segment may be available on more than one SAP. The lowest cost shifting source may not be the one that is mapped directly. We therefore propose the third strategy named the shortest distance mapping strategy. After determining the segment assignment for the new zone, should be allocated more segments to prevent the distances between a new SAP in the zone and the SAPs in the old zone with the assigned segments can be computed. We can therefore map the new SAP to the nearest neighbor in the old zone with the required segment. If there are more than one qualified neighboring SAPs available to choose from, we follow the lowest shifted volume first strategy to balance the load. 
\section[{c) Headlight Sharing}]{c) Headlight Sharing}\par
Headlight shifting only takes the headlight zone of one user into consideration.\par
Segments not yet prefetched by any SAP of the old zone can only be retrieved from the remote source. Since the same media may be viewed by more than one user at the same time, especially for hot medias, the headlight zones of different users may have many segments in common. If they overlap with each others, then it is very likely that we can find the needed segments from other zones with or without shifting. We call this idea headlight sharing since segments prefetched for a zone by an SAP are shared with neighboring SAPs with overlapping headlight zones. Once a requested segment is located in the neighborhood, the cost of prefetching from the remote server can also be saved.\par
To facilitate headlight sharing, a distributed index structure is constructed on each SAP for maintaining the availability of media segments on other SAPs. For ease of presentation, we assume that the set of all medias be M and the set of all segments of media i be Gi . A separate index table Ti = \{Si, M\} is maintained for each neighboring SAP from which an index message is received. Si is the id of the SAP. M = \{(mj , sk , t)|mj ? M, sk ? Gmj \} is the partial set of media and segments available on that SAP. Each segment has an expiration time t to indicate the period of validity. An SAP index keeps track of all the available index tables while a segment index maintains, for each segment, a list of SAPs from which the segment can be found. The information is obtained from the index exchange between SAPs. To avoid additional communication overhead, the index messages are piggybacked with the headlight prefetching messages. With the index ready, the segments prefetched by an SAP can be easily shared with other SAPs to facilitate headlight sharing.\par
The problem now comes to the efficient maintenance of the distributed index. To keep a complete index of all medias and segments on each SAP is clearly cost prohibitive. Therefore only selected information is exchanged based on the following strategies:\par
? Random: Randomly select part of the available segments to exchange index.\par
? Local popularity: Select those segments that are locally popular based on the rationale that they may be popular on other SAPs as well.\par
? SAP specific popularity: Segments that are popular among the users coming from the same SAP are selected to send the index to that particular SAP. This is to satisfy different request patterns of users from different cells.\par
? SAP specific rareness: Segments that are locally popular but rarely requested by the users coming from a particular SAP are selected to send the index to that SAP. This is because the segments available locally are to satisfy either the local requests or headlight prefetching. The availability of the prefetched segments are already known to the SAPs that send the requests. Therefore we only need to send the index of those segments that are not known to other SAPs.\par
Headlight sharing works closely with headlight prefetching and shifting. On receiving a segment request, be it from a local user or a prefetch request, an SAP looks up the index after a cache miss to see if the segment is available on other SAPs. The segment can then be retrieved from a nearby SAP rather than from the remote source. During the headlight shifting, those segments that are in the new assignment but no SAP to shift from can very likely be satisfied using the headlight sharing index. Since the index messages are piggy backed with the prefetching messages and the index search cost is quite low in comparison with segment transmission cost, the over head of headlight sharing is almost negligible. Later in Section 5, we will show that different combinations of these techniques result in significant performance improvement over on demand and simple look ahead prefetching in terms of response time, interruption rate and completion rate. 
\section[{IV.}]{IV.} 
\section[{SIMULATION AND EVALUATION}]{SIMULATION AND EVALUATION}\par
To evaluate the performance of our techniques, we have developed a Java based simulation environment. The set of simulation parameters and their value ranges are listed in Table  {\ref 2}.\par
The first set of experiments is to compare the performance of different combinations of headlight prefetching, shifting and sharing strategies. All strategies are tested under two request patterns: random and Zipf distribution. We are particular interested in the total number of interruptions during a media playback and the average download time of a media segment since they are the dominant factors affecting service quality experienced by the users. All strategies perform significantly better than traditional on demand strategy with simple lookahead prefetching. Since the inclusion of the later makes others hard to compare, we can see that shifting and sharing indeed improve the performance of headlight prefetching, especially when used together. All strategies achieve better performance under Zipf distribution since hot medias can be quickly shared with other SAPs.\par
Comparison of different headlight prefetching strategies on average segment download time.\par
To evaluate the scalability of our approach, we vary the number of total medias then measure the interruption and average segment download time. The combination of shifting and sharing, again leads to best result.\par
Traveling speed is an important factor in mobile environments since the faster the average speed, the less time we have to prepare media segments for users. When the average speed is below 40, both play interruption and average download time are relative independent of the variation in speed. When the average speed is too fast such that the prefetching can no longer catch up with the mobile users, we observe a significant increase in both play interruption and download time, especially the later.\par
The size of client cache also has significant impact on system performance since the larger the cache, the more we can share with others. We note that a cache size 1 does not necessarily imply zero interruption since a media is started after 2\% buffering.\par
The saving is especially evident when the number of total medias is small sincethe chance of successful sharing increase. The set of headlight prefetching techniques are flexible and effective for media streaming services in mobile environments. Headlight prefetching provides a simple but uniform mechanism to allocate the resources on SAPs to the prefetching of needed media segments to the places where a user is most likely to be in the near future. When the movement pattern of a user does not follow the predicted track, headlight shifting and sharing leverage off the downloaded segments to quickly provide seamless media streaming services along the new track. Simulation and performance evaluation demonstrate that the headlight prefetching technique with the help of both headlight shifting and sharing, provides the best performance overall. 
\section[{V. CONCLUSIONS AND FUTURE WORK}]{V. CONCLUSIONS AND FUTURE WORK}\par
We have proposed a new set of techniques to facilitate data management for media streaming in mobile environments. The headlight prefetching techniques provide good performance in comparison with traditional ondemand or simple prefetching techniques. To offer even better data management in response to the changes in user behavior such as access and moving patterns, we are developing an adaptive headlight prefetching technique such that the shape and size of the headlight zone can be dynamically adjusted to accommodate the changes in speed or direction. We are also developing a P2P dynamic chaining method for the sharing of information among peers to maximize cache utilization and streaming benefit.\begin{figure}[htbp]
\noindent\textbf{2011}\includegraphics[]{image-2.png}
\caption{\label{fig_0}M © 2011}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{31}\includegraphics[]{image-3.png}
\caption{\label{fig_1}Fig 3 . 1 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{} \par 
\begin{longtable}{P{0.85\textwidth}}
seamless streaming media services across cell\\
boundaries.\\
?\\
? Once started, the SAP must fetch and transmit the\\
subsequent segments fast enough to catch up with\\
the playing speed. Good prefetching and buffering\\
techniques are required to avoid possible\\
interruption.\\
? A mobile user can move and change direction at\\
any time. Such a dynamism can only be handled by\\
close coordination of neighboring SAPs to provide\end{longtable} \par
 
\caption{\label{tab_0}}\end{figure}
 			\footnote{© 2011 Global Journals Inc. (US) Global Journal of Computer Science and Technology Volume XI Issue XXII Version I 66 2011 December} 			\footnote{© 2011 Global Journals Inc. (US) Global Journal of Computer Science and Technology Volume XI Issue XXII Version I 67 2011 December} 			\footnote{© 2011 Global Journals Inc. (US) Global Journal of Computer Science and Technology Volume XI Issue XXII Version I 68 2011 December} 			\footnote{© 2011 Global Journals Inc. (US) Global Journal of Computer Science and Technology Volume XI Issue XXII Version I} 			\footnote{December} 		 		\backmatter  			  				\begin{bibitemlist}{1}
\bibitem[Huang and Hsu (2003)]{b3}\label{b3} 	 		‘A user aware prefetching mechanism for video streaming’.  		 			C M Huang 		,  		 			T H Hsu 		.  	 	 		\textit{World Wide Web Journal}  		Dec 2003. 6  (4)  p. .  	 
\bibitem[Faria et al. (2006)]{b1}\label{b1} 	 		‘DVBH: Digital broadcast services to handheld devices’.  		 			J A Faria 		,  		 			E Henriksson 		,  		 			P Stare 		,  		 			Talmola 		.  	 	 		\textit{Proceedings of the IEEE}  		Jan 2006. 94  (1)  p. .  	 
\bibitem[Boni et al. ()]{b0}\label{b0} 	 		‘Multimedia broadcast multicast service technology overview and service aspects’.  		 			A Boni 		,  		 			E Launay 		,  		 			T Mienville 		,  		 			P Stuckmann 		.  	 	 		\textit{5th IEE International Conference on 3G Mobile Communication Technologies},  				2004. p. .  	 
\bibitem[Hefeeda and Bhargava (2003)]{b2}\label{b2} 	 		‘On-demand media streaming over the internet’.  		 			M Hefeeda 		,  		 			B K Bhargava 		.  	 	 		\textit{9th IEEE Workshop on Future Trends of Distributed Computing Systems (FTDCS 2003)},  				May 2003. p. .  	 
\end{bibitemlist}
 			 		 	 
\end{document}
